Working fast and slow

Some engineers work very consistently, putting in the same hours every day and getting out the same amount of work. I don’t. Some days I only have a few hours of focused work in me, while on other days I feel like I can go on almost indefinitely. I used to feel like this was a problem - that I was either overworking or slacking off - but now I lean into it. Instead of trying to push harder on slack days and pull back on focus days, I accept that I’ll be much more productive on some days than others. There are serious advantages to this working style.

First, a disclaimer: “focused work” means “genuine progress on projects”, not all work. There’s a set of low-priority tasks I can do while I’m not focused. Company trainings, straightforward PR reviews, responding to messages, and even some straightforward programming is in this category. I’m not doing an hour of work and then going to the beach.

Powering through

Can I just buckle down and power through real work, even when I’m not feeling it? Not really. It’s a common observation about writer’s block that the writing you do in flow state and the writing you do when it’s like squeezing blood from a stone are of equal quality: when you read back, you can’t tell the difference. In my experience, this isn’t true of hard project work. Shipping is hard! When I try and do high-stakes project work when I’m really not feeling it (e.g. writing code for a core part of the project, or a public-facing communication about some part that needs to change), I usually find the next day I’ve missed some key point.

Mistakes when shipping projects cost more to fix than simply redoing the incorrect work, so I personally find it’s better to wait than to try and power through. That’s because of the coordination parts of project work. If you ask a team to do something for you, and you get the request wrong in a subtle way, it might be hard to explain to them what you actually need them to do (and they might justifiably deprioritize your request, since you already got it wrong once).

Powering through when I’m not in the zone has a real physical cost. If I do it for long enough, I typically get headaches and just feel off, like I’m getting sick. I don’t know if this is exactly how it works, but it’s as if I’m consuming some limited internal resource while I’m in the zone that then has to be slowly replenished by mental relaxation. When I’m in the zone, I feel fine even after working for ~12 hours.

Of course, sometimes I have to lock in anyway, whether I’m feeling it or not. Deadlines and last-minute requests don’t wait for anybody. But until the final sprint, projects are typically dominated by time spent waiting on external dependencies (at least in big companies). I find I usually have some leeway in deciding when I do a particular piece of work.

Two kinds of working style

When I’m in the zone, problems seem more straightforward. Even complex tasks feel pretty doable. Once I notice that, I try to pack my time with high-priority work only. I’ll put off responding to all but really important messages (Slack’s “remind me later” is a great feature). I also try as hard as I can to avoid multi-tasking, so I can keep my entire attention on getting a single task right at a time. If I feel like continuing to work through the evening, I let myself do that, knowing I’ll give myself the time back the next day or the one after that.

When I’m not in the zone, every task seems complex and rife with booby-traps. I feel like I have to proceed defensively and avoid taking risks. On days like these, I try and knock out easy wins and don’t worry so much about prioritization. I do a lot of general talking and bouncing between multiple projects. I don’t feel so bad about stopping work earlier than usual, knowing that at some point I’ll make it up with a period of hard focus.

In my experience, this style of work is a surprisingly good fit in large tech companies. On every team I’ve worked on, the team’s work has followed a similar pattern: sleepy periods of low-priority projects, punctuated by high-priority projects where leadership suddenly takes an intense interest. Taking it easy during those sleepy periods and locking in during the intense periods is a very efficient approach.