Developer productivity without fake busyness

Decide what finished means before the first commit

A suite can go green at 15:40 on a branch you will not deploy. The ticket can already sit in a done column. The flag can still be off, and staging can still be waiting for a click nobody put on a list. Standup will accept "PAY-218 is done" if you offer the sentence. The path a user can hit will not.

Finish over motion means a diff a reviewer can read and a check you can repeat. Points, lines, and a green badge only show that something moved. Write the finish line before you code. For this retry: merged, staging orders 4412 and 4413 retried, flag still off until product confirms the cohort Monday at 10:00 UTC. If you did less, say less.

A passing pipeline is not the release. Say the verify path with the merge, or do not say done. See green CI is not finished work.

Example. Assumptions: you own PAY-218, a webhook retry on one service; staging is reachable from your account; the flag defaults off; no customer traffic is on the new path. Finished is "the pull request merged, orders 4412 and 4413 each retried once on staging with the expected codes, flag still off, product decides the cohort Monday at 10:00 UTC." Stop at the green check and you have a branch. You do not have a change anyone can hit.

Keep that sentence on the ticket. If a rewrite needs "make progress," you still do not have a finish line. When chat asks for a percentage, give locations: "Signature check is in review. Staging has not been clicked. Flag is off."

Name one coding block and its stop condition

Checkout, the test filter, the last dead hypothesis, the file that matters: on a cold branch that often takes about twenty minutes. Use that as a guess until your own notes replace it. Batch messages after the first meaningful commit or the first new failing test. A reply in minute eight spends the warm-up.

Name the block before any timer: file, function, or test. If you cannot, you are browsing.

If the room is shared, set the boundary first, or shrink the slice. Protect focus when you work from home.

Twenty-five minutes holds a review. It does not hold a bug you have not reproduced. Pick a range in choose focus length for real client work, then write the stop condition in words. A timer alone ends when you are bored.

The working set is the failing test, the live hypothesis, the open files, and a tree you understand. Park it, or turn it into an artifact. Deep work for developers. One goal, one branch. A second ticket "just to see" becomes five half-started threads. If that list is the real work, name a scatter day. Five small tickets are harder than one feature. After an interruption, run the filter before you edit.

Fill the five-line start worksheet

Primary: PAY-218 webhook retry, failing test and fix, branch retry-218
Secondary: review PR 512 only if it stays under fifteen minutes
If time: draft staging verify steps for orders 4412 and 4413
Waiting on: suite, about eighteen minutes; no second feature while it runs
First move: open the confirmWebhook test and run the filter

Write the five lines before the project finishes indexing. Decide before the inbox votes.

Bad Primary: "Make progress on checkout and stay on top of reviews."

Good Primary: "PAY-218, failing test for the confirmWebhook retry, fix on branch retry-218, push before the 13:00 review edge."

If the first move is "look at the code," you skipped the line. Open the test, run the filter, read the failure. Secondary is what you do when the Primary lands early and the empty hour offers a new feature. The If time line is safe to delete at 15:00. Rewrite the five lines when an incident takes the morning. On a review day, the Primary is the pile, with a count, not a feature you will not touch.

Rank waiting work by abandon cost

Suites, image builds, and deploys open gaps. Do not spend a gap on work that has its own mental model. Write a waiting list before the command returns, ordered by how badly it hurts to drop.

Uploads and exports follow the same order. See what to work on while a build or export runs. Rank the list before you are bored. While a deploy runs, write the orders, the expected codes, and the flag state you will not change.

Example. Assumptions: the PAY-218 suite takes about eighteen minutes; the retry is still the Primary; PR 512 is a small review; a rename in another package looks tempting. A bad gap is chat until the badge moves, then a red suite and no memory of the test filter. A usable gap: draft staging steps for orders 4412 and 4413, touch PR 512 only if you can park it inside fifteen minutes, and leave the keyboard if both are done. When the run returns, read the failure before chat, confirm the branch, and paste the next command on the ticket.

A long suite can start a second feature and still force you to drop it. Keep one Primary. If reviews are the emergency, name a review day and shrink the feature. Plan a developer day with review and feature work. A flag key in config is not a rollout. Do not add another waiting item because an earlier one finished. That gap belongs to Secondary.

Post a debug banner before you chase the bug

A debug session is a hypothesis, a last command, a snapshot, and a suspicion you have not written down. One message knocks that over, and you pay the warm-up again.

Post one line where people actually look, before you go in:

Debugging PAY-218. Async until 11:30 UTC unless this is a P1.
Hypothesis: signature check drops retries after the first 3DS timeout.
Last command: phpunit --filter confirmWebhook on branch retry-218.

Write dead hypotheses on the ticket as they die. If the ping is not a P1, answer at the next window. If you must leave, sixty seconds: next command, current theory, open files, branch. Interruptions are expensive during debugging. Pairing goes on the calendar, in overlap, with an end.

Still stuck after one honest hour? Stop adding theories. Record the reproduce steps, the last command, the branch, and what you ruled out. Ask one person. If the bug depends on a row, name it: "Order 4412. Fixture retry-218.json. Do not refresh that staging row." Otherwise the next run deletes the evidence.

Hand the branch off with state, proof, next, and blocked

Someone on the other side of the clock can continue your branch only when the note contains a first step. Chat scroll is not that note. Your memory of the afternoon is not that note either. Four fields:

State: branch retry-218, pull request link, staging preview, flag off
Proof: the command or URL that shows current behavior
Next: the first physical step, with the owner's name
Blocked: who owes what, by when, and in which timezone

When another person owns the morning, follow leave work someone else can continue, including what they must not repeat. When you still own the ticket, use the shorter shutdown later on this page. "Almost done," written for someone who is coming, costs them the first hour.

Example. Assumptions: you stop at 17:00 in America/Los_Angeles; QA in Europe/Warsaw starts in the morning; there is no shared live window. Leave the pull request, the failing test, the reproduce command, and "do not rebase; review comments sit on the second commit." If a fix failed: "Do not cycle the worker pool. Already cycled at 16:10 UTC." If they cannot open the preview or the vault path, name who grants access and the UTC deadline. Otherwise the note is fiction.

Judge a metric by the user-visible change

Anything you count will flatter the behavior that moves the count. You will still keep a few counts. Pair each one with a sentence that would stay true if the dashboard went dark.

Example. Assumptions: the PAY-218 branch went green at 15:40; nobody ran the staging clicks; the flag is off; no order has exercised the new code. The flattering line is "PAY-218 done." The accurate line is "Merged. Staging not verified. Flag off." After the clicks, and only then, you may say "Merged. Orders 4412 and 4413 verified on staging. Flag off. Product decides the cohort Monday at 10:00 UTC." You do not get to borrow the verified sentence. The checkpoint behind that speech is the same one in green CI is not finished work.

Five open tickets, a blank pull request, "investigating" with an empty ticket: keep one Primary and a waiting list you will drop. Say "Merged X. Verify steps are in the ticket. Blocked on Y until 16:00 UTC." If you cannot, make the artifact first. "It worked when I tried" needs a command.

Batch reviews at the edges you publish

A review inside a feature block charges the warm-up twice. Publish two edges and keep them dull on purpose. A usable pair is 10:20 to 10:45, and 13:00 to 13:40. During a named feature block the pile waits, unless a pull request is genuinely blocking your Primary and cannot sit for an hour. Large reviews get a clock and a resume line: file, line, and the questions you already posted. "Paused in PaymentsController at the retry loop. The null timestamp question is on the pull request. Next pass starts at the error branch." You can restart from that. "Looked at it" restarts nothing.

Past about ninety minutes of honest review, tomorrow is a review day. Shrink the feature until the board matches the hours. Plan a developer day with review and feature work. Put the verify clicks in the description before you request review. "Clean up payments" cannot finish. "Extract the signature check, update callers, delete the old helper" can.

Answer, schedule, or decline review comments at an edge. Left overnight, they steal the block you named.

Close with a status update you can restart from

When the branch stays yours overnight, skip the long handoff. Write four buckets for the morning, including your own:

Done: pull request link, what you verified, flag state
Open: branch name, test filter, what is still dirty
Blocked: who, what, UTC time, or none
First move: the file or command you will run tomorrow

For a wider audience, use end-of-day status update. When the only reader is you, the restart card in restart coding where you left off tomorrow holds the same facts. Write it at the desk. The kitchen version drops the filter you were sure you would remember.

Example. Assumptions: you are an individual contributor; the Primary is the PAY-218 retry; PR 512 is the only review on the waiting list; overlap with Europe is twenty minutes, and only if the questions are already written down.

Name the day or that clock stays empty. If the pager fires, the next Primary is "stable, and written down," shrunk before standup. If you retried a flaky test until it went green, file the command and the failure before shutdown.

Pick Monday's change from the shape of last week

Change one rule for Monday. Skip the new identity and the new scoreboard. Look at what last week actually left in the repo.

If the room breaks the first block, start with protect focus when you work from home. If a green badge is being treated as a release, use green CI is not finished work. Write the finish line before the first commit, and keep a waiting list you can drop when the build returns.