Praise: The Worst Feedback You Can Give Developers?
February 15th, 2010 | Posted in blog 8 Comments »
Lately I have been logging a lot of bugs in JIRA, our bug-tracking database. In one day I logged 25 bugs. This past week I logged about 60 overall. It feels good to log bugs. I feel like I’m finding valuable gaps in the application where code simply isn’t working.
Despite these benefits to the project team, in a recent triage meeting with the lead developer, as we discussed the bugs that needed fixing, it looked like the world was on his shoulders. I realized that developers like to hear about bugs as much as writers like to hear about typos and grammar errors in their writing. With many of the bugs, the developer would softly say, “Okay, we can look into it.”
It made me wonder. If developers only hears about bugs, problems, quirks, errors, and other issues, where’s the motivation to code?
In a recent post on Joel on Software, Joel Spolsky stresses the importance of giving positive feedback to developers, not just negative:
A great tester gives programmers immediate feedback on what they did right and what they did wrong. Believe it or not, one of the most valuable features of a tester is providing positive reinforcement. There is no better way to improve a programmer’s morale, happiness, and subjective sense of well-being than a La Marzocco Linea espresso machine to have dedicated testers who get frequent releases from the developers, try them out, and give negative and positive feedback. Otherwise it’s depressing to be a programmer. Here I am, typing away, writing all this awesome code, and nobody cares. Boo hoo.
In other words, programmers need both positive and negative feedback on their work in order to grow. But when I’m wearing my testing hat, all I’m finding are problems. This doesn’t work. This looks out of alignment. This lookup field is returning the wrong results. This button doesn’t respond when I edit the item. This page isn’t styled like the prototypes. This modal takes too long to appear. When I click this button twice, the rich text editor blows up. And so on.
Logging 25 bugs in one day was sadistically fun in the moment. But in retrospect, especially during the triage meeting with the developer present, the weight of the bugs was like sin on a priest’s back. Every new bug I added seemed to make his heart beat faster into anger or slower into death.
I’m sure that developers like to solve problems. So it’s not as if problems are necessarily depressing in themselves. But as I’m logging bugs in the bug-tracking system, there’s no way to balance out the negative with some positive praise.
A few days ago, near the close of the day, I was investigating a complex scenario in the application I’m documenting. It was a new feature we built into the application that added a level of sophistication the previous version lacked. I thought I would discover a bug, but instead the application worked beautifully. Elegant, fast, and clean. I stared at the screen for a minute, in awe at the neatly arranged display of information. This is perfect, I thought.
But there was no where to log my praise in our bug tracking system. Apart from the occasional iteration meeting where we demo new features, there is no built-in mechanism to provide positive feedback to developers. I was the last one at work that day, so I just went home.
A System of Positive Feedback
Exactly how could I implement a system of positive feedback for developers? Would it be a waste of time? Do I fire off an email now and then? How do I even know which developer coded the page I’m looking at?
The next day I decided to ask a developer who sits next to me: “If all you ever see are problems and bugs, and you never see the praise, how do you stay motivated? Don’t you need a balance of both positive and negative feedback on the work you do? JIRA only allow us to give you the negative.”
He thought for a minute. At first he acknowledged that he did receive occasional user feedback from both users and the project manager (the project manager has an especially encouraging attitude). The developer also explained that he gets to work on an application that matters to him personally, which is a reward in itself. But then he paused and thought a bit more.
“I think at some point you have to find your motivation from within yourself,” he said. “Sure it’s nice to hear positive feedback, but that’s not ultimately what keeps me going.”
Praise as Manipulation
He’s exactly right. In fact, a system of praise might be the worst feedback you can give developers. According to Alfie Kohn in Five Reasons to Stop Saying “Good Job”, telling your children “good job” can distort their intrinsic desire to do an activity to a desire for the “good job” praise. Kohn writes,
The more we say, “I like the way you….” or “Good ______ing,” the more kids come to rely on our evaluations, our decisions about what’s good and bad, rather than learning to form their own judgments. It leads them to measure their worth in terms of what will lead us to smile and dole out some more approval.
… “Good painting!” may get children to keep painting for as long as we keep watching and praising. But, warns Lilian Katz, one of the country’s leading authorities on early childhood education, “once attention is withdrawn, many kids won’t touch the activity again.” Indeed, an impressive body of scientific research has shown that the more we reward people for doing something, the more they tend to lose interest in whatever they had to do to get the reward. Now the point isn’t to draw, to read, to think, to create – the point is to get the goody, whether it’s an ice cream, a sticker, or a “Good job!” …
In short, “Good job!” doesn’t reassure children; ultimately, it makes them feel less secure. It may even create a vicious circle such that the more we slather on the praise, the more kids seem to need it, so we praise them some more. Sadly, some of these kids will grow into adults who continue to need someone else to pat them on the head and tell them whether what they did was OK. Surely this is not what we want for our daughters and sons.
In other words, as soon as you start praising your children, they seek more praise, so that instead of doing an activity out of the pure enjoyment of it, they do it for your praise. Your praise has begun to manipulate their behavior. When the praise stops, the children lose interest in the activity.
In the developer scenario, implementing a system of praise might similarly diminish the intrinsic motivations of developers. It would manipulate the pure enjoyment they feel when they solve problems, figure out solutions, and conquer cryptic, seemingly impossible scenarios. If you begin patting developers on the back each time they do something right, soon their motivation switches from internal rewards to external praise.
Not Just Advice for Children and Developers
The other day I was eating lunch with some colleagues. One of my colleagues said he was interested in starting a blog, but wanted to know what to do when he publishes a new post and only hears crickets. In other words, what do you do if you write and no one provides any feedback? If no one says, Good job, Tom. Way to go, Tom. Excellent post, Tom. I loved reading this, Tom. Then what do you do? What happens if all you hear is silence?
When silence is all you hear, you have to find an intrinsic motivation for writing. You have to write for a higher purpose, more than simply writing for feedback and praise. You may find yourself writing because you love story, or because you enjoy thinking about ideas, or because you like playing with language.
Comments may provide short-term feedback about the effectiveness of your writing. But in the long run, “good job” comments are detrimental to stoking the writing muse. The day the praising comments stop, your motivation wanes.
So now I’m back to logging bugs, but this time I do it without feeling mixed about where to log the praise. I’m not against giving feedback to developers about the application interface and functionality. Analytical, reasons-based feedback isn’t detrimental, because it helps people evaluate their work from another perspective. But when I have nothing to say besides “Good job here,” I’m witholding my comment.
Sponsors
Tags: bugs, developers, feedback, jira, praise, SMEs, Technical Writing
If you liked this post, keep updated with new content: Subscribe to I'd Rather Be Writing.
Both comments and pings are currently closed.

















3967 Subscribers

I think the best thing to do after a job is to give positive and negative feedback. well honesty is the best thing. Thanks for the article
I was going to say nice article, but….
Seriously, though, as a parent and a programmer, I appreciate the points you brought up (although I can’t say that I would find myself attacking bugs with glee, ferocious or otherwise – usually that late into the project, I’m just wanting to attack my own head).
Now if only you’d given an alternative solution to saying “good job!” when your 3rd grader is proudly waving his 100% spelling test in front of your face. “I’m very proud of you but you need to work on your penmanship,” was the soul-sucking “praise” my little brother got the first time he got a good spelling score.
When my kids set the table for dinner, rather than saying “Good job,” she says, “Now we can all eat!” So maybe with the A grade on the spelling test, rather than say “Good job,” you could say “With all these words under your belt, tou’re on your way to becoming the next JK Rowling,” or something. Kind of hard there, I know.
Mr. Johnson,
While I agree with your premise, and with the obviously well-researched underlying analogies, I would like to add that there are ways to provide positive feedback. In reference to the instance you mention where you found a feature that “worked beautifully”, perhaps a mechanism could be developed that allows you to respond by saying something such as “this feature worked very well by allowing me to do …..”. A response of this nature not only gives a positive signal, it is also a way to reinforce the work done and to verify with the developer that you are utilizing the feature in the manner intended, and that the results you see are the same as what the developer saw.
This works in a similar fashion when a parent changes a “Well done!” compliment to something such as “This is great writing…where would you like to go to continue this story?” Or, “What makes you proud of this….” and so forth. Turning the simple positive feedback into something the receiver can respond to, either internally or externally, changes the whole impact – the receiver is actually forced to look at their work, think about it and verbalize their own thoughts to themselves or to others. Now they are acting upon, or reacting to, their own feelings, not just to acclaim from others.
I agree with Aaron Taylor’s comment. Kids (and developers) can tell the difference between empty praise, which is what I think the quoted article is railing against, and genuine approval. I think if you find out which developer coded the feature that delighted you, you should tell him so.
I believe that parents and others should not constantly praise children for everything they do, regardless of of their effort and results. Some parents go to the other extreme and never approve anything their children do, and inhibit those children’s abilities to develop good judgment and self esteem for the opposite reason. Parents should acknowledge their children’s efforts, and thank them when they do their chores, and express genuine approval when they do something outstanding or unexpected. And the discussions and praise should evolve as the children grow from toddler to teen to adult.
Everyone appreciates a (real or virtual) pat on the back, especially when it’s deserved but unexpected.
This post made me to think a while. I feel giving positive feedbacks wrapped up with an appreciation is not an evil.
I agree with Margaret’s points. Worst thing in this competitive world is being Unrecognized. Even nowadays, technical writers are unrecognized in few situations. Let me know how many project managers appreciate the documentation team for their work during a product release.
I feel few parts of this post contradict with your earlier post – Cures for the information exclusion complex. I am sorry if I am wrong.
I dare to say another good one Tom.
As the saying goes, “There’s a time and place for everything,” and I’m not sure any ordinary day is the right time to file 25 bugs. Doesn’t your company schedule bug bashes at key milestones? If not, you might want to suggest it.
We don’t really have bug bash sessions, but that’s a good idea. Thanks for suggesting it. As products near release, we are encouraged to scour it for bugs, but usually at that time everyone is so busy with their own role that the bug bashing doesn’t really happen.