Ask HN: What do you do before you start writing code?

Firstly, time spent learning is not time wasted!

Secondly, the best way to avoid making painful design decisions is... to make them enough times that you instinctively remember them. There aren't many shortcuts to developing that instinct, so take this opportunity to try and generalize your learnings -- what do you recognize now that you didn't see when you started the project? A healthy amount of retrospection will make you a better engineer, and you'll also get better at identifying uncertainties and risks before you start coding.

Lastly, up-front planning and design documents can only get you so far. They're important, sure, but at some point you'll be down in the nitty gritty details, and you'll need to make unanticipated course corrections. As you gain experience you'll start being able to fill in more of those gaps on your own, but until then, you'll want to loop in other engineers more frequently.

One of the qualities of a senior engineer is that they act as a force multiplier for their team. So as a relatively junior engineer, don't be afraid to make use of your senior engineers! They should be there to support you and make you better, beyond just helping you plan out a project. If possible, pair on some of the trickier parts with them, so that you can see how they'd approach the problem and start picking up on things that might not seem so obvious to you right now.

Hope that helps!

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)

there are no such thing of waste of time, except when you delete code. if you have a basic design that code can be used for prototypes. if you have a complex design that code will take your time to handle complex. but if you can't handle all the code you ever write, so the problem is not the code, then you might organize your global assets in a way you can remember how they are organized. but if you are talking about achieving faster your goals then you don't need to code you need lots of people coding and people that can manage a developer team.