tags:

views:

377

answers:

16

I personally write out any program that is not a throwaway script on plain paper. Mostly, this is so that I have something to do during the more boring classes, but I actually feel that it has done a lot for the quality of my programs. Generally, when I jump right in and code, a lot of hacks come into the code and it is generally of lower quality. Also, I tend to run into mental walls, and just seem to take more time to finish. Because I write things out, I can see how things are going to turn out, and can form a better structure, and the ability to write notes in the margins is nice. When I tell this to friends however, they just feel that it takes longer as you can actually test written paper, and you cannot move blocks of code around when they are in ink.

Does anyone else write out their programs, or am I pretty much alone in this?

A: 

No, you are (more or less) alone.

Tom Hawtin - tackline
(Good job this is community wiki.)
Tom Hawtin - tackline
+10  A: 

I like to sketch block diagrams & data flows (example) on paper before punching on a keyboard.

Since my throughput/bandwidth to paper is much higher than drawing on the computer, I am able to identify quickly major bottlenecks/difficult spots.

To put it simply, I still use pen & paper because it helps me be better prepared when I get to hit the keyboard. Saves time & finger pain ;-)

In other words, pen & paper contribute to the "design phase" still. Better planning --> less unforeseen problems.

jldupont
Paper is invaluable for anything diagram related. I have tried multiple times to use tools for these, so that I could save/update these diagrams: I always revert to paper, because it just works and in design phase, I don't want the tools to get in the way of my thinking.
Mathias
I also use online tools such as MindMeister and Gliffy but nothing beats the transfer speed "brain to paper" just yet.
jldupont
Good answer. Also, I'm perfectly capable of pulling out key points in a block of text without being inundated with bold ;).
Simucal
@Simucal: I am glad to hear this: it must be my "marketing side" showing here :-)
jldupont
+1  A: 

You are not alone my friend. I begin and troubleshoot my programs on paper, it is easier for me to quickly jot down notes and to visualize exactly what my programs doing. Only to an extent though, I haven't exceeded more than a page and a half. Plus it serves as a benefit, it gives my eyes a break at staring at a computer the whole time.

Anthony Forloney
+2  A: 

Unfortunately I've gotten too dependent on intellisense.

However, it is my plan to study C# in depth (is that the name of a book?), so that I can eventually hack together any piece of code in a simple text editor like the one on SO (or a piece of paper for that matter), get upvoted to the sky for every post I make, and eventually surpass John Skeet in rep, in my quest for eventual world domination.

Robert Harvey
A: 

I've done it that way. Back in the '90's when I wrote in Ada and C, it helped a lot to write the whole thing out slowly and carefully.

Now that I use Python [Edit: and Java], that kind of meticulous planning isn't necessary.

S.Lott
Proving once again that Python is the holy grail of programming nirvana.
Robert Harvey
@Robert Harvey: nirvana? Really. I thought it was just laziness.
S.Lott
A: 

Perhaps it's the program design aspect of the writing that actually helps you write a better program.

Jon Seigel
+3  A: 

I can't bring myself to write code on paper, but pseudocode or notes to structure my thoughts are another story. Maybe I'm crazy, but the physical act of writing does tend to help me focus more.

Whether other people do it or not is largely irrelevant -- you want to spend your time and effort in a way that maximizes your efficiency. If writing things out on paper helps, then by all means do it, and don't let other people's methods and opinions change your mind.

Jim Dagg
A: 

For general programs I don't, I just jump right in there, however If I am planning a class/object/array structure then I will try to map it out first on paper.

This also helps if I need to iterate through an array, its easier to see what you need on paper, than looking at nested for/foreach/while loops.

Psytronic
+2  A: 

You are definitely not alone. I live and die by my whiteboard. There is something about being able to actually handwrite information down that makes it easier to think about a problem.

With that said, I don't particularly like paper. Creates too much clutter. But, overall, the idea is the same. Writing = Good for Thinking

JasCav
A: 

It depends on how complex of programming is involved. When dealing with something complex, it helps to write things down (though I usually prefer a white board to paper). OTOH, I've never written down complete code on paper, so typing it in was just a matter of transcription -- to me that would represent a monumental waste.

I suspect, however, that it often depends on your relative proficiency at typing and writing. My handwriting is horrible, and I find it almost painful to write more than a few sentences at a time. I'm much more proficient at typing, and can do it for hours without a problem.

The things I'd typically do by hand are most often diagrams of some sort or other though -- class diagrams, state machine diagrams, etc. Like jldupont, it's often quite a bit faster to do some sketches on paper than trying to use a diagramming tool (though the tools come in handy if you have to make presentations of the diagrams).

Jerry Coffin
+5  A: 

I'd never write code by hand, but a data model and a flow diagram live and die on my whiteboard daily.

Dean J
+1  A: 

In general I sketch out object interaction and precious little else. I can't stand over designing things. It has its advantages on some sorts of projects but i work in R&D and over-designing causes chaos when you realise an assumption you made is wrong at a later date.

I also make all sorts of notes on paper when debugging. So yeah having paper around is invaluable.

You won't catch me writing code down on paper though! :)

Goz
A: 

Conceptualize and break down into smaller chunks by hand and paper.

Code on the computer.

Wadih M.
+1  A: 

Write on paper? Nah, I punch it onto 80 column cards.

anon
... difficult to recycle/correct mistakes then ;-)
jldupont
On the contrary. Recycled punch cards were used for several purposes back in the 60s and 70s, particularly for activities that involved erm, "inhaling".
anon
+2  A: 

I do this whenever there is complicated logic or flow control. It helps me to write out pseudo code on paper. It's a good way to kick start your brain into thinking about the problem in the right context. I sometimes just solve the crux of the problem on paper and then finish on the computer. Personally, the computer is a bit of a barrier when trying to capture my thoughts.

When I do transfer from paper to computer I can focus on good variable names, syntax and good programming practices. Since I have solved the problem I can enjoy the programming. This generally results in less time debugging pebcak errors.

A physics professor once gave me good advice to read through an entire test before starting answering questions. The brain will work on problems in the background while you are answering questions. I think writing programs on paper is a similar type of brain trick.

Cadoo
A: 

I have the same experience.

Before I start on a program, I normally sketch UI (if it has a UI), class diagrams and write pseudo code for some important methods. I feel that this approach speeds up the developing process and reduce the chance of messing up code.

If I directly write code on a computer without the instruction of any diagram or pseudo code, it's easy for me to get lost. I think it may be caused the fact that on a screen, you cannot see the all the code at a time.

For example, whenever you need to modify some code snippet that's out of the current view of the text editor, you need to make an effort to get there by scrolling, select the text by moving cursor, and then type in something, and after you finish the modification, you'll have another hard trip get back to the spot you were previously working on. By the time you've made a round-trip on the text editor, you might probably forget what you were doing, or you might start to do another thing instead of the one you planned without even noticing it.

Bryan