April 21, 2026
I’ve been noticing a pattern in my own work that I want to write down before I forget it or start rationalizing it into something cleaner than it actually is.
If I decide at the outset of a day that I’m going to spend it doing one sort of thing, say, reviewing a patch, or writing a specific piece of code, or reading through a subsystem I need to understand, and I actually stick to that decision, I tend to have something to show for it at the end of the day. Not always something finished, but something concrete. A review posted, a diff that compiles (on some days), notes that make sense the next morning.
Days where I don’t make that upfront decision, or where I let the day fragment into three different kinds of work, tend to produce nothing. And a few continuous days of nothing is where things get psychologically ugly. You start questioning whether you’re doing the right thing with your life, which is not a productive line of inquiry when the actual problem is that you didn’t block your time.
The most important thing I do is decide the night before what tomorrow is for. Not a detailed plan, just “tomorrow is a review day” or “tomorrow I’m working on the locking patch.” If I don’t do this, I wake up and spend the first hour of the day context-switching between email, the mailing list, and whatever I was doing yesterday, and by the time I’ve decided what to work on, the morning is half gone.
For reviews, I want to make them not last more than a day. I haven’t done a lot of reviews lately, but I want to do more, and when I think about how to fit them in, a day feels like the right unit. A review has a natural arc: you read the patch, you build a mental model of what it’s doing, you find the parts that bother you, you write your comments. If you break that across two days, you lose the mental model overnight and end up re-reading half the patch the next morning. A review that drags across three days is worse for everyone than a focused day that produces a thorough response.
For my own patches, the day is not the right unit of measurement. This took me a while to accept. When I’m working on something with broad scope, restructuring an execution path, say, or rethinking how locking interacts with pruning, a single day’s work often doesn’t look like much. I might spend a day just understanding the current code well enough to know where to make the cut. Or I spend a day writing code that I throw away the next morning because I realize the abstraction is wrong. That’s fine, actually, but it doesn’t feel fine at 6pm. The unit that works for my own patches is the week. If I look back at a week and I’ve made meaningful progress (the patch compiles and passes tests, or I’ve figured out the right design even if I haven’t coded it all) that’s a good week. If I catch myself feeling anxious at the end of a day because I “only” figured out the right approach but didn’t write much code, I try to remind myself that figuring out the right approach is the work.
I also try not to mix modes within a day. If I start the day reviewing someone else’s patch and then try to switch to writing my own code in the afternoon, the afternoon is usually wasted. I’m still thinking about their design choices, their naming, their approach, and it interferes with getting into my own code’s headspace. Better to make it a full review day and start fresh on my own code tomorrow.
For broader scope work, sometimes dedicating an uninterrupted week works better than trying to make daily progress. If I know I have five consecutive days on a single problem with no reviews or other obligations breaking up the time, I can afford to spend day one and two just reading code and thinking, knowing I have three more days to actually write the thing. I can’t always arrange this, but when I can, it’s noticeably more productive.
This is all well-understood territory.1 People who make things need time in units of half a day at least, a single interruption can destroy an afternoon, and you have to physically partition maker time from everything else rather than interleaving them. Somewhere I read that the limit for hard writing or programming is about five hours a day, beyond which quality declines.2 I think mine is similar, maybe a bit less, which means I really cannot afford to waste any of those hours on the wrong thing or on context-switching between things. A few hours of focused progress every day, even when each day’s delta looks trivial, compounds into a finished patch over a few weeks. You only see that if you’re evaluating your output at the right timescale.
I’ve bought a couple of Cal Newport’s books (Deep Work, Slow Productivity) and I keep going back to them and try to read most things that come through his newsletters. There are ideas in there that match my experience, particularly about judging output over longer timescales and working at a varied pace rather than trying to sustain constant intensity.
I should say something about the panic, because I think it’s common and I don’t see it discussed much. When you have a few days in a row where you don’t produce anything visible, it’s very easy to spiral into “am I even good at this” or “maybe I should be doing something else with my life.” This is especially true when you work on something like Postgres where the feedback loops are long. A patch might take months to get committed, and during that time you’re mostly just pushing it forward incrementally with no external validation.
There’s a version of this where you know you slacked off and the alarm bells are telling you to get back to work.3 That version is manageable. The harder version is when you worked hard all day and still have nothing to show for it. The alarm bells go off anyway, and they’re harder to silence because you can’t just tell yourself to try harder.
The antidote, for me, is having a clear enough plan that I can attribute unproductive days to bad planning rather than to some fundamental deficiency. “I tried to do three different things and finished none of them” is a problem I can fix tomorrow. The alternative explanation, that I’m just not good enough, is almost certainly wrong, but your brain doesn’t care about that distinction at 11pm. Having a plan that I can point to and say “this is what went wrong” keeps the failure in the domain of scheduling, where it belongs.
Paul Graham, Maker’s Schedule, Manager’s Schedule (2009). ↩
Paul Graham, How to Work Hard (2021). ↩
Graham describes this well in the same essay: when he’s not working hard, he can’t be sure he’s getting anywhere, but he can be sure he’s getting nowhere, and it feels awful. ↩