Hard Work Does Not Pay Off

As a programmer, you’ll find that working hard often does not pay off. You might fool yourself and a few colleagues into believing that you are contributing a lot to a project by spending long hours at the office. But the truth is that by working less, you might achieve more – sometimes much more. If you are trying to be focused and “productive” for more than 30 hours a week, you are probably working too hard. You should consider reducing your workload to become more effective and get more done.

This statement may seem counterintuitive and even controversial, but it is a direct consequence of the fact that programming and software development as a whole involve a continuous learning process. As you work on a project, you will understand more of the problem domain and, hopefully, find more effective ways of reaching the goal. To avoid wasted work, you must allow time to observe the effects of what you are doing, reflect on the things that you see, and change your behavior accordingly.

Professional programming is usually not like running hard for a few kilometers, where the goal can be seen at the end of a paved road. Most software projects are more like a long orienteering marathon. In the dark. With only a sketchy map as guidance. If you just set off in one direction, running as fast as you can, you might impress some, but you are not likely to succeed. You need to keep a sustainable pace, and you need to adjust the course when you learn more about where you are and where you are heading.

In addition, you always need to learn more about software development in general and programming techniques in particular. You probably need to read books, go to conferences, communicate with other professionals, experiment with new implementation techniques, and learn about powerful tools that simplify your job. As a professional programmer, you must keep yourself updated in your field of expertise — just as brain surgeons and pilots are expected to keep themselves up to date in their own fields of expertise. You need to spend evenings, weekends, and holidays educating yourself; therefore, you cannot spend your evenings, weekends, and holidays working overtime on your current project. Do you really expect brain surgeons to perform surgery 60 hours a week, or pilots to fly 60 hours a week? Of course not: preparation and education are an essential part of their profession.

Be focused on the project, contribute as much as you can by finding smart solutions, improve your skills, reflect on what you are doing, and adapt your behavior. Avoid embarrassing yourself, and our profession, by behaving like a hamster in a cage spinning the wheel. As a professional programmer, you should know that trying to be focused and “productive” 60 hours a week is not a sensible thing to do. Act like a professional: prepare, effect, observe, reflect, and change.

[This is a reprint of a chapter that I wrote for the newly released O'Reilly book 97 Things Every Programmer Should Know]

14 Responses to Hard Work Does Not Pay Off

  1. Tom Chen says:

    Ye, totally agree…

  2. geirber says:

    As much as I appreciate a tabloid angling on a title, I still think one should use it with caution.

    I agree with the continuous learning and sustainable pace of development, there is no doubt about its imperative. However, I also believe in the (personal, and professional) rewards of very hard work, and I think the solution lies within a combination of the two.

    I try to work hard all week non-stop and I could not be more happy to. Work is split into three main categories.

    * Doing
    * Learning
    * Sharpening the saw

    Avoiding stress by all means is a key principle, but harvesting the energy of eustress (the healty form of stress) is right up there along side it, as well. I find that hard work, correctly balanced between the three categories creates eustress and excitement.

    Failing to adhere to these principles causes grief and sorrow. Failing to keep the three categories above in mind at all times, causes inefficiency.

    I’m curious about the way you post content from the book. Is this content GPL’d, or something? Could I post it on my blog, if I wanted to?

    • olvemaudal says:

      Hi Geir,

      I agree that the title is a bit tabloid. The article is just as much about encouraging programmers to dedicate lots of time to their profession – but make sure that a fair portion of that time is used also for learning and sharpening the saw. So it seems like we agree completely on this point.

      About the posting content from the book. The article is under Creative Commons, and since I am the author of the chapter in the 97TEPSK book it is appropriate for me to reprint it in my personal blog.

      • geirber says:

        Congrats on the co-authorship on O’Reilly!

        I think we agree. If we define “work” in your title as the “doing” in my comment, we are in line. Thus you should not be working (doing) all the time, but also learning and sharpening the saw.

        The book is still not available Kindle (for iPhone), so I won’t be reading it just yet. I’d appreciate if you keep us posted when it arrives on Kindle ;)

  3. I couldn’t agree more (except for the title which doesn’t do the post justice)!

    I think a common problem in the business is that it’s perceived as “cool” and loyal towards your colleagues to work overtime. I’ve even experienced colleagues who have gotten pissed off when someone else didn’t want to work overtime.
    In my book coding (or working/doing) 60 hours/week is just stupid. And during those 20 extra hours you’ve spent coding you have probably produced crap, while at the same time they will have ensured that you haven’t had time to reflect on the problem domain, ensuring that you’ve also produce crap during the first 40 hours.

    Working 30-40 hours/week, studying 10-20 hours/week and (combined) learning for 40-60 hours/week is, if anything is, “cool”.

  4. GeePawHill says:

    Well-said. It continues to amaze me how many geeks still think their 60+ is helping.

  5. Amy Thorne says:

    I agree. (And congrats on being included in that book. I’m looking at it on Safari Books Online right now, and it looks nice.)

    But once a programmer knows this wisdom, the part I’m always worried about him needing to know next is how to convince his employer.

    It reminds me a lot of the “Reward Behavior You Want Repeated” slide in Elisabeth Hendrickson’s “Why Are My Pants on Fire?” slides here, http://testobsessed.com/wordpress/wp-content/uploads/2007/01/wampof.pdf. (Yep, warning, that link is indeed a PDF.)

    I think her point there is similar to where you say, “If you just set off in one direction, running as fast as you can, you might impress some, but you are not likely to succeed.”

    But when it comes to programmers, I think orgainzations often give more recognition to those who run as fast as they can than to those who maintain a sustainable pace.

    That’s obviously a reflection on the organization and not on the idividual programmer. The organization might not want marathon runners. Its leaders might think they’ll win the race with a series of sprinters instead. They might be right. They might be wrong. Or they might not care, figuring that they’ll exit with whatever winnings they’ve gathered long before the race is over.

    Either way, it can make it difficult for a professional programmer. Not only does he need to be prepared to run the marathon, he might also need to either convince his employer that employing marathon runners is a good strategry, or be prepared to find another employer who already feels that way.

  6. [...] Hard work does not pay off. At least not if your ultimate goal is to improve at what you do. And not if what you do is quality product development. [...]

  7. Al Johnson says:

    Hard work only does not pay off if you are stupid and write code that need other people to fix. In that case you’re creating more work for others by your additional effort.

    Otherwise, don’t mock hard work. If you are willing (which is the important point here) and can do it, then do it.

  8. Mike says:

    Hard work for yourself pays off. Hard work for others leads to higher expectations and more work. You need to have personal goals and look for ways to fulfill them through your work. My goal is to work with smart people on intriguing projects. When I’m working on something I’m interested in, I can work 12 hour days and not ever realize the time passed. When I’m working on something mundane, I have trouble making it to lunch.

  9. Douglas Treadwell says:

    In short, the article says working more than 30 hours is bad, but then goes on to say that programmers should continue to learn, attend conferences, experiment, etc. for a total time likely much much greater than 30 hours per week.

  10. Pierre Rasmussen says:

    Couldn’t have said it better!

  11. jrb says:

    A lot of brain surgeons actually do work 55-60 hours/week.Also during training (known as residency) brain surgeons work an average of 80 hours/week for 6-7 years while training.

  12. [...] Hard work does not pay off. At least not if your ultimate goal is to improve at what you do. And not if what you do is quality product development. [...]