Just thinking out aloud - we programmers love all this voting/badges/rep stuff so could a scheme like this be introduced into a companies code review process to encourage better coding.

Something like

  • You (or others on your behalf) can post a review (could be snippet, single commit or series of) for a code review

  • Others can comment on it (would be similar to answers in SE)

  • Badges can be given/suggested (some would be good, some would be bad like "Comment Desert" or some such)

  • You can vote up/down on the code itself and the comments and badges (e.g. if someone suggested a badge and you did/didn't agree)

The aim of a scheme like this would be

  • Introduce a bit of fun to encourage the use of code reviews

  • Improve quality (in this scheme both code reviewee and reviewers are likely to learn)

  • Reduce the chance of code reviews sparking 'ego wars'

  • Give some metrics to help measure individual performance

Could this work? Thoughts?

  • 2
    Just found this site - StackExchange for code reviews - nice idea for open source/personal projects but its public for many companies its a non-starter codereview.stackexchange.com
    – Ryan
    Commented Jun 17, 2011 at 9:50
  • 5
    It sounds like it would be a good idea for a while but the only thing I would do differently is get rid of punishment badges. They carry a stigma and humility with them that will discourage those who are falling behind from trying to catch up.
    – maple_shaft
    Commented Jun 17, 2011 at 11:07
  • 1
    Its a hard one that. I think the brutal truth is that we can often learn more from mistakes (our own and others) than we can from successes. And for all the flowery hippy talk, fair punishments work. Ask your parents ;)
    – Ryan
    Commented Jun 17, 2011 at 11:12
  • 9
    The only problem is that Jon Skeet will always be sitting there at the top with 100k rep. Jon Skeet doesn't work for your company? Doesn't matter. He'll still be there. Commented Jun 17, 2011 at 11:28
  • 1
    Good point - maybe the "I checked a class in without a single line of comment" badge of shame should expire in a time or be revoked once you've done something positive - as otherwise there is no incentive to improve as you've already got 'the mark' and it doesn't matter any more
    – Ryan
    Commented Jun 17, 2011 at 11:57

7 Answers 7


Extrinsic reward such as money, badges or rep will work, short term, like diets and any other reward/punishment based system.

Intrinsic reward, such as purpose & autonomy should be used instead and provide more long term results. It's much more difficult to put it in practice than simple extrinsic reward systems, but it pays.

Many experts did research on the subject. Here are my two favorites:

Daniel Pink made a great presentation at TED on the subject that is easy to watch and understand.

Alfie Kohn, author of Punished by Rewards, wrote on the subject:

Sure, bribes and threats can produce temporary compliance. Offer a reward to adults for going to the gym, or to children for picking up a book, and it may work -- for a while. But they come to think of themselves as extrinsically motivated, so when the reward is no longer available there's no reason to continue. Indeed, they may wind up less interested in exercising or reading than they were before.

Another problem with rewards (and punishments) is that it will modify how people behave. For example if you give bonus to your employee, they will be focused on obtaining those bonuses, regardless the other (company wide) objectives. It will creates individualism and competition between departments and employees. Resentment will take place and everybody will watch everybody. Especially when one of your aim is to "help measure individual performance".

The rest of the employee may disprove the rules of the game and quit. Increased turnover will then become a new problem.

Please note that many suggestions on how to improve motivation have been made in this community.

  • 2
    Pierre, while I agree with some of the things you say and findings of Daniel Pink I don't really think they apply to the solution as he's described them. It would be different if rep, badges etc was tied to a monetary reward but here they're only used to enhance behavior that has an intrinsic meaning. In some ways it's no way different to the gaming aspects of stackexchange which one has to say has been beneficial overall. It's a complex issue though so it has to be implemented carefully
    – Homde
    Commented Jun 17, 2011 at 9:53
  • 2
    @mko: Money is a type of reward. Badges or reputation is another. I believe they have the exact same effect.
    – user2567
    Commented Jun 17, 2011 at 9:58
  • 2
    Pierre, I must disagree. Not only are these rewards purely idealistic, but also they are given to you not by your chieftain, but by your peers. Their acknowledgement is one of the most important reference points for ourselves to measure our mastery and the purposefulness of our actions. A system of votes, badges and reputation score only quantifies the feedback and condenses the loop. I mean, this is why SE works.
    – back2dos
    Commented Jun 17, 2011 at 10:25
  • 1
    Pierre, I really recommend you read Daniel Pinks Book "Drive" it goes in depth on incentives and motivation. There's a lot of examples where a monetary reward was actually detrimental while an intrinsic reward wasnt'
    – Homde
    Commented Jun 17, 2011 at 10:36
  • 1
    yes, but of if a badges,rating is a good measure than that will serve to highlight and drive behavior towards intrinsic rewards. I.e I might not care that much about my actual reputation but I do want to be a good developer. Therefore the rep might be a good to if not measure my absolute skill, measure by relative progress and motivate me to improve it and myself. The things we can't measure we can't change. The difficult part is of course designing the measurement to actually have some meaning and encourage the right behavior.
    – Homde
    Commented Jun 17, 2011 at 10:49

Yes, it could

But only if you design it very carefully, otherwise it might backfire. I've make some comments but thought I'd summarize my position

For reputation the main objective should be to provide a measurement that employees can use to track their skill improvement over time. Design it very carefully with that in mind, the hard thing is coming up with good ways to measure skill, I can't from the top of my head do that.

Badges is mainly a "fun" thing, I'd keep them mainly away and away from more skill-oriented issues. Ie badges like "this weeks night owl" or a group "Shipped! badge" would be ok. If you have some skillbased badges like "Fixed most bugs" or "Reported most bugs" think very carefully on how that might be perceived and gamed. Badges should be more about highlighting behavior than promoting it IMO. Be sure to have both team and individual badges.

I'd strongly recommend against negative badges, these things should be fun and making people afraid of making mistakes is dangerous. Generate a friendly helpful email for those cases instead.

I'd strongly recommend against letting them decide and vote on badges. People can send in their suggestions for badges but since their effect on people can be pretty severe what badges are used should be made by careful decision of a person who knows what they're doing and not majority vote.

Code reviews is an interesting idea and I guess one of the ways you could generate a skill value. Highlighting code and discussing it could be really helpful. However, it might backfire, if everyone knows they're being judge on potentially everything they write development may slow to a crawl. Especially with iterative development where you sometimes write something quickly and then refactor you don't want that behavior.

Perhaps that could be offset by either the person submitting code themselves or someone else only being able to submit code of a certain age. Nevertheless it can be tricky knowing what effects there'll be

I the end I think you'll have to try it and see what works and what doesn't, there's good book called Reality is broken that might be interesting. Also Daniel Pinks book "Drive" is a must-read.


In my opinion, NO, as it measures not the good practice itself, but a symptom (if others think it good practice).

To paraphrase a book by Uncle Bob (forgot the title): Good code seems almost effortless, it makes the problem look trivial, as if the language was made for writing it.

In my expericence, such code goes unnoted, and only after a long time it comes to attention, that this code never made problems, and maybe then one remembers, that the problem was, before the introduction of the code, a huge mess of uncertainty and vagueness. The code that gets praises in reviews is typically the one that the reviewers look upon on a good day when not in the mood to nitpick, and that has the fewest changes.

  • 1
    Erm - re: your first point - yes but thats the best we have isn't it? Code metrics don't give a good enough picture on their own.
    – Ryan
    Commented Jun 17, 2011 at 10:13
  • 1
    Isn't that true for any kind of code review method?
    – nikie
    Commented Jun 17, 2011 at 10:36
  • The problem is imho not that you try to measure it, but that you set a feedback loop between your measurement and, in effect, the teams motivation. In my experience, this leads quickly to motivating the team to 'beat the tests', not code better.
    – keppla
    Commented Jun 17, 2011 at 10:57
  • 1
    "Beat the tests" is much more applicable to metrics than manual code review. To take your 1st argument to the extreme you're saying that there is no way to ever decide anything is 'good'. Well thats true but at some level we've got to accept that if enough people think something is good, then it probably is good.
    – Ryan
    Commented Jun 17, 2011 at 11:07
  • 1
    +1 for the 2nd argument tho - great code may go un-noted.
    – Ryan
    Commented Jun 17, 2011 at 11:08

The idea would bring a new dynamic to the team. If you feel the team is in a rut then this is a good way to shake things up.

Just remember that it will not be all unicorns and rainbows. Some are not going to like the initiative so overall productivity/quality may suffer. However this risk may be worth it. Depends on your situation.


I suggest using extrinsic motivation (what you're proposing is a form of extrinsic motivation) to motivate people to do things that are "mechanical", repetitive and boring, such as:

  • Showing up on time to meetings
  • Getting timesheets submitted on time
  • Updating documentation
  • Sharing information with the team

I wouldn't use it for motivation on any type of work that requires creativity, or where quality can't be measured objectively. For instance, if you have a person making widgets and you can mechanically validate whether a part is good or bad, and you have a process that won't allow a part to be made unless it follows the approved process, then it's productive to motivate the worker with extrinsic rewards for productivity because the process won't allow them to take shortcuts to make more units at the expense of quality.

If you don't have those safeguards in place, then your attempt at extrinsic motivation will surely backfire. Programming falls squarely in this category - we just can't reliably measure software quality. That's because when you make a widget, it leaves the factory and doesn't affect the work you do on the next widget, but when you make software, you have to keep reworking it over and over. Stuff you do now has long term effects. It's these longer term effects that are very important but can't be measured. Intrinsic motivation is a much more useful motivator for this kind of thing.

That means:

  • Let people take responsibility for their work
  • Encourage people to talk to each other about what works well, and what doesn't
  • Show genuine appreciation for peoples' work
  • Wouldn't some sort of internal SO do all three of those things, I mean why do people devote so much time to SO? And the point about 'voting' is that I think its much more likely to be fair, accurate and valuable in a field like this because I totally agree - we don't have any good non-objective way to measure quality.
    – Ryan
    Commented Jun 18, 2011 at 13:28

Part of what makes this work is the large number of participants who do not know each other or have to work with each other daily. I would think that in a small group, it would become more a way to game the system to look good or to make your competition for promotion look bad. This is why formal peer evaluations are often a poor system. In a small group the people with the best rep will be those who are the most politically astute not the best programmers.


The short answer is, yes, it could work.

The slightly longer answer is, yes, it could work, but it could also backfire.

In addition to being a professional programmer, I'm also an amateur behavior analyst.

One of the signature findings of modern behavioral science is that behavior is strongly influenced by its consequences.

If you control the consequences, you can influence behavior to some degree. The degree depends on how important specific consequences are to each individual whose behavior you're trying to change, and on how easy it is for them to avoid your consequences and find others that they're willing to work for.

As a professional programmer, one consequence of writing code is that I get paid; stop paying me, and I'd stop showing up before long. Pay is a really important consequence to me (I'm raising a family), and there aren't any other consequences at my present company that I'd be willing to work for instead of being paid.

If you were my boss, you'd get to decide what consequences (incentives, reinforcers) to offer me. But you don't get to decide how I perceive them. For example, my boss might decide to offer a special parking space if I'm selected as "Coder of the Month". If I lived in San Francisco or New York City and I drove a car, I might be willing to work for that. But where I live now, parking isn't a problem, and I can walk to work anyway.

In my experience, the biggest risk you run with implementing a program like SO in the workplace is that you might be perceived as offering peer votes in lieu of paying people what they're worth.

  • "One of the signature findings of modern behavioral science is that behavior is strongly influenced by its consequences." Thats a finding? Really?? Isn't that something we all learn very early on in our life? Dont touch hot things cos the consequence is it hurts! Mind you I still drink too much sometimes...
    – Ryan
    Commented Jun 18, 2011 at 13:25
  • @Ryan: You'd think. But "don't touch hot things because it hurts" doesn't make a science. Showing how to make changes in behavior measurable, repeatable, replicable, and predictable--that's what makes behavioral science a science. Commented Jun 18, 2011 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.