Its amazing how useful it is to slow down and just write out some problem with pen(cil) and paper. This has help me get unstuck form some bad habits after year of speeding past them.
So while I'm not going to disagree that writing with pen and paper can be a valuable exercise, the assertion that it's inevitable is utterly false. I am far more effective in sketching out my code design in an IDE than I am on paper, and never in my professional career of 23 years have I had to write out code in pen and paper for a job interview, or even in the job.
I mean people are free to do that but the last time I had to was in 1985 and that's because I was programming a KIM-1 by typing in hex codes through the keypad and I didn't have any sort of terminal.
Throwback to my Functional Programming course during Uni years. Writing OCaml code on paper wasn't fun. I think it helped to cement some concepts, but the extent of said help it's not clear to me. In fact, I also believe the same could have been achieved using a text editor.
If you're finding yourself reaching for pen and paper to write actual code, then your tooling sucks.
Your IDE isn't suitable for prototyping, or something else is going wrong.
I'm not suggesting that nothing in the planning phase should be white-boarded, but pen is the wrong medium for code.
You should have a tool where you can fire up your tooling and be writing the same thing you would write on paper, but with autocompletion, error feedback and browsable interactive output.
In my experience that's far more appropriate an environment for rapidly getting something down and working through the problem.
By all means, start with pen and paper to get a feel for the problem domain, but that process should stop short of actual code, and this article doesn't really sell me on the benefits.
I'd rather test my assumptions in something like LinqPad, where I'll get real feedback not just a "feeling" about what I've written.
I don’t know if it’s from Calm Technology, but here something that i read about recently: Don’t make humans act like a computer and don’t make the computer act like a human.
The first part is something I believe in this case. It’s ok to think with pen and paper (and I do when trying to find an algorithm) But I stop short of implementation details, instead typing out code. Why? Because text editors is much more flexible in this particular case (live programming environment, REPLs, or a quick code-compile-run cycle are much more useful)
And the second part is why I don’t like LLMs for code generation. Snippets are more deterministic. I’m ok with it for suggestions of ideas I can explore (in books, not with the LLM)
If you're finding yourself reaching for pen and paper to write actual code, then your tooling sucks.
Or maybe it's horses for courses?
Personally I found the idea of going beyond prototyping on paper as a rule not for me, though there are sometimes final snippets reveal themselves better away from the screen when I'm stuck in the mud on something.
My point is though that we really ought to allow others to find their own way and what is best for them rather than dismissing it so emphatically because we don't personally get it.
You can take as read that all my posts are prefixed with "In my opinion". I find it unnecessary to type that out on every post.
Taking a format that only a computer can interpret, code, and choosing to write it down on a medium a computer can't read, hand-writing, is not typically a productive exercise.
Even in interviews I'd rather hand a candidate a laptop.
There are more worthwhile things to hand-write, such as sequence diagrams, and there are more worthwhile places to write code, such as an IDE.
If someone is finding it easier to write code on paper than in an IDE, I'd rather not ignore that signal and try to discover why their IDE is proving such an impediment.
Maybe it takes 10 minutes to start up, maybe it throws up so many errors for each syntax mistake that it's distracting and hard to see the wood for the trees. Maybe it doesn't actually produce useful output. Maybe it doesn't have real time debugging and step-through.
Who knows, but something is causing it to be mentally easier to write down the same code on paper than the IDE, and that's not something that should be ignored, that's something that should be fixed.
I personally tend to think better when I'm away from the computer.
Coding on the IDE helps me to experiment and quickly put something together that works.
But thinking while writing things down or while walking is a slower process, so it helps me focus on nothing but the problem obvious edge cases, different solution designs, etc...
So by thinking about the code away from the IDE first, then by polishing my ideas on the IDE, I usually end up with higher quality code.
But since it's less fun to do things that way, I just tend to do everything on my IDE.
You can take as read that all my posts are prefixed with "In my opinion". I find it unnecessary to type that out on every post.
Its obviously a given - except where people are commenting in a way that indicates they are expressing the one true way, as you did, and have done again.
The OP's way is not for me, but I'm ok with it being for them.
I agree that if there is a problem in their process or workflow that is influencing an inferior (for them) approach it is better to try to help them fix it.
Oddly, for me the feedback of the computer is too fast for thinking. I like being able to write a bit before thinking about some details.
More, I find that forcing myself to run the code in my head is a good idea.
That all said, I don't do the paper thing often. Really only when thinking at a level other than the symbolic of text. Some system diagrams. Sometimes numeric. I suspect if I got good at Mathematica, I'd do more numeric thinking there.
Honestly, if anything I'm trying to do is sufficiently complex, I reach for pen and paper and use drawings, abstract ideas to have a better idea of what I'm going to code.
Actually, this way you catch a lot of poor design decisions that you would otherwise fall into.
If starting out with code, I might attempt to "fix" poor design through hacks due to the "sunk time fallacy" of code already written, that kinda works, but isn't maintainable.
Honestly, no "tool" on a computer would let me print my imagination as easily as pen and paper. Perhaps a drawing tablet, but that's an additional thing I would need to plug into my PC.
> If you're finding yourself reaching for pen and paper to write actual code, then your tooling sucks.
Oh bull. At the level of thinking where you’d pull out pen and paper, ALL digital tooling sucks. Not one single solitary tool can beat pen and paper at that level. Not one.
For myself by writing prototypic code correctly with pen; not only does it keep my vision straight, it also gives myself clarity and a sense of sanity of say, what that function does.
With the hard evidence you can then refer back to. So, when you are ready to expand your design you already have the foundation on page.
It acts as a pillar to the psuedo code that comes with design later on. If that is the going to be foundation to that function, it might as well be written correctly on paper.
This makes sense to me if the problem I'm solving simply devolves to code and I want as short a path as possible to completing it. I really don't see that much anymore, other than basic bug fixes.
Not every problem I'm solving is just a hunt for the code implementation. I like to reason about solutions beyond the syntax. I use pen and paper a lot, including for code, and I'll use shorthand to represent longer-form code blocks. I find that approach better because I can hide the noise that code blocks can introduce in an IDE. I want code to support my solution -- not a solution to fit into code. IDEs and frameworks can have that affect on people, in my experience.
As with this comment and the one preceding it, your mileage may vary.
It's like you and many people didn't read and understand the post.
> but pen is the wrong medium for code.
Pen & Paper is really excellent for many people, maybe not you but it's fine some others. You may use an electronic device (some people are using Remarkable and alikes) or chalk and black board, or MindMapping app; the key idea is to first forethink and analyse the problem before diving into coding.
> your tooling and be writing the same thing you would write on paper, but with autocompletion, error feedback and browsable interactive output.
What kind of tooling do you use for pseudo-code (not a real language, but textual informal prose) with that features?
I agree that there's not much point in writing actual literal semantically correct code on a piece of paper, but I don't think that's at all the point of the article. The author talks about understanding the problem space, getting their ideas organized, and (if I may charitably interpret the article a bit) even go as far as scratching out some ideas of what the code might look like.
Job interviews with pen and paper are hardly a selling point for me, I had one 10years ago and still dreaded it. My 2 cents are, if a company hires you to work on a computer in X environment then that's what they should test you on - or as close to it as they can.
I remember one Easter break (1987) spending a couple of weeks at my parents working through lambda calculus examples by hand - which was extremely laborious and used lots of paper but actually got me to really like the topic.
I can relate to this. IMO in the title there is a WHEN. Missing. If you are using pencil and paper every time (even for the 100th little API variation) you are doing too much planning haha
I think it is crucial to learn how to code with pen and paper. All computerization adds a mental burden, that shouldn't be there. Also this is a nice way to connect computer science with mathematics.
I disagree.
All code is useless without computers.
We should use every single tool that can boost our efficiency and allow us to make less errors.
Copilot, autocomplete, intelisense, etc…
It’s a waste of your time and you will write worse code if you just use pen and paper. Guaranteed.
Agreed. The faster you implement and correct the better it becomes. It's quite improbable that you'll catch a logical error in writing and not catch it while coding it up. It's also quite unlikely that a sketch of your plan will help you more than a debugger will.
I disagree, if you get into this habit, you risk missing the forest for the trees, which is much more dangerous : for instance that you should have used a different programming paradigm, a different programming language, a completely different approach at solving the problem than coding that, or even sometimes solving that problem might be an actual waste of effort, better spent elsewhere !
And not saying don't think just pointing out that careful handcrafted logic takes almost the same time to implement anyway.
Most problems are such that it's hard to know what really needs to be accounted for initially due to some janky interface or the language not behaving as you expected which can nuke the whole plan.
Writing stuff down can make you more confident about the approach and ironically lead to a dead end because you assumed everything was accounted for.
I can't tell if this is sarcasm or not, you have the word "pen" in your name!
Anyway, not sure if it's "guaranteed" to be worse than using a computer. Yes, you'll definitely get less help with pen and paper. But you'll probably end up understanding the problem better, without relying on GPT completion of code etc...
Even if it did, having to write down thoughts or code by hand at slow speed and without convenient way to modify it is significantly worse. Not to mention I'd constantly get distracted by my ugly handwriting.
If you prefer doing it the oldschool way that's fine, but don't force it on others assuming their brains work the same.
I got blacklisted from an MNC in India because I was writing up the logic for the algorithm problem on paper and the camera flagged me as cheating on the coding test. Its weird cause since childhood we were forced to use pen and paper to solve math/physics/chemistry problems and now you get flagged on online tests for using it. I just cannot do the "thinking" part of the code with my keyboard and IDE.
> If you’re unsure, think about the last job interview you did, and remember how there was no computer around in the interview room — just your interviewers, a blank sheet of paper, and a blue ball-point pen.
I haven't had an interview like this in about 10 years
I'm trying to think... I've had about 30 contracts and a lot more interviews than that.
The only one I remember that involved a sheet of paper was 20 printed pages of code which I had to find the bugs in. And that was actually quite a fun exercise. (I did apparently find more bugs than most, I also subsequently found some bugs in their contract and NDA.)
Had a couple like that, the relief from not ever having to work with those people lasted longer than the trauma from the interview. Look on the bright side, at least you didn't get the job!
Yeah the last job interview I did was me and two other developers on a zoom meeting, with me sharing my screen while I typed out puzzle solutions in codepen.io
I can’t even think of the last time I did an interview without a computer in the room.
I grew up drawing a lot and doing a lot of stuff on paper for thinking so it's natural for me to solve harder/more complex programming problems on paper before writing up the code. It helps me wrap my head around it.
I'd argue it's even more valuable to learn to code without paper. Many of us formed habits of thinking with paper in school and freeze up a bit in front of the screen. I think it's better to work to eliminate that freezing up than to accommodate it.
I understand using paper for Diagrams and arquitechtual design, but for coding?
On college I remember having to code on paper and you simply can't test your code for typos or small error, even if your logic was perfect professor give you marks for a missing ';'
note: the class was evaluating the Logic / algorihtm not basic code syntax
It IS useful - for interviews. I have a whiteboard at home just for that. It's amazing how stressful it is to write code by hand without someone breathing down your neck.
Outside of that - life is short, and this is waste of it.
I only use pen and paper for sketching diagrams and graphical relationships between things. This is probably the main use for paper & whiteboards - they are MUCH cheaper than their digital equivalents for drawing regardless of size.
Writing out pseudocode on paper is… okay… although not my preference. It’s okay if you get stuck and want a context switch.
Writing out syntactically correct code, including commands like “sudo” on paper on the other hand is an enormous waste of one’s own time. God help this man if he ever takes up Java programming. Just type actual computer code like this on computers so you can run it and see if it works. Then if it doesn’t you can just use backspace instead of an eraser.
I mostly work with a whiteboard and then photo and print out the board, and work from the paper to see if I can then make further refinements by writing on the board again, and so on and so on, until I feel like I understand the problem/solution and then get started working on the computer to code.
To each his own. I went the opposite route, now, I don't even have a pen and paper on my desk. I still carry a pen in my bag for signing documents and stuff, but I don't remember the last time I scribbled something on paper.
I usually take notes or lay my thought using a text editor, I find it easier to edit, manipulate, and store. I occasionally use a graphics tablet or my phone with a stylus when I need more than text (ex: drawing schematics), essentially like paper, but more editable and I can save it as a file.
But if you find that pen and paper works best for you, go for it. Maybe one reason I went the opposite route is that the author likes to think in advance before going for the implementation, that's a top down approach.
Mine is very bottom up, I go straight to coding, sometime even before reading the specs. It feels like putting ideas into code makes me think more clearly. I can always scrap that code later, I often do, it is cheap when things are just getting started. And pen and paper is not really suitable for that kind of rapid prototyping.
nah, wanna go old-school, use inkwell pen, or better still feather + ink for hard-core hackers! focuses the mind, you've gotta know your grammar, syntax etcetera. non of that autocomplete sorcery for me
I upvoted the "I couldn't disagree more"-post, but now I regret it (edit: oh, there's an "unvote" button). One can do a lot more with a pencil and a piece of paper than with a blank text entry. Drawing figures, arrows, etc. There is even undo, thanks to rubbers. But it sucks that one can not insert lines in between.
Yeah, I meant stuff like the Remarkable. I have a Kindle Scribe. Amusingly, the scribe was not good at this at launch, but has gotten some good updates. My understanding is the Remarkable is head and shoulders better.
Certainly, I wouldn't go buy one if you didn't want it already. I did the kindle as I was happy to have a large screen kindle. :D
The problem I have with a ton of computer based sketching tools, is that I just don't sketch with a mouse that well. And doing it with the keyboard is ridiculously difficult for me. The Wacom can mostly work, but it takes a ton of getting used to having the pen detached from what you are drawing. Easier than the mouse, but still hard.
A friend of mine, in the 80s, wrote machine code on paper (calculating offsets in his head) having memorized all op codes, and drawing the graphics for a game for a Sharp MZ-800.
I always admired his patience and skills, me using an assembler on an Amstrad to write my games.
102 comments
[ 0.22 ms ] story [ 218 ms ] threadhttps://blog.jgc.org/2013/04/how-i-coded-in-1985.html
If you're finding yourself reaching for pen and paper to write actual code, then your tooling sucks.
Your IDE isn't suitable for prototyping, or something else is going wrong.
I'm not suggesting that nothing in the planning phase should be white-boarded, but pen is the wrong medium for code.
You should have a tool where you can fire up your tooling and be writing the same thing you would write on paper, but with autocompletion, error feedback and browsable interactive output.
In my experience that's far more appropriate an environment for rapidly getting something down and working through the problem.
By all means, start with pen and paper to get a feel for the problem domain, but that process should stop short of actual code, and this article doesn't really sell me on the benefits.
I'd rather test my assumptions in something like LinqPad, where I'll get real feedback not just a "feeling" about what I've written.
The first part is something I believe in this case. It’s ok to think with pen and paper (and I do when trying to find an algorithm) But I stop short of implementation details, instead typing out code. Why? Because text editors is much more flexible in this particular case (live programming environment, REPLs, or a quick code-compile-run cycle are much more useful)
And the second part is why I don’t like LLMs for code generation. Snippets are more deterministic. I’m ok with it for suggestions of ideas I can explore (in books, not with the LLM)
Or maybe it's horses for courses?
Personally I found the idea of going beyond prototyping on paper as a rule not for me, though there are sometimes final snippets reveal themselves better away from the screen when I'm stuck in the mud on something.
My point is though that we really ought to allow others to find their own way and what is best for them rather than dismissing it so emphatically because we don't personally get it.
Taking a format that only a computer can interpret, code, and choosing to write it down on a medium a computer can't read, hand-writing, is not typically a productive exercise.
Even in interviews I'd rather hand a candidate a laptop.
There are more worthwhile things to hand-write, such as sequence diagrams, and there are more worthwhile places to write code, such as an IDE.
If someone is finding it easier to write code on paper than in an IDE, I'd rather not ignore that signal and try to discover why their IDE is proving such an impediment.
Maybe it takes 10 minutes to start up, maybe it throws up so many errors for each syntax mistake that it's distracting and hard to see the wood for the trees. Maybe it doesn't actually produce useful output. Maybe it doesn't have real time debugging and step-through.
Who knows, but something is causing it to be mentally easier to write down the same code on paper than the IDE, and that's not something that should be ignored, that's something that should be fixed.
Coding on the IDE helps me to experiment and quickly put something together that works.
But thinking while writing things down or while walking is a slower process, so it helps me focus on nothing but the problem obvious edge cases, different solution designs, etc...
So by thinking about the code away from the IDE first, then by polishing my ideas on the IDE, I usually end up with higher quality code.
But since it's less fun to do things that way, I just tend to do everything on my IDE.
Its obviously a given - except where people are commenting in a way that indicates they are expressing the one true way, as you did, and have done again.
The OP's way is not for me, but I'm ok with it being for them.
I agree that if there is a problem in their process or workflow that is influencing an inferior (for them) approach it is better to try to help them fix it.
The post isn't about writing code on paper, but about the planing and ideas collection before writing effective code.
> write down the same code on paper than the IDE,
No, pseudo-code and notes and flowcharts aren't the code (maybe the later on some visual language environment.) You're missing the whole point, sorry.
Regardless, I don't see why the parent would have necessarily mentioned pseudocode for any reason?
(Also, even Python is at more risk of funneling you in some direction that might be suboptimal, at least more than pseudocode.)
More, I find that forcing myself to run the code in my head is a good idea.
That all said, I don't do the paper thing often. Really only when thinking at a level other than the symbolic of text. Some system diagrams. Sometimes numeric. I suspect if I got good at Mathematica, I'd do more numeric thinking there.
Actually, this way you catch a lot of poor design decisions that you would otherwise fall into. If starting out with code, I might attempt to "fix" poor design through hacks due to the "sunk time fallacy" of code already written, that kinda works, but isn't maintainable.
Honestly, no "tool" on a computer would let me print my imagination as easily as pen and paper. Perhaps a drawing tablet, but that's an additional thing I would need to plug into my PC.
Oh bull. At the level of thinking where you’d pull out pen and paper, ALL digital tooling sucks. Not one single solitary tool can beat pen and paper at that level. Not one.
We appear to agree there's a place for pen & paper, and we appear to agree that's a different level to coding implementation.
Writing down code, complete with correct syntax, parentheses, indentation, etc, as the article wants, is not in my opinion that level.
At that level, the tooling does not suck.
So yes, I agree, "At the level" where pen & paper shines it should be used.
That level is not writing correct code, unless you can convince me otherwise?
With the hard evidence you can then refer back to. So, when you are ready to expand your design you already have the foundation on page.
It acts as a pillar to the psuedo code that comes with design later on. If that is the going to be foundation to that function, it might as well be written correctly on paper.
Not every problem I'm solving is just a hunt for the code implementation. I like to reason about solutions beyond the syntax. I use pen and paper a lot, including for code, and I'll use shorthand to represent longer-form code blocks. I find that approach better because I can hide the noise that code blocks can introduce in an IDE. I want code to support my solution -- not a solution to fit into code. IDEs and frameworks can have that affect on people, in my experience.
As with this comment and the one preceding it, your mileage may vary.
> but pen is the wrong medium for code.
Pen & Paper is really excellent for many people, maybe not you but it's fine some others. You may use an electronic device (some people are using Remarkable and alikes) or chalk and black board, or MindMapping app; the key idea is to first forethink and analyse the problem before diving into coding.
> your tooling and be writing the same thing you would write on paper, but with autocompletion, error feedback and browsable interactive output.
What kind of tooling do you use for pseudo-code (not a real language, but textual informal prose) with that features?
Job interviews with pen and paper are hardly a selling point for me, I had one 10years ago and still dreaded it. My 2 cents are, if a company hires you to work on a computer in X environment then that's what they should test you on - or as close to it as they can.
Even in college, the computer was in the computer center. So in the dorm I'd still code in spiral notebooks, listening to ELP and Jethro Tull.
I kinda miss that a teensy bit.
And not saying don't think just pointing out that careful handcrafted logic takes almost the same time to implement anyway.
Most problems are such that it's hard to know what really needs to be accounted for initially due to some janky interface or the language not behaving as you expected which can nuke the whole plan.
Writing stuff down can make you more confident about the approach and ironically lead to a dead end because you assumed everything was accounted for.
Anyway, not sure if it's "guaranteed" to be worse than using a computer. Yes, you'll definitely get less help with pen and paper. But you'll probably end up understanding the problem better, without relying on GPT completion of code etc...
Even if it did, having to write down thoughts or code by hand at slow speed and without convenient way to modify it is significantly worse. Not to mention I'd constantly get distracted by my ugly handwriting.
If you prefer doing it the oldschool way that's fine, but don't force it on others assuming their brains work the same.
I haven't had an interview like this in about 10 years
- whiteboard / paper is just so slow
- extremely poor editing functionality on whiteboard / paper
- some people's handwriting is not legible
The only one I remember that involved a sheet of paper was 20 printed pages of code which I had to find the bugs in. And that was actually quite a fun exercise. (I did apparently find more bugs than most, I also subsequently found some bugs in their contract and NDA.)
It was a strong signal I didn't want to work there.
There were even stronger signals that followed. It was by far my worst interview ever, I haven't really gotten over it yet.
It even caused me to sign up to glassdoor just so I could leave a negative review.
I can’t even think of the last time I did an interview without a computer in the room.
Really not sure this is relevant to me.
On college I remember having to code on paper and you simply can't test your code for typos or small error, even if your logic was perfect professor give you marks for a missing ';'
note: the class was evaluating the Logic / algorihtm not basic code syntax
Outside of that - life is short, and this is waste of it.
Writing out pseudocode on paper is… okay… although not my preference. It’s okay if you get stuck and want a context switch.
Writing out syntactically correct code, including commands like “sudo” on paper on the other hand is an enormous waste of one’s own time. God help this man if he ever takes up Java programming. Just type actual computer code like this on computers so you can run it and see if it works. Then if it doesn’t you can just use backspace instead of an eraser.
It was Machine Code.
I usually take notes or lay my thought using a text editor, I find it easier to edit, manipulate, and store. I occasionally use a graphics tablet or my phone with a stylus when I need more than text (ex: drawing schematics), essentially like paper, but more editable and I can save it as a file.
But if you find that pen and paper works best for you, go for it. Maybe one reason I went the opposite route is that the author likes to think in advance before going for the implementation, that's a top down approach. Mine is very bottom up, I go straight to coding, sometime even before reading the specs. It feels like putting ideas into code makes me think more clearly. I can always scrap that code later, I often do, it is cheap when things are just getting started. And pen and paper is not really suitable for that kind of rapid prototyping.
nah, wanna go old-school, use inkwell pen, or better still feather + ink for hard-core hackers! focuses the mind, you've gotta know your grammar, syntax etcetera. non of that autocomplete sorcery for me
Ok, not easily.
The problem I have with a ton of computer based sketching tools, is that I just don't sketch with a mouse that well. And doing it with the keyboard is ridiculously difficult for me. The Wacom can mostly work, but it takes a ton of getting used to having the pen detached from what you are drawing. Easier than the mouse, but still hard.
I always admired his patience and skills, me using an assembler on an Amstrad to write my games.