bdunbar: WRONGDunbar is learning some flavor of Scheme* which I applaud heartily. Anyway, it seems like everyone who codes has strong opinions about paper-and-pencil programming, so I thought I'd put my thoughts online as well.
When I learned how to write code we were expected to flowchart, then write the code down on graph paper, then enter it into the terminal. I can see the wisdom of that approach. On the other hand, it's easy to write fast, make mistakes, then move on. On the gripping hand it's easy to jam along and and not learn anything.
All the best coders I know learned by paper-and-pencil. A lot of them have moved on to the make-mistakes-but-make-them-quickly school where you just dive in head first and iterate your way to a good solution.** I do that a lot myself.*** But we all started being able to trace the value of a variable, or figure out how many times a loop would execute, or determine the output of a weird function on paper. I strongly believe you need to learn that first in order to be able to implement the rapid iteration style later.
I see too many undergrads who have gone through a year or more of programming and still get completely befuddled when they have to interpret some code printed on a piece of paper. The simplest things like resetting a counter back to zero are too complicated for them. And as a result they're bad at iterating their code to a better solution. I've watched them debug, and without the ability to interpret code themselves they're reduced to randomly changing lines until it does what they want. So if it was up to me, and all my friends who TA intro classes, everyone would start with pencil and paper. (Are you listening, AP exam writers? We need fewer questions about the specifics of Java's inheritance rules, and more "What does this code do?" questions.)
The sin qua non of good programming is being able to put yourself in the position of the compiler or interpreter and see the code from its point of view. Working on paper forces you to do that. You must be able to see your code not as you intend it to be or as you think it will work, but as it actually is and actually does.
* Perhaps the same one I was taught in my undergrad intro CS course, but now rebranded as "Racket." I suspect as much, but the LISP family tree is a hoary thicket I'm not going to try to navigate right now.
** See: Solving the wrong problem.
*** Though I don't get the opportunity often. When you're trying to create software based on a particular model that you can later express in equations and diagrams in an academic publication, you have no choice but to start with the model on paper. AI programming -- and graphics, from what I understand -- is a little different from other programming in that respect.