Paper is dead, long live paper programming
sacrideo.us
sacrideo.us
https://news.ycombinator.com/item?id=16455455
I like how this posts shows the strength of APL like notation.
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.
Dang...wikipedia says it came out in 87'. I can't recall energy drinks before ~2003.
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.
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
My handwriting was nowhere near this nice though :)
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.
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.
I think that practice heavily and positively influenced how I code and read other people's codes.
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
Also, I agree with you, Spencerian (or any other ornate script) is not the best for coding notes.
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.
Of course, to each their own... (I love penmanship, and I'm fluent in several scripts, but I do my coding in Emacs, thank you very much!)
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.
Wow, I've now got the urge to look at some javascript in 'ye olde' gothic font, just like the ancients wrote.
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 find this very absurd as a programmer who's written code directly on the PC since like forever.
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.
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.
In many cases this is a faster method, as the amount of debugging can be greatly decreased.
who simulated it's interpreter by cards lifted by his family :)
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.
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.
It is just as important to control process documents as it is to control source code files.
(But I do use paper some - focus reasons, and easier to manage than terrible phone interfaces.)
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.