In his 2009 essay Maker’s Schedule, Manager’s Schedule, computer scientist and YCombinator co-founder Paul Graham defined a manager’s schedule as one that revolves around hour-increments of time, usually switching from one meeting or task to another. In contrast, a maker’s schedule requires closer to half-day units of uninterrupted time to work on a single coding or writing task, which we’ll just refer to as “making”¹.
Since then, we’ve seen office work and schedules change drastically at least twice: once with the introduction of rapid-fire communication tools like Slack and again when the COVID pandemic forced many teams to work remotely and conduct meetings over Zoom². These changes to our communication and scheduling environments make it difficult, if not impossible, for those on the maker’s schedule to carve out uninterrupted half-day units of time to get projects done. We need to become resilient to frequent interruptions by decomposing our making time into smaller chunks that can be completed or checkpointed in shorter periods.
Meetings are exceptions
Graham argues that meetings disrupt makers. “A single meeting can blow a whole afternoon by breaking it into two pieces, each too small to do anything hard in,” he says. It can be challenging to recover from those interruptions. “Having a meeting is like throwing an exception,” says Graham.“It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.”
I often find that when it comes to making, I have a cold-start problem. Every time I sit down to work on a project, I have to load the requirements, details, research, and previous work into my head before figuring out what to do next. If I’m interrupted by a meeting, I have to run through that mental process all over again when I return to my task. Then I make mistakes because I can’t perfectly reload the context each time I return to my project. “You can’t write or program well in units of an hour,” Graham says. “That’s barely enough time to get started.” If I only have an hour, I often won’t even try to begin a coding or writing task because I assume it’ll take too long to get started.
So let’s break this down. Having a meeting in the middle of your making time is like throwing a runtime exception— you sat down to start working, loaded up all the necessary details in your brain, figured out the first few steps, and made some progress. Then you had to drop everything to hop on a Zoom call and take care of any tasks that pop up during the call. When you’re finally ready to switch back to your original project, you’ll have to find your flow all over again.
That’s not ideal, but when the meetings on your schedule prevent you from starting a new project at all— this feels like a scheduling compile-time exception. Graham points out that makers can try to schedule meetings back-to-back at the beginning or end of the day to unlock large chunks of uninterrupted midday making time. Unfortunately, meetings are hardly the only workday interruptions in 2021.
Compared to a handful of in-person meetings, our Slack-ified, Zoom-ified, WFH workplaces might raise tens or hundreds of exceptions in a single day if we let them. We could turn off all notifications and try to batch process these— wrap them all in a big try/except3 block to protect our dedicated solo work time. Some messages require us to actively work through a problem with a colleague, which would typically take us out of our flow. If we process these demands all at once, then we theoretically won’t interrupt ourselves. But, given the fast pace of most teams today, Slacks, emails, and Zooms that require our attention will inevitably come up last minute.
What if your project’s requirements change, a high-priority customer issue arises, or we need feedback from a team member before finishing our project? There are both scheduled and unscheduled interruptions throughout the day for those working from home with kids, pets, or other obligations. Exceptions are unavoidable.
Time-blocking is intentionally raising and catching exceptions
We need to protect our making time by raising exceptions early and often. I’ve often used time-blocking methods like the Pomodoro Technique— 25 minutes of work followed by a 5-minute break— to knock out emails or administrative tasks. I initially thought it wouldn’t work for coding for the same reasons that meetings are disruptive— by the time I got started, I’d get interrupted. At first, I proved my hypothesis right. I often “rolled” over breaks, and I made good progress. After switching from 25 to 50-minute work increments4, I found that decomposing coding work into smaller chunks keeps interruptions from derailing the whole day. These shorter sessions make it easy to checkpoint work.
By proactively decomposing large projects into smaller segments, we can arrive at working, testable, and shippable solutions sooner than we could by sticking to the original plan a priori. I also found myself taking more notes to decrease my reboot time when I picked up the task again.
I don’t suggest chunking ALL hard work this way. There are activities like designing your own programming language, where the task or tools don’t allow you to checkpoint easily. However, I’ve been surprised by the effectiveness of breaking down more extensive coding and writing jobs into shorter work sessions. I make meaningful, measurable progress in 50-minute increments. Rather than setting aside an afternoon to “research and implement the backend and frontend,” I’ll limit myself to researching frameworks or tools for a set period before making a preliminary decision. Then I’ll stop to evaluate that decision or spend 50 minutes getting a prototype working end-to-end. Working this way forces us to avoid premature optimization and to apply the 80/20 rule. Maybe we over-estimated the likelihood of that nasty edge case and we can ignore it for now. Perhaps we can find example code that very closely matches what we need.
We can also get higher-quality code reviews and feedback on smaller chunks of work. Even without collaborating with someone else on the code, it can help us rubber-deck debug our approach. If a “simple task” actually requires more chunks than anticipated, maybe it was never simple and should have been decomposed. If I notice that I’ve spent too many 50-minute periods on the same approach without measurable progress, it might be time to try a different tactic. I haven’t failed, I’ve just found at least one way that doesn’t work. It’s not quite chaos engineering, but you can think of this as deliberately raising exceptions early and often so you can handle them swiftly.
An evolving environment of exceptions
Changing the way we work is hard — if it’s worked so far, why change it? In a recent episode of The Ezra Klein Show with Professor Cal Newport, Klein recalls author Neil Postman’s idea that technology isn’t positive or negative but rather ecological. Technology changes our work environment, so our scheduling and work algorithms need to change too. Most programmers can think back to a time when they tried to reproduce a user-reported bug, only to exclaim, “It works for me!”
Debugging is difficult enough when you can control or account for the variables, but it’s exponentially more complex when the environment is unknown or unstable. Your code might work locally but not in production for several reasons. Your Javascript might work for 99.9% of users but not work for those using Internet Explorer 9. Graham says one of the motivations for writing the first application web server was to avoid writing a store in Windows. If the environment raises many unanticipated exceptions or fails in unexpected ways, we would try to design robust systems that handle the exceptions or failover gracefully and recover. Why not do the same with our work environment?
Even if we block out all distractions, our focus on more agile processes, shorter iteration loops, and increased collaboration come at the cost of long periods of uninterrupted maker time. Even if we block out a few four-hour periods a week, it can be tough to anticipate our energy and creativity levels accurately enough to be productive at designated times, especially when surprise meetings happen. We need to take our energy levels into account when planning our projects and breaks (and use our breaks to recharge rather than working through them.)
When I decompose coding tasks, I find it easiest to start by reviewing code that I wrote yesterday, reproducing a bug in a well-documented way, writing a small component, or writing a function with some values hard-coded. These tasks fit into smaller time blocks and require little energy to complete, giving you a sense of accomplishment to power you through the workday.
Even better, getting started on one easy task may help you think of an easier way to tackle a more complex item on your to-do list.
Chunking coding or other “making” projects to make them more robust to interruptions is a Strong Opinion, Weakly Held. It’s vital for those of us who are both makers AND managers, constantly switching hats throughout the day. Give it a shot and let me know how it works for you.
Thanks to Candace Ramirez, Haley Bryant, Michael Gummelt, Ricky Yean, and Wil Chung for reading the drafts of this.
[1] I’ll mostly refer to coding and writing since those are the types of making that I do most often. I won’t get into the definitions of “makers” or “deep” vs. “shallow” work here. Still, I generally think of “making” as anything that requires creativity, typically requires you to think about how to start and make progress, and often takes at least several hours to complete.
[2] I’ll refer to all text-based instant communication tools as “Slack” and all video ones as “Zoom,” but obviously, your company may use Discord, Microsoft Teams, Mattermost, Google Meet, etc.
[3] I’ll be using `python` syntax because IMO that’s the closest to speaking in English and the language I’m most comfortable with, but feel free to `s/raise/throw,` `s/except/catch,` etc.
[4] I’m still experimenting with this. The traditional 25 minutes of work and 5 minutes of break feels almost for sure too short for most coding tasks. I’ve tried 90 minutes or 120 minutes, but I would often lose focus. Fifty minutes seems to be just short enough to stay focused the whole time and adds some time pressure to try to scope out something sufficiently challenging to complete during the period while being long enough to get meaningful work done. I think “short enough to stay focused the whole time” is definitely trainable, although it should probably vary based on the task as well as how much energy you have.
