Name the day: Feature, Review, Mixed, or Coordination
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. Before coding, pick one primary day type and write one line: "Today is feature-heavy; primary = merge payment retry with staging verify" or "Today is review-heavy; primary = clear queue through 4418." Put reviews at block edges with a size cap. Mixing unnamed types is how planning eight hours into eight hours fails.
Name the day type first
Before coding, pick one primary type. Mixing unnamed types is how planning eight hours into eight hours fails.
Feature-heavy day: two defended composition blocks; reviews only if blocking others, batched at edges; one merge-ready or staging-verified primary.
Review-heavy day: morning and afternoon review windows with a stated cap; one small fix or doc task between if energy allows; primary = "clear queue through ticket N with meaningful comments."
Mixed day: explicit split written in the morning plan, not the accidental default.
Coordination / meeting day: shrink feature ambition to one finishable slice; do not pretend you still have a feature-heavy day.
Write one line: "Today is feature-heavy; primary = merge payment retry idempotency with staging verify" or "Today is review-heavy; primary = clear queue through 4418."
Worked schedule: feature-heavy Tuesday
Assumptions for this worked example: standup 11:00, one optional sync 16:00, your sharp hours are morning, team expects same-day review on blocking PRs only.
| Time | Block | Rule |
|---|---|---|
| 09:00-11:00 | Feature block A | Phone/chat silent except production; park before standup |
| 11:00-11:30 | Standup + park note | Do not re-enter feature mid-standup without park |
| 11:30-12:00 | Review batch (blocking only) | Cap: two PRs or one large diff |
| 13:30-15:30 | Feature block B | Same primary as morning unless morning finished |
| 15:30-16:00 | Review batch (non-blocking) | Cap: remaining queue or timebox thirty minutes |
| 16:00-16:30 | Optional sync or shutdown | Shutdown names merge/verify state |
Primary outcome at 17:00 must be verifiable: PR open with tests, or merged with staging note - not "worked on checkout." Green CI is not finished work belongs in your own definition of done for the day.
Worked schedule: review-heavy Wednesday
Assumptions: five open PRs waiting on you, one small bugfix you own, afternoon energy usually lower (plan low-energy afternoons realistically).
| Time | Block | Rule |
|---|---|---|
| 09:00-10:30 | Review batch 1 | Blocking PRs first; write real comments, not emoji |
| 10:30-11:30 | Small fix / doc | One branch only; park if unfinished |
| 11:30-12:00 | Standup + queue status | Publish "next batch at 14:00" so authors stop DMing |
| 13:30-15:00 | Review batch 2 | Non-blocking and follow-ups; hard stop at cap |
| 15:00-16:00 | Admin / CI follow-ups | Rebase notes, request changes, merge when criteria met |
| 16:00 | Shutdown | List what still waits and when tomorrow's first batch is |
Cap example (GetToWork rule of thumb): three medium PRs or one large unfamiliar service per batch. When the cap hits, defer with a time: "Batch full until 15:00; will pick up 4421 then." Deferring with time beats silent queue growth.
Put reviews at block edges
Reviews interrupt feature depth most when they land mid-loop. Prefer edges: after a park note before standup, 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. When reviewers sit eight hours ahead, their morning batch may hit your evening feature block - post rough windows in the team doc so fairness is predictability, not identical local hours.
Blocking vs backlog reviews
Blocking: author's feature cannot proceed without your comment. Schedule inside the next batch window; escalate if truly urgent. After two async rounds on the same design disagreement, pairing may cost less than another ping-pong.
Backlog: can wait without stopping others. Fits batch edges on feature days.
Treat daily blocking-review pile-ups as coordination debt. If it happens every day, work-in-progress limits may be wrong - too many parallel features asking for instant review.
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 you can stack two blocks with a break. Long loop: ninety minutes, or pair machine waits with admin from work while build runs - not a second feature.
When leaving feature for review: commit or stash, paste failing test output, write next line to edit (restart coding where you left off tomorrow applies same-day after lunch). When leaving review for feature: close review tabs, note follow-ups owed, reload from the park note.
Meetings and day-type honesty
Standup mid-morning feature block is expensive unless you park first. Prep and reload cost more than the slot length - see fewer better remote meetings. If meetings cluster, call it coordination day and shrink feature ambition.
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.
Tech debt / fix-it Friday: name it review-heavy or small-ticket heavy so feature carry-over is expected, not shameful.
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 a green branch and an empty review queue you ignored, 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.
Structure a remote workday aligns with feature morning and coordination afternoon when that matches team time zones. Use it when the calendar already fragmented the day - do not invent a mixed day out of guilt.
Unplanned Tuesday vs named Tuesday
Unplanned: 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.
Named feature-heavy: Same standup. Morning plan line says feature-heavy; primary = merge checkout fix. Reviews only at 11:30 (blocking) and 15:30 (backlog). Authors see your windows in the team doc. At 17:00 you either have a PR with staging notes or a park card with the next failing assertion - not five half-started threads.
Publish one sentence in Slack or the team channel on review-heavy days: "Review batch full until 14:00; blocking PRs still welcome with @mention." Predictability reduces DM snacking during feature blocks.
Freelancer and client-code twist
If same-day review is in the SOW, price the review-heavy days into the estimate. If it is not, say so: "Feature estimates assume review responses within two business days; same-day review is a separate capacity reservation." Otherwise you sell feature-heavy calendars and deliver review-heavy ones for free.