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.
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."
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.
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.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.