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 .