“You’ll turn into Jeff Atwood if you don’t do your work!” That’s how I would motivate my programmers.
Help - I can’t read this Captcha!!!
Seriously though, the most motivating thing I have seen is having developers’ code peer reviewed at scheduled meetings. This allows “star” developers to educate others, and seems the best way to facilitate knowledge sharing. Just don’t leave the meeting until the code is completed, then you just come up with a lot of frustrating “you should have done XYZ”.
I’ve never found competition successful in IT, people in IT tend to be the most un-competitive people I’ve met, and the fact another developer is editing their code just leaves them smirking with a wry smile as if to say “gool luck sucker”.
Great blog, think everyone has experienced the motivation of code being discredited as bad.
What de-motivates me are managers going on about hard work, bonus schemes and teamwork while their ‘plans’ are a series of guesses that are presented as ‘deadlines’.
@gadthrawn: chill and desist
@AM: ++1
@jeff:
Erm… my condolances for getting even more agitated responses for ditching orange then before… I’m pretty sure I was I was solid in the fron rows of that peer-pressure faction hehe
Anyways, as ever, you can expect the fuss to die down with time (as the surprise gets forgotten) and there is reason to assume there will be less residual croaking on the topic of captcha, since, well, erm… it is simply less broken.
To be fair, I miss the oranges as well. May I suggest
Behold the correct word:
Or perhaps make it disabled to prevent it getting the focus (or you’ll still get flames :)).
Disclaimer: my HTML stems from the Gopher era. Plus it hasn’t been exercised since the Gopher era.
Apperently “no HTML” does not imply “plaintext” as I assumed:
label for=“orange” Behold the correct word: /labelinput name=“orange” id=“orange” value=“orange”/
Also: s/fron/front/, s/then/than/
Having “orange” as the captcha was never going to work for long. reCaptcha’s a good step up.
The most memorable quote from my programming days in college
after I complained how hard it would be to create bounding boxes in my ray-tracer… my friend said to me:
“Oh, well, I think I could do it in about an hour”
The race was on!
-Orange
Ditto to AM’s comments. Plus, why wasn’t the problem caught during the code review before it was baselined? Did testing or operational use determine that the system wasn’t meeting its response time specifications? If so, was an analysis of the system done to pinpoint Randall’s code as the code that should be changed to fix the problem? Or, is this a case of premature optimization?
I’m an engineer on the reCAPTCHA team – it’s great to see reCAPTCHA on codinghorror.
@rektide – We believe that CAPTCHA’s shouldn’t be a “waste of” time, which is why one of the words is from an old book or newspaper which we’re helping to digitize.
@Andrew – The phpcaptcha.org captchas are all fairly trivial to break, they use color in such a way to make breaking the CAPTCHA much, much easier. None of them present any challenge in segmentation, and some are probably harder for color blind users. Sadly, there are a lot of CAPTCHA implementations out there which have not undergone proper usability and security testing.
The logical extension of this is that no developer works on any part of the code for any significant period of time without handing it off to another team member. Period. No exceptions. If you’re using pairs, then substitute “pair” for “developer”.
To start, I suggest a time period not greater than 1 week. That should be more than enough to get the code working, or improve it, or fix any bugs assigned to you. And if it takes longer than that, the next developer in rotation will take it up.
The benefits should be clear. Developers will be forced to either document their code or communicate with one another. The bad apples who can’t communicate or can’t write maintainable code will become painfully obvious to everyone, rather than being able to hide in the shadows or bury incompetent work. All the code will eventually rotate through every developer, so familiarity will be widespread. All the code will also be reviewed by every developer, and if bugs can’t be immediately fixed by one, they will be annotated in the source. Furthermore, because no one person controls any part, the overall team morale will organically support the team as a whole and the product as a whole, rather than being divided into petty fiefdoms and isolated areas of alleged expertise.
Sounds great, doesn’t it?
So ask yourself why reality doesn’t work that way.
I’m OK with someone telling me my code sucks. If he can tell me WHY.
I agree with Jeff. Not so long ago a senior developer I deeply respect, was looking at my code and mumbled something to the effect of “how can people write something like this?”
The result was that I refactored my code, and made is smaller, faster, more modular. A hurt pride does wonders.
And people, stop acting like prima donnas - chances are you aren’t the best, and constructive criticism and competition are here to help you. Shut down your egoes for a second, use your brains.
The other side of the coin that I’ve seen is when other developers try to rewrite someone’s code cause ‘it sucks’ when in reality, that code is great, but the person rewriting it is not smart enough to understand it or even work with it.
Heck, I’ve even been guilty of this, only to find out later after many trials my code is approaching the code that I am trying to rewrite.
I don’t get it. What’s the paradox? hm … ok, cool, whatever.
@James: I think that is crap. Many programmers think they know why and when to break rules. But they don’t. If you work in big project breaking style or programming rules is counterproductive and making other programmers extra work in “fixing” the bullshit to standard format when maintaining the code.
My experience says (or better: screams out loud) that the experienced programmer you mentioned are the ones which does not follow coding guidelines, does not comment code, does not know what there codes does a year later (and also have no longer the domain knowledge) and much much worse: Do not follow specification documents and not give back feedback where they “twist” it. Then you have UML Specification of your project, and in some parts quite fast lacks where a stupid coder thinks he knows better. Normally this types of programmers change projects so fast that they never now how much money they burn.
And oh, i’ve a “dogmatic dignity” … if you think about the captchas, they try to make sense
As long as there are developers who think:
It cuts into your sovereignty as a programmer.
There will be the need to motivate developers. You’re not a frakkin country. Not checking in to source control may be the equivelant of borders, but when you’re working on a team for someone else, you don’t have the right to go dark. Sovereignty.
So, I guess your next post will have to explain the advantages of reCaptcha compared to orange …
Hey Jeff,
I don’t know whether this ever happened with orange, but I had to do an extra reload after posting my comment because I didn’t show up the first time.