He also said that a programmers most useful tool was a pencil and a 5mm square A4 pad.
After years of solving thorny problems by getting away from the screen and scribbling in a pad I can't say he was wrong.
I learned BASIC on punch cards using an IBM Mainframe for the junior high school math computer club, and it got changed to the math contest club after they couldn't afford computer time anymore.
In modern times there are IDEs to help people, but most of my best code I used to write on paper first. Visual Studio kind of ruined that as I wrote code in their IDE and painted forms for GUI access.
I find it very beneficial in the early stage of planning a program (or a subsystem of program).
I misplaced it, I would work on it from time to time while riding on a Metrolink train. It is either in my house somewhere or someone stole it.
Back in the 80's he worked on the software that ran/runs digital switching for (iirc) BT, high scale, high reliability stuff in C.
I think that was my peak.
Have you tried to recreate that peak? I'm wondering if it worked so well why you might not have continued working in that mode?
So now, I will walk around doing nothing for 4 to 5 hours to let my brain work on a problem, then type it in and have it work in 10 minutes. I do this same thing with design, not just code. I've noticed that coding has become a lot easier as a result.
I still get stuck when I'm dealing with other people's bugs though, especially with third party libraries.
One I've noticed is that being in my head so much makes it more difficult to explain things to other people and I think this hurts me.
The trick is, whenever you're writing anything, add notes for your future self to make sense of whatever you're doing. It's like adding comments to explain your code.
It's a little extra effort and bookkeeping but it makes old content so much more valuable!
I don't know what the implications of this are, or even if my simplistic understanding is accurate, but it does seem interesting.
[Edit: Elaboration]
In ML, you effectively transform your problem from "What piece of code will solve my problem?" to "What piece of data-driven code might solve my problem, and how do I acquire the right set of data?". Also, some ML-algorithms are designed specifically to enable you to analyze their "reasoning" about the problem after they have been trained.
There's a limited amount of things you can keep in your head at once, and the paper is somewhat of a navigational aid and rapid access memory. Paper also offers you a lot of flexibility in regards to laying out things fast and sketching things, which computers still don't have quite down yet. If I try to layout my thoughts in emacs or photoshop a lot of my processing power is taken up by the act of using the tool ("ugh, was it M-x rect or M-x rectangular-region"/"Let me get the pen tool, and the rectangle tool, and where did the tool tray go?").
Scribbling on a pad doesn't just apply to coding though, it's a useful technique for a lot of areas that have thorny problems that exceed your local memory capacity.
Just my take on the technique.
If you want to get faster and better at sketching diagrams I'd recommend you practice some of the basic techniques that say concept artists use. Straight lines from the elbow with little wrist movement and a little practice, and you'll be drawing things in no time in no time. Unless I need an incredibly straight line, I usually forgo rulers at this point.
If your handwriting has slowed down, or you're cramping, you might want to give that a little bit of practice as well. No need for the cleanest Suetterlin, but getting posture right and yourself up to speed might be worth the time investment. I've been playing around with the palmer method recently, it seems quite nice for this purpose.
Then there's tools. You don't want to be writing with cheap ballpoint pens on rough paper. The lines don't come out properly, which will make you press harder, which leads to fatigue. My current favourite pens are the Uniball eye-fine which is my go to for writing, as its a very smooth disposable ink pen. I've got one of those in front of me with a Kum ergonomic grip. Fountain pens are also very nice, and an entry level Lamy, Pelikan or Pilot will serve you nicely, but they're more suited for linear writing as they may smudge.
Pencils are nice for sketching, but you have to sharpen them, which is annoying. For regular use I use a Faber-Castell Grip 1345 0.5mm mechanical pencil, which is still affordable but doesn't have many of the issues that cheaper mechanical pencils suffer from (broken leads, leads going back in because of insufficient internal grip, etc.). The Faber-Castel leads are also very nice and sturdy and make decent lines even at low pressures.
Paper isn't that variable, as long as you don't totally cheap out on it. I'm particular to .5cm grid paper, but there's circumstances when plain white is nicer to work on.
It's a bit much of a list, but I think a lot about stationery. You don't need all of these, and if you find other tools that do the job for you, then by all means go for them, these are just my personal favourites. One pen and a block of paper is more than sufficient.
But I do think coding and thinking through problems on paper is a valuable skill. One neat thing it allows you to do is to go to a different place than the one you type things at to go think deeply about problems, because it's a lot more portable than a laptop. If like me, you haven't quite figured out how pseudo-code works and still write straight up source code, it also gives you a reason to memorize reserved words which I find does make things quicker ("was it import or include?"). And finally, your IDE won't distract you by having the gumption to tell you that "hey, you aren't using this variable, you lugnut, lookie look, this import is BROKEN! Aint you got any IntelliSense in you?" when you really want to be thinking about more conceptual things and not tiny implementation details. Sometimes you do do your best work when you're away from where you do your regular work.
I have improved my drawing ability significantly by following these lessons.
Drawing the problem is also useful because it focusses different parts of your brain on the problem. If the problem was easy to solve with just the more linear textual parts, you probably could just have sat down and coded it.
But if that's not enough, engaging the visual and spacial parts can help you understand the solution without being able to verbalise it (ie code it) yet.
Edit: Err wait, maybe not. It looks the same but so does the Zaner-Bloser form. Looking at some more methods, apparently I don't understand how it all works.