
Ask HN: To what extent do you “sketch” as you program? - adamzerner
In Hackers and Painters, Paul Graham talks about how he &quot;sketches&quot; as he programs:<p>&gt; For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.<p>&gt; For a long time I felt bad about this, just as I once felt bad that I didn&#x27;t hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you&#x27;re writing them, just as writers and painters and architects do.<p>Do you do this too? To what extent?
======
davismwfl
I probably fall somewhere in the middle and err on the side of paper still. I
absolutely always start with pencil and paper and get the basics laid out and
then after I think I have identified all the first level problems and issues
I'll start building in code. If I find that I missed issues though, I'll
return to paper and update my model and rethink it . Then go back to code, and
usually I find this means I'll change less code to make things work in the
end. At some point there is no point of going back to paper for minor design
changes while you are actively developing things though, however I find having
& maintaining a high level model, an architecture model and a roles &
responsibilities model in documentation form is super helpful and can reduce
the time to get up to speed, find issues etc.

FWIW, I also have been writing code for a long time and have worked on
projects where to compile the entire code base with tests could take hours of
machine time to complete, there was no concept of quick change/compile/test
cycle for the entire product (maybe small modules). So you absolutely designed
things and thought through them first, then moved to code. Obviously
interpreted languages now and shorter compile times means you can sit there
and experiment and it sometimes is faster then thinking through the problem at
least at first, but I'd argue people who do this still usually miss a number
of cases and will have to return to the code more then the person who laid it
out and through through it (regardless of if they did that on paper or in an
electronic document etc).

I have worked with people that do both methods, I have my preferences and like
the tradeoffs I take, but I would be hard pressed to say one way is right or
one is wrong, as long as you get to the same end goal in a reasonable time
period I really don't think it matters.

