1. Specification as a reflex to begin work
Tommy opens a clean TASK_SPEC — before the code, first thing. His hand reaches for the form on its own, before he even has time to think, “I should.”
— Once, I was more afraid of this blank screen than anything else, — he chuckles. — I would freeze up like before an exam: where do I start, which words are right. And now I don’t know how to do it any other way.
He does not rush; he talks it through out loud right in the document:
— The rewards calculation is lying somewhere — that’s the problem. What the behavior should be — the target. What we touch — scope, what we leave alone — right here. What I’ll check, which branch I’ll start from, where the checkpoints are.
Before, every second sentence came out vague, and it had to be rescued. Now the lines come together cleanly on the first try. The form, which once felt like a duty before the “real work,” has become a way to explain the task to himself all the way through — so he won’t wander later. Not a barrier before work. Its first step.
2. One task in one spec, not two
The most grown-up thing about this form is what it does not contain. He is already tempted to squeeze in live data here too, and while he’s at it, revive the portal, why make two passes.
— Oh no, buddy, — Tommy says to that itch. — I know you.
He shuts down the temptation. The spec contains only the core fix, one, clean. He sets the second add-on aside in a separate line: “for later, in a short pass, if the main loop is closed.”
And this is not bureaucracy for bureaucracy’s sake — he knows from experience what happens when you cram two tasks into one: neither gets finished calmly, and both quickly start getting in each other’s way.
— I’ll do everything now, maybe I’ll even have time to bolt on some magic, — he says out loud. — First the fix that needs to be done. Magic is a bonus on top.
The Tommy who wants everything at once, and wants it flashier, has never disappeared inside; in earlier days, that voice was the one steering him. Now Tommy hears it, smirks — and calmly puts it in the queue. The thrill did not go away. It just is not in charge anymore.
3. A good spec does not need rescuing
Tommy hands the form to Alex for a review. On the screen is that same TASK_SPEC he put together in five minutes, without suffering:
# TASK_SPEC — reward-flow award calculation fix
DEFECT: application points are calculated incorrectly (the level multiplier is wrong)
TARGET: award points according to rules.md; the leaderboard gets the correct number
SCOPE: only reward-flow.js
NON-GOALS: do not touch the layout, leaderboard, partner area, or /legacy
CHECK: award test — red on the bug, green on the fix; leaderboard screenshot
BRANCH: fix-reward-flow, checkpoints after the test and after the fixAlex skims the spec and only asks for a couple of small clarifications — the task stands on its own; nothing needs rescuing.
— Clean, — Alex says. — There’s nothing to fix here. Remember how it used to be? You’d bring your spec back, and there was not a living part left in it: “what does ‘fix the calculation’ mean? which behavior is correct? how will you know it’s done?” Every other question was about what you hadn’t managed to formulate yourself.
— I remember, — Tommy answers. — You used to pry the task out of me. And I got offended, thought you were nitpicking.
— And now you closed everything yourself, even before me, — Alex writes back. — What about the plan, though — are we going to talk that through separately?
And Tommy talks it through himself, without waiting:
— Yeah, nothing much. First the plan without edits, I’ll look it over and tweak it, then the implementation. Same as always.
For Tommy, this is not even a separate technique. The plan stopped being a trick you switch on when needed — it simply became a way to begin: the one who once could not even frame a toy task now writes the spec and the plan because he can and wants to, not because the heat is on.