This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 100+ Q&A sites.

ComicStix asked:

I'm a freshman Computer Science student and we just started doing some actual projects in Python. I have found I'm very efficient when I use the pen and paper method that my professor suggested in class. But when I can't write my problem down and work my algorithms out on paper I am really slow. During labs, I always seem to have to take the assignment back to my dorm. When I get there and write it out I solve the problem that took me the whole class in like 5 minutes.

Maybe it's because I get stressed seeing people solving labs before me. Or maybe it's the pen and paper method.

I was browsing through forums and someone wrote that if you have to write your programs on paper then you shouldn't be a programmer. I'm really worried because I'm so much better when I can see what the program is doing and track my way through it before typing actual code. Am I doing something wrong?

See the original question here.

Practice makes perfect

Karl Bielefeldt answers (55 votes):

There's nothing wrong with working out your algorithms on paper first. Not so much for everyday coding, but for more complex algorithms, professional programmers work them out on paper or a whiteboard all the time, especially if a graphical format makes it more clear. For a student, every program is complex.

If you want to get better at designing algorithms at a computer, though, there are some techniques you can practice. Don't just start by writing out the code, write the same things you would put on paper as comments, then expand it into real code or more detailed comments one by one.

For example, if I'm deleting an element from the middle of a linked list, I might start with something like:



// find the element

// point the previous element to the next element

// How do I get a pointer to the previous element?

// doubly linked list?

// another find?

// keep track during the first find?

// delete the element



Then I might replace // find the element with a function with more pseudocode, and keep going until I have a complete solution. Don't think code has to be written in a linear manner.

Related: "How much design to do first?"

Sketch it out

alroc answers (2 votes):

I don't put actual code down on paper, but for anything non-trivial I almost always start out on a whiteboard or a notebook. I usually sketch out:

Algorithms/process/control flow

Data structures

Relationships

Components (how do I break this problem down)

It's usually a combination of sketches, pseudocode, and English.

I find that by doing this, it's easier to visualize as I start coding. I also will spot flaws before I start into the code because I can see everything in front of me (instead of incessant scrolling and window-hopping). Not only that, once it's written out I can let things form in the back of my mind as I'm working on other tasks. I can also work in a non-linear fashion, committing an idea to paper when it hits me and then come back to it when I reach the point where I need it.

Committing something to paper is a tremendous help for memory retention. The tagline for the Field Notes brand of notebooks is this:

I’m not writing it down to remember it later, I’m writing it down to remember it now.

After taking a more focused approach to writing things down on paper, even if I make an entry in the ToDo app on my phone a moment later, I find that the thought is cemented in my head far better than just making the electronic note. In other words, by planning my coding on paper/whiteboard, the ideas stay in my head better.