Live data from Hacker News

How I Write Code: Pen and Paper

noteflakes.com

21–30 of 110 posts

Re: How I Write Code: Pen and Paper

#21
Heh... Growing up in Jamaica in the 80's, my brother and I wrote code on paper this way, before we got a computer.

We bought the books, wrote the BASIC code and rewrote it many times until we thought it was good.

Once the computer came though, all that went out the window. But to this day, my desk is covered in notebooks that help me visualize problems before writing any code.

I sketch out UI. Design database schemas. Draw data flow diagrams and end up with many, many, many notebooks finished up every week. I don't know if it makes me any better as a developer, but whenever I do it, I feel more confident approaching the computer and working on a solution.

Re: How I Write Code: Pen and Paper

#22
All of Dijkstra's EWDs are manuscripts[1]. As far as I know all of his seminal algorithmic work was done with pen and paper. When he was first programming it was just after the second World War and Dutch programmers could only manage to beg about 1 hour of computer time a week from the US occupation. So they got very good at writing programs with the technology they did have, pen and paper. As always, restrictions breed creativity.

I personally really enjoy pen because it makes you own your mistakes.

[1] https://www.cs.utexas.edu/~EWD/

Re: How I Write Code: Pen and Paper

#23

A lot of authors still use a pad and pen. And of course many take notes with it. One of the advantages— perhaps the main advantage — is that the notepad doesn’t have an internet connection.

pretty sure it's a generational thing, and unfortunately, a disappearing habit.

Re: How I Write Code: Pen and Paper

#24

Earlier quoted context omitted.

Can I ask if you ever had any kind of art/drawing type of classes? I very often turn to sketches as my first attempt. I will often turn to paper first. I can sketch things faster than using something like Sketch. Maybe it's because I come from a wood working background where rough/not-to-scale sketches with dimensions written in were common just to double check your cut lists. Mearsure twice, cut once. Also, I'm old…

I haven't really had art classes, no The problem I run into when I'm brainstorming or thinking about high-level architectural/modeling questions, is that if I start drawing something I get focused on how to represent my current idea and I stop actually developing the idea itself. And then if I change my mind, I have to go back and erase or strike things out instead of just redirecting my thought. Etc. Usually if some…

For diagramming, I really only do it to document connections between things. Everything is either a chunk of text, optionally in a box or circle; a line or arrow; or a note beside the first two. It emerges directly from what I'm thinking without much extra thought, and usually gets discarded or rewritten before anyone else reads it, or if there's too much crossed out.

Sort of like a swap file, where if the number of items gets bigger than my working memory, I dump some of them onto a sheet of paper rather than thinking about all of them at once.

I'm interested in hearing how other people approach diagrams, because I bet there are a lot of different approaches, and no one size fits all.

Re: How I Write Code: Pen and Paper

#25
post #24

Earlier quoted context omitted.

I haven't really had art classes, no The problem I run into when I'm brainstorming or thinking about high-level architectural/modeling questions, is that if I start drawing something I get focused on how to represent my current idea and I stop actually developing the idea itself. And then if I change my mind, I have to go back and erase or strike things out instead of just redirecting my thought. Etc. Usually if some…

For diagramming, I really only do it to document connections between things. Everything is either a chunk of text, optionally in a box or circle; a line or arrow; or a note beside the first two. It emerges directly from what I'm thinking without much extra thought, and usually gets discarded or rewritten before anyone else reads it, or if there's too much crossed out. Sort of like a swap file, where if the number of…

Right but as soon as I've written down a blurb or drawn a line I feel like it's set in stone a little bit. It feels like a decision. It isn't necessarily - I can always erase it or draw it again on a new page - but that carries friction which interrupts the process.

It works better at the phase after ideation, where I'm pretty sure I have the major ideas in place and I want to see them to make sure they make sense. But even then I prefer a digital medium because of how easy it is to delete or modify (even an eraser leaves behind a smudge, adding something to a list on paper means moving each item by hand, etc).

Re: How I Write Code: Pen and Paper

#26
I used to code in pencil during the day at school, so I could test when I got home (and avoid boredom). These days I'll still sometimes use paper if I'm trying to optimize some inner loop assembly, easier to draw the code and the data side-by-side when both are changing.

Edit:

This line resonated with me:

> Maybe someday I’ll be able to handwrite code on an e-Ink device and then run it.

Are there successful projects for pen-based programming? I've read about Grail as a historical footnote, using hand-drawn flow charts: https://wiki.c2.com/?GrailSystem

Re: How I Write Code: Pen and Paper

#27

Earlier quoted context omitted.

Can I ask if you ever had any kind of art/drawing type of classes? I very often turn to sketches as my first attempt. I will often turn to paper first. I can sketch things faster than using something like Sketch. Maybe it's because I come from a wood working background where rough/not-to-scale sketches with dimensions written in were common just to double check your cut lists. Mearsure twice, cut once. Also, I'm old…

I haven't really had art classes, no The problem I run into when I'm brainstorming or thinking about high-level architectural/modeling questions, is that if I start drawing something I get focused on how to represent my current idea and I stop actually developing the idea itself. And then if I change my mind, I have to go back and erase or strike things out instead of just redirecting my thought. Etc. Usually if some…

I identify with this so much. Pacing, talking to myself even yes, but always manipulating concepts in my mind - and writing the code once it becomes clear. The idea of introducing diagrams or sketches into that process sounds disruptive and distracting at best.

Re: How I Write Code: Pen and Paper

#28
Server is running out of juice, here's a cached text-version from Google: http://webcache.googleusercontent.com/search?q=cache:8XIZNjh...

On a similar note as the author, I enjoy stepping away from the screen to code, though it's mostly for problems I'm stuck on. There's been many times where I've been lying in bed thinking about a problem and I suddenly think up a possible solution in my head and then run to my computer to type it out to see if it resolves the issue.

Re: How I Write Code: Pen and Paper

#29
When starting on a complicated program, I've learnt over decades that the longer I draw diagrams and write code on paper before turning to the computer, the clearer I am about the program and the quicker it gets done. When I get totally clear about everything, the code writes itself, and I can write it down on paper as fast as I can write. Plus then when you type it in you can really 'write clean code', or halfway clean anyway. If I start typing straight away, it tends to be spaghetti.

Re: How I Write Code: Pen and Paper

#30
post #24

Earlier quoted context omitted.

For diagramming, I really only do it to document connections between things. Everything is either a chunk of text, optionally in a box or circle; a line or arrow; or a note beside the first two. It emerges directly from what I'm thinking without much extra thought, and usually gets discarded or rewritten before anyone else reads it, or if there's too much crossed out. Sort of like a swap file, where if the number of…

Right but as soon as I've written down a blurb or drawn a line I feel like it's set in stone a little bit. It feels like a decision . It isn't necessarily - I can always erase it or draw it again on a new page - but that carries friction which interrupts the process. It works better at the phase after ideation, where I'm pretty sure I have the major ideas in place and I want to see them to make sure they make sense.…

>Right but as soon as I've written down a blurb or drawn a line I feel like it's set in stone a little bit

Use a pencil, and not a pen ;-) Much less permanent. Just knowing you can erase should make it feel less decisionish. For me it's the opposite. If it's a sketch on paper, it is so much more transitional. Once it's in code and executable, it makes me want to keep forcing things until it works. But that's what makes it fun. Each dev sees the same problem totally differently and approaches it in their own way.

Post reply on HN