Coding on Paper
Coding as a process, not a product
If you liked this post, you should support me with a paid subscription. It’s $100 a year, or $10 a month, and in return you get well-researched machine learning/mathematics deep dives such as Machine Learning is Not Just Statistics, Matrices and Graphs, or Vectorization in Theory + Vectorization in Practice.
Your support makes it possible for me to write these high value, high signal posts every week.
Hey!
It’s Tivadar from The Palindrome. Before we dive into today’s post, I’d like to ask you a favor.
I’m running a short reader survey to better understand who you are, what you’re working on, and what you’d like to see more of.
I’ll use the results to improve the newsletter and help match it with better sponsors. Individual responses won’t be shared, and your contact information will only be used if you explicitly opt in.
If you complete the survey, you’re an absolute legend. More importantly, you’ll be helping me make The Palindrome even better.
Thanks!
Let’s get back on track. Today’s post is a video-essay version of one of my earlier posts. This is a new format I’m experimenting with, turning my non-technical writing into podcast-like experiences that you can listen to while driving or perhaps washing the dishes.
I’ve been focusing on videos lately because I find the medium better suited to my technical content. If you enjoy my posts, don’t forget to subscribe to my YouTube channel!
Cheers,
Tivadar
Video version
Written version
The single most useful programming exercise I ever did was also the one I hated most: writing C code with a pen, on paper.
When I was a young mathematics student, one of my first university courses was called “Introduction to Programming,” where the computer scientists in our faculty threw us, innocent and naive mathematicians, straight into the deep end.
In the Eastern school system, we believe in immediately applying pressure so intense that it weeds out the unworthy faster than they can chug their welcome drinks at the regular semester launch parties. So, fifteen minutes into the first lecture, we were already dereferencing pointers left and right, because everything else was trivial. At least, according to our professor.
And by the way, this was the same in our math courses. The first sentence of our linear algebra class was “let F be a field, then V is a vector space over F if...”. And just like that, our heads went spinning.
I remember having classmates so technologically inept that they could hardly manage to navigate in Windows XP (the most popular OS at the time), let alone compile C code. So, the “Introduction” to Programming class felt like a punishment for most of us.
And the rock bottom of our whole miserable experience were the coding-on-paper exercises, where we had to write functioning C programs with a pen, on paper.
Coding on paper is antithetical to how we code in practice. Whenever I’m working on a project, I never move in a straight line. I refactor. I bugfix. I go back and forth.
These days, large language models write most of the code I ship. (Even the animation you are watching right now was written by Codex, my coding agent of choice.) But when I actually write the code myself, I use Jupyter Notebooks, where I take a shot at implementing the function, test it on a couple of examples, and fix all the dumb mistakes I’ve made, perhaps even prompting an LLM or two meanwhile. (Or Googling when I feel old school.)
None of that is available on paper. No autocomplete, no syntax checks, no code formatter.
With pen and paper, you can’t run the script, you don’t have autocomplete, and once you’ve written the “code,” you can’t really change it.
It’s linear, uninteractive, and tedious. Coding on paper felt like a punishment.
Is there a point?
I used to believe there wasn’t; now I know there is.
The revelation finally came by drawing analogies, my Number One Tool for noticing patterns. Sometimes, patterns are hard to see in the thing we’re looking at directly. But when we look at something similar, suddenly patterns become obvious.
(Sometimes, we are emotionally charged, like I am about coding on paper, which I used to hate. However, taking another perspective helped me see clearly.)
So, let’s talk about a different problem. What do you think about having an LLM write your essay for you?
Even when generative AI is allowed, you cheat yourself by outsourcing your cognition to a language model. The purpose of writing lies not only in the final outcome, ready to transfer your thoughts to other minds, but in forming those thoughts as well!
What is writing? As said by Donald M. Murray in his famous essay “Teach Writing as a Process Not Product”, writing is
“...the process of discovery through language. It is the process of exploration of what we know and what we feel about what we know through language. It is the process of using language to learn about our world, to evaluate what we learn about our world, to communicate what we learn about our world.” - Donald M. Murray
Coding - that is, engineering and building systems - is also a process, not just a product.
Here’s the catch: you can only get better at delivering products if you master the process. There are no shortcuts.
“But Tivadar, how to master the process?”, you might ask.
By practice. Lots of practice. And by far the best way to practice is to restrict your tools. To make it as hard as possible.
Have you ever seen an athlete exercise with a mask that limits airflow? That’s just to make things hard, to help them perform even better when the restriction is lifted.
When I was practicing Kung Fu, our trainer instructed us to practice complex moves with our non-dominant hands. This technique is magic: after stumbling around with a wooden stick in my left hand for a couple of minutes, I could effortlessly perform the flashy movements with my right hand, which is my dominant one.
Another example: I love playing video games; a significant portion of my life skills are from some game, one way or another. My favorite one by far is Elden Ring, which is notoriously hard. Even the most basic enemies can easily whoop you if you are not on guard.
By purposefully denying yourself of the countless tools available in the game, say, you refuse to level up, you are forced to get good at reading attack patterns and dodging at the perfect moments. When any boss can one-shot you, there’s no room for error.
Thinking about all of these life lessons I learned, I suddenly realized that coding on paper fits the above. It took me a decade and a half, but I’m finally there.
Coding on paper forces you to pay attention to details (instead of letting autocomplete do it for you), to be deliberate (instead of brute forcing your way to a solution through trial and error), and to figure things out on your own (instead of outsourcing your cognitive abilities to an LLM).
Whenever you are alone with a pen and a piece of paper, there’s room for your thoughts.
Now, I know that by restricting our tools, we can build the muscles whose work we offload to tools.
Muscles that will carry all the cognitive load for you later.
Thanks for reading!
If you liked this post, you should support me with a paid subscription. It’s $100 a year, or $10 a month, and in return you get well-researched machine learning/mathematics deep dives such as Machine Learning is Not Just Statistics, Matrices and Graphs, or Vectorization in Theory + Vectorization in Practice.
Your support makes it possible for me to write these high value, high signal posts every week.