Don’t Play Hurt «

Code: , , ,

I love the c2 wiki. At least once a year I’ll dive in for a day or two and read a swath through its accumulated wisdom. As I learn and experience colors my perspective, I always find new things.

One of the most important articles I’ve read on the c2 wiki wasn’t about a programming technique. It was PlayHurt. The core debate of the page is whether software developers can produce good code even when their hearts are not in it. Because development is a creative mental activity, it’s profoundly affected by the developer’s mental state. When I first read the page, one comment on it really caught my attention:

Is it possible that few of us have ever done anything but programming for a company while playing hurt? Companies seem to put most programmers into unproductive situations most of the time. Without properly supporting a technical developer, then developers PlayHurt and probably fail (the 95% of software projects fail rule again). For example if the marketing is not in place and we don’t have and never will have any real customers then we are playing hurt no matter how good a job we do on the code.

I was working on a product that was unrelated to the rest of the company’s business. It had originally been built in a hurry by inexperienced developers in an unfamiliar language, and no one inside or outside the company had a complete understanding of the product (self included). The CEO set the goal to increase sales 10,000% percent by the year’s end without creating a marketing budget (10% growth would have been lucky). The company culture was built around churning recent college graduates, so there were low standards and no professional criticism.

I don’t often read things and think they speak exactly to my situation, but that comment sure did. It put a name to what I was feeling. I felt terrible because I didn’t understand why I didn’t want to go to work in the mornings and why I had to push myself to fix every bug and complete every feature. I didn’t have the perspective or experience to recognize all the things I just listed that had gone wrong, so I felt like a failure because I couldn’t develop on command. I found some of that understanding on the wiki. I couldn’t Play Hurt anymore. I was just plain tired of being hurt. I quit that month.

If you want to write good code, you can’t play hurt. If you want to be proud of your work, you can’t play hurt. If you want to feel you’re making something of your life, you can’t play hurt. The best work is powered by passion and meaning, not obligation. Play hurt if you’re getting through the occasional frustrations that every job has, if you need to pay the bills, if you’re setting up someone you like to do motivated work. But don’t play hurt if you can avoid it. Find something you love. Create something meaningful. Encourage an environment that allows people to work at their full potential. And take risks to do it.


  1. Small world, I wrote the original entry many years ago. The intent was not for programmers to stick in an abusive relationship. Definitely leave. But some the qualities like good code and pride are based purely on your professionalism. If they don’t care about good code then that’s another decision for you to make. Making something of your life is a lot to ask out of a job, it might be better to look for a more expanded view of life than just work. A job isn’t about your best work, it’s about consistent sustainable quality. That’s what playing hurt means. I’m all for doing what you love, finding meaning, self actualization, but if you are taking a pay check your obligation is to be professional and do a good job. That is, play hurt.

  2. Oh, that’s why I’m finally sticking with just one job. It’s because I do that so rarely now, and it’s an awesome feeling.

    Ironically, I took the job because it was a big pay jump, but then discovered I loved the work.

  3. Interesting analogy. I would consider playing hurt as being at a job where you are getting little mental stimulation on a regular basis. Like in sports, playing hurt is often recipe for further injury down the road, namely boredom, burnout, and mental stagnation. On the c2 wiki, it seemed like there was a divide between those who felt that one must play hurt if one is to be professional, and those who say that as long as you get the job done well and on time you are being professional enough, so you don’t need to worry about appearances. I feel like I am of the latter opinion.

    Once you have found the right job and environment, I definitely think that attitude is a huge part of being happy with what you are working on. In a software project there are small details that might seem like they are contributing little value but are necessary for the overall product quality. I’ve seen people get discouraged by these kinds of tasks and people that take them head-on. This obviously assumes that you are in the right place. It seemed like moving was a good choice for you.

    Arbitrary deadlines or goals like the one that you state about sales seem to cause a big morale hit. Have you had this experience in many other places?

  4. You’re right, a lot of it is attitude, and I’ve also seen (and felt) a difference between checking off small items being a series of great little successes vs. a tedious slog

    I think anytime that developers (or any employees) will lose morale anytime they aren’t invested in goals. Salary, benefits, stock options, and profit sharing are literal ways to get them invested, but if employees will still underperform if they feel like they’re wasting their time. The goal I was given back then was ridiculously bad because it came from someone high-up and uninvolved in the project who was withholding the resources needed to accomplish it. Perhaps I’m just echoing Ricardo Semler, but authority may be the fundamental problem. How do you tell someone else to care about?

    (Hm. I sense another post stirring.)

Leave a Reply

Your email address will not be published.