Andrew Wulf asks a question every programmer runs into sooner or later: how many hours a day can you write code before the work gets worse, and how many weeks of that can you keep up? His essay “How Many Hours Can You Code?” on The Codist answers it with two stretches from his own forty-year career, thirty years apart, and this is my summary of it.
Some background on the author first, because it explains why his numbers carry weight. Wulf spent nearly four decades as a programmer in almost every kind of company and industry, and by his own description he stayed a programmer whatever his title was. In the 1980s he was one of the three developers of Trapeze, an early Mac spreadsheet. After Trapeze he started a company that built Mac software for other firms, worked for a year on Persuasion, an early presentation program, and spent five years on DeltaGraph, a charting application. Later he built web apps and services and, at the end of his career, iOS apps for a large company outside the tech industry. He retired in 2021, writes The Codist about the craft of programming, and now makes digital art, still writing code every day to support it.
The first one was in 1986. Wulf had come up with Trapeze, a Mac spreadsheet that referred to blocks of data by name instead of by row and column, and his company planned to launch it at the next Macworld in San Francisco. At the Boston Macworld in August 1986 he saw other people’s applications for the first time, which wasn’t easy before the internet, and decided that the user interface he had built was unusable. He spent the next four and a half months writing a new one at about 90 hours a week, in an office with no air conditioning at weekends, kept awake by Jolt Cola. Trapeze made it to the show with a pop-up menu that crashed about one time in ten (fixed before it shipped), and afterwards he was so worn out that his doctor sent him to hospital for several days. He also thinks the exhaustion cost the product: selling it through ordinary retail put it next to Excel, while a direct sales team, the way Mathematica was sold a couple of years later, would have reached the people who needed a modeling tool.
The second stretch came when he was 59, at a large company that wasn’t a tech company, where he was the last iOS developer left on a big project. A huge late change request landed at the same time as an expansion of an internal customer service app, and on top of that he ended up guiding a new team of two contractors as their unofficial lead and tester. That meant three months of seven-day weeks at around 70 hours each. This time he slept properly, ate decently and slowed down on purpose, because rushing while tired is how mistakes get made. The project shipped and went on to earn a nine-figure sum every year.
His conclusion is blunt. Short bursts are survivable, months of them are not, and no salary is worth what that does to your health and your relationships. He mentions a manager from his first job who collapsed and died during a meeting, and people in AAA game studios who work brutal hours and get laid off afterwards. If you’re stuck in that kind of schedule, he’d rather you walk away than keep going until you collapse.
The full essay has more detail on both projects, and it’s worth reading in his own words.