May 22, 2009
There's an inherent paradox in motivating programmers. I think this Geek Hero Comic illustrates it perfectly:
It's a phenomenon I've noticed even in myself. Nothing motivates like having another programmer tell you they're rewriting your code because it sucks. Dave Thomas has talked about this for years in his classic Developing Expertise presentation, supported by the following quote:
Interestingly enough, a friend of mine (who is a quality control manager in a hospital) often makes identical statements in reference to doctors: Polite requests, coercion, etc. are useless at best and often detrimental. Peer pressure and competition are the key.
Don't try to race sheep,
Don't try to herd race horses
Yes, the use of the term sheep is mildly derogatory, but the general principle is sound: use motivational techniques that are appropriate to the level of developers you're working with. If you have neophyte developers, herd them with maxims, guidelines and static rules. If you have experienced developers, rules are less useful. Instead, encourage them to race: engage in a little friendly competition and show off how good they are to their peers.
Posted by Jeff Atwood
Giddy up! Thanks for the tips, will try them this week.
Someone funnier than me that I used to work with described our Operations Director as taking a carrot and stick approach to motivation - except that the carrot was really big, and he'd hit you with it.
I strongly recommend that you read The Psychology of Computer Programming by Weinberg and please, please, please do not espouse this kind of stuff. As a hiring manager I would never want to hire a programmer who is so proud of their code that somebody rewriting their code motivates them. There is a very big difference in "taking pride" in your work and "being proud" of your work. I will take the former any day and shun the latter any day. Most projects are about team work and rewrites are a fact of life. I would go so far as to say the if you are not rewriting/refactoring your code, you are missing something big that will come back to bite you.
If you want to motivate a programmer, understand that if the programmer cannot find something in the project that appeals to them, you _will_ not get 100% from the person. Programmers IMO need to be challenged, but with tough, new or complex (not the same as tough) problems not by appealing to their egos and touching off an internecine war. Part of their work needs to be in an area that they are interested in. They need to have the flexibility to work when they want where they want (within limits of course). Provide them the resources required to get the job done and learn at the same time. Some form of free food also helps. If they still need extra motivation maybe its time for an honest conversation with them as to what they want to do and why its not working.
Just my $.02
AM hit the nail on the head here. I'd also add that these sorts of competitions can be demoralizing - in the end, someone is "wrong". If all developers can come at an effort with humility, they'll understand that no code is perfect, and there are often many ways to solve one problem.
If somebody comes to me and tells me that they've found a problem with my code, I'm grateful, and ask them to show me the fix so that I can understand where I went wrong and not repeat the mistake.
In any of the teams I've worked in, the programmer in the comic above would be the first against the wall when the revolution came.
I've run competitions in our office several times to create the "best" and most optimized code for a task and I won every time (note: there was no particular experience bias in the competitions)
Is the conclusion I should sack everyone else and write it myself?
Your right that some competition encourages better code - but I think that a better approach is a few good coders who will "get there in the end". Because the finished product is inherently better and more complete.
Bullshit. Rules are also good for exp. programmers. Yust because a programmer think hes good, he should not leave the path of rules. It is yust a lousy excuse for people who are to lousy at coding to follow rules, do comments rigth and so on.
A some more bullshit for programmer who cannot follow rules or do comments the right way. There is nothing like an experienced programmer who should not follow rules. That are the bastard which code cannot be read a while later (even by themselves) and therefore not mantained.
AND THIS FUCKING VERIFICATION THING BEYOND SAYS FOR 1 COMMENT tHAT THERE ARE TO MANY COMMENTS. LOUSY BULLSHIT.
Ah...after a while the comment is shown even if the message is to many comments. sick. what are ropolitan bonitoes? #somtehing to eat?
As some have already indicated, that depends on what "flavor" the competition in your group/office is. It is strongly tied to what flavor (if any) of "teamwork" and "management culture" you have. When you have a culture of collaboration, the competition will be focused on contributing and helping others or "the team"; when your culture emphasizes "leadership" (and especially when that is attributed based on "visibility", posture, and verbal claims), this will foster domination by the most competitive and backstabbing jerks, and people who are not of that description will tend to drop out of the competition, or even withhold their "normal" level of contribution.
The use of peer pressure as a deliberate "performance management" tactic (as opposed to leaving it at the (healthy?) level to which it grows "organically") almost always correlates with the latter - bullying, poseurship, mediocrity, and politics.
.. hm.. lets see if it can make some sense:
Association to fillip: Shakespeare:
What is this?
Your knees to me? to your corrected son?
Then let the pebbles on the hungry beach
Fillip the stars; then let the mutinous winds
Strike the proud cedars 'gainst the fiery sun;
Murdering impossibility, to make
What cannot be, slight work.
That verification game below is funny.
Remaining removal - take out the waste
I never obeyed rules, I always left office before everyone else :-D
I also agree with AM -
You want your team members to be motivated to help each other, and competition sort of kills this off.
All you need for a motivated programmer is a positive work environment, a manager that doesn't micromanage, and an interesting task :)
Apologies @AM, but that sounds like load of pointy-haired hogwash and bollocks.
"As a hiring manager I would never want to hire a programmer who is so proud of their code that somebody rewriting their code motivates them."
You propose hiring people who dont care that whatever job they just did is so inadequate that it must be scrapped & redone?
"There is a very big difference in 'taking pride' in your work and 'being proud' of your work. "
How can you take pride if you arent proud of your work? The semantic difference you're slicing hairs over isnt nearly as obvious to me as it seems to appears for you; what exactly is the difference, please explain.
". . . rewrites are a fact of life. I would go so far as to say the if you are not rewriting/refactoring your code, you are missing something big that will come back to bite you."
I'm more receptive to this, but rewrite has very different meaning than refactor. Sometimes yes even rewrites are necessary, but there'd typically better be an epic story about changing requirements or extreme hardships encountered (or egregiously crappy code; code that qualifies as _dangerous_ to a project). I expect an awfully long retrospective when the word rewrite is raised.
Refactors should be continual, but refactors are usually related to bringing different bodies of code better in to alignment, rarely about fundamentally changing the way code is working: lessons learned + code improved type situations, and algorithmic changes only when trying to adapt to different patterns.
Awwwww,... did you change your beloved and mind intriguing orange captcha because of peer pressure?
I kinda miss that orange captcha.
“Nothing motivates like having another programmer tell you they're rewriting your code because it sucks.”
Maybe I’m not a typical programmer, but I find someone telling me my code sucks is the opposite of motivational. In fact, wasn’t there some research suggesting that “bad apples” like this could reduce team performance?
I typed "orange" and my post got rejected!
..or you could try treating them like human beings..sheesh.
Rules are to be followed until you know _why_ they're rules and when it's appropriate to bend, twist, or outright break them.
There is no such thing as friendly competition. Judging each other and ourselves is useless. Stop promoting it Jeff
I wouldn't know. Nobody has ever rewritten my code while I was still there. (Except me. And I hate that.) :-)
Whoa... When did you get rid of the "Orange" captcha? I kinda miss it.
Interesting post. I wonder which I am?
Rules are fine, so long as you understand and agree with the reasoning behind them. Few things are as useless and discouraging as are rules seen as arbitrary - "use the new coversheet for your TPS reports"...
Friendly competition is fine, so long as it stays friendly; let it get out of hand, and watch cooperation disappear, as each team or each team member begins to view sharing information as a liability.
Orange is no longer the CAPTCHA, eh? Well i for one welcome our youngest dormice...
It cuts into your sovereignty as a programmer.
Best post here in a long while. I was beginning to despair.
Anyway... looks like "orange" is no longer good enough.
I agree, and I would say more, if it wasn't for the more pressing matter - are you going to write another version of the orange article now?
Now you've pointed this out no self-respecting programmer is going to obey rules because that would make them a sheep.
I'm definitely a racehorse. :)
Shouldn't you try to motivate them before they write the code, not after?
Competition does motivate me, but telling me my code sucks is simply stating a fact I already know. At the end of a software project I'll know far more about the problem domain than I did at the beginning, so any solution I programmed in the past sucks compared what I could do in the present.
Sorry, but what a load of rubbish.
If your programmers need those kinds of shallow tactics to produce code, your methods are wrong; your management sucks; and you most definitely have the wrong programmers. They should be proud of every line they collaboratively produce, not constantly looking behind their backs.
It works on me, that's for sure. I don't really get offended by it though (although, depending on WHO is going to change it, sometimes I worry that they will just BREAK it).
Haha... I'm still in college, but I'm in the second (competitive) group - it always throws my friends off when I let that side show...
"Best post here in a long while." Agreed. I laughed, I felt enlightened. Awesome.
I recently gave in with a co-worker producing ridiculously amateur code, and have given up the "lets see what we can do to improve your coding" game and switched to the "rewriting from scratch the last week of code in 2 hours" plan. While there may be merit to threatening to rewrite someones code, actually having to do it is horrible and I would not recommend it unless their code jeopardizes your project. Its akin to having people on the team slapping each other in the face, and its not a pleasure for either party.
My verification CATPTCHA is "waste of": thats somehow fitting.
this post reminds me of the games we used to play at school. those of you who remember turbo C know that it was/is extremely unforgiving. instead of competing against each other we would see who could sit down and type a program form start to finish, compile it and have it run with out a single bug.
of course some malicious moron (Mr malice) on the team would type a letter, symbol or the number zero into your program just to break it which also taught us to "idiotproof" our programs.
then that lecturer at university with his day one motivational talk. "hello all, I'll be taking you in C. not all of you will be here at the end of the year. it is not your fault. they call me Mr malice, but that is okay..." most people hated him, some quit his class and a select few of us remember him with fondness now because they can write code. working code. the motivation, cajoling and competitions shaped me.
"they call me mr mallice, but it's okay..."
Rules are always needed at some level. Race can be harmful at some level even if it was meant to be friendly.
>> you have UML Specification of your project
If you have that, you have bigger problems than just motivation of programmers. You probably program in Java, you (mis)use Agile and TDD, and your software is overengineered to hell. Your developers regret they were ever born, but come to the office for the paycheck, and pretend they're working by coming up with more UML, unit tests (that don't test any failure cases), and Spring configuration XML files. It's kinda hard to motivate people in this environment.
This is definately true.
At a pevious job I was the sole developer on a project. It was good but I was managing everything so sometimes I would be more motivated to check mail and only do the bare minimum work in a day.
Until one day I was off sick and another developer had decided to change large, random parts of my code!
I was quite annoyed and just had to jump up and fix everything.
"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
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!
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 ...
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.
“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.”
I’m all in favor of constructive criticism, but I don’t think that’s what Jeff is arguing here. Rewriting someone’s code “because it sucks” is not constructive, and encouraging developers to “show off how good they are to their peers” is not asking them to shut down their egos.
"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."
I don't think that's anything to do with the improved captcha - I used to have to do that with the old orange method.
Personally, I’d like to congratulate Jeff on finally fixing the captcha. Now if only he could fix the other problems with comments, such as adding threading, or at least numbering comments.
Agreed! Numbering comments would be an improvement.
"but the person rewriting it is not smart enough to understand it or even work with it."
That's pretty much my definition of "this code sucks".
Internal competition has to walk a fine line between in-fighting/insecurity and promoting an enjoyable/learning atmosphere at work. Anything that destroys cooperation within your software team is going to be detrimental at some point.
Heh, I thought this was going to be a variation on your other post: how to demotivate programmers (http://www.codinghorror.com/blog/archives/001205.html): by rewriting everything they produce, "to make it more clear". I can testify first hand that that is devastating, I've had it happen to me.
Where I work the notion of code "ownership" is an officially sanctioned, strictly enforced policy ("thou shall not touch my code or you shall be piunished). I cannot convince the management that it is a counterproductive practice so I learn to live with it.
And here I get something unexpected. Based on the comments above, I conclude that officially-sanctioned "code ownership" is not such a limited practice as I thought. In fact, most commentors seem to accept it as quite natural.
I am very (unpleasantly) surprised. Was I wrong in my beliefs?
Jeff I don't think you have any basis for this argument I know best you don't get out
Hey, great post, and I'm glad to see a popular site using "reCaptcha". It's a great example of killing two birds with one stone.
Fight, slaves, fight!
Fight, slaves, fight!
Fight, slaves, fight!
I just wanted to say Jeff, this was a very timely post. Keep up the good work!
And somehow developers rise to say designers are prima donnas, vain people who can't stand criticism...
I'm licensed to say that, since I'm of both sides of this. : )
But an interesting thing to notice, nonetheless.
The irony is that this really is true, even when we know our code is not the fastest written...How DARE they improve my algorithm?
If you refresh enough you are likely to still see "orange." :D
(And you might win the lottery too)
Bad analogy. 'Racehorses' are herd animals:
so... you absolutely can 'herd racehorses.' In fact, you herd these horses any time you let them wander the pasture, or lead them into a stable.
If you race a horse 100% of the time, you'll only wind up with a dead racehorse.
Cooperation and teamwork both are well and good, but when bonuses and promotions often are geared to individual performance, they can be thrown by the wayside. If someone has family responsibilities, going home to the wife and saying, "I didn't get the raise, but I sure did work well with everyone" isn't going to cut it.
It's a competetive world, boys and girls. If someone isn't up to snuff when it comes to being able to do the work, it is doing a company absolutely no good to waste time getting them to a serviceable level. It's best to cut your losses and move on. Having someone who needs to have his code reviewed and rewritten constantly is worse than having no one at all. No one is perfect, but you probably can think of someone you've worked with who clearly wasn't good enough.
Ideals are great, but let's live in the real world. It's survival of the fittest.
Great post! Programmers need to 'race' in order to stay competitive. You need a few people in your organization who can make others 'race' and keep them not only on the edge of their seats but also on the edge of technology. I currently fulfill a role something akin to that in my workplace :) Programming is challenging and that's why we like it. Moreover, programming has a lot of challenge left because it is still largely an art. Every program can be made better from one perspective or another, and every time you 'race' yourself you become a better programmer.
Depends if you are self-centered and competitive. Some of the worst code I wrote in the .NET framework is being rewritten from scratch right now, and I couldn't be happier about that...
Microsoft does this and has got hit a lot more than it would admit.
Google, on the other hand, takes Grand Challenge type problems and asks their guys to cooperate, not compete. They dont fight each other, or peer-pressur-ize the office, they fight tough problems and do concept mashups to make new solutions to big problems. ( I'm not going into negative aspects of known Microsoft management strategies. )
The end of "The Era of Orange" ;-) seems like the end of Agent Orange! :-D :-D
But Rays of hope from The Mountains are still very tricky, as always...
ReCAPTCHA-ing the web isn't all that appealing for a *workhorse*, race horses may rightfully disagree.
Haha, CodingHorror readers are sitting in front of the their PCs pressing the refresh button on reCaptcha trying to get it to display the word "Orange"...
UPDATE: 'Practicality' beat me to it :)
I like the idea of using this on doctors. They are hard people to get to listen to you.
Rules are essentially abstractions. They're meant to encapsulate the details of some process so that thinking isn't required to carry out the process in a consistent way.
Since a rule is essentially an abstraction, it follows Joel's "Law of Leaky Abstractions", stated thus:
"All non-trivial abstractions, to some degree, are leaky."
Level 1 & 2 programmers can't identify the leaks. They aren't able to perform necessary re-evaluations of the rules to make them more robust and more performant. I work with many developers (some with 10 years under their belt) that are stuck at level 1-2. They lead teams of others, and their non-technical management just accepts their poor performance and chalks it up to: "Well, i guess that's just how long things take."
hahaha! Excelen joke, and it is true.
At my last job I had a coworker who didn't care about code quality, only that "it worked". Eventually, I tried something like this and got nowhere. Ironically he's now in charge of updating his own code, so he's starting to get it, but still seems to treat all projects as one off solutions he'll never look at again - despite being forced to look at them again.
On the other hand, I have no illusions of perfection, and want other programmers to review/improve my code.
I can't believe no one has mentioned the fact that both animals mentioned are motivated by threats in order to perform the behaviors they are associated with. The race horse has a small being at least a quarter of its size (presumably containing a quarter of its natural talent as well) sitting on its back whipping it to run in a circle. The sheep have to deal with a yappy little dog nipping at its ankles all day in order to be herded.
Count me out of being either...both possibilities sound horrifying.
@Jay: The company should have rules for programming. Also there should be code reviews in any case. Some rules could be enforced by automatic check runs.
If someone breaks the rules, he should correct the mistakes, not someone else. If the breaker doesn't correct, then he might get away with it, but others start to dislike the rule breaker.
All code should look a bit similar, not different. And there are many rules that are not just about style, for example normalizing the database to the third form. You can compete with others still, but there should be some minimum rules that should be followed. I mean if your company regards it good / obligatory practise to use some rule, then make the rule a rule, not a gossip. If you just gossip about how someone didn't follow a "rule" and therefore is worse than others, what good that gives?
Anyone is welcome to rewrite my code!
Just show me the money. Its the only motivation I need. YOu can have your reasons. Money works for me. It can buy whatever else I can think of.
i don't believe this applies to all coders..
some coders i've encountered don't even care what will happen next to their codes once they've seen it working.
they will even appreciate it if somebody modifies their codes! saves them the work.
Really, what you have written is a bit of a nonsense.
Motivation is a managerial issue and there are many different techniques to motivating individuals, groups and teams which applies to any profession.
Stick to talking about programming (because your 'About Me' section suggests you might know something about that) and leave articles on management techniques alone!
Shoot, must not show this at work otherwise they will actually force me to code again :)
Anybody notice that the guy in the bed is "Randall Monroe", rather similar to "Randall Munroe," of XKCD fame?
some coders i've encountered don't even care what will happen next to their codes once they've seen it working.
haha... so true!
I admit, the thought of someone ELSE redoing my code makes me a cringe a bit to myself, especially when it's something I've been working long and hard at.
It was a very nice idea! Just wanna say thank you for the information you have shared. Just continue writing this kind of post. I will be your loyal reader. Thanks again.
Just show me the money. Its the only motivation I need. YOu can have your reasons. Money works for me it can buy whatever else I can think of