First 10 minutes of a coding sprint

Fast-start guidance focuses on reducing preflight: pick a target, set a timer, close chat. This guide assumes preflight happened and asks: what does professional motion look like in minute three? That is where branches, baselines, and verification live.

Confirm you are in the right repo, right profile, and right VPN or cloud shell if needed. Open the ticket or note that defines done for this sprint. Close unrelated tabs that will tempt you—especially email and social—so attention residue does not accumulate before you touch code.

Create or checkout a branch with a name tied to the ticket. If you are on main by accident, everything after this is borrowed time. Re-read the acceptance criteria once—if it cannot fit in the timer, cut scope now, not at minute forty.

Run the narrowest test that proves your starting point: unit tests for the module you will touch, or a typecheck if that is the fast signal. The goal is not green CI for everything—it is knowing whether the ground is stable before you pile changes on top.

Make the smallest change that moves the work forward: a failing test that captures the bug, a stubbed function, a log line behind a flag. Write the next action in one sentence in your notes if you use them. If you cannot name the next diff, you are still planning—shrink the target.

If dependencies are broken or main is red, your sprint might need to be “fix local dev” instead of “ship feature”—that is valid work, but it should be named explicitly so you do not feel fraudulent when the timer ends without a product diff.

Replace “smallest diff” with “smallest observation”: reproduce, log once, bisect. The first ten minutes still need a stable branch and a test or script that proves the failure—otherwise you are reading code at random.

• Reading docs without a targeted question.
• Refactoring “while you are here” before the failing test exists.
• Sliding into Slack to “ask one quick question” that becomes twenty minutes.
• Starting a merge or rebase you are not ready to finish inside the sprint.

In a typed frontend repo, minute five might be pnpm test components/Button after you branched from main. In a JVM service, it might be ./mvnw -pl auth verify -DskipITs when integration tests are too slow for the opening gambit. In Go, go test ./... might be acceptable if the module is small; if not, narrow packages.

The pattern is constant even when commands change: prove the floor before you stack behavior on it. If your team’s CI is the only truth and local tests are flaky, write that risk down in the ticket and choose the smallest honest signal—sometimes a compile or a linter run is the best you can do in ten minutes without lying to yourself.

Data and ML work may spend the first ten minutes on environment: kernel ready, dataset path mounted, GPU visible. That is still legitimate “first minutes” work—just name it as environment setup so you do not confuse it with model experimentation.

Some codebases need twenty minutes of CI to tell you anything useful. In that world, the first ten minutes inside a local sprint might only establish branch + partial signal. Consider splitting work: one sprint to reproduce locally with logs, another sprint after you have a faster test harness—or negotiate team time to improve the feedback loop because no personal ritual fixes thirty-minute builds.

If you routinely exceed ten minutes to get signal, track that separately from “focus.” Slow verification is an engineering tax that accrues interest every sprint; fixing it belongs on the roadmap, not only in your evening guilt.

The first ten minutes are where intent becomes verifiable engineering motion: branch, baseline signal, smallest next step. Nail this pattern and the rest of the sprint spends time on the real problem—not on rediscovering that you were on main.