Plan, then code
Recently I saw this tweet in a screenshot on a LinkedIn post.
The post was about improving business writing, but the original tweet was about software engineering.
For me, the main sentence within the tweet is, "Resist the urge to do something before having a plan." - or as the LinkedIn post said, "Resist the urge to start typing before having a plan.".
This is something that I've focused on a lot over the last few years, always asking, "What problem are we trying to solve?" and using flow charts and ADRs or technical design documents to come up with a plan before starting to write any code.
Doing this makes me think of and answer as much as possible upfront - what we need, how things should work, the required steps, and what edge cases and pitfalls there might be. I'll usually have two or three solutions I'll consider and document, as well as which I decided to use and why.
Once I've planned the solution, coding is usually very fast and straightforward, as most or all questions should already have been answered. I don't need to stop and answer questions whilst writing the code, and the code should be cleaner as I'm coding to the plan rather than figuring it out as I go.
- Oliver
