Hacker News Reader

Comment by m0nastic | Hacker News Reader

I hesitate to recommend my process to other people, because I don't think I'm a very good programmer.

But for the past year or so, I find that I program best by actually writing out my program in a notebook (in my case a quad-ruled lab notebook). I don't even start typing until I have it laid out pretty much in it's entirety on paper.

This sounds ridiculous (and I can imagine it's not practical for all types of programming), but I've found that it's been tremendously helpful in getting me to understand what all the code that I'm writing does.

Most of the code I've written this past year has been in Haskell, so that helps somewhat by not having a lot of syntax to write down, but I'm sure I'd be doing the same thing even if I was writing in Java.

View on HN

I find it very hard to convince my students to pull out a pencil and a notebook before they start coding.

"Draw some pictures. Make some notes. Write a function that you suspect will be tricky. Make a flowchart. List the methods that will have to be in that class. Write out how the user will interact with it. Try to list all the pain points for the user. You can write it any way that helps you think. Make up a notation if you want."

Yes, the assignment is due and they need to get code on the screen. But one of these days I'm going to give them a programming assignment and tell them that I only want to see their notes.

Paper rules.

I had to add a new feature to a decades old user facing codebase with had to interact with all of the existing system. The implementation of the core of the new feature took only a few hundreds of lines of code since it was just a bunch of graph operations basically. Interfacing with the rest of the system was hell.

I began by just investigating the requirements and designing on paper. I realized on my paper designs quickly that a few graph operations would be sufficient. Understanding how it fit with the rest of the system was only achievable to me by documenting for myself on paper how the bits and pieces worked I had to touch.

Took half a year to get the sucker ready.

Worked just like it was supposed to and my colleague praised how easy the codebase was to extend later on.

Paper and carefull design. It just rules.

As a beginner I recall myself asking other programmers "is using pen and paper cool before writing any actual code?" and they giggled before nodding in agreement.

I had this false expectation in my head that when programmers tackle a new problem (be either writing a small program or solving a challenge) they're able to think about it for a few minutes then straight up write code and if I can't it's because I suck and this job isn't for me.

Then I realized that what I expected was unrealistic and the "no pen and paper" stage only occurs to people who already met the same or similar challenge before and can recall even the slightest hint of what they did back then.

I think most people would agree that writing things on paper first is a total necessity if you are writing mathematical code (I mean, are you going to do the equations in your head and type them out?), and I think the benefits to paper increase in proportion with the mathiness.

On the non-mathy side, I find it useful to take the concept of "rubber duck" debugging (which is totally applicable to original design and creation, and not just debugging) but write a "duck" document rather than talk out loud. Aside from not looking crazy, I find writing easier for thought organization.

Sometimes preparing slides can also be a nice way to really force your thoughts into simplest and clearest form. And hey, when you're done, you can present it to your co-workers.

Paper is my favorite programming tool. The beauty of paper is that it's easy to find out when you're wrong, when you're pursuing the wrong path, without going deeply in and getting distracted by the small-scale details of the code.

This gets right back to the design thing.

To put it another way, it's far less time-consuming to edit a Word document than it is to update an entire production system.

No, I need to get away from the computer completely. Word docs (or any other computer typing) is still bound by the computer structure and the computer distractions.

With paper, I can draw graphs of relationships, write tables, add notes to things I drew earlier, etc. It's far more expressive, and far faster, than any computer tool I've tried.

This is the way I work too. I don't handwrite pseudocode, but I draw data structures and relationships in varying degrees of granularity at least until I'm sure I understand the problem. Only then do I begin writing tests and coding.

Paper is awesome. I find I rarely visit my notes afterwards. I just need a medium to spit out my thoughts, or I end up going in circles. As soon as I flush to paper, then my mind is unblocked to go solve the next problem. Most of the time, I remember most of what I've written down, so the paper is write-only.

My best work I do while half-napping with a notebook by my side.

No matter how you do it, taking notes on paper is very good.

One advantage, I think, is that we can type faster than we can write with pen and paper. Thus paper is a more deliberate medium than a keyboard is.

Reply on news.ycombinator.com