60 Hour Weeks and Diminishing Returns
There are producitivity gains in rest
It has been almost a month since I last published a post. The reason for that is not that I've lost interest, but because I was worked several 60-70 hour weeks in a row. That left me without the mental capacity to write. However, it did leave me with material to write about now that I've had a chance to rest.
I've long been extremely skeptical of long hours being a productivity boost. Some of those reasons I've written about before. The origin of this skepticism was early in my career. I spent a lot of my first job fixing race conditions, but there was one in particular that stood out. I gave myself a self-inflicted deadline and spent two 14-hour days working on it. At the end, all I had done was tighten the timing of the bug. Part of me wondered if it was good enough and I decided to go home to get some sleep.
I reviewed that code the next morning and almost immediately realized my whole approach was wrong. I deleted nearly every change I made and rewrote it all in 2 hours. The fix was perfect. 28 hours for a faulty solution vs 2 hours for a working solution. Taking into account the quality of the solution, that's more than 14x the productivity just from rest.
One could argue that those 28 hours were spent gaining context into the problem. That time was not wasted, but a necessary experience. That is a valid argument in a lot of cases, but not this one. The first bit of code I looked at in my review was the unused precursor to the correct solution. That means I had at some point realized what the good fix was, started writing it, and somehow forgot about it. That is the cost of fatigue.
Given my workaholic tendencies, that was easily one of the most important experiences I needed to have early in my career. With the exception of on call rotations, I became a strict 9-5er. I later took a job where people were shocked at how I left the office the same time every day. My predecessor had apparently worked 3-4 hours more a day than I did. No one criticized me for it because my level of output was greater.
It is not enough to just say rest is important for productivity. It is important to understand why that is so. Theory of constraints does apply, but there is more to it than that. Exhaustion tends to result in a person getting tunnel vision. When you're exhausted, the most important thing is just getting an activity over with so that you can rest. Whatever appears to be the most direct route to completion is the route you're going to take. If you're at the office at 2am and encounter a problem, the thought that comes to mind is never going to be "Is this the right approach? Should I reconsider and look at alternative implementations?" That is a 2pm thought, not a 2am thought. The 2am thought is "How can I make this work good enough so that I can sleep?"
Looking at the big picture does not happen at 2am. Strategy does not happen at 2am. Questions are not asked at 2am. The only thing that happens at 2am is trying to solve what is directly in front of you and only what is directly in front of you. That mentality may help with productivity on an assembly line, but it's a liability in software development.
I've held this position for nearly two decades, so why did I just go against my own beliefs? The reality of entrepreneurship is that there are going to be times where a pile of urgent tasks happen at the same time. An entrepreneur has enough incentive to stay productive during these periods of long hours, but that incentive only goes so far. Even entrepreneurs break at some point. We all have a different breaking point (mine is apparently 5 weeks). It is important to know when you've hit that point and stop. There may still be things to do, but someone past the breaking point is likely to do more harm than good trying to power through it. There will also be more times when urgent tasks pile up and keeping a reserve of energy is important to deal with those times.