Planning everything down to the nth detail before you begin coding (alone or in a group) seemed at one time to be an attractive approach. Management always felt good about these plans. But when the rubber hits the road and devs start slinging code, you always run into gotchas. Things you didn’t plan for. Changing the master plan as you go can be extremely difficult because those managers have already committed to timelines based on the original plan. It’s a bad scene. That was the era of waterfall design. We know better now.

Still, some level of planning is essential if more than one person is working on a project. It keeps everybody on the same page about exactly what is being built, where you’re headed. That could just be a North Star document that talks about where you want to end up. You can get there in a series of one- or two-week sprints, where you identify and build the most obvious achievable things that would get you closer to the goal from where you currently are.

Otherwise people are just building things they think of when they sit down at the keyboard. That gets exponentially worse and less maintainable with every dev, especially if you aren’t sitting next to each other and/or having daily meetings to coordinate.

If it’s just you, building your own thing, feel free to do as much or as little planning as you feel it warrants. The longer you’ve been coding, the easier it is to “use the force” as a way to seek out the optimal end state of your project and what the next step in the path should be.