The questions I ask before writing any code
The most expensive code I've written wasn't buggy. It worked perfectly — for a problem nobody actually had.
So before I open the editor, I ask four questions.
1. What problem does this solve, and for whom?
If I can't say it in one sentence without naming a technology, I don't understand the task yet. "Add a Redis cache" is a solution. "The dashboard takes eight seconds to load for every manager" is a problem.
2. What does "done" look like?
A screen, a number, a test that passes. Without a clear finish line, a task keeps growing until someone stops it.
3. What already exists?
Half the time there's a helper, a component or an endpoint that does most of it. Twenty minutes of reading beats two days of writing something the codebase already has.
4. What's the smallest version a real user can touch?
Not the smallest version of the product — the smallest version of this change. Ship that, watch it get used, then decide what comes next.
The honest nuance: this isn't a meeting or a document. For a small task it's five minutes in my head. The point is that the questions get asked before the code — not in code review, when changing direction costs ten times more.
Writing code is the fast part. Knowing what to write is the job.
What do you check before you start coding?