I recently had an opportunity to work on a relatively high-profile project with a crazy timeline. A coworker and I spoke with the client for the first time around lunchtime on a Friday, and the client needed a completed website, complete with a relatively sophisticated design (which had, at that moment, not yet been delivered by the designer) and a relatively sophisticated data model, by mid-day the coming Monday. That’s 72 hours to build and skin a fully functioning website.
I realize that “fully functioning” doesn’t tell you much about the scope of the project, but we live in a world of non-disclosure agreements. Suffice to say, it was a non-trivial amount of work.
Keeping in mind that the two of us had already worked 36 hours of our 40-hour work week on other projects, we agreed to take on the project. Between the two of us we worked about 60 hours that weekend, most of it solo, and had the site finished at start of business Monday morning. This might not seem particularly heroic (particular to anyone who writes software for the game industry), but keep in mind that at Pivotal we believe strongly in the concept of sustainable pace; we really do work eight hour days, five days a week. People working late at Pivotal is relatively unusual; people working weekends is almost unheard of.
The thing that struck me about this project was that I enjoyed it. I had a little rush of excitement when I agreed to give up my weekend and work late into the night as necessary. Even as I was doing it, bleary-eyed and mentally dull, I felt the high of accomplishment.
I spent the next several days trying to get my sleep schedule back to normal, and feeling generally tired and worn out. At the same time the two of us on the project spent a fair bit of our time, unsurprisingly, regretting some of the decisions we had made while working late into the night. Also during that week I came to something of a startling realization: I’m an addict.
I knew when we agreed to work on the project that the amount of sleep I would lose would make me miserable. I also knew that putting in a bunch of time over the weekend would mean starting work the next week without a day off, without time to do the non-work things I need to get done. More directly, while I was working on the project when I hadn’t taken a break all day and hadn’t slept the night before I knew my focus was poor, I knew my decision-making skills were compromised, and I knew I was prone to cutting corners I shouldn’t have cut; I consciously thought these things to myself at the time. And yet, I continued to work, without taking a break.
I don’t claim to be an expert on the psychology of addiction, but I do know that I’ve met a lot of people with drug and alcohol problems in the past. Lots of them talk about how they know that drinking/shooting up/huffing/whatever is hurting them, and hurting their friends and family, but they do it anyway. Because they’re addicted.
How many programmers work past the point of fatigue at which they can continue to make effective design decisions, to clearly think through scenarios, or to correctly differentiate between a reasonable trade-off and a regrettable hack? How many do so when they know their judgement is compromised, because they’re getting their fix of problem solving?
Proponents of “flow,” like Joel Spolsky (whose credentials for “writing great software” appear to be a summer internship at Microsoft and a silver tongue) will tell you this is a good thing; starting the flow of a great programmer takes so much effort you want it to go on for as long as possible. I’m not convinced; I know when I’m sharp and when I’m not, and I don’t even trust myself to stop the magic when I’m not doing my best work. And, this is a bit like an alcoholic explaining the health benefits of vodka.
Addicts most commonly manage their addictions by talking with other addicts. Maybe that’s an as yet unheralded benefit of pair programming: someone to cut you off when you’ve had one too many.
