Two jobs compete for one brain
Feature work needs a loaded working set: hypothesis, files, failing test, uncommitted diff. Code review needs a different load: someone else's intent, style constraints, risk scan across unfamiliar paths.
Both are real engineering. Doing them in the same hour without a plan means neither gets depth. Notifications turn review into snacking and features into stop-start fragments.
A planned developer day names which hours belong to which job, and what "enough" looks like for each.
Example: unplanned Tuesday
Example: Calendar shows one standup and "open time." You start a feature at 09:15. At 09:40 a review request arrives. At 10:00 standup asks for ETA. At 10:20 you review while half the feature model lives in RAM. At 11:00 another review. By lunch the feature is unchanged from yesterday and reviews got shallow comments.
The day felt full. Output is thin on both ledgers.
Example: meeting-light day with named blocks
Example:
- 09:00-11:00 feature block (primary: merge checkout fix)
- 11:00-11:30 review batch (blocking PRs only)
- 11:30-12:00 standup and park note
- 13:30-15:30 feature block
- 15:30-16:30 review batch (non-blocking queue)
Naming blocks beats hoping open time sorts itself.
Name the day type first
Before opening the IDE, pick one primary type:
Feature day: two defended composition blocks, reviews only if blocking others, batched at edges.
Review day: morning and afternoon review windows, one small fix or doc task between if energy allows.
Mixed day: explicit split, not default.
Mixed without naming is how planning eight hours into eight hours fails.
Put reviews at block edges
Reviews interrupt feature depth most when they land mid-loop. Prefer edges: before standup after a park note, after lunch before afternoon block, end of day when you will not return to feature anyway.
If your team expects same-day review, publish your feature windows so authors know when you batch. Predictability beats heroic instant response.
Size feature blocks to the loop
Match block length to compile-test cycle and meeting placement. Deep work for developers describes ending with a reviewable artifact, not hours at keyboard.
Short loop: forty to fifty minutes may suffice if meetings allow stacking two blocks with a break.
Long loop: ninety minutes or pair machine waits with admin from work while build runs, not a second feature.
Cap review load
Review capacity is finite. Decide maximum pull requests or maximum diff size per batch. When the cap hits, defer with a note: "Batch full until 15:00; will pick up 4421 then."
Deferring with time beats silent queue growth that blocks teammates while you pretend to feature work.
Blocking reviews versus backlog reviews
Blocking: author's feature cannot proceed without your comment. Schedule these inside the next batch window, escalate if truly urgent.
Backlog: can wait without stopping others. Fits batch edges on feature days.
Treat blocking review as coordination debt. If it happens daily, team work-in-progress limits may be wrong.
Standup and planning meetings
Standup mid-morning feature block is expensive unless you park first. Meetings destroy engineering throughput counts prep and reload, not only slot length.
If meetings cluster, call it coordination day and shrink feature ambition to one finishable slice.
One primary outcome per day
Write one line in the morning plan: "Merge payment retry idempotency with staging verify" or "Clear review queue through 4418."
Secondary outcomes are optional. If primary completes early, pull from backlog consciously.
Afternoon energy realism
Plan low energy afternoons realistically applies: hard feature composition morning, reviews or small fixes afternoon if that matches your curve.
Do not schedule deep unfamiliar refactor at 16:00 because the calendar is empty.
Handoff between blocks
When leaving feature block for review batch, park: commit or stash, failing test output, next line to edit. Restart coding where you left off tomorrow applies same-day after lunch.
When leaving review batch for feature, close review tabs, note any follow-up comments you owe, then reload feature context with your park note.
Split remote workday pattern
Split remote workday for focus and coordination aligns with feature morning and coordination afternoon when that matches team time zones.
Finished means more than green CI
Reviews should ask whether done criteria are met, not only style. Green CI is not finished work belongs in reviewer checklist: staging verified, flag state noted.
Team norms that make the plan stick
Response-time expectations for review, no-meeting windows, and definition of done reduce surprise work that breaks the plan.
Individual calendar blocks fail when culture treats every ping as urgent.
Weekly rhythm
Some teams use review-heavy Monday and feature-heavy midweek. Pattern matters less than explicit naming each morning.
Freelancers on client code should contract review turnaround if same-day is expected; otherwise feature estimates lie.
Measure the right output
At shutdown, note artifacts: merged feature, meaningful review comments that prevented rework, staging verify notes - not "worked on API."
If days end with green branch and empty review queue, you planned feature but served neither finish nor teammates.
Planning a developer day is choosing where depth lives and where batching lives. Put reviews at edges, cap their load, defend composition blocks, and write one primary outcome you can verify at 17:00. ## Remote time zones and review fairness
When reviewers sit eight hours ahead, their morning review batch may hit your evening feature block. Publish rough windows in team doc so authors know when to expect first pass without demanding instant global sync.
Fairness is predictability, not identical local hours.
Tech debt days
Some teams schedule fix-it Friday as review-heavy or small-ticket heavy. Name that day type so feature carry-over is expected, not shameful. ## Make the habit visible
Put the next review on calendar before you close this week. One recurring block beats remembering when tired. If the habit slips, shrink the review to fifteen minutes rather than skipping entirely - continuity matters more than perfection.
Example: what changed this month
Example: Billable ratio fell because sales calls doubled. Maintenance choice is raise quote for new work and batch sales to two afternoons, not pretend the old ratio still holds. Write that sentence in your rate note so January you is not guessing. ## Make the habit visible
Put the next review on calendar before you close this week. One recurring block beats remembering when tired. If the habit slips, shrink the review to fifteen minutes rather than skipping entirely - continuity matters more than perfection.
Example: what changed this month
Example: Billable ratio fell because sales calls doubled. Maintenance choice is raise quote for new work and batch sales to two afternoons, not pretend the old ratio still holds. Write that sentence in your rate note so January you is not guessing. ## Make the habit visible
Put the next review on calendar before you close this week. One recurring block beats remembering when tired. If the habit slips, shrink the review to fifteen minutes rather than skipping entirely - continuity matters more than perfection.
Example: what changed this month
Example: Billable ratio fell because sales calls doubled. Maintenance choice is raise quote for new work and batch sales to two afternoons, not pretend the old ratio still holds. Write that sentence in your rate note so January you is not guessing.