55 ms·

Why Isn't Debugging Treated as a First-Class Activity?

244 points by dannas 8y ago

thecodeboy 8y ago
Prejudice. The same reason NASA janitors aren't glorified as the astronauts are.
- coldtea 8y ago
  Well, the astronauts could always wipe the floors themselves, or just work in a dirty building. The janitors probably lack the skills to go to space and command a spaceship.
erik_seaberg 8y ago
I'm afraid of building a habit of making haphazard tweaks until it seems to DTRT in one case. I don't like the idea of needing the machine to explain to me how my own code actually works. The feeling of complete understanding is an important motivator to me.
- iainmerrick 8y ago
  I don't like the idea of needing the machine to explain to me how my own code actually works. I think it's useful to turn that on its head a little -- I know how the code should work, but a debugger can show me what it's actually doing, so I can see what's going wrong. I don't think there's a big difference here between debugging and testing, say. Couldn't you also say that tests explain how your own code works? I'm afraid of building a habit of making haphazard tweaks until it seems to DTRT in one case. I like to think of debugging more as a science. It's literally a mix of theory and experiment: the program does something weird, you run some random experiments to gather more data, you come up with a theory that explains the results, you design an experiment to test your theory; a successful theory will then lead you to the correct fix. A good debugger can help get the most data from your experiments. It's as if the LHC had sensors capable of tracking individual gluons, or the ability to replay a specific collision over and over, or even the ability to set up a desired collision from scratch.
- pjc50 8y ago
  I find it quite useful to have the machine explain to me how other people's code works, especially once working on a system of sufficient size and legacy that a truly complete understanding is impossible. Especially over here in C++ land where surprises lurk under every operator.
- akerro 8y ago
  If you had a bug, then you didn't know what machine is doing. You think you have an idea it's doing X, while it does Z. If you have ever written a bug because you should have written ++x instead x++, then you need the machine to tell you what it's doing, because it's not doing what you think. If have never ever written a bug, contact me for a job offer, I'll pay you 300% of my salary.
  - comboy 8y ago
    > If have never ever written a bug, contact me for a job offer, I'll pay you 300% of my salary I know just the guy. He was interested in learning how to code.
- pjmlp 8y ago
  Good luck achieving that in feature implementations on distributed teams with 10+ devs. There isn't such thing as "my own code".
- yoklov 8y ago
  > I don't like the idea of needing the machine to explain to me how my own code actually works. But you're fallible. This is the same reason you need to use a profiler to see if your optimizations actually sped anything up. A debugger shows you what really happens, not what you think happens.
greyman 8y ago
From the article: > One thing developers spend a lot of time on is completely absent from both of these lists: debugging! I notice that times changed a bit. This was true in software engineering like 10 years ago, but in recent years there is much more emphasis on good practices, constant refactoring, implementing lots of tests alongside the production code, etc. I debug maybe 1-2 hours per month, as a full-time programmer.
- JohnBooty 8y ago
  in recent years there is much more emphasis on good practices, constant refactoring, implementing lots of tests alongside the production code, etc. I debug maybe 1-2 hours per month, as a full-time programmer. I mean, sure, but in my career the practices you describe are rare. An awful lot of software development involves slogging through "legacy" code that is about as far away from those practices as it gets.
  - wool_gather 8y ago
    What do you mean by "slogging through legacy code" if not debugging, refactoring, and (hopefully/sometimes) writing tests?
    - oblio 8y ago
      Aren't you agreeing with him? :)
    - JohnBooty 8y ago
      Yeah that's what I mean. Because I spend a lot of time slogging through legacy code, I spend a lot of time debugging.
      - wool_gather 8y ago
        I guess I misunderstood/reversed the point you were making; sorry.
lolc 8y ago
The result of debugging will be summed up in a commit or a ticket in Gitlab. Why should Gitlab care about the process?
- lallysingh 8y ago
  Gitlab supports CI for build + test. An additional setup to run tests under gdbserver is a reasonable request.
- Mashimo 8y ago
  Maybe he wants something like a log analyzer similar to splunk? Or something mobile clients send their exceptions? Sadly the post is not very clear, so we can only guess.
- deleted 8y ago
  [deleted]
watwut 8y ago
Debugging is hidden here: Bug handling is easy, fast, and friendly Information on “code flow” is clear and discoverable I use interactive debugger inside IDE or inside profiling tools. Debugging is something I do alone, so it does not need special process support.
busterarm 8y ago
Just get them working on some mess of a WordPress project and you'll get them all reaching for xdebug right quick :D
mjw1007 8y ago
He writes « Perhaps people equate "debugging" with "using an interactive debugger" » I think it's useful to think of two independent 'axes' of debugging: - single-stepping vs reading traces - using specialist debugging software vs modifying the code Most of the time I much prefer reading traces, and IDEs often have decent primitives for setting sophisticated tracepoints, but the UI support for them is often very weak (while adding a breakpoint might be a single key press). So I've often found myself using 'printf'-style debugging because (until compile times get very long) it's more ergonomic then using the debugger's tracepoints. I haven't tried rr yet. Does anyone know how good it is at this? I'd like to be able to do things like define a keypress for a given tracepoint and toggle its output on and off while I'm scrolling through a trace.
- abhishekjha 8y ago
  > using 'printf'-style debugging And the horror that descends upon you once you commit+push those statements.
  - pjc50 8y ago
    Either "don't do that then" or have a logging framework that lets you leave enough printf in to diagnose crashes in the field.
    - abhishekjha 8y ago
      I used to debug using print statements earlier and that was because we were not allowed to use any IDE. Now that I know hoe to use IDEs properly, things have been better. And there is always logging and `git diff` to help you out. Those colouring schemes really come handy.
  - Vinnl 8y ago
    A pre-commit hook can prevent that for you. (I use a linter that will only allow log statements if they're preceded by an exception comment, which I will only add if I actually intend to log things.)
  - 8y ago
enriquto 8y ago
Because debugging is not a first-class activity. If you are careful when you program (assertions, tests, logging) you rarely need to use a debugger. Time spend on a debugger is invisible and lost. It is much better to spend time adding assertions, levels of logging, and writing tests.
- jlg23 8y ago
  Depending on the capabilities of a debugger, developers might have test failures drop them into an interactive debugger that allows reloads/re-execution of code units. Debuggers can be I instrumented to do a lot of dev-only logging for you. I do write tests and assertions, but if those fail, I am dropped into a debugger (if prog is executed interactively), I can immediately inspect the state of my program and more often than not fix the problem on the fly.
  - mirceal 8y ago
    I think that, while this might work, the approach to managing state and writing the tests is not ideal. For one, your tests should be fast (ie you should be able to rerun them with almost 0 time penalty and see the results instantly). Second, if it’s easier to stop the flow and look at the state / modify the state than looking at what the state should be via the test setup it’s possible that the abstractions you’re using are not quite right and/or the code is tightly coupled.
    - jlg23 8y ago
      > I think that, while this might work, the approach to managing state and writing the tests is not ideal. I strive to not manage state but to write purely functional code, it makes life so much easier - see your second point as an example :)
- apk17 8y ago
  Time spent on assertions is visible, but still lost, unless they actually fire. Depending on how you work, debugging is simply finding out why your tests fail (without you expecting that in the first place).
apk17 8y ago
> One thing developers spend a lot of time on is completely absent from both of these lists: debugging! The other thing that is absent from both list: Actually writing code. (@Gitlab: Code isn't created with branching tools.)
pjmlp 8y ago
I use debuggers in anger since Turbo Vision based IDE for Turbo Pascal 6.0 on MS-DOS. If everything that one can do with a graphical debugger is single-step, step-into and continue, then they are using like 1% of its capabilities. Taking advantage of a graphical debugger, specially when the environment supports code reload, is quite productive for interactive programming.
- kjeetgill 8y ago
  One of the besting things about Java and having a strong IDE ecosystem. When I was working in Java 7 + Eclipse the ability to hotswap in changes to functions made debugging (even in production) a dream! Dropping a few new lines of conditional logging into a service was crucial for those 3am war room sessions. Now, working in Java 8 + Intellij hot swapping fails constantly because lambdas don't seem to compile is a stable fashion. Eclipse uses a more development friendly compiler ECJ so I wonder if it has this solved.
  - pjmlp 8y ago
    I am yet to try out that scenario on Eclipse as I tend to refrain my FP enthusiasm due to team members.
- fierro 8y ago
  what are the top 5 other things you find yourself doing with the visual debugger?
  - pjmlp 8y ago
    1) Going through the code 2) Edit-and-continue/REPL 3) Visual representation of data structures 4) Visual representation of ongoing tasks and thread stacks 5) Visualization of memory, CPU, IntelliTrace(.NET) and Java Flight Recorder data 6) Extra one as it is only for hobby coding, GPU debugging
dboreham 8y ago
Reading the comments here I get the impression folks are thinking about "debugging MY code". In my experience when you are debugging you are almost always looking at an issue in someone else's code.
josephv 8y ago
The omission is interesting only in that it highlights that programming and debugging are one in the same. Us old folks that have been programming for 20 years don't even separate the two, there is no meaningful distinction. Programming is not a write-only operation (Perl excepted). If it's an existing project/product, I get it running and find the entry point. If it's new, I write and entry point and get it running. Then I change something, or write something, and debug it. Is it working as expected? Maybe the execution flow isn't what I expected. Why do I always forget to initialize things right. Probably because every language thinks their version of native v. abstract references are fancier. Blah, I need to get to work cod... debug.... what am I doing today? Ah yea, writing documentation. Fack
- corey_moncure 8y ago
  Right. Reading through code is just executing it on a high level, and very fuzzy and forgetful, virtual machine in your own brain.
  - jonbarker 8y ago
    My only complaint about my meatware computer is that it has a really bad ability to handle space complexity. With paper I can do OK with time complexity (although clockspeed is also an issue).
    - mikec3010 8y ago
      Mine is like a quantum computer. Not in performance, but that the register values decay within seconds to minutes.
  - montenegrohugo 8y ago
    I loved this comment. Great visualization!
- lizmat 8y ago
  Possibly with the exception of COBOL, I think you can write write-only code in any programming language.
flohofwoe 8y ago
I'm using IDE debuggers as integral part of my normal programming workflow, not for actual "debugging", but for stepping through new code to check if it "feels right". I hardly find bugs that way (that usually happens when the code is out in the wild and several unexpected things happen at the same time), but I add a lot of little changes based on the step-debugging... rename a variable here, add a forgotten comment there, and also think about what to do next. I'm quite sure I spend more time in the debugger then writing code. I wish edit-and-continue, rewinding time, etc... would be better supported across IDEs. Programming should be a "conversation with the machine", and ultimately with other programmers. When I'm stepping through my own code, I try to assume the role of an "outsider" and judge my code from the "outside". The debugger is also the most important tool for me to understand code written by others.
- maaaats 8y ago
  Edit-and-continue works in several languages. Java can hotswap, for instance. And you can to some extent rewind by dropping the current frame (unless your code had side effects, but that's just another reason to avoid them ;) ) But I think my workflow is similar to yours. I often set a breakpoint in my new code and just watch the state to see if it looks as expected, so small tidbits of usage here and there.
- jpindar 8y ago
  Edit-and-continue and the WYSIWYG GUI editor are two of the best features of VB6 that I wish other languages had.
- candiodari 8y ago
  > I wish edit-and-continue, rewinding time, etc... would be better supported across IDEs. Programming should be a "conversation with the machine", and ultimately with other programmers. When I'm stepping through my own code, I try to assume the role of an "outsider" and judge my code from the "outside". This is because of a good reason: implementing debugging is hard ... very hard, and therefore expensive to implement. This is of course the main reason in practice.
pdpi 8y ago
One practice I don't think I've ever really seen properly discussed is exploratory debugging. Given a large codebase I'm not familiar with, I've found that this workflow is an incredibly fast way to get familiar with the overall flow and structure of the code: - run the thing - grab an output string of some sort (either output proper or logs or whatever else) - grep for it - set a breakpoint where the string is generated - run again From there, you can explore the stack, and you start to get your bearings. How is this particular thing generated? Find the place in the stack where it first shows up, set a break point, start over and debug from there. Repeat until you have a sufficiently solid grasp of the codebase that you can just navigate the source tree searching for where things are.
- Kagerjay 8y ago
  Whenever I explore a library, I do the same, but when I think of CRUD functions I always look for these first in this general order: - Create methods - Delete methods - Update Methods - Read Methods Creating and deleting things are usually the easiest starting points. You always have an idea on how an app does this so its pretty easy to figure what things you need to do to trigger the breakpoint. Usually the create and delete methods are named something obvious so grepping for it is not terribly difficult If you work with JS libraries there is always some demo website, you can check for any event listeners on that element too, set breakpoints go from there.
  - deleted 8y ago
    [deleted]
- segmondy 8y ago
  To each their own, I use to enjoy such. I absolutely hate it now. Given a codebase, I want to know the story. Why was the code written, what problem was being solved, why did they decide to solve it in a specific ways, WHY, WHY, WHY? I need to know the whys. I want the story, I want to know the domains. How is the software layered, can I explore one layer without going into other layers? I don't want to do so with a debugger. I want to do so with a document reader.
azhenley 8y ago
The academic Software Engineering community certainly does put a lot of attention on debugging. See my list of publications for a number of empirical studies on debugging and tools to support more efficient debugging: http://austinhenley.com/publications.html http://austinhenley.com/publications.html
bionsystem 8y ago
Ask Bryan Cantrill. He is a first grade debugger.
henrik_w 8y ago
I agree with the author that a debugger is a poor fit for many systems. However, debugging is essential, and I think debugging by checking logs works very well in many cases (provided that the logging is good). Some of the advantages (over debuggers): - Anybody can look at the logs, not just developers. - The logs show the sequence of events, not just a snapshot. - Feasible to do in a live system. https://henrikwarne.com/2014/01/01/finding-bugs-debugger-versus-logging/ https://henrikwarne.com/2014/01/01/finding-bugs-debugger-ver...
- M_Bakhtiari 8y ago
  A debugger that doesn't support those three things is just a lousy debugger.
  - seanmcdirmid 8y ago
    There are many different kinds of debugging, and a debugger optimized with an interface for pinhole inspecting and stepping isn’t the best tool for logging and log processing, it is ok for them to be separate things.
    - M_Bakhtiari 8y ago
      I never said not to log or look at logs, but a good debugger should be possible to attach to a running process, and reverse debugging can give you access to past events.
      - seanmcdirmid 8y ago
        Sure, but you are still dealing with a pinhole even if you can move that pinhole around. It isn’t a complete debugging experience, nor was it meant to be.
reikonomusha 8y ago
Debugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp, as the facilities are built into the language itself. While Lisp gets a lot of flak for basically (up to a few daring power-user exceptions) requiring Emacs, SLIME/SLY [1,2] are environments that will make you feel closer to your program than you get in other environments, including graphical IDEs. Given that the normal way to develop a Lisp program is to do it incrementally, your program (or someone else’s!) will break, and it will break often, and you’ll get launched into an interactive debugger. But it’s friendly, not requiring a completely separate, foreign toolchain, and much of the functionality works regardless of which editors/IDEs you’re using (though Emacs makes the experience much more ergonomic). I think this is perhaps a bigger selling point of Common Lisp than all the great, oft-quoted things like metaprogramming. [1] https://common-lisp.net/project/slime/ https://common-lisp.net/project/slime/ [2] https://github.com/joaotavora/sly https://github.com/joaotavora/sly
- kadenshep 8y ago
  I've loved this aspect of CL. I often repeat a self-quote of mine (somewhat patronizingly) to my teams. Often times, it's not necessarily how something works, but how well it breaks. Things will break, so engineer for it. You'll be happy, the team will be happy, and the business will be happy. Debugging and error handling are first class activities. Building a thoughtful, "well engineered" tool chain around these activities is the mark of a great platform (and the developers behind it), in my opinion.
- ranit 8y ago
  > Debugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp A bit of nitpicking: It is anything but "extraordinarily", it is a completely ordinary activity.
  - kcanini 8y ago
    To nitpick your nitpick, the word "extraordinarily" here is not an adjective modifying "activity"; is an adverb that stresses that debugging is uncommonly "first-class, up-front, and frequent" in Common Lisp compared to other languages.
deepaksurti 8y ago
Because most languages treat edit, compile, test, debug phases. No organic evolution of your idea to code to running app all the while tweaking it without restarts, which are pit stops that completely break your momentum. That needs languages designed upfront with debugging etc as a first class live feature.
paulsutter 8y ago
"90% of coding is debugging. The other 10% is writing bugs” - Bram Cohen
dm03514 8y ago
I feel like it has a lot to do with the ambiguity involved in debugging, and the fact that it is hard to teach. I have found debugging to be fuzzy and largely based on experience, mental models, and internal (scientific method based?) approaches. There seem to be a relatively few debugging methodologies or frameworks. (ie in performance/systems realm there are USE, RED, ...?). I have only started to recently create a formal framework (a google doc I update after each incident) after 9 years of engineering experience! Not because I wasn't interesting in debugging, but it literally took 9 years worth of debugging incidents for patterns to start to become apparent to me (i work devops/system so when there is a general feeling of a problem I'm usually tasked with finding root causes). On a side note: so far the framework has been successful within my org and I hope to formalize it enough to write about it in the near future :)
carusooneliner 8y ago
More broadly, reverse engineering a codebase is a critical software activity. If you can't reverse engineer a codebase you can't debug it or add to it. Working with an existing code base is pretty much a given, unless you're developer #1 on a startup. Your success as a software developer hinges on how well you can work with an existing codebase. One less celebrated but very valuable approach to grasp a codebase is the way you document what you've learnt. While you can learn about a codebase through exploratory debugging (mentioned by someone on a separate comment) you have to persist that knowledge on "paper" in some way. My favorite ways to do that: - class diagrams (for static stuff like data structures, class relationships, etc.) - sequence diagrams (for dynamic stuff like which functions call which and data passed between them) With good documentation for your own learning purposes, it'll become easier to start working on a codebase and especially when you context switch, it'll help you return to a codebase more easily.
- JetSpiegel 8y ago
  Ideally, documentation would be written so that there is no need to reverse engineer every project you wade into. Otherwise why share the source code in the first place?
  - carusooneliner 8y ago
    There's various kinds of documentation of differing granularity. Typically the high level documentation (coarse grained if you will) about architecture, requirements, etc. stays good over time but finer grain documentation (the kind I mentioned in my earlier comment -- data structures, order of function invocation, etc.) gets stale quickly because source code is constantly changing -- it gets refactored, plenty of bug fixes are put in, etc. Reverse engineering is probably a loaded word, but in general digging in to understand the codebase helps you work more efficiently and avoid introducing bugs to the extent possible.
acroback 8y ago
I see a disturbing trend in industry especially in Bay area from my experience. Young engineers are bad at debugging, bad means real bad but good at programming puzzles. This points to the fact that people value puzzles over experience and in turn miss the big picture. Sure you can code up a balanced RB tree in 5 mins, but what will you do when packets start showing up in bursts on your service? Can you find out that on a live system? I despise this new Bro culture of mugging programming puzzles from leetcode and hackerank. Faltering at first real world challenge is not only disappointing, but an insult to craft of engineering. /Rant over
- fancyfish 8y ago
  Echoing this and an earlier thread...interviewers could have debugging exercises with an existing codebase. I have seen this ambitious approach at a few startups. Instead of asking yet another sorting algorithm or HackerRank brainteaser. Until the application process changes, the applicants won't change.
  - convolvatron 8y ago
    interviewing is only a small part of the picture. mvp has so eroded the notion of correctness that whole organizations don't even look for bugs anymore. try upgrading the dependencies. wrap the service in a harness to make sure it gets restarted when it fails. forget about proactively looking for bugs, wait until they come in, and if you have time that week before they slip into the 'stale - never to be addressed' pile, spend a few minutes trying to reproduce and mark 'works for me'
- draw_down 8y ago
  It goes further, too. Hotshots who crank out cool-looking stuff with lots of problems under the covers get promotions and accolades; people who do really important maintenance work and fix all the stuff the hotshots didn't think of get the table scraps. Where I work, there is a regular time where an employee tells the whole company about something they fixed and why. It's a nice thought and all, but if the promotions and other material benefits still accrue to the people cranking out new stuff, it doesn't matter too much in my opinion.
vfc1 8y ago
I used to spend my days in the Java debugger, stepping through framework code to troubleshoot application-level errors, as the stacktrace we had obfuscated the error, or everything was simply broken. Depending on the situation, I might spend most of my day debugging, as a way to better understand the program and as a code analysis tool. This was especially useful if dealing with a code base that I was not familiar with, while in code that I wrote myself most of the time logging is sufficient. I'm not sure why the author thinks that debugging is not a priority for tool makers, the debuggers that we currently have are awesome and have been so for years.
stcredzero 8y ago
There were Smalltalk server processes that would catch an exception, snapshot their memory image. A developer could then come along, and open a full interactive debugger on a live, running version of the system, which they could then modify then run as a quick dev test.
spenrose 8y ago
I worked on petabyte-scale data at Mozilla. Here is a talk I gave on the history of debugging and the ways in which doing distributed large data analysis requires moving beyond printf() and STEP: https://www.youtube.com/watch?v=QHJBPzfrokU https://www.youtube.com/watch?v=QHJBPzfrokU
LargeWu 8y ago
Somebody once posted in a Slack channel I was part of asking for things they should include in a course they were teaching for new programmers. My #1 recommendation was how to read a stack trace. The second was how to put a logging statement into your code to capture state.
hannofcart 8y ago
I would go so far as to suggest that if you need a debugger, you're probably doing it wrong. I have found that code that needs a debugger is code that is written in an extremely stateful fashion. The very reason why debuggers exist is to deal with code that has a dozen variables book-keeping complex state that you need to track closely to figure out how something works (or why something doesn't). Debuggers even have "watches" to track something closely so that it doesn't change underneath you, when you aren't looking. To me this is a code smell. I would suggest that instead of using a debugger, we ought to be composing small functions together. Small and pure functions only need an REPL to test. Once you make sure the function is behaving right, you can almost just copy paste over the test cases you ran in your REPL into unit tests. The simplest way to enforce this discipline is to do away with assignments, and instead constrain oneself to using expressions. This forces one to break code into smaller functions. Code written this way turns out to be much more readable, as well as reusable. I suggest that we eschew the debugger in favour of the REPL.
- maerF0x0 8y ago
  Debuggers help to isolate _where_ code breaks as much as what state it was in when it broke. Seeing that fn1 breaks on DataB is not as useful as seeing that fn1(f2(DataA)) is the actual error.
  - sushisource 8y ago
    Yes, this is why they are useful. Generally speaking once I've found where the error is, it's real simple to find the one or two variables in scope, look at their values, and figure out the bug. I would agree that if you're using a debugger to verify over many iterations that something isn't going wacky with state, then yeah, that's not a great sign.
- striking 8y ago
  It is true that you can answer any question by changing the question. It would be nice if everyone wrote code that minimized state, or if every problem could operate with minimal state. But not all code is or should be like that. "to do away with assignments" is not my favorite way of phrasing what you mean either; I would prefer people assign as many new variables as they like, and just avoid mutating them (i.e. making them `const` and using immutable data structures if performance allows)
wilun 8y ago
While we probably will always have to debug, and if not the "code" it will be a specification formal enough so that it can be considered code anyway, there are different ways to approach its role within the lifecycle of software development: on the two extremes, one can "quickly" but somehow randomly throw lines without thinking much about it, then try the result and correct the few defects that their few tries reveal (and leave dozen to hundreds of other defects to be discovered at more inconvenient times); or one can think a lot about the problem, study a lot about the software where the change must be done, and carefully write some code that perfectly implement what is needed, with very few defects both on the what and on the how side. Note that the "quick" aspect of the first approach is a complete myth (if taken to the extreme, and except for trivially short runs or if the result does not matter that much), because a system can not be developed like that in the long term without collapsing on itself, so there will either be spectacular failures or unplanned dev slowdown, and if the slowdown route is taken, the result will be poorer as if a careful approach would have been taken in the first place, while the velocity might not even be higher. Of course, all degrees exists between the two extremes, and when going too far on one side for a given application is going to cause more problems than it solves (e.g. missing time to market opportunities). Anyway, some projects, maybe those related to computer infrastructure or actually any kind of infrastructure, are more naturally positioned on the careful track (and even then it depends on which aspect, for ex cyber security is still largely an afterthought in large parts of the industry), and the careful track only need debugging as a non-trivial activity when everything else has failed, so hopefully in very small quantities. But it is not that when it is really needed as a last resort, good tooling are not needed. It is just that it is confined to unreleased side projects / tooling, or when it happens in prod it marks a so serious failure that compared to other projects, those hopefully do not happen that often. In those contexts, a project which need too much debugging can be at the risk of dying. So the mean "value" of debugging might be somehow smaller than the mean "value" of designing and writing code and otherwise organizing things so that we do not have to debug (that often).
logfromblammo 8y ago
For the same reason that the water treatment plant gets more respect than the sewage treatment plant. Everyone would prefer to provide something fresh and clean than to wade through other people's poop.
nhoe98thnuoe 8y ago
In my opinion the reason that debugging isn't treated as a first-class activity is that it isn't taught at all in schools. Or at least it wasn't when I was in school. We were given about 2 sentences that said, "the debugger is at /usr/bin/gdb. It can help you step through your code to find a bug." And then we were thrown to the wolves with what is arguably one of the worst debuggers in the world with no documentation and no help.
cuddlybacon 8y ago
One thing that may be relevant is that I was never introduced to debugging in university at all. You were expected to just invent useful techniques on your own. Without any exposure, it is hard to justify learning that over any other topic you feel like you aught to be learning.
codedokode 8y ago
I think that is because there are no good free open source debuggers? In Visual Studio you just set a breakpoint and examine the variables; it works great. On Linux you are left alone against a command-line monster with outdated weird command syntax. gdb has an awful interface; it requires you to read a long manual and learn outdated command syntax before even using it; it is often faster to add logging and rerun the program. It is not a debugger for humans. For comparison, JS debugger in Chrome devtools works pretty good and is easy to use. It is really helpful and allows you to identify a problem very quickly (faster than reading an introduction page for gdb). But it has problems sometimes, when you try to set a breakpoint and it is set in another place or is not set at all without any error messages. I saw some comments here against visual debugging; maybe their authors had experience with some buggy or poorly written debugger? I also tried to use Firefox developer tools in several versions up to FF45 and almost every time something didn't work. And when they work, they choke on scrolling large minified files or heavy sites with lots of ads.
- flukus 8y ago
  > In Visual Studio you just set a breakpoint and examine the variables; it works great. On Linux you are left alone against a command-line monster with outdated weird command syntax. You're comparing an IDE to a command line environment, Linux has various IDE's that are more comparable and I believe some standalone front ends to gdb, windows also has windbg and dotnet mdbg that are the command line equivalents of gdb that VS is interacting with for you. Gdb (and windbg for that matter) is much more powerful than visual studio debugging though, much like vim and similar tools it's not easy to learn but it's easy to use once you have learned. Stop expecting instant gratification.
nicostouch 8y ago
I often wonder why it's not treated as a first class citizen when teaching programming. I think there should be a full CS course dedicated to it. I put together http://www.debug.coach/ http://www.debug.coach/ because a guy I used to work with had better debugging skills than anybody and I noticed it was because he always knew the right questions to ask.
eftychis 8y ago
I think the approach we should take is to pour more effort into minimizing the risk of debugging being necessary. Good practices, better type checkers and logic models (e.g. there was an article posted in the front page here about using linear logic to push the boundaries of file systems). Debugging can be a time sink and can become a painful task for fast distributed systems. We should learn and hone that skill of course, as it does not only offer a solution when lightning strikes, but a way for the developer to gain comprehension of the "internals".
yitchelle 8y ago
If you needed to debug, it is a sign that you have made a mistake. Who wants to admit to making the mistake? :-) Seriously though, I imagine that the junior devs would have such a view of debugging. But the matured devs would plan for it as they know their limitations.
fierro 8y ago
has anyone written intelliJ plugins that deal with the debugger? I have an interesting idea wrt to this, but writing an IntelliJ plugin has so far been extremely painful. If anyone out there is interested send me a message and let's chat

244 points by dannas 8y ago

thecodeboy 8y ago

Prejudice. The same reason NASA janitors aren't glorified as the astronauts are.

coldtea 8y ago
Well, the astronauts could always wipe the floors themselves, or just work in a dirty building. The janitors probably lack the skills to go to space and command a spaceship.

erik_seaberg 8y ago

I'm afraid of building a habit of making haphazard tweaks until it seems to DTRT in one case. I don't like the idea of needing the machine to explain to me how my own code actually works. The feeling of complete understanding is an important motivator to me.

iainmerrick 8y ago
I don't like the idea of needing the machine to explain to me how my own code actually works. I think it's useful to turn that on its head a little -- I know how the code should work, but a debugger can show me what it's actually doing, so I can see what's going wrong. I don't think there's a big difference here between debugging and testing, say. Couldn't you also say that tests explain how your own code works? I'm afraid of building a habit of making haphazard tweaks until it seems to DTRT in one case. I like to think of debugging more as a science. It's literally a mix of theory and experiment: the program does something weird, you run some random experiments to gather more data, you come up with a theory that explains the results, you design an experiment to test your theory; a successful theory will then lead you to the correct fix. A good debugger can help get the most data from your experiments. It's as if the LHC had sensors capable of tracking individual gluons, or the ability to replay a specific collision over and over, or even the ability to set up a desired collision from scratch.
pjc50 8y ago
I find it quite useful to have the machine explain to me how other people's code works, especially once working on a system of sufficient size and legacy that a truly complete understanding is impossible. Especially over here in C++ land where surprises lurk under every operator.
akerro 8y ago
If you had a bug, then you didn't know what machine is doing. You think you have an idea it's doing X, while it does Z. If you have ever written a bug because you should have written ++x instead x++, then you need the machine to tell you what it's doing, because it's not doing what you think. If have never ever written a bug, contact me for a job offer, I'll pay you 300% of my salary.
- comboy 8y ago
  > If have never ever written a bug, contact me for a job offer, I'll pay you 300% of my salary I know just the guy. He was interested in learning how to code.
pjmlp 8y ago
Good luck achieving that in feature implementations on distributed teams with 10+ devs. There isn't such thing as "my own code".
yoklov 8y ago
> I don't like the idea of needing the machine to explain to me how my own code actually works. But you're fallible. This is the same reason you need to use a profiler to see if your optimizations actually sped anything up. A debugger shows you what really happens, not what you think happens.

greyman 8y ago

From the article: > One thing developers spend a lot of time on is completely absent from both of these lists: debugging! I notice that times changed a bit. This was true in software engineering like 10 years ago, but in recent years there is much more emphasis on good practices, constant refactoring, implementing lots of tests alongside the production code, etc. I debug maybe 1-2 hours per month, as a full-time programmer.

JohnBooty 8y ago
in recent years there is much more emphasis on good practices, constant refactoring, implementing lots of tests alongside the production code, etc. I debug maybe 1-2 hours per month, as a full-time programmer. I mean, sure, but in my career the practices you describe are rare. An awful lot of software development involves slogging through "legacy" code that is about as far away from those practices as it gets.
- wool_gather 8y ago
  What do you mean by "slogging through legacy code" if not debugging, refactoring, and (hopefully/sometimes) writing tests?
  - oblio 8y ago
    Aren't you agreeing with him? :)
  - JohnBooty 8y ago
    Yeah that's what I mean. Because I spend a lot of time slogging through legacy code, I spend a lot of time debugging.
    - wool_gather 8y ago
      I guess I misunderstood/reversed the point you were making; sorry.

lolc 8y ago

The result of debugging will be summed up in a commit or a ticket in Gitlab. Why should Gitlab care about the process?

lallysingh 8y ago
Gitlab supports CI for build + test. An additional setup to run tests under gdbserver is a reasonable request.
Mashimo 8y ago
Maybe he wants something like a log analyzer similar to splunk? Or something mobile clients send their exceptions? Sadly the post is not very clear, so we can only guess.
deleted 8y ago
[deleted]

watwut 8y ago

Debugging is hidden here: Bug handling is easy, fast, and friendly Information on “code flow” is clear and discoverable I use interactive debugger inside IDE or inside profiling tools. Debugging is something I do alone, so it does not need special process support.

busterarm 8y ago

Just get them working on some mess of a WordPress project and you'll get them all reaching for xdebug right quick :D

mjw1007 8y ago

He writes « Perhaps people equate "debugging" with "using an interactive debugger" » I think it's useful to think of two independent 'axes' of debugging: - single-stepping vs reading traces - using specialist debugging software vs modifying the code Most of the time I much prefer reading traces, and IDEs often have decent primitives for setting sophisticated tracepoints, but the UI support for them is often very weak (while adding a breakpoint might be a single key press). So I've often found myself using 'printf'-style debugging because (until compile times get very long) it's more ergonomic then using the debugger's tracepoints. I haven't tried rr yet. Does anyone know how good it is at this? I'd like to be able to do things like define a keypress for a given tracepoint and toggle its output on and off while I'm scrolling through a trace.

abhishekjha 8y ago
> using 'printf'-style debugging And the horror that descends upon you once you commit+push those statements.
- pjc50 8y ago
  Either "don't do that then" or have a logging framework that lets you leave enough printf in to diagnose crashes in the field.
  - abhishekjha 8y ago
    I used to debug using print statements earlier and that was because we were not allowed to use any IDE. Now that I know hoe to use IDEs properly, things have been better. And there is always logging and `git diff` to help you out. Those colouring schemes really come handy.
- Vinnl 8y ago
  A pre-commit hook can prevent that for you. (I use a linter that will only allow log statements if they're preceded by an exception comment, which I will only add if I actually intend to log things.)
- 8y ago

enriquto 8y ago

Because debugging is not a first-class activity. If you are careful when you program (assertions, tests, logging) you rarely need to use a debugger. Time spend on a debugger is invisible and lost. It is much better to spend time adding assertions, levels of logging, and writing tests.

jlg23 8y ago
Depending on the capabilities of a debugger, developers might have test failures drop them into an interactive debugger that allows reloads/re-execution of code units. Debuggers can be I instrumented to do a lot of dev-only logging for you. I do write tests and assertions, but if those fail, I am dropped into a debugger (if prog is executed interactively), I can immediately inspect the state of my program and more often than not fix the problem on the fly.
- mirceal 8y ago
  I think that, while this might work, the approach to managing state and writing the tests is not ideal. For one, your tests should be fast (ie you should be able to rerun them with almost 0 time penalty and see the results instantly). Second, if it’s easier to stop the flow and look at the state / modify the state than looking at what the state should be via the test setup it’s possible that the abstractions you’re using are not quite right and/or the code is tightly coupled.
  - jlg23 8y ago
    > I think that, while this might work, the approach to managing state and writing the tests is not ideal. I strive to not manage state but to write purely functional code, it makes life so much easier - see your second point as an example :)
apk17 8y ago
Time spent on assertions is visible, but still lost, unless they actually fire. Depending on how you work, debugging is simply finding out why your tests fail (without you expecting that in the first place).

apk17 8y ago

> One thing developers spend a lot of time on is completely absent from both of these lists: debugging! The other thing that is absent from both list: Actually writing code. (@Gitlab: Code isn't created with branching tools.)

pjmlp 8y ago

I use debuggers in anger since Turbo Vision based IDE for Turbo Pascal 6.0 on MS-DOS. If everything that one can do with a graphical debugger is single-step, step-into and continue, then they are using like 1% of its capabilities. Taking advantage of a graphical debugger, specially when the environment supports code reload, is quite productive for interactive programming.

kjeetgill 8y ago
One of the besting things about Java and having a strong IDE ecosystem. When I was working in Java 7 + Eclipse the ability to hotswap in changes to functions made debugging (even in production) a dream! Dropping a few new lines of conditional logging into a service was crucial for those 3am war room sessions. Now, working in Java 8 + Intellij hot swapping fails constantly because lambdas don't seem to compile is a stable fashion. Eclipse uses a more development friendly compiler ECJ so I wonder if it has this solved.
- pjmlp 8y ago
  I am yet to try out that scenario on Eclipse as I tend to refrain my FP enthusiasm due to team members.
fierro 8y ago
what are the top 5 other things you find yourself doing with the visual debugger?
- pjmlp 8y ago
  1) Going through the code 2) Edit-and-continue/REPL 3) Visual representation of data structures 4) Visual representation of ongoing tasks and thread stacks 5) Visualization of memory, CPU, IntelliTrace(.NET) and Java Flight Recorder data 6) Extra one as it is only for hobby coding, GPU debugging

dboreham 8y ago

Reading the comments here I get the impression folks are thinking about "debugging MY code". In my experience when you are debugging you are almost always looking at an issue in someone else's code.

josephv 8y ago

The omission is interesting only in that it highlights that programming and debugging are one in the same. Us old folks that have been programming for 20 years don't even separate the two, there is no meaningful distinction. Programming is not a write-only operation (Perl excepted). If it's an existing project/product, I get it running and find the entry point. If it's new, I write and entry point and get it running. Then I change something, or write something, and debug it. Is it working as expected? Maybe the execution flow isn't what I expected. Why do I always forget to initialize things right. Probably because every language thinks their version of native v. abstract references are fancier. Blah, I need to get to work cod... debug.... what am I doing today? Ah yea, writing documentation. Fack

corey_moncure 8y ago
Right. Reading through code is just executing it on a high level, and very fuzzy and forgetful, virtual machine in your own brain.
- jonbarker 8y ago
  My only complaint about my meatware computer is that it has a really bad ability to handle space complexity. With paper I can do OK with time complexity (although clockspeed is also an issue).
  - mikec3010 8y ago
    Mine is like a quantum computer. Not in performance, but that the register values decay within seconds to minutes.
- montenegrohugo 8y ago
  I loved this comment. Great visualization!
lizmat 8y ago
Possibly with the exception of COBOL, I think you can write write-only code in any programming language.

flohofwoe 8y ago

I'm using IDE debuggers as integral part of my normal programming workflow, not for actual "debugging", but for stepping through new code to check if it "feels right". I hardly find bugs that way (that usually happens when the code is out in the wild and several unexpected things happen at the same time), but I add a lot of little changes based on the step-debugging... rename a variable here, add a forgotten comment there, and also think about what to do next. I'm quite sure I spend more time in the debugger then writing code. I wish edit-and-continue, rewinding time, etc... would be better supported across IDEs. Programming should be a "conversation with the machine", and ultimately with other programmers. When I'm stepping through my own code, I try to assume the role of an "outsider" and judge my code from the "outside". The debugger is also the most important tool for me to understand code written by others.

maaaats 8y ago
Edit-and-continue works in several languages. Java can hotswap, for instance. And you can to some extent rewind by dropping the current frame (unless your code had side effects, but that's just another reason to avoid them ;) ) But I think my workflow is similar to yours. I often set a breakpoint in my new code and just watch the state to see if it looks as expected, so small tidbits of usage here and there.
jpindar 8y ago
Edit-and-continue and the WYSIWYG GUI editor are two of the best features of VB6 that I wish other languages had.
candiodari 8y ago
> I wish edit-and-continue, rewinding time, etc... would be better supported across IDEs. Programming should be a "conversation with the machine", and ultimately with other programmers. When I'm stepping through my own code, I try to assume the role of an "outsider" and judge my code from the "outside". This is because of a good reason: implementing debugging is hard ... very hard, and therefore expensive to implement. This is of course the main reason in practice.

pdpi 8y ago

One practice I don't think I've ever really seen properly discussed is exploratory debugging. Given a large codebase I'm not familiar with, I've found that this workflow is an incredibly fast way to get familiar with the overall flow and structure of the code: - run the thing - grab an output string of some sort (either output proper or logs or whatever else) - grep for it - set a breakpoint where the string is generated - run again From there, you can explore the stack, and you start to get your bearings. How is this particular thing generated? Find the place in the stack where it first shows up, set a break point, start over and debug from there. Repeat until you have a sufficiently solid grasp of the codebase that you can just navigate the source tree searching for where things are.

Kagerjay 8y ago
Whenever I explore a library, I do the same, but when I think of CRUD functions I always look for these first in this general order: - Create methods - Delete methods - Update Methods - Read Methods Creating and deleting things are usually the easiest starting points. You always have an idea on how an app does this so its pretty easy to figure what things you need to do to trigger the breakpoint. Usually the create and delete methods are named something obvious so grepping for it is not terribly difficult If you work with JS libraries there is always some demo website, you can check for any event listeners on that element too, set breakpoints go from there.
- deleted 8y ago
  [deleted]
segmondy 8y ago
To each their own, I use to enjoy such. I absolutely hate it now. Given a codebase, I want to know the story. Why was the code written, what problem was being solved, why did they decide to solve it in a specific ways, WHY, WHY, WHY? I need to know the whys. I want the story, I want to know the domains. How is the software layered, can I explore one layer without going into other layers? I don't want to do so with a debugger. I want to do so with a document reader.

azhenley 8y ago

The academic Software Engineering community certainly does put a lot of attention on debugging. See my list of publications for a number of empirical studies on debugging and tools to support more efficient debugging: http://austinhenley.com/publications.html http://austinhenley.com/publications.html

bionsystem 8y ago

Ask Bryan Cantrill. He is a first grade debugger.

henrik_w 8y ago

I agree with the author that a debugger is a poor fit for many systems. However, debugging is essential, and I think debugging by checking logs works very well in many cases (provided that the logging is good). Some of the advantages (over debuggers): - Anybody can look at the logs, not just developers. - The logs show the sequence of events, not just a snapshot. - Feasible to do in a live system. https://henrikwarne.com/2014/01/01/finding-bugs-debugger-versus-logging/ https://henrikwarne.com/2014/01/01/finding-bugs-debugger-ver...

M_Bakhtiari 8y ago
A debugger that doesn't support those three things is just a lousy debugger.
- seanmcdirmid 8y ago
  There are many different kinds of debugging, and a debugger optimized with an interface for pinhole inspecting and stepping isn’t the best tool for logging and log processing, it is ok for them to be separate things.
  - M_Bakhtiari 8y ago
    I never said not to log or look at logs, but a good debugger should be possible to attach to a running process, and reverse debugging can give you access to past events.
    - seanmcdirmid 8y ago
      Sure, but you are still dealing with a pinhole even if you can move that pinhole around. It isn’t a complete debugging experience, nor was it meant to be.

reikonomusha 8y ago

Debugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp, as the facilities are built into the language itself. While Lisp gets a lot of flak for basically (up to a few daring power-user exceptions) requiring Emacs, SLIME/SLY [1,2] are environments that will make you feel closer to your program than you get in other environments, including graphical IDEs. Given that the normal way to develop a Lisp program is to do it incrementally, your program (or someone else’s!) will break, and it will break often, and you’ll get launched into an interactive debugger. But it’s friendly, not requiring a completely separate, foreign toolchain, and much of the functionality works regardless of which editors/IDEs you’re using (though Emacs makes the experience much more ergonomic). I think this is perhaps a bigger selling point of Common Lisp than all the great, oft-quoted things like metaprogramming. [1] https://common-lisp.net/project/slime/ https://common-lisp.net/project/slime/ [2] https://github.com/joaotavora/sly https://github.com/joaotavora/sly

kadenshep 8y ago
I've loved this aspect of CL. I often repeat a self-quote of mine (somewhat patronizingly) to my teams. Often times, it's not necessarily how something works, but how well it breaks. Things will break, so engineer for it. You'll be happy, the team will be happy, and the business will be happy. Debugging and error handling are first class activities. Building a thoughtful, "well engineered" tool chain around these activities is the mark of a great platform (and the developers behind it), in my opinion.
ranit 8y ago
> Debugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp A bit of nitpicking: It is anything but "extraordinarily", it is a completely ordinary activity.
- kcanini 8y ago
  To nitpick your nitpick, the word "extraordinarily" here is not an adjective modifying "activity"; is an adverb that stresses that debugging is uncommonly "first-class, up-front, and frequent" in Common Lisp compared to other languages.

deepaksurti 8y ago

Because most languages treat edit, compile, test, debug phases. No organic evolution of your idea to code to running app all the while tweaking it without restarts, which are pit stops that completely break your momentum. That needs languages designed upfront with debugging etc as a first class live feature.

paulsutter 8y ago

"90% of coding is debugging. The other 10% is writing bugs” - Bram Cohen

dm03514 8y ago

I feel like it has a lot to do with the ambiguity involved in debugging, and the fact that it is hard to teach. I have found debugging to be fuzzy and largely based on experience, mental models, and internal (scientific method based?) approaches. There seem to be a relatively few debugging methodologies or frameworks. (ie in performance/systems realm there are USE, RED, ...?). I have only started to recently create a formal framework (a google doc I update after each incident) after 9 years of engineering experience! Not because I wasn't interesting in debugging, but it literally took 9 years worth of debugging incidents for patterns to start to become apparent to me (i work devops/system so when there is a general feeling of a problem I'm usually tasked with finding root causes). On a side note: so far the framework has been successful within my org and I hope to formalize it enough to write about it in the near future :)

carusooneliner 8y ago

More broadly, reverse engineering a codebase is a critical software activity. If you can't reverse engineer a codebase you can't debug it or add to it. Working with an existing code base is pretty much a given, unless you're developer #1 on a startup. Your success as a software developer hinges on how well you can work with an existing codebase. One less celebrated but very valuable approach to grasp a codebase is the way you document what you've learnt. While you can learn about a codebase through exploratory debugging (mentioned by someone on a separate comment) you have to persist that knowledge on "paper" in some way. My favorite ways to do that: - class diagrams (for static stuff like data structures, class relationships, etc.) - sequence diagrams (for dynamic stuff like which functions call which and data passed between them) With good documentation for your own learning purposes, it'll become easier to start working on a codebase and especially when you context switch, it'll help you return to a codebase more easily.

JetSpiegel 8y ago
Ideally, documentation would be written so that there is no need to reverse engineer every project you wade into. Otherwise why share the source code in the first place?
- carusooneliner 8y ago
  There's various kinds of documentation of differing granularity. Typically the high level documentation (coarse grained if you will) about architecture, requirements, etc. stays good over time but finer grain documentation (the kind I mentioned in my earlier comment -- data structures, order of function invocation, etc.) gets stale quickly because source code is constantly changing -- it gets refactored, plenty of bug fixes are put in, etc. Reverse engineering is probably a loaded word, but in general digging in to understand the codebase helps you work more efficiently and avoid introducing bugs to the extent possible.

acroback 8y ago

I see a disturbing trend in industry especially in Bay area from my experience. Young engineers are bad at debugging, bad means real bad but good at programming puzzles. This points to the fact that people value puzzles over experience and in turn miss the big picture. Sure you can code up a balanced RB tree in 5 mins, but what will you do when packets start showing up in bursts on your service? Can you find out that on a live system? I despise this new Bro culture of mugging programming puzzles from leetcode and hackerank. Faltering at first real world challenge is not only disappointing, but an insult to craft of engineering. /Rant over

fancyfish 8y ago
Echoing this and an earlier thread...interviewers could have debugging exercises with an existing codebase. I have seen this ambitious approach at a few startups. Instead of asking yet another sorting algorithm or HackerRank brainteaser. Until the application process changes, the applicants won't change.
- convolvatron 8y ago
  interviewing is only a small part of the picture. mvp has so eroded the notion of correctness that whole organizations don't even look for bugs anymore. try upgrading the dependencies. wrap the service in a harness to make sure it gets restarted when it fails. forget about proactively looking for bugs, wait until they come in, and if you have time that week before they slip into the 'stale - never to be addressed' pile, spend a few minutes trying to reproduce and mark 'works for me'
draw_down 8y ago
It goes further, too. Hotshots who crank out cool-looking stuff with lots of problems under the covers get promotions and accolades; people who do really important maintenance work and fix all the stuff the hotshots didn't think of get the table scraps. Where I work, there is a regular time where an employee tells the whole company about something they fixed and why. It's a nice thought and all, but if the promotions and other material benefits still accrue to the people cranking out new stuff, it doesn't matter too much in my opinion.

vfc1 8y ago

I used to spend my days in the Java debugger, stepping through framework code to troubleshoot application-level errors, as the stacktrace we had obfuscated the error, or everything was simply broken. Depending on the situation, I might spend most of my day debugging, as a way to better understand the program and as a code analysis tool. This was especially useful if dealing with a code base that I was not familiar with, while in code that I wrote myself most of the time logging is sufficient. I'm not sure why the author thinks that debugging is not a priority for tool makers, the debuggers that we currently have are awesome and have been so for years.

stcredzero 8y ago

There were Smalltalk server processes that would catch an exception, snapshot their memory image. A developer could then come along, and open a full interactive debugger on a live, running version of the system, which they could then modify then run as a quick dev test.

spenrose 8y ago

I worked on petabyte-scale data at Mozilla. Here is a talk I gave on the history of debugging and the ways in which doing distributed large data analysis requires moving beyond printf() and STEP: https://www.youtube.com/watch?v=QHJBPzfrokU https://www.youtube.com/watch?v=QHJBPzfrokU

LargeWu 8y ago

Somebody once posted in a Slack channel I was part of asking for things they should include in a course they were teaching for new programmers. My #1 recommendation was how to read a stack trace. The second was how to put a logging statement into your code to capture state.

hannofcart 8y ago

I would go so far as to suggest that if you need a debugger, you're probably doing it wrong. I have found that code that needs a debugger is code that is written in an extremely stateful fashion. The very reason why debuggers exist is to deal with code that has a dozen variables book-keeping complex state that you need to track closely to figure out how something works (or why something doesn't). Debuggers even have "watches" to track something closely so that it doesn't change underneath you, when you aren't looking. To me this is a code smell. I would suggest that instead of using a debugger, we ought to be composing small functions together. Small and pure functions only need an REPL to test. Once you make sure the function is behaving right, you can almost just copy paste over the test cases you ran in your REPL into unit tests. The simplest way to enforce this discipline is to do away with assignments, and instead constrain oneself to using expressions. This forces one to break code into smaller functions. Code written this way turns out to be much more readable, as well as reusable. I suggest that we eschew the debugger in favour of the REPL.

maerF0x0 8y ago
Debuggers help to isolate _where_ code breaks as much as what state it was in when it broke. Seeing that fn1 breaks on DataB is not as useful as seeing that fn1(f2(DataA)) is the actual error.
- sushisource 8y ago
  Yes, this is why they are useful. Generally speaking once I've found where the error is, it's real simple to find the one or two variables in scope, look at their values, and figure out the bug. I would agree that if you're using a debugger to verify over many iterations that something isn't going wacky with state, then yeah, that's not a great sign.
striking 8y ago
It is true that you can answer any question by changing the question. It would be nice if everyone wrote code that minimized state, or if every problem could operate with minimal state. But not all code is or should be like that. "to do away with assignments" is not my favorite way of phrasing what you mean either; I would prefer people assign as many new variables as they like, and just avoid mutating them (i.e. making them `const` and using immutable data structures if performance allows)

wilun 8y ago

While we probably will always have to debug, and if not the "code" it will be a specification formal enough so that it can be considered code anyway, there are different ways to approach its role within the lifecycle of software development: on the two extremes, one can "quickly" but somehow randomly throw lines without thinking much about it, then try the result and correct the few defects that their few tries reveal (and leave dozen to hundreds of other defects to be discovered at more inconvenient times); or one can think a lot about the problem, study a lot about the software where the change must be done, and carefully write some code that perfectly implement what is needed, with very few defects both on the what and on the how side. Note that the "quick" aspect of the first approach is a complete myth (if taken to the extreme, and except for trivially short runs or if the result does not matter that much), because a system can not be developed like that in the long term without collapsing on itself, so there will either be spectacular failures or unplanned dev slowdown, and if the slowdown route is taken, the result will be poorer as if a careful approach would have been taken in the first place, while the velocity might not even be higher. Of course, all degrees exists between the two extremes, and when going too far on one side for a given application is going to cause more problems than it solves (e.g. missing time to market opportunities). Anyway, some projects, maybe those related to computer infrastructure or actually any kind of infrastructure, are more naturally positioned on the careful track (and even then it depends on which aspect, for ex cyber security is still largely an afterthought in large parts of the industry), and the careful track only need debugging as a non-trivial activity when everything else has failed, so hopefully in very small quantities. But it is not that when it is really needed as a last resort, good tooling are not needed. It is just that it is confined to unreleased side projects / tooling, or when it happens in prod it marks a so serious failure that compared to other projects, those hopefully do not happen that often. In those contexts, a project which need too much debugging can be at the risk of dying. So the mean "value" of debugging might be somehow smaller than the mean "value" of designing and writing code and otherwise organizing things so that we do not have to debug (that often).

logfromblammo 8y ago

For the same reason that the water treatment plant gets more respect than the sewage treatment plant. Everyone would prefer to provide something fresh and clean than to wade through other people's poop.

nhoe98thnuoe 8y ago

In my opinion the reason that debugging isn't treated as a first-class activity is that it isn't taught at all in schools. Or at least it wasn't when I was in school. We were given about 2 sentences that said, "the debugger is at /usr/bin/gdb. It can help you step through your code to find a bug." And then we were thrown to the wolves with what is arguably one of the worst debuggers in the world with no documentation and no help.

cuddlybacon 8y ago

One thing that may be relevant is that I was never introduced to debugging in university at all. You were expected to just invent useful techniques on your own. Without any exposure, it is hard to justify learning that over any other topic you feel like you aught to be learning.

codedokode 8y ago

I think that is because there are no good free open source debuggers? In Visual Studio you just set a breakpoint and examine the variables; it works great. On Linux you are left alone against a command-line monster with outdated weird command syntax. gdb has an awful interface; it requires you to read a long manual and learn outdated command syntax before even using it; it is often faster to add logging and rerun the program. It is not a debugger for humans. For comparison, JS debugger in Chrome devtools works pretty good and is easy to use. It is really helpful and allows you to identify a problem very quickly (faster than reading an introduction page for gdb). But it has problems sometimes, when you try to set a breakpoint and it is set in another place or is not set at all without any error messages. I saw some comments here against visual debugging; maybe their authors had experience with some buggy or poorly written debugger? I also tried to use Firefox developer tools in several versions up to FF45 and almost every time something didn't work. And when they work, they choke on scrolling large minified files or heavy sites with lots of ads.

flukus 8y ago
> In Visual Studio you just set a breakpoint and examine the variables; it works great. On Linux you are left alone against a command-line monster with outdated weird command syntax. You're comparing an IDE to a command line environment, Linux has various IDE's that are more comparable and I believe some standalone front ends to gdb, windows also has windbg and dotnet mdbg that are the command line equivalents of gdb that VS is interacting with for you. Gdb (and windbg for that matter) is much more powerful than visual studio debugging though, much like vim and similar tools it's not easy to learn but it's easy to use once you have learned. Stop expecting instant gratification.

nicostouch 8y ago

I often wonder why it's not treated as a first class citizen when teaching programming. I think there should be a full CS course dedicated to it. I put together http://www.debug.coach/ http://www.debug.coach/ because a guy I used to work with had better debugging skills than anybody and I noticed it was because he always knew the right questions to ask.

eftychis 8y ago

I think the approach we should take is to pour more effort into minimizing the risk of debugging being necessary. Good practices, better type checkers and logic models (e.g. there was an article posted in the front page here about using linear logic to push the boundaries of file systems). Debugging can be a time sink and can become a painful task for fast distributed systems. We should learn and hone that skill of course, as it does not only offer a solution when lightning strikes, but a way for the developer to gain comprehension of the "internals".

yitchelle 8y ago

If you needed to debug, it is a sign that you have made a mistake. Who wants to admit to making the mistake? :-) Seriously though, I imagine that the junior devs would have such a view of debugging. But the matured devs would plan for it as they know their limitations.

fierro 8y ago

has anyone written intelliJ plugins that deal with the debugger? I have an interesting idea wrt to this, but writing an IntelliJ plugin has so far been extremely painful. If anyone out there is interested send me a message and let's chat