The Questions I Ask Before Writing Any Code

The best part of a project happens before I open an editor.

Not because writing code isn't satisfying. It is. But by the time I'm typing, most of the decisions that actually matter have already been made, quietly, in the thinking that came before.

The first question is rarely about code at all. It's about the problem itself, not the version someone hands me, the actual thing underneath it. People ask for features. They rarely ask for the problem to be solved in the simplest way it could be. Sitting with that gap for a while, before writing anything, tends to save weeks later.

Then there's the question of who inherits this. Not in the abstract, specifically: someone, in roughly two years, who wasn't in the room for any of these decisions, opens the file cold and has to make sense of it. I try to write for that person more than I write for today's deadline. It changes what feels acceptable. A shortcut that saves an afternoon now can cost them a week later, and they won't know why, because the reasoning lived in my head and never made it into the code.

Simplicity gets asked about constantly, though rarely out loud. Can this be simpler is a question worth returning to at almost every stage, not as a rule but as a habit. The honest answer is usually yes, not because the first version was wrong, but because the first version is rarely the simplest one. It's just the first one that worked. Most of the value in revising code comes from noticing that difference.

I also try to imagine the same system carrying twice the weight. Twice the users, twice the data, twice the edge cases nobody thought to mention. Software rarely fails gracefully under growth. It fails at the exact point nobody stress-tested, because nobody imagined the project succeeding quite that much. Asking the question early is cheap. Discovering the answer in production is not.

Underneath all of it sits the question I find hardest to ask honestly: what am I assuming right now that I haven't said out loud. Every project runs on assumptions, about data, about users, about how something will be used. The ones worth worrying about are the ones so obvious they never get mentioned. Naming them doesn't make them disappear, but it turns a wrong assumption into a known risk instead of a surprise.

None of this shows up in the finished thing. Anyone using it has no way of seeing the questions that shaped it. They just experience the outcome, whether it happens to hold up or not.

I don't think good software starts with good code. I think it starts with good questions, asked early enough that the code gets to stay the easy part.