How to Motivate Programmers

There's an inherent paradox in motivating programmers. I think this Geek Hero Comic illustrates it perfectly:


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/05/how-to-motivate-programmers.html

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.

AM FTW.

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.

Association fillip
… 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 :smiley:

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 :slight_smile:

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?

http://www.codinghorror.com/blog/archives/001227.html

…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.