Calling a notebook the “most important tool” for a dev is pure romanticism. Useful for some, sure, but let's not pretend it outweighs a debugger, version control, or CI. This isn't craftsmanship cosplay, it's software engineering.
The tools you shared are of course important and I enjoy having them a lot. Wouldn't want to work as a developer without version control or debuggers, for sure. Those are tools that if I lost them, it surely would slow me down and be annoying.
I do truly consider notebook more important to me than those. Writing and running code is the tool to get things done but software development to me is more importantly building something valuable that solves problems or makes life easier. And to that, code is often somewhat trivial implementation detail — it's much more important to figure out what to build and how.
Some people are good at thinking when they are in a code editor or other digital tools. My brain goes into detail implementation mode and it's hard for me to see the big picture when I'm writing in code editor and building functionality.
For me, it's crucial part of my job to take my notebook and use it as a tool for thinking before (and during!) coding. While losing access to the other tools would definitely slow me down, not being able to think through writing with pen and paper would cripple my thinking, my problem solving ability, my creativity and thus cause me writing bad software.
Yes, but the post above is pointing out that you would be significantly slower without an IDE, compiler or debugger than you would be without a pen/paper. In fact, I don't think you would be a professional programmer if you didn't have them.
Saying you like a notebook and pen while designing and writing software is very different than saying a notebook and pen are more important than an IDE, compiler, or debugger.
Slower at creating what? With just great tooling there is still a real risk of creating the wrong thing just very fast.
OP's point is that it is a thinking tool more so than a creating tool.
This is a strange take. Programmers were around before any of those tools were. And today, even many professional programmers do their work without using any of them: they use text editors, they write interpreted languages, and they use printf()-debugging or other techniques.
Like a human brain? I'd say that is the programmer's most important tool, and it is not connected to electricity, an OS, or the internet.
When people criticize like that, you know you’re doing something right. “Only people doing less than you will criticize “
Keep it up!
I love "This isn't craftsmanship cosplay, it's software engineering.". I will definitely steal this, let me put it in my notebook.
The difference between the blue collar machinist and the white collar engineer is exactly this view of the machines they use.
For an engineer a machine - be in a slide rule, calculator or super computer - is just a tool. You're not doing engineering because you're using the tool. You're doing engineering because you're thinking and the tool helps you think a bit faster.
For a machinist the machine is the job. You can't make widgets if you don't have a machine to make them on. Thinking about widgets is pointless because they don't get made by thinking.
Do you mean that they use robots today and therefore aren’t “old school”? That’s true in most industrialized economies.
But the sentiment holds true. When you're building software designing good code is the most fundamentally important aspect of your job. All the tools you mention are things that enable you to delivery that code, but if the design of the code itself is wrong then they mean very little. The process of designing code feels like a lost art these days; developers are far too happy to throw crap at a wall until enough of it sticks to pass the acceptance criteria. Going back to actually working out the logic and flow of the code (on paper, in a diagramming app, whatever) is missing for a vast amount of the dev community.
If people were happy to work through the logic of a feature before hitting their IDE and debugging the first thing they code up, maybe apps would be a bit less buggy.
Although I would agree that we have more modern tools, I'm not sure they're better along every dimension: pen and paper is better for memory retention than typing. Also, while YMMV, oen and paper works wonders for brainstorming for me.
Though admittedly search is easier with digital tools.
I throw away almost all my handwritten notes, because of the downsides: illegibility, unsearchability, physical bulk.
But the qualitative difference of thinking or reading +/- handwriting is huge. I don’t get caught up in editing. I can draw diagrams easily. It slows me down, makes me dwell on an idea while I’m writing it, and thereby physically calibrates my thought process.
So far, I haven't found tools that beat pen and paper as tools for thinking _for me_.
I still do write a lot of digital notes too but I find that the flexibility of pen and paper — not to mention never having to worry about running out of battery compared to tablets or similar — crucial benefit.
Digital tools might result in better outputs but that's not what my notes are for. I prioritise minimising the friction that's between my thoughts and getting them on paper. On digital, I'm either limited by structure (f.ex. a Markdown file is limited by text being forced into lines) or having to change between tools when I want to jot down something in different format (text, circles, rectangles, arrows, whatever). It's a very small amount of work to switch between them but it cuts my thought because I need to think about the tools.
Pen and paper is the most direct connection my brain I've found.
"when building a house, obviously a hammer is more important than the _paper_ blueprints. This isn't art class, it's construction".
(when digital notes/digital blueprints are an available option)
Nice slap down.
Aaaa. I’d like to see stats over the comments—if management role, job history, age, income, education—and I’d expect opinions would be revealed as archetypical. In other words, it says more about the speaker than it says about successful software development.
Clearly the OP is talking about what works for them mentally—focus, creativity.
It’s a mistake for anyone to read a post like this and think of it (and the criticism) as prescriptive. Emulating any of the patterns would have the same result of cargo cult behavior.
Has a notebook or a whiteboard been handy at times? Of course. But the rubber meets the road behind the IDE, and the tooling there is the story of the day.
What kind of code do you work on?
I find notebooks useful all the time, but I write in C for embedded systems, so a lot of what I do involves setting up data structures, memory layout, etc.
Everyone’s different I guess, but for me I’ve never really reached much for a notebook. I just start writing code, refactor as needed, and rely on tooling from debugger/IDE/devtools when and where applicable.
In my now ~35 years of programming, I've found reaching for the notebook often saves me from needing to rely on a debugger unless it's code I inherited and didn't write myself. Even then, though, mapping it out on paper and using my pseudocode-shorthand to describe what the program does and what it intends to do is often faster than dealing with a debugger for anything but trivial bugs.
I’d go further to say that software development isn’t about writing code, it’s about designing and understanding programs. Code is an implementation detail, the understanding is what is crucial.
The new stuff is often fast and many jobs need it by way of keeping up with the standard practices and creating a hiring filter, but it's a supplement, not a foundational tool for thought. It can't be all that important because it's constantly shifting.
For people with higher confidence, those of us who have been around the block a few times, the article is correct. The supporting tools you mention are beneficial, but they aren’t the most important tool. The most important tool is soft skills and taking notes.
For at least some people, stepping away from the keyboard may be the best way to do that thinking.
To put it in your own style: This isn't typing class, it's software engineering.
Pen and paper is more helpful when I'm trying to see how the solution I came up with fits into the code, at least for me. I can't visualize at all, so even basic things about how data flows will be helpful if I write them down. The more concrete I'm getting, the more I use pen and paper or text documents. Otherwise it's just give myself time to work through the code as I know it, thinking of things and discarding them quickly, and waiting for inspiration to strike.
That's not to say I don't also use debuggers when necessary, I just reserve those for very hairy problems that can't be solved any other way, e.g. stepping into dependencies. Let's not forget that debuggers have their limitations too, e.g. release build GC optimization (or indeed any release-only bug), and any init process where you have to attach the debugger after the startup, fundamentally cannot be debugged using debuggers.
Linus Torvalds:
> I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a debugger, but as a disassembler on steroids that you can program.
> I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing.
> Oh. And sure, when things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger.
> I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_.
https://lkml.org/lkml/2000/9/6/65
And I agree. At least for me, print debugging goes a long way, and I'm already invested in building mental models about code. I think using a proper debugger has to be the last resort, because nothing else works and it's time to get into the ugly details. Two valuable avenues for producing good code are formal verification (and its ilk, such as specification) and horse sense/common sense, which combine to say that we should have rigorous mental models that impose on our code. That's the primary objective, to me. The use of tools such as debuggers is secondary, and in my experience, largely neutral or harmful. There's the classic caveat of "if your goal is to ship code fast, then this isn't practical", which is fair, but I have some things to say about shucking off that culture.
But perhaps it's a lack of knowing what a debugger can deliver.
A debugger gives you the ability to immediately dive in and instantly inspect the complete stack trace, all the values on the stack, all the values of local variables, etc. Without restarting the program or calling out specifically what you're going to want to inspect ahead of time.
A debugger will "pause the world" and let you see all the parallel stacks.
A debugger will let you set conditional breakpoints. If you need to debug the conditions for when a variable gets set to a particular value, a conditional breakpoint on the variable set to break when it's set to that particular value makes that a doddle.
A debugger will let you enumerate collections and re-write values on the fly.
A debugger will let you break on exceptions, even ones normally caught and handled.
A debugger can launch and attach itself.
All of that is a massive force-multiplier and time-saver, which print debugging doesn't deliver.
I use my debugger often, but sometimes you need to track the value of something over time (say, over 1000 iterations) and a debugger can't show you that.
So prints are still relevant. Debugger are more for "needle-in-haystack" stuff I think.
A debugger that could record the execution over time (and query that execution), that would be great. I know there are some, but are there for python for example ?
Do you mind providing examples? I’m not sure what I would search to find that and I’m interested in the idea.
Admittedly, I mostly develop with sbcl and slime, so the judiciously place 'break' statement brings you to a stack trace.
Also with sbcl/slime, you can do ESC-. on a function and go to the actual source, even deep within the core of sbcl itself.
Nonetheless, I mostly depend on logging statements and print statements. When I need to go to python, print statements give most of what I need.
You can design a house on paper, but you need e.g. mallets and wheelbarrows to build it; you can design software with "tools for thought", more or less computerized, but you need the automation offered by CI, version control etc. to handle the more concrete aspects properly.
I iterate faster, have more freedom and information is displayed and manipulated in a more ergonomic way to me on a computer, in such a way that it creates a symbiotic relationship. I severely doubt physical notetaking and brainstorming could ever compare
? It's the (mostly anonymous) internet and not linkedin. People call these things out all the time?
And even writing software I often make toss-away paper sketches; they help me see things in a way that make sense to me. Not replacing a computer, but complementing it. I would not push my method on everyone but it works for me. I also think similar techniques are fairly common. People discuss ideas verbally. They take walks to let brain take a different view, etc. My 2c.
Plenty of the research is online for you to answer your own question.
Some of us who grew up in the 1970s and 1980s even used to "program" by handwriting code on paper as kind of a rough draft.
I did this particularly for systems I didn't have at home, like the Apple ][. I'd handwrite programs at home, then take it to school and type it into an Apple ][. This was somewhat common.
I'm personally not a fan of pen and paper, I find it to not scale, I often change devices or I'm on the move, so I rely mostly on note apps (mostly Notion).
I agree with parent comment of notebook and pen being pure romanticism. I mean, heck, I'd rate Obsidian or some other back linking note software as more important than a notebook and pen. A sticky note and pen would be even more important than a notebook and pen.
(Maybe it’s different in modern college classes now but wasn’t for decades.)
(Maybe it’s different in modern college classes now but wasn’t for decades.)
/Old enough to have heard, "OK, now put away your slide rules…"