The Case Against Overtime
Comments(29) 
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 .
Popularity: 37% [?]
Well said! This was a hard lesson for me to learn. Even now, that idea of bravado can set it. It’s not worth it.
Very good post Russ!
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.
[...] The Case Against Overtime (Russell Ball) [...]
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.”
Great post, this concept of a 40 hour workweek is also referenced in Peopleware, Code Complete, and a couple other great books.
Here’s one of my favorite references from Steve McConnell (Code Complete):
..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
Couldn’t resist adding a couple quotes from Peopleware (published 1987):
“Nobody can really work much more than forty hours, at least not continually and with the level of intensity required for creative work.” – Chapter 3
“People under time pressure don’t work better; they just work faster.” – Chapter 3
@Phil Haack – Yeah, I often feel nostalgic for gonzo programming days. This post was as much a reminder for myself that I am better off abstaining from these urges as anything else.
@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…
@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.
@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.
Very interesting points. I hate longerm overtime work, it totally saps my energy and has hurt my health. I am a diabetic and I find it much harder to manage my diabetes when I work overtime.
@George 60 minutes ran a series on sleep. One researcher suggests that lack of sleep and diabetes are interrelated. They also discovered that sleep deprived rats started dying.
Watch the videos here:
http://www.cbsnews.com/section.....d=3942130n
http://www.cbsnews.com/section.....d=3942132n
@George – Interesting! That doesn’t surprise me. I’ve noticed other health related issues for myself when I’ve worked long periods of overtime before as well.
@Adam – Ugh, that doesn’t bode well for me as a new parent…:-)
Adam,
Wow, that is interesting. Didn’t know about the link with Diabetes. I will have to check out the videos.
Very nice post and explains the reasons behind the no overtime policy!
[...] Russell Ball of Caffeinated Coder wrote a great post about the futility of self-imposed overtime. The post is geared towards programmers and their misguided attitudes about overtime programming; however, I believe most of the points asserted in the post can apply to any profession. A highly recommended read for all programmers and a recommended read for even non-computer professionals that do overtime when its not required. [...]
Rats!
I was hoping you would continue to slave over a hot keyboard for free forever.
Guess I’ll have to lay you off and hire a new batch of fresh college graduates now.
They’re always eager to show me the stuff real programmers are made of – working for free.
Think Microsoft and Google.
@futureturnip – Wow, I’ve never heard of a place having a no overtime policy. Where do you work?
@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?
@FerventCoder – Yep, it’s down hill from here. It won’t be long now before you’ll be eating dinner at 4:00.
[...] [WORKHACKS] The Case Against Overtime, caffeinatedcoder.com [...]
The Case Against Overtime | Caffeinated Coder…
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…
STUMBLED!
Seems like I am working overtime everyday.
VOTED for you at:
http://www.newsdots.com/indust.....ted-coder/
[...] not read in a long time. I checked it out today and it had an excellent post about “The Case Against Overtime“. This could not come at a more valuable time for me to reflect back on this. I’ve [...]
[...] Forced Overtime – As I argued here, I think overtime is rarely a good idea and is almost always preventable. However, if you are [...]
[...] leitura recomendada: “The Case Against Overtime” [...]
[...] leitura recomendada: “The Case Against Overtime” [...]