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.
OP here. Last time my blog caught attention in HN, I was told I'm "living in a fantasy" and this time it's "pure romanticism".
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.
> Those are tools that if I lost them, it surely would slow me down and be annoying.
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.
> significantly slower without an IDE, compiler or debugger … In fact, I don't think you would be a professional programmer if you didn't have them.
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.
They are examples, the exactness is not what is important here. Choosing something that is not connected to electricity, an OS, or the internet to be a software developer's _most important_ tool is, in fact, the strange position here.
Choosing something that is not connected to electricity, an OS, or the internet to be a software developer's _most important_ tool is, in fact, the strange position here.
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.
Hmm, but doesn't the brain run on electricity? And why couldn't it possibly have something like an OS? I don't think we know exactly how the brain works
Thanks for pointing this out. In the same vein there are so many posts about productivity systems where people put endless amount of time into crafting their gtd notebooks with tabs and lists, etc. All that time spent to be productive instead of actually being productive. Or people describing their ideal Obsidian work flows instead of actually noting anything useful down in it. People writing about how they built their own blogging engine because their particular way of blogging is so unique that they had to hand-roll something. All that time spent on building a blog rather than blogging. (I've been there too).
I love "This isn't craftsmanship cosplay, it's software engineering.". I will definitely steal this, let me put it in my notebook.
You see this everywhere. In sports its the people who spend most of their time worrying about their equipment instead of just playing the game. I was there with learning Chinese as well, spent way more time thinking about tools than actually learning the language.
What you're talking about is software machining, not software engineering.
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.
That’s funny, because if you go into any machine shop you’ll find machinists writing things down in notebooks (and probably cursing engineers who never set foot in the shop).
There are no more “old school” production lines left? I’m not sure what you mean; obviously there are a lot of production lines in the US, including the manufacturing of engine blocks as shown here.
Do you mean that they use robots today and therefore aren’t “old school”? That’s true in most industrialized economies.
The literal argument here is fine - using a notebook is antiquated and we have better tools.
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.
> using a notebook is antiquated and we have better tools
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.
For fast, physically intuitive, flow-of-thought expression, there’s nothing like pen and paper, for me.
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.
> using a notebook is antiquated and we have better tools.
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.
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.
This 100%. I was going to write something similar. In my entire 15 years in software engineering, the amount of times I've reached for a notebook pales in comparison to the amount of times I've relied on version control or a debugger.
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.
> the amount of times I've reached for a notebook pales in comparison to the amount of times I've relied on version control or a debugger.
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.
This is exactly my thought. Be it pen and paper or digital, writing out what your software needs to do and how it will do it saves an immense amount of time debugging or throwing things at the wall. I’m shocked at some of the responses here; there is a qualitative difference in the development experience when you spend the time designing (I also frequently do this by hand, but it doesn’t have to be) before implementing anything vs. opening an IDE and hammering something out.
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 amount of times I've reached for a notebook pales in comparison
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.
I do/done a little bit of everything. Backend Java, mobile ObjC (iOS) and Java (Android). Spent 2 years as a firmware dev on NRF platform so very familiar with spending time on data structures and byte alignment. I’ve also spend 4 years doing TS/JS back in the early Angular days.
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.
Over generations, we'll get to where the software tools are relatively more important, but as of right now, it is almost a certainty that the quality of the software you write benefits from writing less code and relatively more of it with a paper draft that is based on carefully reading sources and documentation, and not from any other kind of tools investment.
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.
What about an issue tracker? Or requirements? Design and planning? A debugger doesn't help you design, version control doesn't tell you what you still need to do, and CI doesn't tell you you've implemented the requirements (or even that the requirements you think you have are the actual requirements).
If you need a framework to do the job you were hired to perform then, clearly, that framework is the most important tool. You likely don’t exist professionally without it.
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.
That and taking a shower, doing dishes or taking a walk around the block, in fact I'd say that the ratio of bugs/issues I've solved while away from the computer compared to being in front of the computer is quite high (in favour of the "away from the computer"-fixes, that is).
The balance of rest is an important factor that I’ve understood the value of only later in my career. Pausing on a difficult engineering task at the end of the workday in favor of exercise or cooking dinner (or both) gives my mind and body time to reset it needs. Often answers or alternate approaches will materialize mid curl, crunch, or vegetable chop.
All right, let me put it this way: As a developer, my most important tool is my brain. The time I spend figuring out what to build and how to build it is more important than just banging out some code.
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.
It's not romanticism and it's very important for me too. I spend a lot of my time drawing out what I'm trying to do before I actually try to do it. I tend to work on greenfield embedded projects though for context. Coding and debugging is hard to get good at and are obviously important, but you still need to figure what to actually build and those tools won't get you there. For me, I use a pen and paper to actually figure out what I need to do.
When trying to figure out what to code or how to solve a problem, pen and paper is too "concrete" for me for some reason. If I'm waiting for inspiration I would rather just go for a walk or pace back and forth or just stare at something (monitor, wall, whatever) and think it through. When I write something down (or especially when I type it into a document) it becomes too set in stone for me, and if I do it too much I get way too "close" to it to see the solution.
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.
The conclusion I draw from this is that some debuggers are so bad it's not delivering value over "print debugging".
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.
A debugger doesn't show you the evolution of your program over time. A few well placed prints give you that.
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 ?
I've spent some quality time with debuggers but have come to the conclusion that it is a seductive way to spend time that doesn't necessarily get me there any faster than with printf or equivalent.
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.
I don't know you or your work. But I know (senior) developers that don't use a debugger and I've often noticed that when fixing a bug, they don't build a full mental model of what really goes wrong and often just fix the symptoms. Think "that shouldn't be null, we need a null check here" instead of "why is this value null? we should check here, but also make sure the caller works correctly."
On the other hand, though this is n = 1 and from 2000 (and it is classic Linus):
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_.
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.
Debugger for me is more about inspection than actual debugging, especially when dealing with a complex systems. It's possible to just use a printf, but the debugger gives more information. It's rare that I need to do stepping. I mostly just want to see the stack trace and the state of the program. One of the nice thing about Common Lisp and Smalltalk is to be able to do this any single point.
I do not know what you work on, but debugging is indispensable for certain workloads. Print debugging doesn’t come close to setting up a breakpoint and inspecting every single variable in the stack with a good interface. You don’t even have to select what to print and where, anything can be printed anywhere in two clicks. A UI like the debuggers in Jetbrains IDEs provides smart rendering for all types so that for example map or list elements can be collapsed. The entire call stack is neatly organized and searchable too. It saves hours, creates less friction and also greatly enhances exploratory debugging, where you don’t even know where in the call stack your problem might be. I’d feel very hindered and unhappy if I didn’t have access to a good debugger.
My bread and butter at one point was working on various pathfinding and numerical computing problems, and I'm primarily a print statement debugger. The time evolution of the system is usually the most important signal for debugging these types of problems, and is easy to dump.
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.
Debuggers are important tool, but not all debugger are good and not all problems require debugger. That's why I wrote a simple tool, which given a list of methods and classes will printf to log every invocation and exit of selected functions (via java reflection and function rewriting). It was much better than a normal debugger at finding actual flow of data in very complex multi-program system, so essentially machinegun-printf saved the day.
I was the same until I started working on a Go server. It helps immensely when I want to know the value of objects say when a request is handled and how that flows.
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.
"Most important tool" depends on what you mean by "important". For TFA, it means the environment where most of the thinking is done. So it's a legitimate claim. If you want to restrict "important" to the most critical link in the development chain, I suppose you would have to choose the compiler.
Finally someone had the guts to say it. I see the same arguments again and again that writing in a notebook makes you remember things better and think more thoroughly, but who exactly was tested here? Were people with an extensive and deeply personal Zettelkasten note taking system added as participants in the studies? What was their note taking process? Most people severely underutilize or even misuse their digital tools. Just take a look at people who use Notion ;)
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
Different people learn and work in different ways. To become comfortable with a new complex topic I personally have to work things out, with a pencil and an eraser, on a piece of paper.
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.
I see the same arguments again and again that writing in a notebook makes you remember things better and think more thoroughly, but who exactly was tested here?
Plenty of the research is online for you to answer your own question.
Think of it this way: The brain outweighs those tools (for now). The notebook is an extension of thought and the brain.
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 would say that planning, analyzing and tracking is by far the most important part of engineering process, software or not.
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).
As a developer my most important tools are a computer with working keyboard, monitor, and mouse. Everything else is secondary. A notebook and pen falls somewhere below cpu, gpu, hard drive, ram, reliable internet, etc.
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.
