HACKER Q&A
📣 adamzerner

To what extent do you “sketch” as you program?


In Hackers and Painters, Paul Graham talks about how he "sketches" as he programs:

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

> For a long time I felt bad about this, just as I once felt bad that I didn'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're writing them, just as writers and painters and architects do.

Do you do this too? To what extent?

  👤 davismwfl Accepted Answer ✓
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.