Programming By Hand

By: Amy M Haddad

I was like a fish out of water without my laptop by my side.

I needed a new computer battery, so I left my MacBook at the Apple store. I was hoping that they’d simply swap out the old battery with a new one on the spot.

That was wishful thinking. “Your computer should be ready within three days,” I was told. I’m sure my eyes bulged open and my face turned white when I heard that response.

How does a programmer program without a computer for three days?!

The answer: by hand. So that’s what I did.

I settled in at my empty desk with the problem statement and more primitive tools: a notebook, and a pencil. It was time to get to work.

The Artist-Programmer

Using a notebook and a pencil has always been part of my problem-solving practice.

Each problem I solve or program I write starts the same way: I open up one of my many artist sketchbooks and draw sketches and write pseudocode. An artist sketchbook offers plenty of space to get my ideas down.

But the main reason for using a sketchbook is because writing and drawing are means of thinking for me. The problem becomes easier to reason about by making the abstract concrete with a sketch or diagram. In the process, I also find myself really understanding what I'm being asked to do.

If I can get my ideas fully flushed out on paper, then the code flows much more easily and naturally. These are reasons why I turn to my artist sketchbook first—before I type a line of code. It’s also why I sometimes feel like an artist-programmer: I spend a lot of time sketching out my ideas, like an artist, before heading to my editor.

Although I’m accustomed to spending a good portion of my programming time scribbling and doodling on paper. I’m not accustomed to spending all of my time there. Eventually, I do make it to my editor.

However, without a computer, I had no other option: I spent all of my programming time getting the problem working on paper.

And I’m glad I did. It taught me some valuable lessons.

Visualize your Code

The first of which is the importance of visualizing your code and having a mental model of its execution.

I couldn’t write tests and use the errors they produced to inform me of the code that I needed to write. I couldn’t insert a few print statements to spot a bug. Instead, I had to carefully step through each line of code and visualize in my mind (and on my paper) what was happening at each step, and potential errors that could happen along the way.

Now I realize that this might sound incredibly laborious. And, it was. But the work was worth it.

Our code editors are valuable tools. We need them. But sometimes we depend on them way too much; programming by hand reminded me of that. Many of us are guilty of “just running the code to see what happens,” instead of thinking through and anticipating the result ourselves.

Working through the problem from start to finish in a notebook forces you to “see” what happens. This will help you be more thoughtful in your code selection.

You’ll take more time thinking through the pros and cons of using a hash map versus an array, as you carefully walk through the code on paper with each data structure. You’ll think more carefully about potential edge cases. All of this thinking will test your knowledge and help you justify your code selections.

Since there’s no feedback from a failing test, you’ve got to work through all of the possible scenarios of what could go wrong—and why. That means, you’re constantly questioning your code, asking yourself “why” and “what if …”.

And that’s a good thing. The more I questioned my code, the more I began to see it from multiple perspectives—instead of a single one, the approach I thought of initially. This leads to the second benefit of solving problems by hand: doing so will boost your creativity.

Boost Your Creativity

I was well on my way writing approach "A” on my paper, when I stopped myself. “What if …”.

There I was questioning my code, thinking about it from another angle. I was considering the edge cases that would break my first approach. So I started thinking through approach "B.”

“Approach A could work,” I reasoned to myself. "But approach B seems much more promising. Plus, it'll reduce the program’s complexity by a landslide."

So I began the problem-solving process again, with a new approach. I’m convinced that if I had my editor handy I would’ve gone down a rabbit hole trying to make my first approach work. I probably wouldn’t have considered another approach until I got the first one working, even though the second one was by far the better of the two.

The bigger picture is understanding why I even began thinking about multiple approaches and how I came to them. I’m pretty certain it has to do with actually writing lines of code on paper. It was the programmer's version of freewriting.

Many writers, including myself, use freewriting as part of their writing process. The aim when freewriting is to pour your ideas on paper for a set amount of time. Many see this as a way to tap into the unconscious mind, which can offer interesting thoughts and insights. This is a reason why I use freewriting in each article I write.

I also saw the benefits of freewriting as I was coding on paper. The effect was the same: interesting ideas and insights, which led me to my new and better approach.

Be Resourceful

Perhaps the biggest lesson of all is that solving problems by hand teaches you to be resourceful: to do more with less.

After I solve a problem, I sometimes add a constraint: something I must do or remove from the problem, as a little extra challenge. For example, re-solve the problem without using a conditional statement. Adding a constraint is a way to stretch myself a bit and to get outside of my comfort zone.

Well, when solving a problem by hand, the constraint is not having your computer. There are no tests to run. There’s no documentation to reference. It’s a great practice for dealing with ambiguity and having to figure things out, which is really what we do as programmers each day. It’s also great for building a mental module of your code.

Get It Working on Paper First

As it turned out, Apple under-promised and over-delivered. They called the next day saying that my computer was ready to be picked up.

Once I got my hands on my laptop, I put my hand-written problem into a Vim file to check the result. Did my program work?

Not quite. I must admit, there were a few tweaks here and there. But soon enough the tests were passing, and my hand-written code working.

I can’t say that I’ll solve every problem by hand entirely from start to finish. But there’s a lot of value in getting the problem to work on paper first.