The Case Against Overtime

I remember reading the eXtreme Programming Core Practices several years ago and smirking when I got to the practice that called for regular 40 hour work weeks for programmers.

Like many of my fellow developers, I saw overtime as a geek badge of honor and felt pride at having enough stamina to regularly work 60-80 hours a week on my death march project.

Although I occasionally received half-hearted warnings from management to slow my pace down in order to avoid burn-out, the underlying message from above was clearly that my willingness to work long hours made me an exemplary employee and that overtime was one of the surest paths to professional growth and advancement.

While I may have agreed with the XP practice of capping the work week at 40 hours in theory, my traditional geek machismo prevented me from accepting it as anything other than a naive and idealistic goal that would probably never be gain widespread acceptance in corporate America.

That was then.

Now, when given a choice, I rarely opt to work overtime for my employer (at least not directly according to my task list). I would never hesitate to work extra hours prior to a release or due to unexpected production problems, but I now view anything more frequent than that as a serious problem and even as a potential reason to start looking for another job.

Why the dramatic change in attitude?

Here are some reasons that finally caused me to stop seeing overtime as a heroic effort and start seeing it as a destructive practice that is a sign of a seriously broken process within an IT organization.

Lost Opportunity Costs in Professional Growth – Once I completed a handful of large projects in my career, the opportunities I saw for professional growth started coming more and more from external sources outside of my job. While I still learn plenty during the day by observing my co-workers and attempting to solve common problems in novel ways, I often feel that my skills grow faster outside of work through reading, writing, presenting, social networking, and pet projects. It is sometimes tempting to spend 10 extra hours a week clearing the items from my daily TO DO list, but I believe that I am accomplishing much more for my professional career by devoting those hours to catching up on my RSS feeds, working my way through my tech book reading list, or exploring new programming languages instead.

Increased Professional Risk from Lack of Diversification - Everyone knows that diversification is the key to managing financial risk, but few people seem to apply this principal to their professional careers. Most developer shops are relatively limited when it comes to the number of technologies and problem domains they deal with. If you want to diversify your resume without job hopping every year, then it makes sense to actively seek out technology experiences that are different from the ones you use in your day job. By this reasoning, working overtime will increase your professional risk by reinforcing skills you already have whereas working on open source or pet projects that require you to learn new skills will mitigate your professional risk and make you more marketable should you ever decide to leave your current job.

Decreased Professional Passion – To paraphrase Jean-Paul Boodhoo, the best fuel for professional growth is always a developer’s joy and passion for his or her craft. I find it much easier to sustain this passion when I am allowed free reign to follow my curiosity. Work doesn’t usually allow for this type of unstructured exploration, but free time does.

Lost Productivity – Overtime work is highly susceptible to the law of diminishing returns. Spending long hours on the same tasks in a high stress environment leads to fatigue, which in turn leads to producing poorer quality work at a slower pace. When you factor in the time it takes to find and fix bugs and design flaws produced by overly tired developers, the net gain for twenty hours a week of overtime probably drops down to only a few hours while at the same time greatly increasing the risk to the project. Overtime just doesn’t yield the results promised by management Gantt Charts which provide an oversimplified view of the software development process by only measuring the quantity of the hours spent on tasks without also taking into consideration the quality of the time.

Poor Code Quality – Besides being more likely to miss obvious errors, developers who are under pressure and fatigued are far more likely to cut corners and engage in shallow thinking when it comes to design solutions. Besides driving up the long term cost of a project by making it more difficult to maintain, code quality issues can put the whole project or even business at risk by introducing critical errors and undermining customer confidence and loyalty.

Lost Personal Revenue – If you are a salaried employee and your are concerned with maximizing your personal income, then you should read this post by Max Pool where he points out that you are almost always financially better off to focus your time across multiple revenue streams rather than allowing your time to be sucked up by one job through excessive overtime.

The Usual Personal Reasons – These are all the usual things that workaholics neglect until it is too late, such as family, friends, health, and entertainment. Although I think they are among the most important reasons, many of us seem to have blind spots when it comes to these issues due to cultural biases so I chose to focus on other more novel arguments about overtime in this post instead. Nevertheless, these are some of the most compelling reasons to question any work schedule that consistently includes overtime.

If you are convinced about the evils of chronic overtime but don’t know how to break out of your current overtime cycle at work, then meditate on the following two concepts:

Time Should Be Fixed, but Features Should Always Be in Flux - If a customer went into a store and put more items in their shopping cart than they had money for, then they would reasonably expect to have to put a few items back while checking out. This is exactly how it should work in software, but the reality is often that customers naturally have a very difficult time connecting their feature requests to a real cost because IT departments have traditionally been so willing to hide the extra cost through overtime. Agile iteration planning and planning poker does a great job of addressing this issue by having developers assign a relative point cost to each feature, tracking an average velocity of points completed each week, and then only allowing customers to choose enough features to equal the velocity points in any given iteration. Besides providing a much more realistic expectation of what can be accomplished in an iteration, this approach emphasizes that developer time is a fixed resource and that feature requests must be variable based on continual assessment and reprioritization.

A Large Number of Proposed Project Features are Unnecessary and even Harmful to the Project – It is amazing how many “must-have” features suddenly become unimportant when a project is time-boxed and resource-boxed in an effective way. I’ve actually seen overall product quality and customer satisfaction increase in these circumstances because it helps focus stakeholders on what is essential about a project and aids them in more easily spotting bloatware features that would otherwise delay implementation, increase cost, and hinder usability without returning discernible value.

Sometimes you just can’t change the way your processes work or management thinks, but you can always change your own attitude by resisting self-imposed or peer pressure to work overtime. I’m guessing that the majority of overtime is not officially mandated, but rather manipulated through subtle peer pressure. If that is the case, just say no.

If your goal is constantly to maximize your own professional growth, then you’ll be surprised at how much respect you can still win without playing the overtime game. For example, who do you think is going to get noticed more, someone who closes a few more issue in the bug tracking system, or someone who is able to introduce a new concept, process, tool, or technology to the group because of work done in their spare time?

In conclusion, the next time the opportunity for overtime arises, ask yourself if you are really maximizing your professional growth or if you are just focusing too much on short term job goals and not enough on long term career goals .

36 Comments

Like you eluded, when you are young and enthusiastic, putting in long hours can be a labor of passion…but gosh darn it if these old bones have more and more trouble showing my passion through shear work effort.

Show your passion through blogs, mentoring, writing, speaking, podcasting, or just meditating on the problems at hand is just enough out-of-office extra credit to stay balanced and diversified.

Well put and spot on. You should, however, also point out (maybe you did and I missed it) that if you routinely do overtime, management begins to expect that you will always do it. You become viewed as a “high volume” programmer and when you decide to pull back for personal or professional reasons, management thinks you’re slacking off. As I always say, “No good deed goes unpunished.”

..programming machismo is pure B.S. and an almost certain recipe for failure. Those all-night programming stints make you feel like the greatest programmer in the world, but then you have to spend several weeks correcting the defects you installed during your blaze of glory. By all means, get excited about programming. But excitement is no substitute for competency. Remember which is more important. – Chapter 33.8, Gonzo Programming

@Max – I often still put in the equivalent time on programming related activities, but I feel like it is much more sustainable because of the diversity and fun involved in it than simply slugging through overtime in the office.

I agree with you on the old stuff. I didn’t want to say anything, but you’ve definitely been looking like an old man these days…

Russell Ball
April 9, 2008 9:19 am

@Bret – Excellent point! I definitely should have mentioned that. I did notice that tendency from management to view my performance differently when I first started working normal hours like everybody else. People are often judged according to prior performance rather than objectively against each other in an IT department. Going on a long term OT binge can definitely cause problems for you down the road. It’s also a self-fulfilling prophecy because you tend to get more work piled on you, thus making it more difficult to not work OT.

Russell Ball
April 9, 2008 9:21 am

@Adam – Thanks for the quotes! It definitely helps to have more authoritative figures back up this stance. I must admit that I was a little worried that I would come across as lazy and a undesirable to present and future employers when I first thought about writing this post.

@futureturnip – Wow, I’ve never heard of a place having a no overtime policy. Where do you work?

Russell Ball
April 11, 2008 12:19 pm

@Mr_Simple – Ah, a realist! Who let you in here?

Seriously, you bring up a good point. But I think there is a difference between large software vendors and business IT shops. Businesses that develop custom software in-house are much more reluctant to take on more than a few college graduates at a time. It simply takes too long to learn the business domain and professional skills are required when interacting with clients\co-workers that usually only comes from experience (at least in the places I’ve worked so far…). Businesses also tend to have a huge landscape of legacy apps to support, which means that experience with a wide variety of technologies is usually a bonus as well, which college students simply don’t have.

However, I’ll keep my skewed work ethic in mind if I ever try to get a job at either Microsoft or Google.

Very interesting post…I tend to put in at least five or more hours of overtime in per week. More recently I have been noticing that it makes me irritated when it never bothered me before. Does this mean I am getting older?

Russell Ball
April 12, 2008 3:04 pm

@FerventCoder – Yep, it’s down hill from here. It won’t be long now before you’ll be eating dinner at 4:00.

I’ve never liked over time. I tried it a couple of times when I was younger. I worked over time a couple weeks (i was paid every two weeks) once I got my first check that included over time. I said forget it. I was taxed so much, it didnt make it work the extra time I had to stay. I’m now 36 with a little daughter and I wouldnt do it now either. Thought sometimes having a little extra sounds good. I dont see her enough as it is. I wouldnt will fully want to stay more hours for a few more bucks. I’m only going to have her at this age once.

IMO there is really no reason to work overtime. It makes you look good in your own eyes (“I’m such a hard worker”), but the real “secret” to being productive and getting most out of yourself is concentrating and ACTUALLY WORKING all the time you work.

Theresa82
November 17, 2011 8:19 pm

Other clients really upset when a certain project goes on overtime. They are actually employing a time frame for each details of activities so once the other goes overtime it actually directly affects other activities.

amazing news dudeThank buyers being transmit ideal nice informations. Your New web is greatI am impressed by The advice that you allow at things like this blog. this displays Techniques to excellent end users understand your nice. saved this page, will come back being significantly more. end users, my mate, ROCK!

Shop is located in one of Amsterdam’s picturesque 18th-century building, the original structure elements are retained with full power, and into a new interior design. Customers can shop at 150 square meters, the experience of the world