[itamarst]

Over time these small wastes-of-time will decline, as you get more experienced and learn from feedback. But there's also the really big wastes of time: working on wrong thing, and building something with assumption that turns out to be false. The latter has been a problem for me recently, so been working on it by adding step 4 below.

Here's vague model of what I do:

1. Figure out what's really important to achieve: ask why you're doing something, what the constraints are. Figure out if you really have best solution, maybe there's different way to solve real problem.

2. Sketch out a design, in my head or in writing depending on complexity.

3. Figure out riskiest assumptions.

4. Try to build smallest possible end-to-end proof-of-concept implementation. This will validate or invalidate assumptions, and usually influence design in some way.

5. Start on real coding.

(If you'd like to learn from mistakes I've made over the years, in design and testing and writing software, I write a weekly email with a mistake and what I learnt from it: https://softwareclown.com)