I've started writing more pseudocode before tackling problems and it's helped a lot in sussing out the general control flow / structure of what I intend to write, basically helping with the programming equivalent of writer's block.
It got me to wondering - what else do people do before ever putting hands to keyboard?
Obviously there's documentation, meetings with stakeholders, project prep as this whole thing, but I was thinking more for narrower concerns - you're adding a small feature on a mature product or writing a one-off script - what do you try and do beforehand?
I find it useful to write out a workflow of things the code will need to do from a high level.
Ex: “Validate form input” or “filter API response based on submitted criteria”
Those become doc blocks for functions and classes.
Then I break those down into more granular directives still more abstract than pseudo code.
Ex: “determine whether name input is alphabetical” or “iterate response. check contents of all 3 phone fields against submitted value”
Writing both code and tests against that then becomes nearly trivial.
I do database schemas, GUI layouts, and control flow plans on paper before putting code down.
For example, in adding lens correction profile support to my photo editor, I used paper to track which camera brands have what exif fields that I need to get lens names.
Then I worked out the logic of how/whether to enable corrections on images that had been edited in the past.
As a result of this planning I do, new features usually work almost entirely as expected, first time.
Mine is similar to CarVac, but I also rough out some Use Cases, and I rarely do GUI as I hate doing GUIs. When thinking about the design if there is a part I think is tricky I might pseudo code it. If it keeps me from sleeping I will actually write it out.
I first try to explain the problem, and then potential solutions, to either a beta user or someone non-technical. I'm lucky to have a very patient wife regularly fill this role.
If the solution is trivial and can be completed in an hour, I'll just code it from there.
If I think it'll take a day or more, I'll write down both the problem, and potential solutions, along with pros and cons for each approach, with the focus on trying to justify my actions to Future Me.
If I think multiple people are going to want to know how it ticks, I'll write a design doc and share it with some beta users.
I've found it to be frustratingly common that when I skip this process I will code the first solution that comes to me. This frequently is neither the simplest to implement nor the most efficient approach.