How much time should you spend planning a commit before writing code?

Firstly: when coding for a living, especially as a junior in a team, typically not much design work is needed. This is because you'll be working in an existing code base. Chances are, you'll often be working on a feature that is similar to existing features, so you can look at those as an example. This is nowhere near as boring as it may sound; you'll be learning plenty of things, still need to understand the examples and adapt them to suit your needs.

Designing something new can indeed be much harder, but it is also much rarer, especially when you're a junior developer.

That is to say: in a typical junior-level development job, I don't think you'll run into the things you're worried about. Or at least to a far smaller extent.

If I don't do this amount of planning, I just end up writing code that will have to be undone

I would argue that for most developers, this is fairly normal, if they are developing something that is novel (to them and their existing code base).

I do that planning sometimes, and when I start writing the code, I often realise that the plan translates to an awkward implementation that feels forced or over-engineered.

... which is good to know! Coding provides feedback on the plan.

Planning and coding are very much iterative processes. You plan a bit, try to create some code with the planning in mind, which makes you realise that you overlooked something during planning, so you adjust the plan, code some more, rinse, repeat.

I like to think that this is also how artists work. It's a creative journey. Often messy, sometimes boring, sometimes exhilarating, sometimes frustrating. Sometimes you end up with something boring that just works, sometimes with something beautiful that doesn't work. And, every now and then, with something that works and is beautifully elegant.

[I] don't like wasting any code I've already written and try to recycle it as much as possible (my precious).

Throwing code away is fine! The code has already served a useful purpose: it provided feedback on the planning. It helped you iterate.

Someone said that programming isn't about how fast you can type, it's about how fast you can think. I'm not very good at thinking fast.

Neither are most people, especially if they have to do the thinking without seeing any code. Coding helps to make things concrete. It may also obfuscate the bigger picture, so zooming in (code) and out (planning) is part of the iterative process.

It's also worth noting that people, after years of professional experience, develop a kind of muscle memory for specific approaches, and an instinct for applying these. Which is half the battle when making something new. You cannot be expected to have that already (nor should you expect it from yourself).

Put differently, the examples in existing code bases that I mentioned at the top of this answer are in their heads now, and they can apply them in new projects as well.

I think I'm overly cautious making my productivity not economically viable, but even still its far too easy for me to waste a whole lot of time making a mess of my codebase.

I think you're being too hard on yourself (I can relate). Try to change your mindset to allow the iterative process, to embrace the creative journey.

And code that just works (and is readable) is good enough. If later on, new requirements or new features means that the code is no longer good enough, you can adjust it. That adjustability is the reason the world moved away from specialised hardware and embraced software (running on generic hardware).

Edit:

Also, small steps are good, and focussing on making it work first, and only then making it right is also good. If you already have working code, the planning gets easier because there are fewer unknowns an hypotheticals. Relevant quote is relevant:

First make it work, then make it right Kent Beck

in the smallest steps you can manage. Uncle Bob Martin

(source)

As always, everything is more nuanced in practice, and I don't completely let go of design when focussing on making it work.

Solved by user172016 (654 )
Aug 07, 2022 at 09:00