
Ask HN: How do you “pre-code”? - webappsecperson
I&#x27;ve started writing more pseudocode before tackling problems and it&#x27;s helped a lot in sussing out the general control flow &#x2F; structure of what I intend to write, basically helping with the programming equivalent of writer&#x27;s block.<p>It got me to wondering - what else do people do before ever putting hands to keyboard?<p>Obviously there&#x27;s documentation, meetings with stakeholders, project prep as this whole thing, but I was thinking more for narrower concerns - you&#x27;re adding a small feature on a mature product or writing a one-off script -  what do you try and do beforehand?
======
mceachen
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.

------
gshdg
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.

------
CarVac
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.

~~~
thecupisblue
Similar - having it on paper gives me higher agility in thinking and writing
than any computer tools. Maybe discuss it out loud with someone. As I write it
down, the code and the flow starts popping in my head and by the time I get
down to actual writing it's already thought through.

------
sloaken
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.

