I do not use a debugger (2016)

Some of the opinions on debuggers are more nuanced than the author is letting on. Take Bob Martin, for example:<p>&gt; I consider debuggers to be a drug -- an addiction. Programmers can get into the horrible habbit of depending on the debugger instead of on their brain. IMHO a debugger is a tool of last resort. Once you have exhausted every other avenue of diagnosis, and have given very careful thought to just rewriting the offending code, <i>then</i> you may need a debugger.<p><a href="https:&#x2F;&#x2F;www.artima.com&#x2F;weblogs&#x2F;viewpost.jsp?thread=23476" rel="nofollow">https:&#x2F;&#x2F;www.artima.com&#x2F;weblogs&#x2F;viewpost.jsp?thread=23476</a><p>I&#x27;m still baffled by people like the author who &quot;do not use a debugger.&#x27; A print statement is a kind of debugger, but one with the distinct disadvantage of only reporting the state you assume to be important.<p>This part was a little surprising:<p>&gt; For what I do, I feel that debuggers do not scale. There is only so much time in life. You either write code, or you do something else, like running line-by-line through your code.<p>I could easily add something else you might spend the valuable time of your life doing: playing guessing games with print statements rather than using a powerful debugger to systematically test all of your assumptions about how the code is running.

I practically live in the debugger. I do use it sometimes to debug a problem, but most of the time I use a debugger to <i>avoid</i> debugging. I use it for coding.<p>I spend a lot of time working with APIs and libraries that are poorly documented and often that I haven&#x27;t used before.<p>Instead of writing out a bunch of code based on my limited understanding of the docs, and likely with many bugs, what works for me is to just write a few lines of code, until I get to the first API call I&#x27;m not sure about or am just curious about. I add a dummy statement like &quot;x = 1&quot; on the next line and set a breakpoint there.<p>Then I start the debugger (which conveniently is also my code editor) and hopefully it hits the breakpoint. Now I get to see what that library call <i>really</i> did, with all the data in front of me. Then I&#x27;m ready to write the next few lines of code, with another dummy breakpoint statement after that.<p>Each step along the way, I get to verify if my assumptions are correct. I get to write code with actual data in front of me instead of hoping I understood it correctly.<p>If I&#x27;m writing Python code in one of the IntelliJ family of IDEs, I can also hit Alt+Shift+P to open a REPL in the context of my breakpoint.<p>Of course this won&#x27;t work for every kind of code. If I were writing an OS kernel I might use different techniques. But when the work I&#x27;m doing lends itself to coding in the debugger, it saves me a lot of time and makes coding more fun.

&gt; Doing “something else” means (1) rethinking your code so that it is easier to maintain or less buggy (2) adding smarter tests so that, in the future, bugs are readily identified effortlessly. Investing your time in this manner makes your code better in a lasting manner… whereas debugging your code line-by-line fixes one tiny problem without improving your process or your future diagnostics.<p>I&#x27;ve been a professional now for about 15 years and very, very rarely do I get to work on &quot;my code&quot;. Almost all of the code I have to work with was written by someone else originally and I have to just modify the system for new requirements. Tests do not exist or if they do they are largely incomplete.<p>So the only thing to do is to step through find the problem, fix the ticket and move on.<p>Sure If I get to design the system I normally write it very simply &#x2F; well structured with appropirate levels of abstraction and with enough tests to expose the bugs in my code. But very rarely do I get paid to work on my code, because my code doesn&#x27;t need a lot of maintenance. I normally am asked to make changes to bad systems.<p>&gt; Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.<p>Thinking harder when I have a project with millions of lines of code (this is normal in large financial systems) won&#x27;t help me. A debugger will.<p>I think a lot of these famous programmers have never had to work with something terrible and probably never will and that is why they make such blasé statements.

I wonder if the author has actually used a debugger with practical reverse execution, like rr, UndoDB or TTD. It is not just another feature like &quot;pretty-printing STL data structures&quot;; it changes everything. Debugging is about tracing effects back to causes, so reverse execution is what you want and traditional debugging strategies are workarounds for not having it.<p>Those record-and-replay debuggers also fix some of the other big problems with debugging, such as the need to stop a program in order to inspect its state.<p>The author is right that the traditional debugger feature set leaves a lot to be desired. Where they (and many other developers) go wrong is to assume that feature set (wrapped in a pretty Visual Studio interface) is the pinnacle of what debuggers can be. It&#x27;s an understandable mistake, since progress in debugging has been so slow, but state-of-the-art record-and-replay debuggers prove them wrong. Furthermore, record-and-replay isn&#x27;t the pinnacle either; much greater improvements are possible and are coming soon.

The article neglects one of my most important use cases for a debugger: figuring out how an undocumented piece of legacy code works. For example, if I perform a particular action in the UI, does function foo() get called? I find that setting breakpoints and tracing execution and variable changes in a debugger is an effective way of doing this kind of reverse engineering.<p>Also, when you&#x27;re working with code that takes a long time to compile and link, using a debugger to check program state can be a lot quicker than recompiling the code with added print statements.<p>Different developers work with different types of code in different environments, so just because Linus Torvalds or Rob Pike does something one way doesn&#x27;t mean that this is the most effective way for everyone else to do it.

The article talks about live debugging &amp; stepping through code, which I agree, I almost never do. But post-mortem debugging of coredumps is a different thing entirely.<p>In my job on the kernel team at Netflix&#x27;s Open Connect CDN, I do post-mortem debugging of kernel core dumps almost daily. On a fleet the size of our CDN, there will invariably be a kernel panic which you&#x27;d not otherwise be able to reproduce. In fact, I often use <i>2</i> debuggers: kgdb for most things, and occasionally a port of the OpenSolaris mdb for easily scripting exploration of the core.<p>My hat is off to all the people who made my debugging so much easier. Eg, the llvm&#x2F;clang folks who emit DWARF, gdb folks who make the FreeBSD kgdb debugger possible, and the Solaris folks who wrote the weird and wonderful mdb.

As always with these kinds of dogamtic posts it ignores the real world: working on years old legacy software with millions of lines of code and off-the-charts cyclomatic-complexity.<p>I could show anyone of these authorities a situation where their bravado would fail a trying to figure out a particular bug by &quot;staring at the code and thinking harder&quot; would be impossible.<p>Besides - they all tend to concede that they will use print statements or whatever as a last resorted. That is just retarded - you have to add the statements, recompile the code, and eventually remove them again. Just use the goddamn debugger that&#x27;s what it&#x27;s there for.<p>What starts as a completely reasonable &quot;hey maybe sometimes you should try to read the code and not let the debugger become a crutch&quot; turns into a sensationalist black&#x2F;white statement &quot;I NEVER USE A DEBUGGER&quot;. Grow up.

I find this to be completely unbelievable. If I&#x27;m in IntelliJ or Visual Studio, then adding breakpoints is equivalent, but easier than adding print statements. It&#x27;s trivial to click the gutter on the line I&#x27;m suspicious of and run the program in debug mode. I can see all the local vars (exactly what I&#x27;d do with a print statement) and if something is amiss, easily go back up the call stack to see what went wrong. I find it mind-blowing when developers don&#x27;t do this because it&#x27;s so easy and so valuable. It&#x27;s just so much harder to do with functional languages or languages without a first-rate IDE which seem to be what people like these days. In fact, I find it mind-blowing when developers don&#x27;t consider this a mandatory feature to need when choosing a language.

The author fails to understand the true purpose of &quot;debugging&quot;. It&#x27;s not about finding and fixing a bad line of code. It is about broadening your understanding of a system and correcting faulty assumptions about how it works. Then applying this greater understanding to a) find and fix issues and b) avoid creating new problems in the future.<p>Once you have extensive knowledge of how a system works, you can more easily spot incorrect code and are less likely to write it yourself. You should always treat any debugging session as &quot;learning more about the system&quot;. If you can&#x27;t explain to another person _why_ a bug occurred, then you won&#x27;t be able to convince them that the problem is truly fixed.<p>The approach you take to learn how the system works is not important, and will vary from person to person. Experienced developers can read code, think about it, and understand what it does. Some people understand control flow through print statements. Some people can fly through with a debugger. Saying someone else&#x27;s method of study is &quot;wrong&quot; is just silly if in the end they understand how it works.<p>This article is especially wrong because it makes the assumption that you must step through a program line by line when you use a debugger, which you don&#x27;t have to do. You can just put breakpoints at the same places where you would have put an equivalent print statement, except now you can inspect _everything_, instead of the one or two things you bothered to print out.

I use debuggers (GDB) exclusively in batch mode. It allows for a very methodical debugging approach:<p>1 Formulate a Hypothesis<p>2 Determine what data you need for verification<p>3 Instrument code using gdb break commands, to hook function calls, sys-calls, signals, state-changes, etc. and print debugging information (variables, stack traces, timings) to a log file.<p>4 Then run an automated or manual test, of the failure you are debugging.<p>5 Then STOP data collection. Kill the process. Shut down the debugger.<p>6 Perform forensics on the log file.<p>7 Validate&#x2F;Discard the hypothesis.<p>With this allows you reason reliably about the computational process:<p>- Why did I see this log line before this one?<p>- Why was this variable NULL here, but not in here.<p>You don&#x27;t need to do that while you are in debugging session. You can take your time. You can seek back and forth in the file. It&#x27;s like dissecting a dead animal, not chasing a fly.<p>In addition, you can share concise information with your colleagues:<p>- This is the instrumentation<p>- This is the action I performed<p>- This is the output<p>And ask concise questions, that people might be able to answer:<p>&gt; I expected XYZ in long line 25 to be ABC, but it was FGH. Why is this?

So the argument is that if you use a debugger you become lazy and stop reasoning about the code. That&#x27;s a pretty terrible argument against any tool. &quot;It&#x27;s a good tool, but if used wrong has drawbacks&quot;. I have heard a similar argument against syntax highlighting. I&#x27;m not kidding.<p>I&#x27;m sure I&#x27;d write more thought through code if I took a screwdriver and removed my backspace key. But that doesn&#x27;t mean it&#x27;s a good idea.<p>How about: use a debugger AND reason about the code? My pet theory: The reason the listed developers Kerningham, Torvalds et.al, don&#x27;t use debuggers is because the debuggers they have available just aren&#x27;t good enough. It would be very interesting to have them describe their development environments, and what debuggers they have actually used, and in which languages.<p>A debugger isn&#x27;t much better than println if you are working in a weak type system and with a poorly integrated development environment. If you do C on linux&#x2F;unix and command line gdb is your debugger then I understand why println is just as convenient.<p>println doesn&#x27;t solve the problem of breaking in the correct location, trying a change without restarting (by moving the next statement marker to the line before the chnaged line), It doesn&#x27;t support complex watch statements to filter data or visualize large data structures and so on.

So I work with a company where we provide online nutrition consultation to employees from other organisations as part of a larger corporate medical program. Our system has a scheduling system developed in Rails to deal with these appointments. This system was developed by a person who quit the company some time back.<p>A few weeks back, we got some complaints from a client who said some of their employees weren&#x27;t getting allotted an appointment slot, despite the fact that the slot is supposedly free. I dived into the codebase to try and figure out the problem. There were some minor bugs which I spotted first, and could fix without using a debugger. But the appointments were still getting dropped occasionally. So I started tracing the control flow more carefully.<p>That’s when I found one of the strangest pieces of code I had ever seen. To figure out what the next available appointment slot was, there was a strange function which got the last occupied slot from the database as a DateTime object, converted it to a string, manipulate it using only string operations, and finally wrote it back to the database after parsing it back to a DateTime object, before returning the response! This included some timezone conversions as well! Rails has some very good support for manipulating DateTimes and timezones. And yet, the function&#x27;s author had written the operation in one of the most confounding ways possible.<p>Now, I could have sat there and understood the function without a debugger as the article recommends. And then, having understood the function, I could have then rewritten the function using proper DateTime operations. But with a client and my mangers desperately waiting for a fix, I used a debugger to step through the code, line by line, just understanding the issue locally, and fixed the bug which was buried in one of the string operations. That solved the problem temporarily, and everyone was happy.<p>A week later, when I had more time, I went back and again used the debugger to do some exploratory analysis, and create a state machine model of the function, observing all the ways it was manipulating that string. I added a bunch of extra tests, and finally rewrote the function in a cleaner way.<p>Instead of romanticising the process of developing software by advocating the use or disuse of certain tools, we should be using every tool available to simplify our work, and achieve our tasks more efficiently.

The end of the essay implies that &quot;debugger&quot; is a poor name because of course you still have to fix the bug yourself. If we call it instead &quot;bug-location-explorer&quot; I find them invaluable for certain problems. In particular when you have a very complex system that takes a while to get into its fragile state, when I&#x2F;O is difficult (e.g. many embedded systems), or as others have noted here when you are spelunking others&#x27; code. Breakpoints are crucial since most bugs with modern languages are wrong output and not bus errors.<p>I started out as a user of &quot;print&quot; as a debugging technique, but early on Bill Gosper took pity on me and introduced me to ITS DDT and the Lispm debugger. They both had an important property that they were <i>always</i> running, so when your program fails you can immediately inspect the state of open files and network connections. No automatic core dumps except for daemons. The fact that you explicitly have to attach a debugger before starting the program is a regression in Unix IMHO.<p>It doesn&#x27;t surprise me that Linus doesn&#x27;t use one as kernel debugging is its own can of worms.

I use debuggers to track down and understand compiler codegen bugs.<p>I use debuggers to track down and understand undefined behavior, where mutating the code with logging statements may cause the bug to disappear.<p>I use debuggers to understand the weird state third party libraries have left things in, many of which I don&#x27;t have the source code to, or even headers for library-internal structures, but <i>do</i> have symbols for.<p>I use debuggers to understand and create better bug reports and workarounds for third party software crashing, when I don&#x27;t have the time, the patience, or the ability (if closed source) to dive into the source code to fix it myself.<p>I use debuggers to verify I understand the exact cause of the crash, and to reassure myself that my &quot;fixes&quot; actually fixed the bug. This is especially important with once-in-a-blue-moon heisencrashes with no good repro steps. I want a stronger guarantee than &quot;simplify and pray that fixed it&quot;.<p>Yes, if your buggy overcomplicated system is a constant stream of bugs, think hard, refactor, simplify, do whatever it takes to fix the system, stem the tide, and make it not a broken pile of junk.<p>But sometimes bugs happen to good code too though, and sneaks through all your unit tests and sanity checks anyways. And despite rumors such as:<p>&gt; Linus Torvalds, the creator of Linux, does not use a debugger.<p>Linus absolutely uses debuggers:<p>&gt;&gt; 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.<p>He just pretends he&#x27;s not using it as a debugger (as if &quot;a disassembler on steroids that you can program&quot; isn&#x27;t half of what makes a debugger a debugger) and strongly encourages coding styles that don&#x27;t require you to rely on them heavily.

I see mentions of gdb - an extremely cumbersome tool - no mention of Visual Studio and its marvelous debugger.<p>I too, when I&#x27;m on Linux, don&#x27;t use a debugger, because there&#x27;s no good debugger and adding a print statement is faster and easier, and figuring out what is going on with gdb is just plain horrible and slow.<p>That&#x27;s why as soon as I find a bug on Linux I try to have it on Windows to leverage VS&#x27;s debugger. I can&#x27;t count the number of times where I could instantly spot and understand a bug thanks to VS&#x27;s debugger.<p>&quot;Think harder about the code&quot;, sure, and what if you didn&#x27;t write the code?

Sounds like a theologist who wouldn&#x27;t use a microscope, and instead think over&#x2F;interpret harder their Holy-book-of-choice. You can get into interesting insights along the way, but I wouldn&#x27;t call it practical or efficient.<p>Debuggers are the most <i>amazing</i> tools to explore and learn the code in your hands. They do have limitations, as pointed out, but presuming that your inner insight&#x2F;gut feeling leads to more scalable and lasting results is ridiculous.

Smarter people have expressed more ill considered opinions.<p>&quot;In the 1950s von Neumann was employed as a consultant to IBM to review proposed and ongoing advanced technology projects. One day a week, von Neumann &quot;held court&quot; at 590 Madison Avenue, New York. On one of these occasions in 1954 he was confronted with the Fortran concept; John Backus remembered von Neumann being unimpressed and that he asked, &quot;Why would you want more than machine language?&quot; Frank Beckman, who was also present, recalled that von Neumann dismissed the whole development as &quot;but an application of the idea of Turing&#x27;s &#x27;short code.&quot;&#x27; Donald Gilles, one of von Neumann&#x27;s students at Princeton, and later a faculty member at the University of Illinois, recalled that the graduate students were being &quot;used&quot; to hand-assemble programs into binary for their early machine (probably the IAS machine). He took time out to build an assembler, but when von Neumann found out about it he was very angry, saying (paraphrased), &quot;It is a waste of a valuable scientific computing instrument to use it to do clerical work.<p>&quot;<a href="https:&#x2F;&#x2F;history.computer.org&#x2F;pioneers&#x2F;von-neumann.html" rel="nofollow">https:&#x2F;&#x2F;history.computer.org&#x2F;pioneers&#x2F;von-neumann.html</a>

He cite Linus, who says that not using debugger result in longer time to market. which is good for Linux in his mind. How is this convincing for me?<p>Anyway, imagine a detective trying to figure out a murder scene without going through it step by step. Of-curse with experience come speed. So, weird flex but OK. I will still prefer C# over any language just because the debugger in Visual Studio is amazing!<p>After re-reading the article, I see it as another &quot;Just code better&quot; which hopefully will make it easy to pinpoint the bug just from the problem itself. In complex system with a lot of feedback loops, It&#x27;s nearly impossible without debugging or using logs (which for me are just serialized debugger).

Debugging is reverse-engineering, i.e trying to understand what&#x27;s really happening inside a program.<p>It necessarily implies some loss of control over the code you (or somebody else) wrote, i.e you&#x27;re not sure anymore of what the program does - otherwise, you wouldn&#x27;t be debugging it, right?<p>If you get into this situation, then indeed, firing up a debugger might be the fastest route to recovery (there are exceptions: e.g sometimes printf-debugging might be more appropriate, because it flattens time, and allows you to visually navigate through history and determine <i>when</i> thing started to went wrong).<p>But getting into this situation should be the exception rather than the norm. Because whatever your debugging tools are, debugging remains an unpredictable time sink (especially step-by-step debugging, cf. Peter Sommerlad &quot;Interactive debugging is the greatest time waste&quot; ( <a href="https:&#x2F;&#x2F;twitter.com&#x2F;petersommerlad&#x2F;status&#x2F;1078958027175329793" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;petersommerlad&#x2F;status&#x2F;107895802717532979...</a> ) ). It&#x27;s very hard to estimate how long finding and fixing a bug will take.<p>Using proper modularity and testing, it&#x27;s indeed possible to greatly reduce the likelihood of this situation, and when it occurs, to greatly reduce the search area of a bug (e.g the crash occurs in a test that only covers 5% of the code).<p>I suspect, though, that most of us are dealing with legacy codebases and volatile&#x2F;undocumented third-party frameworks. Which means we&#x27;re in this &quot;loss-of-control&quot; situation from the start, and most of the time, our work consist in striving to get some control&#x2F;understanding back. To make the matter worse, fully getting out of this situation might require an amount of work whose estimate would give any manager a heart attack.

“Stepping through code a line at a time” is a rather narrow definition of using a debugger. Setting a logging breakpoint. Conditionally breaking. Introspection by calling functions while the program is paused. Testing assumptions by calling functions. Conditionally pausing the program. Setting a breakpoint in code and then calling functions to activate the code path to the breakpoint. This is the core of what lldb does for me. I agree, single stepping is rare and is like looking for the needle in the haystack. But are all these other aspects not assumed to be using the debugger?

&gt; However, the fact that Linus Torvalds, who is in charge of a critical piece of our infrastructure made of 15 million lines of code (the Linux kernel), does not use a debugger tells us something about debuggers.<p>It tells us more about Linus. I hope no impressionable developers take this article too seriously.

Coding efficiency is heavily influenced by the time it takes to iterate. Once you write something, the time it takes to test it out, change it, and try something new provides a nice upper limit on how fast you can develop software.<p>The speed of iterating changes to code has a huge influence on the tools that you use. In a language like C, compiling new changes to code can take many seconds or sometimes minutes. Thus, you&#x27;ll want to have heavy duty tools that can carefully analyze how your code is operating.<p>In contrast, in a scripting language, changing a line and rerunning the code can take far less time (a few seconds for even large programs). Thus, you can iterate more often, and so you don&#x27;t have to be as careful in each iteration.<p>The moral of the story is that debuggers can be extremely helpful for some languages, especially those that take a long time to compile. However, while still helpful, they are far less helpful for languages that you can run quickly (I&#x27;m thinking Python here).

The anti-debugger argument always seems to set up this strawman debugger user who blindly starts the debugger in response to any problem, applies no thought to what&#x27;s going on, doesn&#x27;t dig deeper, etc.<p>Sure, maybe that guy exists. Maybe you&#x27;ve seen &quot;that guy&quot; or been &quot;that guy&quot;. Does that mean that it has no value to be able to stop a program and look at all the values?

I think we need to rethink what we mean by debugger. In Dark (<a href="https:&#x2F;&#x2F;darklang.com" rel="nofollow">https:&#x2F;&#x2F;darklang.com</a>), we don&#x27;t have a debugger. Instead we combine the editor with the language, and then when you&#x27;re editing code you have available at all times a particular program trace (typically a real production value, which are automatically saved because dark also provides infra). As a result, you can immediately see the value of a variable in that trace.<p>Is this a debugger? Sure. It sorta lets you step through the program and inspect state at various points. But it&#x27;s also a REPL, and it also strongly resembles inserting print statements everywhere. It&#x27;s also like an exception tracker&#x2F;crash reporter and a tracing framework.<p>IMO it&#x27;s both simpler and more powerful than any of these. It&#x27;s like if every statement had a println that you never have to add but is available whenever you want to inspect it. Or like a debugger where you never have to painfully step through the program to get to the state you want.<p>So overall, I think we need to think deeper about what a debugger is and how it can work. Most of the people quoted do not have a good debugger available to them, nor a good debugging workflow.

I hate this article and disagree strongly with the ideas presented.<p>“Debuggable” code is written in a certain style — just like “testable” code.<p>I consider a codebase to be good when there are meaningful places to put break points sufficient for running learning experiments about the code. Just like a codebase with “tests” is often a better codebase as a result of being written in a way that supports testing - a codebase that supports debugging can also often be a better codebase. And these work well together putting break points in test cases is often a really great idea!).<p>I think one of the reasons the value of the debugger so often fails to be noticed by experienced developers is that so many systems are architected in a horrific way which really does not allow easy debugger sessions — or the debugger platform is so underpowered that debugging is unreliable. There’s nothing worse than not trusting the debugger interface — “i want to do an experiment where I run code from here up to here” needs to be easy to describe and reliable to execute otherwise it is too much pain for the gain. In my opinion, failure to make this easy is not a fault of the concept of debugger but a fault of the codebase or the tooling (which often is very inadequate).

I do not use a debugger most of the time either. Let me tell you why I don’t:<p>- Because I forgot how to use it (or never knew how.) There are many debuggers and UIs and I still know how to use some of them to decent effect, but I simply don’t know how to be effective with most of them.<p>- Because I’m pretty confident I have a good understanding of what code is doing nowadays. My intuition has been honed over the years and I tend to quickly guess why my code isn’t working.<p>- Because my code is all unit tested now. This contributes to my ability to be more sure about what code is <i>actually</i> doing.<p>There are still some cases where I may try a debugger. I had one recently where I was unsure what path my code was taking and I wasn’t sure how to printf debug. That helped a lot.<p>Not using a debugger is not really a choice I made or something I do to try to look impressive, rather it’s most likely a result of the growing diversity of programming languages and environments I work in, combined with better testing habits. I just feel like I have enough confidence to fix the bugs quickly. When I lose that confidence is when I break out printf or the debugger.

&gt; Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.<p>Of course the first tool is careful thought. But when forced to fall back to print or log statements it feels like a handicap.<p>If I have to use a print statement it means I&#x27;m not sure what&#x27;s going on so I&#x27;m not sure what, exactly, to print. By breaking on that code I don&#x27;t have to know exactly because I can execute arbitrary code in that scope. What takes multiple iterations with print is often just one with break.<p>I can compare directly, because on a production-only bug I&#x27;m forced to use log debug statements. And usually in that case I have the same code open locally in a debugger. The difference is night versus day.<p>Maybe it&#x27;s like a chess master who really doesn&#x27;t need the board. For the kid in Searching for Bobby Fischer, it may really be a distraction. But I notice that grandmasters use a chess board in serious competition. And as a programmer I&#x27;m no grandmaster, and I play this weird game better with the board in front of me.

When I worked at Google Search last year, running a service locally in the Debugger was just about the only way to figure out what it does. There are so many control flow transfers - async message passes and you have no idea what is coming back - and people that think they are Templating gods and idiots who want to use syntactic sugar to define a new language and people using functors just &#x27;because&#x27; and lambdas and other BS C++21 features inside Google and inheritance&#x2F;container trees that look like a 3-D house that the debugger is the only way you can trace the control flow of such a haywire spaghetti code base.<p>Sadly, gdb is running out of gas at Google - it takes 60s to load &quot;hello world&quot; + 200MB of Google middleware and often it would step into whitespace or just hang, forever. This was often because not smart people were maintaining the gdb&#x2F;emacs environment at Google.

Debuggers a great tool to have in your toolbelt. They can arbitrarily modify the state of the program at any point, let you safely inject code (I’ve written “coroutines” in LLDB for applications I did not have the ability to insert print statements in), and can be <i>extremely</i> helpful when performing dynamic analysis. That being said, sometimes you don’t have access to a debugger, so you have to do your best with the tools you have available. Finding a bug is always a challenge of removing extraneous state you don’t care about (“where do I put this print statement so it doesn’t get called a million times”, “how can I visualize the value of this variable when it changes in a way that is important”) so not having a debugger doesn’t change this: it just makes it somewhat more annoying (and requiring more ingenuity) to perform these tasks because you now have more limitations.

Debugging complex multithreading or timing-related bugs is one of the areas where a debugger, or even a bunch of logging, is not going to help you at all, because the slightest change in timing can make them disappear; only (very) careful thought is likely to lead to a solution.<p>Thus I mostly agree with the author of this article --- blindly stepping through code with a debugger is not a very productive way of problem solving (I&#x27;ve seen it very often when I taught beginners; they&#x27;ll step through code as if waiting for the debugger to say &quot;here is the bug&quot;, completely missing the big picture and getting a sort of &quot;tunnel-vision&quot;, tweaking code messily multiple times in order to get it to &quot;work&quot;.) If you must use it, then make an educated guess first, <i>mentally</i> step through the code, and only then confirm&#x2F;deny your hypothesis.

I use a debugger all the time. Why guess about any of this stuff, and why trust your fallible intuition, when you could have the computer tell you exactly what&#x27;s really happening? I think of it as analogous to using a profiler in this respect.

I write scientific simulations in Matlab. Debugging, that is, stopping the programs and interacting with the data and functions, is essential to me.<p>To a point, this is due to me not planning through my programs. So I can see that for some areas a debugger may not be essential.<p>But in other cases, I am actually interested to trace what happens with data in my mechanisms. For this kind of work, a debugger is essential.<p>Most importantly, as someone who maybe does not use the absolute best practices of designing software, debugging allows me to write solid and successful programs without having completed a CS degree.

I would like to meet someone who writes code without any bugs. Now if you&#x27;re not putting bugs on purpose in your program, you probably don&#x27;t know what they may arise from. So why use a tool (prints) which is deeply influenced by your assumptions on the program and which probably where wrong in the first place? Some more arguments for the debugger: -No need to recompile for each print -Available for multi-threaded progs -possibility to see the state in libs you&#x27;re dependent on, in which you can&#x27;t put logs nor asserts.

That depends on what problem or code base you are working with.<p>The debugger is the best answer when you are working with bad code, which you cannot reason about the code locally -- a random bug only happens on the production env, a mutable monolith, or a complex system integrating with 3rd party services. Because debugging is to know what happens in the first step, then build a theory to reason about everything. Sometimes, fixing the plane in middle-air requires you need to know what happened to the specific plain, instead of building a theory to make a plane having the exact problem without looking at the plane itself. Like in control theory if there are too many possible states, it&#x27;s not cost efficient to reason about the state from behavior -- wherein software you can cheat and inspect the state directly.<p>However, I agree with the author that in the ideal scenario there&#x27;s almost no need to use the debugger. Like in SICP, in the first few chapters the mental model is about the substitution model -- it&#x27;s not how a computer really works, but it&#x27;s easier to reason about, you don&#x27;t have to in specific step with the specific environment to reproduce the problem (that&#x27;s where debugger really helps). The code is written is a matter which is more coupled with the environment (which reflects the environment model in the following chapters), the more one needs to use the debugger to work with that code. And that&#x27;s why the virtue of functional programming and the referential transparency are praiseworthy.

Debugger is just an inspection tool that allows you to see in detail how your contraption (program) behaves while it&#x27;s running. Treating it as the tool of last resort, only after you&#x27;ve exausted examining your program while at rest, is needlessly limiting. I can see how that could make more sense in physical engineering (if you turn the contraption on without fully understanding it, you&#x27;re risking doing some damage), but there is no such risk in SE, so why limit yourself?

I feel like debuggers usefulness is directly correlated to how specialized it is. A good debugger is all about giving you specific information on your problem. I find the classical step-by-step debuggers do an incredibly poor job at this. I never use them.<p>A tier up from that for me are higher-level debuggers, generally specific to some technology. For example, the browser dev tools, GTK Inspector, wireshark, RenderDoc etc. I&#x27;d also put tools like AddressSanitizer, Valgrind and Profilers into this category. Because they are more specialized, they can give you richer information and know what information actually matters to you. I usually find I use these regularly when developing.<p>The highest tier is tools specialized to your specific application. This could be a custom wireshark decoder, a mock server or client, DTrace&#x2F;BPFTrace scripts and probes, metrics, or even an entirely custom toolbox. Interestingly, print statements end up in this same category for me, despite being the possibly simplest tool. Being specific to the problems you actually face allows you to focus on the very specific problems you have. This tier is interesting because these tend to become not just something you use when things go wrong, but become part of how you write or run your code.<p>Under this lens, I don&#x27;t think it&#x27;s that surprising people don&#x27;t really use general step debuggers that much. They are a primitive tool that allows you to have many of the benefits of tier3 debuggers without any of the effort involved in making custom tools. They are the maximum reward&#x2F;effort in terms of debugging.

Another way to think of this is that the debugger is a tool, just like other familiar tools such as tcpdump, ping, traceroute, nslookup, nc (netcat) etc. Choosing the right tool for the right observations to make progress in squashing said bug(s) is key here. Sometimes, all you really need is a methodical approach in putting print statements in the right lines of code, or even pinging a host that doesn&#x27;t seem like it&#x27;s up in the first place.

My problem with debuggers is that they are too good of tools. You use them, solve the bug, and move on. In the process, <i>you</i> might have learned something additional about the code base, but the only improvements to the code are fixing that particular bug. In contrast, when you don&#x27;t use a debugger, then every now and then when you try to debug, you find that some of your work is not simply a temporary hack to identify the problem, but something that should stay in the code long term to assist in future debugging (be it asserts you added, or additional logging calls). The end result is that the more you debug without a debugger, the more debuggable you code becomes.<p>I am currently working on a codebase where all the developers are adamant debugger users. The code is practically impossible to debug without the use of a debugger, because no one has ever had to build up the debugging infrastructure.<p>Complex&#x2F;diffucult bugs still take about as long to fix, but simple bugs take far longer than they normally do, because every time you use a debugger you are starting from scratch.

This is actually well written article by a CS professor and cited with experiences of few very productive programmers. Especially Linus&#x27;s no bar holds post on this topic is worth reading:<p><a href="https:&#x2F;&#x2F;lwn.net&#x2F;2000&#x2F;0914&#x2F;a&#x2F;lt-debugger.php3" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;2000&#x2F;0914&#x2F;a&#x2F;lt-debugger.php3</a><p>Many people say not using debugger is other side of the pendulum but perhaps it is not. You want to have assertions&#x2F;prints in your program at critical junctions. That should be able to explain the behavior of the program you are seeing. If it doesn&#x27;t then you probably have missed some critical junctions OR don&#x27;t really understand your own code. There is actually a third possibility where you <i>will</i> need debugger. This is the case when compiler&#x2F;programming language&#x2F;standard libraries itself has bug. Instead of more time consuming binary search for where you first get unexpected output, debugger might be better option.

The author ignores a variety of points, but the major one seems to be that there seems to be some ignorance about debuggers being a &quot;line-by-line&quot; tool. I usually use it to understand big codebases, by stepping through the functions in the order they are called, and I am quite sure there isn&#x27;t some other way to tackle this requirement.

Those who say kernels should be debugged with print statements inserted into the code should promptly hand in their register and backtrace dumping functions, lockup detectors, memory allocation debugging, spinlock debugging, &quot;magic sysrq key&quot;, ...<p>Oh wait; all of that is judiciously inserted print statements.

My gut reaction is that the article is nonsense but I think there&#x27;s a very valuable point in it.<p>When you work mainly on enterprise code where you&#x27;re unlikely to encounter any code you wrote, rather than another team member, on a daily basis you&#x27;ll need a debugger or print statements.<p>But the reasonable point the article makes is a debugger makes it very easy to solve the problem localised to a function or a couple of lines of code rather than take the time to improve the whole area and&#x2F;or add test coverage. But the other thing people who don&#x27;t work on enterprise code won&#x27;t necessarily understand is you don&#x27;t usually have time to do that. So it&#x27;s a good thing to keep in mind but it feels a little too Ivory Tower to be broadly applicable.

As a professional support programmer (read that: I have to debug code someone else wrote), I don&#x27;t use debuggers often.<p>But sometimes I do. And when I do, I&#x27;m glad they&#x27;re there, because they are a great tool of last resort.

Single-stepping is just one use for a debugger. Breakpoints are far more useful. Inspecting local variables by clicking through the stack is generally faster than adding print statements.<p>A lot of people also have never used a debugger that isn&#x27;t terrible to use. <i>Most</i> debuggers fall into that category.<p>As for all of this &quot;read the code first and get a better understanding&quot; talk - this is obvious highfalutin&#x27; bullshit. You&#x27;re human, you made a <i>dumb</i> mistake somewhere, the debugger will help you find it faster than your brain going on an excursion.

On a similar note: I once did a project entirely in notepad. This really forces you to write clean, readable, well organized code.<p>I don&#x27;t have anything against debuggers. I do - however - have a concern with people who rely heavily on the find feature in their IDE to search for certain code they need to change. Oftentimes they don&#x27;t look at the bigger picture and miss how certain things might better be implemented elsewhere. They don&#x27;t run into the problem of finding code that&#x27;s poorly structured. They don&#x27;t have a need to restructure it.

A step-through debugger is a ridiculously useful tool when you don&#x27;t have a serial console. Or when adding in tons of prints would violate timing constraints and compiling takes a significant amount of extra time compared to just restarting the device under test &amp; moving the breakpoint until you find where things go wrong. Much nicer than having just a logic analyzer.<p>Of course embedded systems aren&#x27;t the focus of the article, but they&#x27;re all over and a very good place to have a debugger.

I debug sometimes, but if it&#x27;s a simple script I&#x27;m working on, I usually don&#x27;t. I&#x27;ll just log where I think the problem is (usually indicated by an error, perhaps). I&#x27;ll pull out the debugger when my best guesses at the problem aren&#x27;t panning out.<p>Do whatever works for you. But it&#x27;s good to have more tools in our toolbox - use puts debugging if that&#x27;s easier (often is in very complex environments), use a debugger if you need to.

I never got comfortable with debuggers for the work that I do. Thus I rely heavily on &quot;print debugging&quot;. There are tools such as &quot;icecream&quot; [0] (in Python), that improve print-debugging ergonomics a lot. I wish every language had something like &quot;icecream&quot; built-in.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;gruns&#x2F;icecream" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gruns&#x2F;icecream</a>

I read this blog post in full and geez.<p>Since the author quoted Guido van Rossum, I&#x27;ll share a recent anecdote from my interaction with Guido at PyCon. I first met Guido this past Wednesday, I&#x27;m guessing after he attended the Python language summit. He honestly seemed to be bristly at the time, probably because he&#x27;s heard many of the same arguments raised over thirty years (I can imagine something like &quot;hey why not get rid of the GIL&quot; -&gt; &quot;Wow, why didn&#x27;t I think of that?! Just get rid of the GIL!&quot; although hopefully it was more higher-level than that). One of the other language summit attendees was talking about a particular Python feature, which I don&#x27;t remember, but the underlying notion was that even if you get testy with contributors they&#x27;ll still be a part of the community. I remember thinking, &quot;No. That&#x27;s totally not how it works. If you get testy with contributors they&#x27;ll just leave and you&#x27;ll never hear from them again, or you&#x27;ll turn off new contributors and behead the top of your adoption funnel meaning your language dies when you do&quot;.<p>Python has such great adoption because it caters to the needs of its users first. Take the `tornado` web server framework. I haven&#x27;t confirmed it myself but apparently it has async in Python 2 (async is a Python 3 feature). How? <i>By integrating exceptions into its control flow and having the user handle it</i>. But it shipped, and it benefited its users. IMHO, `pandas` has a decent amount of feature richness in its method calls, to the point where sometimes I can&#x27;t figure out what exactly calling all of them does. Why? Because C&#x2F;Python interop is likely expensive for the numerical processing `pandas` does and for the traditional CPython interpreter, and ideally you want to put together the request in Python once before flushing to C, and because people need different things and so need different default args. `pandas` also ships, and benefits a lot of people.<p>Shipping is <i>so</i> important in production, because it means you matter, and you get to put food for you, your family, and the families of people you employ. You can&#x27;t just bemoan debugging is bad because somebody isn&#x27;t a genius or not in an architect role. Debugging means you ship, and you can hire the guy who isn&#x27;t aiming for a Turing Prize who may have a crappier job otherwise and he can feed his family better.<p>Don&#x27;t cargo cult people you&#x27;re not. Use a debugger.

Debuggers also double as an instant profiler. &quot;Hmm, this program is running slowly, I wonder why...&quot; -&gt; gdb -p $PID -&gt; a few random Ctrl-C&#x27;s and c&#x27;s -&gt; finding the bottleneck and the state that led to it (which a real profiler won&#x27;t usually tell you).<p>Also watches are invaluable when you know something is getting a wrong value but you don&#x27;t know where.

The debugger is just another tool in the toolbox.<p>Turning a blind eye to one of your tools is disingenuous. Step by step debugging has its uses and some work environments may favor it. And in fact, I&#x27;m am quite sure that guys like Linus are competent in using them and will do when needed. It is just that it is not their favorite tool and it is not well suited too their project.

More pretentious and self-serving claims by academics and other “elite” programmers who are in reality far removed from frontline coding

So the argument is a debugger makes fixing bugs so easy you won&#x27;t want to improve process?<p>I think I&#x27;ll keep using them.

I work with embedded software. About a decade ago, when we switched to a new target processor with a JTAG interface (in-circuit debugging), my boss decided to buy an in-circuit debugger to help development. The target was an high-end (at the time) SoC, so it could run uClinux and we could also have GDB too.<p>I tried hard to use the hardware debugger because it was rather expensive (this is I think a case of sunken costs fallacy). Problem is, our system is soft real time; stepping in the main program causes the other things connected to the system notice that the main program does not respond, and act upon this.<p>The hardware debugger was quite capable so we had watchpoints and scripting to avoid this problem, but you had to invest considerable amounts of time to learn to program all that correctly. Amusingly, this was another occasion to make more bugs. Now you need a debugger to debug your debugger scripts...<p>Moreover, the &quot;interesting&quot; bugs were typically those who happened very rarely (that is, on a scale of days) - bugs typically caused by subtly broken interrupt handlers; to solve that kind of bug in a decent time frame with you would need to run dozens of targets under debuggers to test various hypothesis or to collect data about the bug faster. That&#x27;s not even possible sometimes.<p>I also happen to have developed as a hobby various interpreters. The majority were bytecode interpreters. There again debuggers were not that useful, because a generic debugger cannot really decode your bytecode. Typically you do it by hand, or if you are having real troubles, you write a &quot;disassembler&quot; for your bytecode and whatever debugger-like feature you need. Fortunately, the interpreters I was building all had REPLs, which naturally helps a lot with debugging.<p>So I&#x27;m kind of trained not to use debuggers. I learned to observe carefully the system instead, to apply logic to come up with possible causes, and to use print statements (or when it&#x27;s not even possible, just LEDs) to test hypothesis.<p>One should keep in mind that debuggers are the last line of defense, just like unit tests that will never prove the absence of bugs. So you&#x27;d rather do whatever it takes not to have to use a debugger.<p>My current point of view is that the best &quot;debugger&quot; is a debugger built inside the program. It provides more accurate features than a generic debugger and because it is built with functions of the program, it helps with testing it too. That&#x27;s a bit more work but when you do that functionality, debugging and testing support each other.

Often when dealing with layers of code that I am not familiar with, the debugger helps.<p>But when there is a bug in code I wrote, I can reason about it and place prints where I need them. For side projects I hardly ever use a debugger.

I do 99% of my development in the chrome debugger. I usually step through every line of code for the first run through. It catches an incredible amount and variety of subtle bugs. Printf debugging is for chumps.

Bart Locanthi wrote the debugger for the BLIT (Bell Labs Intelligent Terminal) and named it <i>joff</i> because most of the time you’re in a debugger you’re just ....

A lot of this is appeal to authority. It seems to be a contribution to a growing sort hip- or leet-ness around not using debuggers. Implicit in this seems to be: I don&#x27;t need a debugger, neither do these famous people, why do you? Aren&#x27;t you tough enough or smart enough like me and these famous people? You&#x27;re clearly doing this programming thing wrong.<p>Well, I use debuggers. I think they&#x27;re great tools. My feeling is that I&#x27;m very happy to use any tool that helps me create, understand, and improve software. When people tell me that a tool that is useful to me in that endeavor is not actually useful, all I can think to do is roll my eyes.<p>Having said that, something I <i>am</i> very interested in is learning new approaches to interrogate software complexity and solve problems. So, &quot;here are some approaches to understanding and debugging code that have worked for me&quot; from someone who doesn&#x27;t use debuggers would be interesting to me. But I actually don&#x27;t see any of that here.

To heck with that. Ever use a gdb watchpoint? Amazing feature that&#x27;s saved my bacon more times than I can count.

I think print statement makes it quicker and obvious to expose the internal state I want to observe at the precise point I want, thus fulfilling the hypothesis cycle faster. Debugger, on the other hand, seems effort taking to set up and expose too much additional details, it becomes overwhelming very quickly.

Just &quot;test first&quot;; TDD your code. I&#x27;m so tired of working with and being surrounded by crappy, uncontrolled codebases.<p>We &quot;control&quot; our code when tests prove it does what we think it should.<p>Debuggers are rarely-usable, inefficient tools for software development. I agree with OP, debuggers don&#x27;t scale.

The debugger is a valuable tool. I don’t not use X. It is meaningless.

I also lie in my headline:<p>&gt; there are cases where a debugger is the right tool

Would you get the job if you said that at a job interview?

I use whatever tools I can to solve the problem.

I think while this article doesn&#x27;t really prove its thesis very well there is a kernel of an idea here which is useful to investigate. That is the idea that line by line stepping is a crutch that weakens the programmer.<p>Out of the 5 beliefs he quotes from celebrities we only have reasons for 3. Of those 3 the common thread I see is that we should be able to reason about our code and debuggers act to derail that. Furthermore, it appears that the aspect of debugging most being maligned here is stepping through code line by line. I&#x27;m fairly certain that is specific to a certain type of mindset. If I was writing a title for a talk in this area it might be more like &quot;single stepping bad for students&quot; and then talk about how to build code that is easy to model and think about and then use that to work through most problems. If you&#x27;ve got yourself past that student part (and yes, you&#x27;ll dip back into this with new tech &#x2F; languages) then being able to single step when it makes sense (don&#x27;t have docs, processor isn&#x27;t doing the right thing, etc.) makes you more powerful. Not less.<p>The focus on printing is a bit annoying. The writer seems to have never worked in embedded systems, distributed systems, or systems where reproducing the bug isn&#x27;t an option. In the last case a debugger is your tool for grunging around in a core dump. In the embedded case some type of debugger or forcing a core dump (and thus using a debugger) might be your only choices.<p>I also question if he has ever worked on web systems. Reasoning &quot;harder&quot; about how some new CSS or javascript &quot;feature&quot; behaves across different browsers is useless. Writing little ad hoc uses (maybe in a debugger) and carefully tracking how they act in a debugger is powerful.<p>A lesson from my history is that of systems that take a long time to build and upload. The one I worked on early took 60 minutes to build and 30 minutes to upload to test hardware. You didn&#x27;t fix bugs one by one. You fixed them by discovery, fixing on the platform (inserting nops, etc.) in assembly while replicating that in source (probably kicking of a build in case that was the last bug of this run), and then continuing to test &#x2F; debug and get every little bit you could out of the session. And if you had to single step then that was worth it. Is this entirely a historical artifact? I havn&#x27;t worked with anything that bad in decades but I still work with embedded (and some web) systems where the time to build and upload can be a minute to minutes. Getting more out of the session is useful and debuggers are part of that.<p>Refactoring as a response to a bug seems like a mistake worse than line by line stepping to me. Not understanding a cause but making a change propagates incorrect thinking about the system.<p>But I think the real missing part of this article is a discussion of what are other useful tools. The last comment in the article mentions &quot;Types and tools and tests&quot;. It is easy to say tests are table stakes but a similar article about testing would create a flamefest so it is a bit hard to tell what kind of table (or is it stakes)? So what are those tools beyond testing? I&#x27;d love to have DTrace everywhere I worked. The number one best tool I&#x27;ve ever seen for working with a live system. The ideas in Solaris mdb about being able to build little composable tools around data structures is awesome. Immutable methods of managing databases are wonderful. It would have been nice if this author talked about design and refactoring &quot;tools&quot; (could be methodologies) he liked or thinks should exist.

This reminds me of the more generalised &quot;I do not use IDEs&quot;. It&#x27;s a fascinating kind of phenomenon similar to ludditism to me where programmers reject the very premise of their own existence: that computers are capable of adding value or assisting with a task. It feels to me that this is its own form of dogma, no better justified than people who lean on the IDE or the debugger to do everything.<p>I don&#x27;t pull out the debugger very often, but knowing how and when to do that, and do it well is a significant tool in my arsenal. There are times when I can guarantee you I would have spent a massive number of hours or maybe never properly resolved certain bugs without doing it.

The opinions stated are incompetant.