Working Overtime: What It Really Means
Posted by Davy Brion on June 24th, 2010
One of the things that pretty much every developer has had to face at least once in his career is the issue of working overtime (typically, to meet a deadline). If you’re lucky (or smart), this is a rare occasion. For some however, this is either a habit, or happens frequently. There are actually quite a few developers who are proud of being able to do 60-80 hours a week. And they could not be more wrong.
There’s nothing wrong with putting in a few extra hours occasionally. Sometimes, it just needs to be done. But, as soon as it is required more than occasionally (and with occasionally, i mean every couple of months), something is wrong. First of all, you’re not gonna produce anything good if you’re doing a lot of overtime. At first, it starts with a couple of late nights. The first couple of nights, the work you do is still ‘good enough’. It’s not gonna be great, but hey, it’ll do. After a couple of nights though, if you’re still doing a lot of extra hours, there’s gonna be a noticeable negative effect on the work you’re doing. And you know what the worst part is? You, of all people, won’t notice it. You’re working hard, you’re trying to catch up with the schedule, and you’re doing the best you can. Or at least, you think you are.
In reality, you are hurting yourself, the project and your teammates more than you could imagine at that time. Here’s the deal: there’s a reason why most people are working 8 hours a day on average. If you routinely work more than 8 hours a day, your work is going to suffer from it (it depends on the job obviously, but for software developers, i’d argue that this is definitely the case). If you do a bit of overtime occasionally, then you, nor the project will suffer from it. It’ll just take a little bit more out of you than what you’re used to. But once it becomes a routine, you, as a human being, will start performing worse and worse as time goes on. Inevitably, that deterioration will become very noticeable in your work. And here’s the sad thing: you’re putting in the extra effort to catch up with the schedule. But by doing so, you’re actually performing worse and you’re hurting the schedule. Here’s what happens: you spend a few late nights at the office. At first, things go ok. You’re getting things done and it appears to be working. You keep spending late nights at the office. After a few days (really, it happens that fast), the quality of your work starts deteriorating. And you won’t notice it until you get back the next day. So then what happens? You start cleaning up the mess you made the night before. Which only means you’re getting even more behind schedule. So then you’ll need even more time to catch up with the schedule. But you’re already spending this much extra time at work, and the problem only seems to get worse! Well, yeah… that’s the whole point that i’m trying to make here. You know what’s the best thing you could possibly do in those situations? Go home at 3 or 4 in the afternoon, go have some fun, relax, and get a good night’s sleep. You won’t believe how much more productive you’ll be the next day.
But where is this need to do overtime coming from? I’d argue that, in the large majority of cases, this is due to management mistakes. Either the wrong things were promised to the customer, or your management doesn’t have a clue of what is really going on. So, if you find yourself in a position where you routinely need to do overtime, you really need to start asking yourself whether or not you’re working for the right company. If you routinely need to do overtime to reach a deadline, that tells you that the project management (and highly likely, every kind of management beyond that) is pretty messed up. I don’t know about you, but i really don’t want to work for people who don’t know what they’re doing. If you’re doing a lot of overtime, your management is either clueless or stupid. Probably a combination of both.
As for the developers who are proud of their 60-80 hour work weeks… what does that tell you about them? There truly are very few people who can keep on producing great results beyond the regular 40 hours a week. Something tells me that very few of those developers who brag about their extra hours really fit into that category. If they really did fit into that category, they’d let their results speak for themselves instead of needing to brag about the amount of effort they’re putting in.
June 24th, 2010 at 10:05 pm
Thank you for stating something which should be obvious, and yet is sadly not recognized as such. Nothing wrong with a spike of activity from time to time, it’s the nature of the beast, and it can even be fun, in the same way these “it’s-the-last-day-of-the-quarter-and-the-project-is-due-tomorrow” heroic college evenings were. But fundamentally, software is a creative activity, which requires your mind be alert to perform well – and no matter how tough you are, lack of sleep and deprivation of fun will get to everyone. Regular overtime should be a big red flag when considering a position.
June 25th, 2010 at 12:18 am
This is one (though not the most important) of the reasons why I work as an independent contractor, and have declined multiple opportunities to get ‘flipped’ into full-time employment at various clients. It seems that there is an expectation that people will work more than 40 hours (and not just in IT), and often times, a lot more. I’m fine with that (to a point), and as a contractor, I make it clear that I will bill for all of those extra hours.
June 25th, 2010 at 8:49 am
If you are working on the team as a dev, I would agree. Working overtime does NOT have a positive effect on the quality of the code. The sheer amount of shortcuts added is unbelievable. What’s worse it that you add think time to support the “why” you took the shortcut.
But, in my current role I’m responsible for the architecture of our solution. As such I’m constantly working on exploring /refining / improving our code base, craftmanship and implementing new tech concepts (like Agatha
. This consumes most of my time and certainly more than 8 hours a day. Now note, I’m not only doing this for the project, most of what I’m doing is learning and as such I have difficulty determining what time is work / free time.
So, as a true consultant I think I would have to say: it depends
June 26th, 2010 at 5:22 am
Overtime is like a virus that infects a team or organization, and Workaholics are people who refuse to be vaccinated. Much like a virus, this behavior can spread to the rest of a team when individuals don’t want to appear lazy, or undedicated. Soon enough everyone is working 10-12 hour days and nobody really knows why or how it started. It gets worse when the progress spreads to leadership and they start basing projections on these hours. 37Signals has it right – fire the workaholics.
June 26th, 2010 at 6:44 am
I agree with this sentiment, but there’s more to it than just the fatigue issue. The fact is, that if we, as developers consistently work more than 40 hours a week, we’re lying to our bosses. That’s because an expectation is implicitly created about what we can do in a certain amount of time.
Yes, it is possible to \crunch\ for short periods and deliver, but that behaviour can’t be extrapolated to long periods of time, and that’s what management (in general) don’t grok.
June 27th, 2010 at 3:58 am
Most people do not want to be working overtime. But can this be helped? Most of the projects that start out require a great deal of learning or understanding the existing system which definitely takes more than 8 hours.
Also during system testing and bug fixing, when those critical bugs show up, you just can’t leave when you are tracking a bug and are half way between and probably could fix it or at least get to a certain level of fixing it.
Software development is not like the other fields where we can predict the amount of work we can complete in 8 hours. It varies by a great deal and is quite unpredictable.
And it gets worse if you are working for a project where it is expected that you will finish your work in deadlines set by the business over which you do not have any control.
June 28th, 2010 at 4:42 pm
I’ll remind you of this post next time you post your pizza order on facebook at 20:00 while being in the office;)
I do however agree with your statement, as I also had the opportunity
to see how bad one can code when working overtime frequently.
Cutting back to normal hours (or less) seems to be working mighty fine.
@Kevin
‘Software development is not like the other fields where we can predict the amount of work we can complete in 8 hours. It varies by a great deal and is quite unpredictable.’
Errr ? Unless you are talking about factory based construction I do feel that every field has this ‘problem’. Try to forecast how much time you will spend on drawing a flyer for some new product or how much time it will cost you to write a book just for an exercise. Heck, predicting how long it will take to iron a shirt is hard. It is not that we are all coding for the nasa rocket launcher projects. Experience and putting some effort in your estimations will tend to get you a good hunch on the workload. Try ‘poker planning’ with your team just for the heck of it and see what happens.
I do agree that it will get (even) worse if you feel that business sets deadlines that you do not control. Projects get 1 year overdue one day at a time, so inform mgmt and/or business frequently about the status of work remaining in the latter case.
Cheers,
Stefan
June 29th, 2010 at 8:44 am
@Stefan
that happened about a year ago i think
June 29th, 2010 at 11:58 am
I totally agree with what you said Davy, I’m impressed about the clearness of what you said.
This is unfortunately my situation, specially in this last period of time, and I’m starting to think that could be possible the company i’m working it’s not the right for me.
But I agree even with Tom De Koning when he said that, as an architecture resposible, I’m overtime more that developers does, this because I’m constantly working on exploring /refining / improving our code base, craftmanship and implementing new tech concepts (like Agatha
)
But I think also that (@Tome De Koning) even if as an architect I have more overtime, even that means that something is wrong, for me for example, I have this situation because our developers leaves (aa part of them) technical debts everywhere and I have to fix, redefine, and so on…
This to say that, I think that even an architect could do the canonically 40 hours, If he/she can define an architecture, all the methodologies to apply and then the team does his works as well as the architecture says!
I agree even with jdn when he said that this is one of the reason it’s better to work as a contractor, because all of my extra time is billed! So I’m starting to think I have to comeback to my old contractor situation..
Thanks at all and sorry for my english
June 30th, 2010 at 6:32 pm
It’s really true. I have experienced this situation several times.
July 2nd, 2010 at 11:16 am
Hit the nail on the head.
The best manager I’ve ever had said this when he first became our project manager after having worked 60-80hrs a week for a year.
“No more overtime”. He stated that if we were doing overtime, it meant he wasn’t doing his job and the team wasn’t communicating.
Something I’ll never forget.
What did this mean result in:
1. Better scheduling.
2. Better transparency.
3. Increased morale.
4. Better quality work. Meaning less rework and more work being completed.
5. We did not hate work.
July 19th, 2010 at 5:09 pm
Oh how true! The problem couldn’t be more relevant in a country like India where software is outsourced. Cost cutting is THE motivating factor for offshoring, sadly leading to complete disregard for quality and programmer work-life balance. If you as a programmer do resist the inhumane conditions, you will not only be hated by the management but also buy your co-workers who are not in a position to stand up for themselves. Eventually you will be replaced by two inexperienced developers who will willingly work 24/7 for they are more than grateful for being recruited by an international MNC.
Hopefully the software industry will mature leading to more stable and reliable working conditions for developers.