How to plan a developer day with review and feature work

The month I was everyone's fastest reviewer

For about a month on a remote team, I was quietly proud of my review turnaround. A pull request would land, the notification would slide in, and within ten minutes I'd have left comments. People thanked me in standup. It felt like being a good colleague.

What I wasn't doing was finishing anything. The ticket I owned, a rework of how a client's booking form handled half-saved drafts, had been "nearly there" for eight working days. Every morning I'd load it up, get the failing test running, start tracing why a draft was saved twice, and then a review request would arrive. Twenty minutes later I'd come back with somebody else's code in my head and my own failing test looking like a stranger's.

Then I overcorrected. I muted everything, blocked out whole days as focus time, and finished the booking form in two days flat. During those two days, a frontend colleague had a small pull request sitting in my queue that blocked her afternoon. Twice. I had swapped one failure for another: before, my feature starved, and now the team did.

What actually fixed it was boring. I started deciding each morning what kind of day it was, and I gave reviews a specific place in that day instead of letting them go everywhere or nowhere.

I started deciding each morning what kind of day it was, and I gave reviews a specific place in that day instead of letting them go everywhere or nowhere.

Feature work and review load different things into your head

Feature work needs a working set: the hypothesis you're testing, the four files that matter, the failing test, the uncommitted diff, and the half-formed idea about what to try next. Review needs a different working set: someone else's intent, the constraints they were under, the risky paths through code you didn't write, and the team's conventions. Both are real engineering. Neither is the warm-up for the other.

The annoying part is that they don't share memory well. When I switch from my feature to a review, I don't pause my working set, I overwrite it. Coming back costs ten or fifteen minutes of rereading before I'm useful again. And a review squeezed into the gap between two feature thoughts is usually a shallow one. I've approved things in that state that I would have questioned an hour later with a clear head.

So the planning problem isn't really "how much time do I have". It's "which of these two loads am I carrying today, and when do I swap".

Name the day before you open the editor

Before I open anything, I write one line in my day note. Four types cover nearly every day I've had:

• Feature day. Two defended blocks on one primary piece of work. Reviews happen only at the edges, blocking ones first.
• Review day. Two review windows with a stated cap, plus one small fix or doc task between them if there's energy left.
• Mixed day. An explicit split, written down in the morning. Not the thing that happens when you don't decide.
• Coordination day. Meetings, planning, a release. Feature ambition shrinks to one slice you can actually finish.

The line itself should be specific enough to check at 17:00: "Feature day. Primary: draft-save fix merged, with a staging check." Or: "Review day. Primary: queue cleared through the payments refactor, with real comments."

This sounds sensible until you actually try it, and then the first thing you notice is how often you were planning a feature day on a calendar that was obviously a coordination day. Three meetings and a release window is not a feature day, however much you want it to be. Pretending otherwise is exactly how planning eight hours into eight hours fails: the plan assumes depth the calendar never offered.

Diagram

A feature day, block by block

Here's what a feature day looks like for me when it works. The assumptions: standup at 11:00, an optional sync at 16:00, my sharpest hours in the morning, and a team that expects same-day review on pull requests that block someone, not on everything.

The slot that makes this work is 11:30. Anyone blocked on me waits a morning at most, which is about what people tolerate before they start sending direct messages. Anyone who isn't blocked waits until 15:30, and in my experience they rarely notice.

By 17:00 the primary has to be something I can point at: a pull request open with tests, or merged with a note about what I checked on staging. "Worked on the booking form" doesn't count. Neither does a green pipeline on its own, for reasons I've written about in green CI is not finished work.

A review day, and why the cap matters

Review days happen when the queue has grown: five pull requests waiting, one small bug of my own, and an afternoon I already know will be slower than the morning. I stopped fighting that afternoon dip a while ago (plan low-energy afternoons realistically explains how).

The cap is my own rule of thumb, nothing more scientific than that: three medium pull requests, or one large change in a service I don't know, per batch. Past that, my comments get worse. I start pattern-matching instead of reading, approving things because they look like code I've approved before.

When the cap hits, I defer with a time attached: "Batch is full, I'll pick up the export change at 15:00." That one sentence does more for the team than heroic speed. People can plan around a known time. They can't plan around silence, and silence is what they get from a reviewer who is quietly drowning.

Reviews belong at the edges of blocks

A review interrupts feature work most when it lands mid-loop, while I'm holding a hypothesis I haven't tested yet. It costs almost nothing at an edge: just after I've written a park note before standup, straight after lunch before the afternoon block, or in the last half hour when I wasn't going back into the feature anyway.

So I publish my windows. On that remote team it became one line in the team doc: "I review at roughly 11:30 and 15:30 my time. Mention me directly if something is truly blocking." The time-zone part mattered more than I expected. A colleague eight hours behind me opened pull requests near the end of my day, which meant my 11:30 batch the next morning was, from her side, overnight turnaround. Once that rhythm was written down, nobody felt ignored, because it was visible.

Blocking and backlog are different queues

Not every review request deserves the same speed, and treating them all as urgent is how you end up back in the fastest-reviewer trap.

A blocking review is one where the author can't continue without my comment. It goes into the next window. If it truly can't wait that long, it gets a direct mention and I'll break a block for it. If the same design disagreement has gone two rounds in comments without converging, I stop typing and suggest a short call, because by then pairing usually costs less than another round of ping-pong.

A backlog review can wait without stopping anyone. It fits the afternoon edge on feature days and the main windows on review days.

If blocking reviews pile up every single day, that isn't a personal scheduling problem. It usually means the team has too many features in flight at once, all waiting on the same two reviewers. I raised that in a retro once, and the fix turned out to be a limit on work in progress, not faster reviewing.

Swapping modes without losing the thread

The switch is where most of the damage happens, so I've made it mechanical.

Leaving feature for review: commit or stash with a message I'll understand later, paste the failing test output into the ticket, and write down the next line I intend to change. It's the same habit as restarting coding where you left off tomorrow, just applied over lunch instead of overnight.

Leaving review for feature: close every review tab, note any follow-ups I owe, and reread the park note before touching code. If I skip closing the tabs, I'm back in someone else's diff within ten minutes, "just checking" whether they replied.

The length of a feature block depends on the loop. If my compile-and-test cycle is short, forty-five minutes is enough for a useful block. If it's long, I want ninety, and the waiting inside it goes to small chores on the same task (what to do while a build runs), not to a second feature and not to the review queue.

Meetings decide the day type if you don't

Standup in the middle of a morning block is expensive unless I park first. Two or three meetings scattered across a day make it a coordination day, named or not. I'd rather name it, shrink the ambition to one finishable slice, and be pleasantly surprised than plan a feature day and feel like I failed by 17:00.

Some teams run a fixed weekly rhythm, say review-heavy Mondays and feature-heavy midweek. That works fine. The pattern matters less than naming each day in the morning. A fix-it Friday is a small-ticket day, and carrying a feature over the weekend after one is expected rather than a failure.

The freelancer version: reviews are capacity you're selling

When I'm working inside a client's repository, review turnaround is part of the deal whether anyone wrote it down or not. If they expect me to review their in-house developers' pull requests the same day, that's capacity I'm reserving, and it belongs in the estimate. If it isn't in the agreement, I say so up front: "Feature estimates assume I review within two working days. Same-day review is a separate reservation."

Otherwise I end up quoting feature days and delivering review days for free, and the estimate looks wrong for reasons nobody can see in the ticket history.

What I check at 17:00

Before I close the laptop I write down artifacts rather than activity: what merged, which review comments prevented rework, what's verified on staging, and what's still waiting on me along with when I'll get to it.

The failure I watch for now is the one from my muted-everything phase: a feature branch I'm proud of and a review queue I quietly ignored. That day looks productive from my chair and expensive from everyone else's. Planning a developer day comes down to two decisions made before you open the editor, where the depth lives and where the batching lives. Make both in writing, tell your team the second one, and reviews stop feeling like interruptions because they finally have somewhere to go.