Programming on Paper

Ages ago, during my first year of computer science at the university, one of the recurring complaints was about the stupidity of implementing programs on paper. Reasoning was usually around memorization and libraries and how it is or is not the essence of programming. At that point, I didn't really care about it. I labelled it as "probably stupid" and put it around the most random conversation topics in my mind. I was more interested in mailing integer sequences to my favourite lecturer at very particular points in time after midnight.

Around third year, we had microcontroller laboratories where, among other things, we used Motorola 6800. Sometimes we ended up at the whiteboard discussing selected implementations. Sometimes it was even closer to golfing. I didn't think much about it and this time nobody was complaining.

oeis a55 in mail

Shouldn't we have complained though? After all, these two are similar in their lack of computer in the process and necessity to remember things.

First difference is in the people. Four or five semesters is a significant time in this kind of environment. Those who complained might have just failed. Although, I doubt we changed our views. If anything, we were in survival mode. Years later I hear similar complaints from people that went through this exact or matching process.

Second difference is in the intent and scope. Golfing in a small ISA with your drink buddies is a fun exercise. Pascal exam written on paper during your first semester when you have no clue whatsoever is not.

But, can it be made fun or useful?

Quack! Consider rubber duck debugging method. In essence, we attempt to resolve a problem by explaining it aloud. The idea is that by doing so we need to step back, think it through, choose correct vocabulary, and put it in a frame. In other words, we formalize the problem and define our solution to it if any. In process of doing so we may come up with resolution.

golfing on whiteboard

Both fun and useful, although, there's no piece of paper and it's usually a pure natural language explanation and not a programming one. But the golfing example suggests that a whiteboard—so a written medium—along with a variation of programming language works as well. In the end, we pick language and vocabulary based on our intent and discussion partners. If writing machine code on white board works, so be it. If a mathematical explanation of problem is required, that works too.

And, of course, plain code is also fine. It's the most basic communication language for programmers. Not just between us and computers, but especially between one another.

Does a programming exam written on paper work? No.

However, using programming languages to express ideas and problems does. Knowing vocabulary and idioms will help with it, so working towards them is a decent goal. It's just not a starting one. After all, we don't hand dictionaries to toddlers expecting them to converse with us. We have fun with words and expand horizons over time. Same here, we first build stable foundations in selected syntax, build intuition around it, learn how platform works and then expand. On the way, we memorize things and it's equally important.

Let's have fun then. And let's not only write code, but talk about it and talk using it. On paper, e-mail, code review, whiteboard, napkin, or with beer in hand. Let's refine how we use programming languages and then have even more fun.