Writing things down before building them
A paragraph of plain prose catches more problems than an afternoon of code.
Before I write code for a new project, I write a paragraph. Not a spec, not a diagram — a paragraph, in ordinary words, describing what the thing does and who it’s for.
It sounds like a small habit. It has saved me more time than any tool I’ve adopted.
Prose doesn’t let you hide
Code lets you defer decisions. You can stub a function, leave a TODO, build the easy half and tell yourself the rest will become obvious. Prose won’t let you. If you can’t describe what happens when the list is empty, you don’t know yet, and the sentence stops dead until you do.
Half the projects I’ve abandoned, I abandoned because of a question I could have answered in writing on day one.
It makes cutting easy
When the paragraph becomes three paragraphs, that’s the signal. Something has crept in. It’s far easier to delete a sentence than a feature you’ve already built and grown fond of.
My rule: if the description doesn’t fit in one paragraph, the project is too big for me right now.
It becomes the explanation
The nice side effect is that when the thing is finished, you already have the text for the homepage, the README and the message you send a friend. You wrote it before you were too close to the project to explain it simply.
Try it on something you’ve already started
Take a project that’s stalled and write the paragraph now. In my experience you’ll either find the missing decision within ten minutes, or you’ll realise you stopped because the idea was never quite there. Both are useful answers.