Writing Code on Paper Is Good Actually

Lately, I've been struggling with the way generative AI has "disrupted," as the tech bros would put it, education. Part of me just wants to put all the computers away and make students code by hand, but would their be any value in doing so? I'm starting to think so. The Case for Never Writing Code on Paper There are generally very few opinions out there that folks universally agree on, but I like to imagine that one of them is the idea that folks in tech—from computer science students to principal engineers—shouldn't be expected to handwrite code. Most students hate it when they have to write code on an exam, and many more folks on the job market hate whiteboard interviews. It's an opinion that I think most of us share. In fact, I am someone that hates writing code on paper. I hated it when I was a student. I hated it when I was looking for jobs. And, I hate it as an educator. As a student, I really hated writing code on paper because there was always this expectation that I had to have syntax and APIs memorized. Sometimes professors were nice and let us make cheat sheets, and some professors even provided a reference sheet. But generally, I felt like most of my time was spent memorizing details rather than working on my problem solving abilities. When I was hunting for jobs, the mindset pivoted slightly. Now, companies were expecting me to be able to solve problems, but the problems themselves were often very obscure. Google, who I interviewed with, was famous for this. Sure, they let you code in a Google doc in the first interview, but you'd move on straight to the whiteboard when they flew you out. From there, unless you read "Cracking the Coding Interview," you had to hope you got a problem that you knew how to solve. Eventually, when I became a lecturer, I knew I had to do something about this. My solution was to basically tell students what kind of problems to expect on the exam, so they had some time to prepare. Even then, I never expected perfect syntax because I was more interested in each student's ability to think through a problem. Likewise, I always gave them an API reference sheet. Hopefully, by the time they came to exam, the hard part was already over. Later, I gave up on paper exams altogether and shifted to online exams. That allowed students to write code in the appropriate environment (i.e., in their editor of choice). Unfortunately, in the age of generative AI, this kind of exam isn't really possible anymore. Perhaps the only solution in the future will be to have dedicated computer labs for exams. People Change However, I think my opinion on handwriting code has shifted recently. Perhaps I am so removed from studying and being on the job market that I've forgotten how painful it is, but I really think we ought to start normalizing writing code on paper again. And while I'm not sure I can make that argument for the broader community, I am confident that handwriting code is the way forward in education. There are several reasons for this. IDEs Stunt Learning One of the reasons I think it's important for students to handwrite code is that I actually think contemporary IDEs stand in the way of learning to code (but to be clear, I don't have empirical evidence for this). In fact, I'm not even talking about generative AI providing code completion. I'm talking about something as simple as underling syntax errors. It's just too easy for students to look at a red squiggly line as a sort of permutation challenge: "if I just change the code enough, the error should go away." I say this as someone who learned to code in DrJava. Errors are only provided to you when you hit the compile button. At that point, you have to read the error message to figure out what went wrong. Likewise, there is no code completion. Trying to call a method will not automatically populate a list out of the API. You need to read the documentation to know what methods are available and what they do. There is no way to mess with a line long enough until it compiles. You have to learn. I'm not saying this as some boomer who's trying to claim that I had it harder. Instead, I'm arguing that I'm better off because I had to actually put in some effort up front. So many IDEs now do everything for you, and the tech industry is continuing to push in that direction. I mean, isn't Cursor trying to be the first "no code" editor? And look: you don't need to dive head first into C, FORTRAN, or ALGOL like your forefathers did—back when programming languages apparently only came in capital letters. You can pick up a language that is kind, like Python. I know there are plenty of folks who are already mad I've even made this concession. I can hear it now: "But, how will they learn memory management? You're making their life harder." "What about static typing? Duck typing is horrible for learners." "They'll never be able to handle pointers. Great job, asshole." But, I stand by it. Python is just fun to use, and learning requires that you have some fun. If I'm telling you to stay away from IDEs, the least I could do is recommend a language that's approachable. But of course, without getting too off the rails, the argument I'm trying to make is that writing code by hand would benefit students because there's less hand-holding. Generative AI Makes Learning Impossible While there is probably room for debate on the IDE front, it's much harder to argue against the harms caused by generative AI when learning to code. When there is a technology that can completely solve beginner-level problems for you, there is just no incentive to learn at all. You are forever stuck in the Dunning-Kruger effect, not knowledgeable but incredibly confident. Unfortunately, given that every IDE is racing to include some sort of chat bot AND that chat bots are so accessible (e.g., universities are already paying for every student to have access to them), they're practically unavoidable. Even in my futile attempts to disable Copilot via the settings file in VS Code, students always race to turn it back on. It's a nightmare to be an educator right now. And look, I realize that I'm an AI hater. That's the entire premise of this whole series, so I don't expect you to trust me. Even with my background in education, you could easily make the argument that I'm biased, a Luddite, or an idiot. In fact, most of my arguments against AI have no basis in empirical evidence. I am purely speculating based on what I already know about learning theory and pedagogy. However, I think you're going to start to see evidence in my favor. To me, these arguments are obvious; the classic "leftism is just about being right too early" but for my thoughts on generative AI. In fact, here's a video hot off the press at the time of writing: https://www.youtube.com/watch?v=HTUh0OO6Kmo If you don't have the time to watch, the video basically talks about a study that looked at the effects of AI integration in novice programming courses. It turns out that the obvious is true: students who rely on AI don't learn. What they found was that generative AI is actually widening the gap between "people who find programming easy and people who don't." Of course, the video still does a bit of generative AI propaganda by arguing that "foundational concepts and prior experience are not just nice to have but necessary for successfully using AI." Interesting that we can show how AI is bad for learning but still argue that it's okay if an expert uses it. I'll remember that argument when I want to convince my friend that it's fine to skip a few sets at the gym because I'm an expert. Snark aside, even if you oppose writing code on paper like I used to, it has to be preferable to this age of slop. How can anyone possibly form a thought when the text editor is suggesting code at every key press? Concepts and Tooling Can't Be Learned Simultaneously Finally, if neither of those arguments are compelling to you, know that there is research on how people can't really learn tools and concepts at the same time. If your goal is to teach someone how to code, but you never teach them how to use their text editor, IDE, or (in the worst case) generative "tools," they are going to use up all their cognitive load on navigating the tool without actually learning the current topic. Hopefully, that intuitively makes sense, but if you don't trust me, here's a book that I always like to recommend called How Learning Works (#ad). In the chapter titled "How Do Students Develop Mastery," the authors talk about integrating component skills. In short, they argue that "if students lack critical component skills—or if their command of those skills is weak—their performance on the overall task suffers." In this case, you might ask students to write a program that prints out hello world. While this probably seems comically easy to even a newer developer, beginners have to integrate a series of component skills, such as: writing a print statement, constructing a string, writing a main method, and compiling and running a program. If you never take the time to break down each of these component skills for the student, they're going to struggle to complete the task. One area where I struggle with this is when I introduce students to both VS Code and git. Given the lack of time dedicated to learning these tools in the class, I sort of have to trust that students will take the time to learn these tools themselves. That might be a reasonable expectation, but I also understand that their understanding of the course material will suffer as a result in the short term. That's why so much of the early section of the course is review, so they have a chance to learn the tools. But I think in my ideal world, there wouldn't be tools at all. We would simply work through the logic of the algorithms on paper. Algorithmic thinking is a skill after all. Why do we accept this as the truth for math but software developers are incapable of existing without their machines? Handwriting Leads to Deep Thinking Of course, it's not so much that writing code in an IDE or with generative AI is bad. It's that handwriting code leads to a much, much deeper understanding of the material. Let me explain. In one thread I was looking at, someone suggested, "hand-written coding, hand-written problem solving," a position that I basically hold in this article. As a counterargument, someone said, "Coding requires testing your code and making corrections." Here's the thread for reference. At first, I was kind of on the same page as the counterargument. That immediately seemed like a major hurdle to me, but then I thought about it a bit. You can absolutely test and debug a solution on paper. Often, in our early coding courses, we teach students how to trace their code. The whole idea is to try some inputs and trace them through their solution. To me, this is the same thing as testing, but it requires you to be more strategic and more systematic (i.e., important skills to learn). If you can appropriately select inputs, you can reduce your workload. Eventually, students stop tracing by hand, mostly because it's a lot of work but also because they've developed better intuition. It becomes much easier for them to spot bugs because they've fixed so many of them before by hand. This intuition is something that allows me to easily identify bugs in student code at a glance, and it surprises them every time. It turns out that when you've written thousands of bugs yourself, you tend to see them easily in the code of others. In fact, this exact realization happened to me in undergrad when I was pounding my head over a bug for a couple of days before taking it to my instructor. They fixed it in less than 30 seconds. I actually felt so stupid at the time, but I was inspired to keep working hard. After all, if they could do it, why couldn't I? Another way I think about this is with chess. Knowing how the pieces move is not really enough to be good at the game. In fact, even playing hundreds of games will only help you develop some basic pattern recognition. To get good, you have to sit down with pen and paper and analyze positions. That same principle applies to software. Ultimately, I don't think you need any fancy tools to learn how to code. All you need is a pen and some paper. In fact, before generative AI, that's how you would have solved any difficult coding problems. Your first attempt would fail, and you'd go back to the drawing board, literally. Some of the best students I've ever had always had a notebook next to them to reason through problems. It turns out that problems are often a lot easier to solve when you can visualize them on paper. So if you're not on board with handwriting code, you can't really discount the importance of problem solving on paper (i.e., by hand). Get Tech Out of the Classroom When I was asked to switch back to paper exams, I'll be honest: I kind of breathed a sigh of relief. I know I wrote about how online exams made my life so much easier (and they absolutely do), but there was definitely something lost in the classroom. Students who otherwise couldn't write a line of code in lab were passing with flying colors. I don't know if they were getting help from friends or from the "thinking machines," but I knew learning wasn't happening. Like, I don't really trust paper exams as the best (or even a good) way to evaluate students, but it's the only tool we have now. Otherwise, how can I be sure anyone has learned anything? Moving forward, I'm interested in removing as much technology from the classroom as possible. Like, I'm still going to use clicker questions (i.e., peer instruction) and slides, and I'm obviously still going to have students write, run, and test their code. But, I would love to focus more on algorithmic thinking, something that our theory courses prioritize. After all, I really feel like learning is going to have to start happening in the classroom. There are just too many ways to bypass the learning process otherwise. Certainly, I think my students learn a lot through the active learning techniques I employ in the classroom, like think-pair-share, peer instruction, and jigsaw, but I think giving them more chances to handwrite and trace code will be good for them long term. At the very least, it will give them some handwriting practice before each exam. Anyway, I hope this was an interesting piece for you. The more I wrote, the more incoherent this started to feel, so I apologize for that (honestly, this is why it's behind a paywall). My main argument is really that we should probably have more balance in the classroom; let's not rely on technology so much for learning. Or rather, technology is not inherently better than more traditional forms of learning just because it might map more closely to your career (e.g., you should still learn to code without an IDE or AI agent, even if your boss expects you to use those tools). As an example, I use tools like Anki and WaniKani to study Japanese, but you all know my thoughts on Duolingo. Likewise, I'm not only using those tools to learn. I'm also practicing speaking with my instructors by reproducing scripts and adapting those scripts in new contexts. Technology is not a suitable replacement for all your learning needs, despite what EdTech might tell you, and I absolutely would not trust anyone pushing LLMs for learning. As a wise man once said, who wants to 'hire a tutor who plays "Two Truths and a Lie?"' That said, I don't have much else to say. Normally, I would share some links with your, but since you're already subscribed, I'll just end it here. Thanks for reading!