In 1992 for my final pre-exams deliverable at uni I wrote the entire program text (in Pascal) out on pen and paper overnight, fuelled by cheap lager and Red Bull. Queued at the door waiting for the lab to open in the morning, then typed the lot in and was delighted to discover not only no syntax errors, but no bugs. Ran it, took a few screenshots, printed them and the listing, delivered it to my tutor and went to the pub.
To this day I swear by pen and paper — not for actual code any more, but most specs/designs/flowcharts/pseudocode, and absolutely all meeting and personal notes. I highly value the focus which comes from not being distracted by the quality/features/font/customisation/whatever of some device/app/workflow du jour.
I can readily agree with this approach. My handwriting is... suitable for a doctor at best, so a word processor is pretty important to me when it comes down to implementation, but I've had so many problems just melt away in the face of a pencil and a good graph or summary.
I remember Jolt Cola [0] which was a super-caffienated cola drink, which I drank in the late 80s/early 90s when it was available in the UK (at least I found it in Edinburgh and Glasgow) from a few select delis that did US imports. Apparently a hacker staple in the USA, which is why we searched for it here...
I remember being surprised when I first regularly visited in 99 that red bull wasn’t well known in the US; it was readily available in the UK at that time.
exact same year, in pascal also, I did the same thing for an assignment implementing an embedded multitasking mini OS. I was so exicited at the idea of making my own multitasking system I went home and coded it all on paper. Went in to the lab the next day, coded it in, and it worked straight away with only a few minor issues.
I participated in a few programming competitions in college where paper programming is a must.
There are typically 3 members on each team but only one computer.
Our strategy involved first finding the easiest problem in the set and handing it over to our fastest typer to solve. In parallel, the other 2 members ranked and categorized (graph search, DP, arithmetic, etc.) the remaining problems. We then proceeded to split the problems based on our strengths and difficulty.
Obviously, while the computer was occupied, the rest of the team had to design and type out their solutions on paper. Once a solution is ready, that member gets priority to use the computer.
In my experience, at least in a competitive setting, writing code on paper tends to minimize common mistakes, especially once you get used to it. By the time you type it out, you'll have addressed most of the issues, so the code should (hopefully) compile and run with little modification.
Over time, I got used to catching off-by-one errors in loops as well as assignment to incorrect variables of the same type.
But when I write code in an editor, these errors always pop up. I guess it's because the feedback loop is so small, whereas every second counts in a competition environment.
Yes, it was pretty fun. I wish I took it more seriously though: we never really practiced much and just attended competitions for the experience. We did manage to get 5th place twice in a row in a regional competition (Gulf), so we weren't terrible :P
I would think you'd catch more errors since you're reading through your own code in it's entirety, as well. Mistakes like mis-assigned variables are easy to make while you're actively thinking about your code but they stand out when you're just reading it.
When I was growing up I couldn't afford a computer so I would write Basic on paper and save it for when I could get to school or somewhere else with a machine, then type it in. I definitely feel it made me a stronger developer as I had to "think like the machine" a bit more than when receiving immediate feedback while composing a program. The programs I was writing were insanely simple but I feel it was still a good exercise.
My handwriting was nowhere near this nice though :)
I am always reminded of the first chapter of Lev Manovich's The Language of New Media where is writes about growing up in the Soviet Union and he took two years of computer programming without ever touching a computer. At the end of the course he got to use a computer once where he put his program into the computer and it doesn't work because he typed Os instead of 0s.
My first programming class was in high school in 1980. The teacher, Mr. Schultz, invented a pared-down, abstract assembly language he called SIMPLE (Schultz's Imaginary Machine Programming Language for Everyone). We spent the first month of class writing out solutions to programming problems in SIMPLE on paper before we ever touched a computer. And even then, we only had the one machine, so we had to take turns on it. We coded our BASIC programs on paper and checked them as thoroughly as we could to maximize the effectiveness of our precious time with the actual hardware.
I really like finite state machines, for sketching out a basic program flow.
Nothing as complicated as big formal UML diagram, but IMO a quick sketch of a program as a 'grid' is a nice way to visualize and quickly iterate on logic flows.
I took my first programming class when I was eight years old, at a night class that my granddad wanted to take at the local community college. He took me along with him after I badgered him. It was 1978.
The school only had one computer, and no one in the class had their own. We wrote BASIC programs on paper, handed them in, and the instructor entered them, ran the program, and let us know the results afterwards.
Up until college, I had a habit of writing programs on paper first. I'd forgotten how well that worked for focusing the mind. This is a great reminder.
My school had a two year course on programming in C\C++; fairly basic, being an introduction to programming itself. At that time, I didn't own a computer, and to use the computers in the lab you needed to wait an extra hour and arrange for your own transportation (the normal hours had buses). You could also use some time off your lunch breaks, but that wasn't clearly enough for trial and error. So I got into the habit of writing programs on paper first, walking through them with arbitrary values assigned to variables, and entering it during my lunch break, hoping for a very small number of errors which I could hopefully fix on the spot.
I think that practice heavily and positively influenced how I code and read other people's codes.
I used notebooks extensively - the harder the problem, the more ink I used. But the huge advantage of paper is the ability to draw diagrams - much easier to review later, and to revise. I am surprised not to see any in these pages.
In my first job in 1981 the first few weeks we had 7 people sharing a single terminal. We had to write code on paper until it we got an hour or so to use it. This lasted two week before they got a couple more. You still had to sit at your desk with paper for 2-3 hours a day. I have less than zero percent desire to write code on paper again. It's hard for people not from back then to imagine a time when most desks did not have access to any computer system. I think of this today as the Desk Operating System. Thankfully that only lasted a couple years and I moved on to PCs.
Back in college I used to take all my notes in cursive, mostly to help me pay attention in class (the busywork of trying to make my handwriting as nice as possible helped me keep focus).
The earlier programming courses involve a lot of paper programming, because the finals involved writing programs on paper. So I ended up writing a lot of programs in cursive, and it looked something like this (except much uglier). Although I found it a fun exercise, I don't know how much (if at all) it helped me develop my understanding of programming
Yeah, he's doing calligraphy (either Spencerian script or Copperplate, maybe?) for coding, which is absolutely not a good hand for it. I mean, I personally take notes in cursive, but they're typically prosaic (e.g. "Fix the VPN", "Ask Steve about those CSS changes", etc).
I know this was a joke, but do you by any chance know any shorthand? I tried to teach myself Gregg here and there years ago, but it requires more dedication than I was willing to put in to become fluent.
Gregg is not the way to go if you're looking for a shorthand
that captures text in the way you would need for programming or science and I don't know of a good shorthand for this [if it wasn't already APL.]
Gregg is very much a "visible" sound system from a time when people just needed to capture the conversations and later expand back into text with the aid of a secretary. That is, if you didn't mutate your shorthand for your own purposes.
That being said, Aaron Hsu's handwriting is beautiful, but not my cup of tea for thinking on paper--my initial reaction to his scanned pages was unpleasant because it wasn't what I was used to from my own hands.
I know teeline. But programming in it seems pretty silly since half the time you are only differentiating the meaning of words using sentence context. I do like the idea of using it for maybe some very basic terms in psuedocode though (if, for, define, class, etc)
Did you not learn cursive in grade school? This looks exceptionally readable to me, and other than the capital letters it doesn't really have any flourishes.
And given how practiced his hand looks, I wouldn't be surprised if he was able to write this much quicker in cursive than I could write it in printed letters.
I learned cursive in grade school (xennial represent) but neither I nor my classmates wrote like this. This is some Declaration of Independence shit right here.
I learned cursive too, but it's still much slower to read than plain old 'normal' lettering. I assume the author would be able to read it just fine. It is gorgeous though.
I'm an engineer I do something similar despite sitting in front of a computer it's often faster for me to solve simple problems "by hand".
I keep a notebook beside me as I work I end up going through several notebooks a year. I think it's a consequence of how I was taught in school. During high school physics one of the first thing we were taught was to always sketch out a diagram depicting the problem and all the boundary conditions. It is a habit I carried on through university and into my career. I guess the equivalent in programming terms would be to draw a state diagram before attempting to write any code.
I shit you not, but in India, at our university, we are not allowed to write code on the PC unless we present the code, pseudo code and flowchart first.
Same story for the CAD subject. (Cs majors have to study that)
I find this very absurd as a programmer who's written code directly on the PC since like forever.
I often like to write out programs by hand (in some sort of pseudocode or whatever language I'm currently using) on "paper", except that "paper" is GoodNotes on an iPad Pro with an Apple Pencil. The benefit is that I can move things around after I write them. So, I can insert lines, indent or un-indent blocks, or move code into a subroutine. I can also easily add little diagrams. It's really opens up a new way of thinking! It's gotten to the point where when I'm at a whiteboard, I have the urge to rearrange stuff minority-report-style, until I remember that it's not a huge iPad.
That handwriting is lovely; mine is unreadable, but indeed the older I get, the more I program on paper. And it pays off; less bugs and generally better results in my field. The break shit mentality never worked but it definitely does not work in embedded. You lose a lot of time and probably prototypes (actual money) if you work like that. Writing things out and testing them in your head with maybe some level of formal proofs on paper (they do not have to be complete, just a lot of deep thinking) really saves us time and money.
In France, the competitive exams to major schools are not only done on paper, but you have no access to a computer whatsoever.
I was initially surprised at the idea, since it means that errors that can immediately be found on a computer (using a wrong library function, edge conditions on loops, ...) are easy to miss.
I always find writing out my programs (even in pseudocode) before actually attempting to type it out has helped me weed out bugs in the long run. This is especially true as long as whiteboard interviews is still relevant.
Despite me typing pretty fast on a keyboard (~90wpm), writing things out on paper makes me think more carefully, and I don't have to maintain a contextual overhead in pressing the right keys or seeing a red, strong underline for every typo I make. This is also true for non programming related work. It frees my mind into solving the actual thing where typing is just the medium.
Then again, I grew up doing a lot of writing and only got my first iPhone in college. This might be different for kids who interact with iPads in elementary school though.
yeah i think this is a gooid practice rather then diving right into the editor. Of course certain tasks you might know exactly where/what to code so you just get it done. But if there is any uncertainty or open-endedness i find it's very helpful to write out a set of steps to accomplish. breakign down the problem , smaller chunks etc. many benefits for me not limited to better code less bugs. Biggest one for me is the ability to turn off my dang monitor for a while and look at something that is not a screen. I'll grab my notebook, go sit by a window or something and start brainstorming. it's a nice refresh, plus when you get back to your terminal it's moreso a translation exercise and you can really pump out the code fast.
I like this very much - talking about non-simple problems. Coding before typing forces one to think about and solve the problems first. Randomly flipping if-statements won't happen this way.
In many cases this is a faster method, as the amount of debugging can be greatly decreased.
Ironic that a post, I assume, promoting the tech of yore, is posted on a blog that I can only read when I enable all sorts of JavaScript. I don't meant that some parts don't work, I mean that the whole page is empty until I enable JS. No thanks.
Backspace was what moved me away from paper when I was a kid. I can't go back to paper programming, the ability to cleanly delete anything I messed up is ingrained in me. I admire if somebody still keeps the art of 0 mistakes going!
I used to write algorithms and solutions to my Delphi programs in paper when I was bored at school, in 2009/2010. It was very cool to think a great solution and write it. But for learning programming it is awfull and I don't know why universities still insist in using this method in classes and exams.
Wow! I’m a little jealous of his handwriting. I don’t handwrite code/pseudo-code very often, but when I have a complex issue, writing things out can really improve the thought process.
This is the sort of thing I write into "notes.txt" and check in to source control as a support document.
Writing your notes in a bound notebook as un-OCR-able calligraphy, and then scanning the results to image files is not likely to endear you to me as a co-worker.
In practice I've found it takes ten times as long writing in a way co-workers can understand as it does writing personal notes.
As such I'll mostly write personal notes for my own reference and make a judgement call about where I put in the 10x effort to communicate to co-workers.
Your approach seems to couple problem solving with communicating with co-workers. Sometimes that's an advantage - often not.
Yes, but I have a tool for making images on my computer, too.
The handwritten bound notebook cannot be searched, diff'ed, or versioned. It is strictly inferior to the plaintext file in most ways that are in any way relevant to writing software.
Its nemesis, of course, is and has always been the mathematical equation, whose notations confound the plaintext writer at every turn. For those, you can write it to an image, or use LaTeX or MathML.
So searching an image is definitely nice, but it's a tradeoff in my opinion as it takes much longer to write out an equation in equation editor (I'm very proficient btw) or the other mathematical CAD tools I use when compared to a Notebook sketch. I use them all the time, take a pic and put it in OneNote with some keywords to search.
This assumes that the purpose of the doucment is to be archived, searched, diffed and reproduced. None of these is in fact the case. The purpose is as a tool in the production of the program being written.
https://news.ycombinator.com/item?id=16455455
I like how this posts shows the strength of APL like notation.