14 ms·

“Good debugger worth weight in shiny rocks, in fact also more” I’ve spent time at small startups and on “elite” big tech teams, and I’m usually the only one on

“Good debugger worth weight in shiny rocks, in fact also more” I’ve spent time at small startups and on “elite” big tech teams, and I’m usually the only one on my team using a debugger. Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow. I generally agree that it’s the best way to start understanding a system. Breaking on an interesting line of code during a test run and studying the call stack that got me there is infinitely easier than trying to run the code forwards in my head. Young grugs: learning this skill is a minor superpower. Take the time to get it working on your codebase, if you can.

avhception 1y ago
Using a debugger on my own code is easy and I love it. The second the debugger steps deep into one of the libs or frameworks I'm using, I'm lost and I hate it. That framework / lib easily has many ten thousands of person-hours under it's belly, and I'm way out of my league.
- ronjakoi 1y ago
  But you can just use the "step out" feature to get back out when you realise you've gone into a library function. Or "step over" when you can see you're about to go into one.
  - avhception 1y ago
    While that's true, it doesn't necessarily help me understand why my parameters for said lib or whatever lead to things blowing up.
- never_inline 1y ago
  IDEs tend to have a "just my code" option.
- msluyter 1y ago
  "Step out" is how to get out of the lower level frameworks, and or "step over" to avoid diving into them in the first place. I can't speak for other IDEs, but all of the JetBrains products have these.
roncesvalles 1y ago
I'd love to use a real debugger but as someone who has only ever worked at large companies, this was just never an option. In a microservices mesh architecture, you can't really run anything locally at all, and the test environment is often not configured to allow hooking up a stepping debugger. Print debugging is all you have. If there's a problem with the logging system itself or something that crashes the program before the logs can flush, then not even that.
- frollogaston 1y ago
  Same, this isn't my choice, debuggers don't work here. And we don't even have microservices.
  - monkeyelite 1y ago
    > debuggers don't work here It’s impossible? Or would take engineering work to enable
    - frollogaston 1y ago
      It's not a realtime system kind of thing where the debugger would change the behavior too much... It's possible with enough engineering work, but nobody has put that work in, in fact they had a debugger for some staging envs that they deleted. Lately they keep adding more red tape making it hard to even run something locally, let alone attach a debugger. I guess you can attach a debugger for unit tests, but that's not very useful.
      - Kwantuum 1y ago
        > I guess you can attach a debugger for unit tests, but that's not very useful. That is in fact incredibly useful
        frollogaston 1y ago
        Eh, it's there for those who want it, but nobody uses it
novia 1y ago
Well, what's your workflow? Is there a particular debugger that you love?
- titanomachy 1y ago
  I’ve learned not to go against the grain with tools, at least at big companies. Probably some dev productivity team has already done all the annoying work needed to make the company’s codebase work with some debugger and IDE, so I use that: currently, it’s VS Code and LLDB, which is fine. IntelliJ and jdb at my last job was probably better overall. My workflow is usually: 1. insert a breakpoint on some code that I’m trying to understand 2. attach the debugger and run any tests that I expect to exercise that code 3. walk up and down the call stack, stepping occasionally, reading the code and inspecting the local variables at each level to understand how the hell this thing works and why it’s gone horribly wrong this time. 4. use my new understanding to set new, more relevant breakpoints; repeat 2-4. Sometimes I fiddle with local variables to force different states and see what happens, but I consider this advanced usage, and anyway it often doesn’t work too well on my current codebase.
ipsento606 1y ago
I've been doing this professionally for over a decade and have basically never used a debugger I've often felt that I should, but never enough to actually learn how
demosthanos 1y ago
There was a good discussion on this topic years ago [0]. The top comment shares this quote from Brian Kernighan and Rob Pike, neither of whom I'd call a young grug: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient. I tend to agree with them on this. For almost all of the work that I do, this hypothesis-logs-exec loop gets me to the answer substantially faster. I'm not "trying to run the code forwards in my head". I already have a working model for the way that the code runs, I know what output I expect to see if the program is behaving according to that model, and I can usually quickly intuit what is actually happening based on the incorrect output from the prints. [0] The unreasonable effectiveness of print debugging (349 points, 354 comments) April 2021 https://news.ycombinator.com/item?id=26925570 https://news.ycombinator.com/item?id=26925570
- samsepi01 1y ago
  But can't you instead just set a breakpoint next to wherever you are gonna put that print stmt and inspect value once code hits? print stmt seems like extra overhead
  - teaearlgraycold 1y ago
    That doesn’t necessarily give you a clean log to review
    - piva00 1y ago
      While also avoiding having to re-run cases to get new introspection when you forgot to add a print statement. I tend to do both, print statements when I don't feel I want to be stepping through some cumbersome interplay of calls but diving into the debugger to step through the nitty gritty, even better when I can evaluate code in the debugger to understand the state of the data at precise points. I don't think there's a better or worse version of doing it, you use the tool that is best for what introspection you need.
PaulHoule 1y ago
I would tend to say that printf debugging is widespread in the Linux-adjacent world because you can't trust a visual debugger to actually be working there because of the general brokenness of GUIs in the Linux world. I didn't really get into debuggers until (1) I was firmly in Windows, where you expect the GUI to work and the LI to be busted, and (2) I'd been burned too many times by adding debugging printfs() that got checked into version control and caused trouble. Since then I've had some adventures with CLI debuggers, such as using gdb to debug another gdb, using both jdb and gdb on the same process at the same time to debug a Java/C++ system, automating gdb, etc. But there is the thing, as you say, is that there is usually some investment required to get the debugger working for a particular system. With a good IDE I think Junit + debugging gives an experience in Java similar to using the REPL in a language like Python in that you can write some code that is experimental and experiment it, but in this case the code doesn't just scroll out of the terminal but ultimately gets checked in as a unit test.
- ses1984 1y ago
  Debuggers exist in the terminal, in vim, and in emacs.
- bandrami 1y ago
  Why would you want a GUI debugger?
  - PaulHoule 1y ago
    Can see all your source code while you're debugging. And it's not like emacs where your termcap is 99.99% right which means it is 0.01% wrong. (Mac-ers get made when something is 1px out of place, in Linux culture they'll close a bug report if the window is 15000 px to the left of the screen and invisible because it's just some little fit and finish thing)
  - ipdashc 1y ago
    Honestly, I consider myself pretty comfortable with the terminal and vim and whatnot, but I've never been able to get into using GDB. For me I feel like a debugger is one of those things that's just so much better as a proper GUI.
deleted 1y ago
[deleted]
nyarlathotep_ 1y ago
> and I’m usually the only one on my team using a debugger. Almost everyone in the real world (at least in web tech) seems to do print statement debugging. One of the first things I do in a codebase is get some working IDE/editor up where I can quickly run the program under a debugger, even if I'm not immediately troubleshooting something. It's never long before I need to use it. I was baffled when I too encountered this. Even working collaboratively with people they'd have no concept of how to use a debugger. "No, set a breakpoint there" "yeah now step into the function and inspect the state of those variables" "step over that" : blank stares at each instance :
- joshvm 1y ago
  For desktop GUI development I can't imagine not using breakpoints and stepping. Especially when you have several ways that some callback might be triggered. It's super helpful to break on a UI element signal (or slot) and then follow along to see why things aren't working. I don't use debuggers as often in Python, probably because it's eaiser to throw code in a notebook and run line by line to inspect variables, change/inject state and re-run. That's possible but a lot harder to do in C++. Also for embedded work, using a debugger and memory viewer is pretty powerful. It's not something people think about for Arduino but almost every commodity micro supports some sort of debugwire-like interface (which is usually simpler than JTAG).
bloomca 1y ago
Personally, I think that debugger is very helpful in understanding what is going on, but once you are familiar with the code and data structures, I am very often pretty close in my assessment, so scanning code and inserting multiple print lines is both faster and more productive. I only used debugger recently in C# and C, when I was learning and practicing them.
- oh_my_goodness 1y ago
  A lot of people think that. That's why it's important to read the essay.
geophile 1y ago
I am also in the camp that has very little use for debuggers. A point that may be pedantic: I don't add (and then remove) "print" statements. I add logging code, that stays forever. For a major interface, I'll usually start with INFO level debugging, to document function entry/exit, with param values. I add more detailed logging as I start to use the system and find out what needs extra scrutiny. This approach is very easy to get started with and maintain, and provides powerful insight into problems as they arise. I also put a lot of work into formatting log statements. I once worked on a distributed system, and getting the prefix of each log statement exactly right was very useful -- node id, pid, timestamp, all of it fixed width. I could download logs from across the cluster, sort, and have a single file that interleaved actions from across the cluster.
- hobs 1y ago
  A log is very different than a debugger though, one tells you what happened, one shows you the entire state and doesn't make you assemble it in your head.
  - demosthanos 1y ago
    Your framing makes it sound like the log is worse in some way, but what the log gives you that the debugger makes you assemble in your head is a timeline of when things happen. Being able to see time is a pretty big benefit for most types of software. I can always drop an entire state object into the log if I need it, but the only way for a debugger to approximate what a log can give me is for me to step through a bunch of break points and hold the time stream in my head. The one place where a debugger is straight up better is if I know exactly which unit of code is failing and that unit has complicated logic that is worth stepping through line by line. That's what they were designed for, and they're very useful for that, but it's also not the most common kind of troubleshooting I run into.
    - hobs 1y ago
      It's not worse or better, but its not really comparable is all I am really saying, I would not use them for the same things.
wagwang 1y ago
I find that debuggers solve a very specific class of bugs of intense branching complexity in a self contained system. But the moment there's stuff going in and out of DBs, other services, multithreading, integrations, etc, the debugger becomes more of a liability without a really advanced tooling team.
- eternityforest 1y ago
  I think of "don't break the debugger" as a top important design heuristic. It's one point in favor of async, and language that make async debugging easy. And at the very least, you can encapsulate things so they can be debugged separately from the multi threading stuff. If you're always using the debugger, you learn to build around it as one of your primary tools for interacting with code, and you notice right away if the debugger can't help with something.
btreecat 1y ago
I've had more sr devs than I tell me they don't see a benefit to using a debugger, because they have a type system. Wtaf?
mlinhares 1y ago
I don't use debuggers in general development but use them a lot when writing and running automated tests, much faster and easier to see stuff than with print statements.
shadowgovt 1y ago
It has gotten to the point where when somebody wants to add a DSL to our architecture one of my first questions is "where is your specification for integrating it to the existing debuggers?" If there isn't one, I'd rather use a language with a debugger and write a thousand lines of code than 100 lines of code in a language I'm going to have to black box.
never_inline 1y ago
I am young grug who didn't use debuggers much until last year or so. What sold me on debugger is the things you can do with it * See values and eval expressions in calling frames. * Modify the course of execution by eval'ing a mutating expression. * Set exception breakpoints which stop deep where the exception is raised. One other such tool is REPL. I see REPL and debugger as complementary to each other, and have some success using both together in VSCode, which is pretty convenient with autoreload set. (https://mahesh-hegde.github.io/posts/vscode-ipython-debugging/ https://mahesh-hegde.github.io/posts/vscode-ipython-debuggin...)
mikepurvis 1y ago
The rise of virtualization, containers, microservices, etc has I think contributed to this being more difficult. Even local dev-test loops often have something other than you launching the executable, which can make it challenging to get the debugger attached to it. Not any excuse, but another factor to be considered when adding infra layers between the developer and the application.
- bluefirebrand 1y ago
  Debuggers are also brittle when working with asynchronous code Debuggers actually can hide entire categories of bugs caused by race conditions when breakpoints cause async functions to resolve in a different order than they would when running in realtime
Buttons840 1y ago
Another underutilized debugging superpower is debug-level logging. I've never worked somewhere where logging is taken seriously. Like, our AWS systems produce logs and they get collected somewhere, but none of our code ever does any serious logging. If people like print-statement debugging so much, then double down on it and do it right, with a proper logging framework and putting quality debug statements into all code.
- mrkeen 1y ago
  If you want to double-down on logging and do it right: make your logs fit for computer consumption and the source of truth. That's all event-sourcing is.
rendaw 1y ago
Are you more productive with a debugger? For all bugs? How so?
GrumpyYoungMan 1y ago
Debuggers are great until you have to work in a context where you can't attach a debugger. Good old printf works in every context. By all means, learn to use a debugger well but don't become overly dependent on them.
- deleted 1y ago
  [deleted]
- mrngm 1y ago
  I'll introduce you to our bespoke tool that automatically restarts processes when they exit... and redirects stdout/err by default to /dev/null :D
whateveracct 1y ago
I use a repl instead of a debugger. White box vs black box.
- never_inline 1y ago
  They can be used in conjunction. You can drop into debugger from REPL and vice versa.
ghiculescu 1y ago
I’m a debugger guy too, but print statements can be very powerful. I keep this bookmarked https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debuggerer/ https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debugger...
octo888 1y ago
My hypothesis is that because we generally don't/can't use debuggers in production but rather rely on logging and tracing, that extends to local dev.
- Nezteb 1y ago
  Agreed! If you usually aren't able/allowed to use a debugger in production and must rely on observability tools, it's helpful to know how to utilize those tools locally as effectively as possible when debugging.
MangoToupe 1y ago
> Breaking on an interesting line of code during a test run and studying the call stack that got me there is infinitely easier than trying to run the code forwards in my head. I really don't get this at all. To me it is infinitely easier to iterate and narrow the problem rather than trying to identify sight-unseen where the problem is—it's incredibly rare that the bug immediately crashes the program. And you can fit a far higher density of relevant information through print statements over execution of a reproduced bug than you can reproduce at any single point in the call stack. And 99% of the information you can access at any single point in the call stack will be irrelevant. To be sure, a debugger is an incredibly useful and irreplaceable tool.... but it's far too slow and buggy to rely on for daily debugging (unless, as you indicate, you don't know the codebase well enough to reason about it by reading the code). Things that complicate this: * highly mutable state * extremely complex control or data flow * not being able to access logs * the compiler lying to you or being incorrect * subtle instruction ordering issues
slt2021 1y ago
debugging is useful when your codebase is bad: imperative style, mutable state, weak type system, spaghetti code, state and control variables intermixed. i'd rather never use debugger, so that my coding style is enforced to be clean code, strong type system, immutable variables, explicit error control, explicit control flow etc
- commandlinefan 1y ago
  You've gotten downvoted but I think you're correct - if there were no debuggers, the developers would be forced to write (better) code that didn't need them.
  - slt2021 1y ago
    Thank you for defending the common sense opinion. Some people here are too reactionary
nardi 1y ago
Having worked in many languages and debuggers across many kinds of backend and front end systems, I think what some folks miss here is that some debuggers are great and fast, and some suck and are extremely slow. For example, using LLDB with Swift is hot garbage. It lies to you and frequently takes 30 seconds or more to evaluate statements or show you local variable values. But e.g. JavaScript debuggers tend to be fantastic and very fast. In addition, some kinds of systems are very easy to exercise in a debugger, and some are very difficult. Some bugs resist debugging, and must be printf’d. In short, which is better? It depends, and varies wildly by domain.
scotty79 1y ago
What's insane is that debuggers could support at least 80-90% of print debugging workflow with a good UI. The only thing that's really missing is history of the values of the watches you added, all in one log. With filters because why not. For some reason I never seen this option in any debugger I tried.
- scotty79 1y ago
  UPDATE: Heh, who knew, debuggers already have this feature under the name tracepoints (VS) or logpoints (Viscose). https://code.visualstudio.com/blogs/2018/07/12/introducing-logpoints-and-auto-attach https://code.visualstudio.com/blogs/2018/07/12/introducing-l... It should be way more well known among print debug crowd.
pydry 1y ago
>Young grugs: learning this skill is a minor superpower. Take the time to get it working on your codebase, if you can. TIL Linus Torvald is a young grug.
thesz 1y ago
I used to use debugger when I was young - disk space was small, disks were slow and logging was expensive. Now, some 35 years later, I greatly prefer logs. This way I can compare execution paths of different use cases, I can compare outcomes of my changes, etc. I am not confined to a single point of time with tricky manual control as with debugger, I can see them all. To old grugs: learning to execute and rewind code in your head is a major superpower. And it works on any codebase.
fellatio 1y ago
I thought debugging was table stakes. It isn't always the answer. If a lot is going on logs can be excellent (plus grep or an observability tool) However debugging is an essential tool in the arsenal. If something is behaving oddly even the best REPL can't match debugging as a dev loop (maybe lisp excepted). I even miss the ability to move the current execution point back in .NET now I use Go and JS. That is a killer feature. Edit and continue even more so! Then next level is debugging unit tests. Saved me hours.
Cthulhu_ 1y ago
It's been years since I last used a debugger, but then, it's been years since I last worked on code that was complicated enough to warrant it. Which is a good thing! Easily comprehended code that you can reason about without stepping through it is good for grug brain.
ay 1y ago
There might be another factor at not using the debugger beyond the pure cluelessness: often you can’t really run it in production. Back when I started with coding (it was Turbo Pascal 3.0, so you get the idea :-), I enjoyed the use of the debugger quite a lot. But in 2000 I started working in a role which required understanding the misbehavior of embedded systems that were forwarding the live traffic, there was a technical possibility to do “target remote …” but almost never an option to stop a box that is forwarding the traffic. So you end up being dependent on debugs - and very occasional debug images with enhanced artisanal diagnostics code (the most fun was using gcc’s -finstrument-function to catch a memory corruption of an IPSec field by an unrelated IKE code in a use-after free scenario) Where the GDB shined though is the analysis of the crash dumps. Implementing a “fake” gdb stub in Perl, which was sucking in the crash dump data and allow to leisurely explore it with debugger rather than decoding hex by hand, was a huge productivity boon. So I would say - it’s better to have more than one tool in the toolbox and use the most appropriate one.
- leojfc 1y ago
  Wholeheartedly agree. There’s often good performance or security reasons why it’s hard to get a debugger running in prod, but it’s still worth figuring out how to do it IMO. Your experience sounds more sophisticated than mine, but the one time I was able to get even basic debugger support into a production Ruby app, it made fixing certain classes of bug absolutely trivial compared to what it would have been. The main challenge was getting this considered as a requirement up front rather than after the fact.
HPsquared 1y ago
Indeed. Let the machine do the work!
deleted 1y ago
[deleted]
lhamil64 1y ago
I work with some pretty niche tech where it's usually, ironically, easier to use a debugger than to add print statements. Unfortunately the debugger is pretty primitive, it can't really show the call stack for example. But even just stopping at a line of code and printing variables or poking around in memory is pretty powerful.
cyberax 1y ago
> Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow. Sigh. Same. To a large extent, this is caused by debuggers just sucking for async/await code. And just sucking in general for webdev.
- sensanaty 1y ago
  I try all the time, but I always end up having to wrestle a trillion calls into some library code that has 0 relevance to me, and if the issue is happening at some undetermined point in the chain, you basically have to step through it all to get an idea for where things are going wrong. On the other hand, the humble console.log() just works without requiring insanely tedious and frustrating debugger steps.
  - cyberax 1y ago
    I mean, "step over" and "go to line" exist...
flmontpetit 1y ago
My current position has implemented a toolchain that essentially makes debugging either impossible or extremely unwieldy for any backend projects and nobody seems to think it's a problem.
perrygeo 1y ago
Running a debugger on test failure is a ridiculously effective workflow. Instead of getting a wall of text, you drop right into the call stack where the failure/error happened. `pytest --pdb` in python, worth its weight in shiny rocks for sure!
jmull 1y ago
I find the differences between printf debugging and line debuggers (or whatever you call them) unimportant in most circumstances. Line debuggers usually have some nice conveniences, but the major bottlenecks are between the ears, not in the tool.
- voidUpdate 1y ago
  I usually use a normal debugger to find a problem when I can see its symptoms but not the original caus. That way I can break on the line that is causing the symptom, check what the variables are like and go back up the call stack to find the origin of the incorrect state. I can do all that in one shot (maybe a couple if I need to break somewhere else instead) rather than putting prints everywhere to try and work out what the call stack is, and a load of prints to list off all the local variables
DangitBobby 1y ago
Sometimes I need a debugger because there's a ton of variables or I just have no idea what's wrong and that's the easiest way to see everything that's going on. It's really frustrating to feel like I need a debugger and don't have a good way to add the IDEs visual debugger (because I'm using a CLI on a remote session or something). It's also really frustrating to be inside a debugging session and wish you knew what the previous value for something was but you can't because you can't go backwards in time. That happens so often to me, in fact, that print debugging is actually more effective for me in the vast majority of cases.
connicpu 1y ago
I love debuggers, but unfortunately at my current job I've found that certain things we do to make our application more performant (mainly using giant structs full of fixed size arrays allocated at the start of the application) cause LLDB to slow to a crawl when `this` points to them. It really really doesn't like trying to read the state of a nearly 1GB struct...
- oehpr 1y ago
  This is one of those reasons why you really really need to get other people on board with your workflows. If you're the only one who works like that and someone does something insane, but it technically works, but it blows your workflow up... that's your problem. "You should just develop how I'm developing. Putting in a print statement for every line then waiting 5 minutes for the application to compile." So long as no one sees your workflow as valuable, they will happily destroy it if it means getting the ticket done.
TOGoS 1y ago
Some people are wizards with the debugger. Some people prefer printfs. I used to debug occasionally but haven't touched a debugger in years. I'm not sure exactly why this is, but I'm generally not concerned with exactly what's in the stack on a particular run, but more with some specific state and where something changes time after time, and it's easier to collect that data programatically in the program than to figure out how to do it in the debugger that's integrated with whatever IDE I'm using that day. And the codebase I deal with at work is Spring Boot. 90% of the stack is meaningless to me anyway. The debugger has been handy for finding out "what the f*$% is the caller doing to the transaction context" but that kind of thing is frustrating no matter what. Anyway, I think they're both valid ways to explore the runtime characteristics of your program. Depends on what you're comfortable with, how you think of the problem, and the type of codebase you're working on. I could see living in the debugger being more useful to me if I'm in some C++ codebase where every line potentially has implicit destructor calls or something.
profsummergig 1y ago
I want to master JS/React and Python debugging. Am an "advanced beginner" in both. What tools do you recommend?
- steve_adams_86 1y ago
  For JavaScript, you're actually able to debug fairly easily by default by adding a `debugger()` call in your code. Browsers will stop at that call, and start the debugger. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Another way (and probably a better idea) is creating a launch definition for VS Code in launch.json which attaches the IDE's debugger to Chrome. Here is an article describing how that works: https://profy.dev/article/debug-react-vscode https://profy.dev/article/debug-react-vscode Breakpoints are nice because they can't accidentally get shipped to production like debugger calls can. For Python I essentially do the same thing, minus involving Chrome. I run the entry point to my application from launch.json, and breakpoints in the IDE 'just work'. From there, you can experiment with how the debugger tools work, observe how state change as the application runs, etc. If you don't use VS Code, these conventions are similar in other IDEs as well.
Drew_ 1y ago
I'm looking around and I don't see anyone mentioning what I think is one of the biggest advantages of debugging: not having to recompile. Even assuming print statements and debuggers are equally effective (they're not), debuggers are better simply because they are faster. With print statements, you might need to recompile a dozen times before you find whatever it is you're looking for. Even with quick builds this is infuriating and a ton of wasted time.
norir 1y ago
Here is my circular argument against debuggers: if I learn to use a debugger, I will spend much, possibly most, of my time debugging. I'd rather learn how to write useful programs that don't have bugs. Most people believe this is impossible. The trouble of course is that there is always money to be made debugging. There is almost no incentive in industry to truly eliminate bugs and, indeed, I would argue that the incentives in the industry actively encourage bugs because they lead to lucrative support contracts and large dev teams that spend half their time chasing down bugs in a never-ending cycle. If a company actually shipped perfect software, how could they keep extracting more money from their customer?
- deleted 1y ago
  [deleted]
- dieortin 1y ago
  So you think that not knowing how to operate a debugger will exempt your code from having bugs, or you from having to debug them?
kakuri 1y ago
I loved Chrome's debugger for years, then build tools and React ruined debugging for me. Built code largely works with source maps, but it fails often enough, and in bizarre ways, that my workflow has simply gone back to console logs. React's frequent re-renders have also made breakpoints very unpleasant - I'd rather just look at the results of console logs. Are there ways I can learn to continue enjoying the debugger with TS+React? It is still occasionally useful and I'm glad its there, but I have reverted to defaulting to console logs.
- dgb23 1y ago
  Console logs in the browser have some unique advantages. You can assign the output to a variable, play with it etc. But yes, any code that is inside jsx generally sucks to debug with standard tooling. There are browser plugins that help you inspect the react ui tree though.
- jesse__ 1y ago
  Agreed, debugging tools for the browser are almost comically incapable, to the point of not even useful in most cases.
- duderific 1y ago
  I find myself doing a mix of both. Source maps are good enough most of the time, I haven't seen the bizarre failures you're seeing - maybe your bundling configuration needs some tweaking? But yes, the frequent re-renders are obnoxious. In those cases logging is generally better. Conditional breakpoints help alleviate the pain when there are frequent re-renders. Generally you can pinpoint a specific value that you're looking for and only pause when that condition is satisfied. Setting watch expressions helps a lot too.
mdavid626 1y ago
Nobody has time for that. Need time for prompting AI!
acureau 1y ago
I refuse to believe there are professional software developers who don't use debuggers. What are you all working on? How do you get your bearings in a new code-base? Do you read it like a book, and keep the whole thing in your mind? How do you specify all of the relevant state in your print statements? How do you verify your logic?
jalapenos 1y ago
Debuggers are great. I too have tried and failed to spread their use. But the reason is simple: they are always 100x harder to set up and keep working than just type a print statement and be done with it. Especially when you're in a typical situation where an app has a big convoluted docker based setup, and with umpteen packers & compilers & transpilers etc. This is why all software companies should have at least one person tasked with making sure there are working debuggers everywhere, and that everyone's been trained how to use them. There should also be some kind of automated testing that catches any failures in debugging tooling. But that effort's hard to link directly to shipped features, so if you started doing that, management would home in on that dev like a laser guided missile and task him to something with "business value", thereby wasting far more dev time and losing far more business value.

avhception 1y ago

Using a debugger on my own code is easy and I love it. The second the debugger steps deep into one of the libs or frameworks I'm using, I'm lost and I hate it. That framework / lib easily has many ten thousands of person-hours under it's belly, and I'm way out of my league.

ronjakoi 1y ago
But you can just use the "step out" feature to get back out when you realise you've gone into a library function. Or "step over" when you can see you're about to go into one.
- avhception 1y ago
  While that's true, it doesn't necessarily help me understand why my parameters for said lib or whatever lead to things blowing up.
never_inline 1y ago
IDEs tend to have a "just my code" option.
msluyter 1y ago
"Step out" is how to get out of the lower level frameworks, and or "step over" to avoid diving into them in the first place. I can't speak for other IDEs, but all of the JetBrains products have these.

roncesvalles 1y ago

I'd love to use a real debugger but as someone who has only ever worked at large companies, this was just never an option. In a microservices mesh architecture, you can't really run anything locally at all, and the test environment is often not configured to allow hooking up a stepping debugger. Print debugging is all you have. If there's a problem with the logging system itself or something that crashes the program before the logs can flush, then not even that.

frollogaston 1y ago
Same, this isn't my choice, debuggers don't work here. And we don't even have microservices.
- monkeyelite 1y ago
  > debuggers don't work here It’s impossible? Or would take engineering work to enable
  - frollogaston 1y ago
    It's not a realtime system kind of thing where the debugger would change the behavior too much... It's possible with enough engineering work, but nobody has put that work in, in fact they had a debugger for some staging envs that they deleted. Lately they keep adding more red tape making it hard to even run something locally, let alone attach a debugger. I guess you can attach a debugger for unit tests, but that's not very useful.
    - Kwantuum 1y ago
      > I guess you can attach a debugger for unit tests, but that's not very useful. That is in fact incredibly useful
      - frollogaston 1y ago
        Eh, it's there for those who want it, but nobody uses it

novia 1y ago

Well, what's your workflow? Is there a particular debugger that you love?

titanomachy 1y ago
I’ve learned not to go against the grain with tools, at least at big companies. Probably some dev productivity team has already done all the annoying work needed to make the company’s codebase work with some debugger and IDE, so I use that: currently, it’s VS Code and LLDB, which is fine. IntelliJ and jdb at my last job was probably better overall. My workflow is usually: 1. insert a breakpoint on some code that I’m trying to understand 2. attach the debugger and run any tests that I expect to exercise that code 3. walk up and down the call stack, stepping occasionally, reading the code and inspecting the local variables at each level to understand how the hell this thing works and why it’s gone horribly wrong this time. 4. use my new understanding to set new, more relevant breakpoints; repeat 2-4. Sometimes I fiddle with local variables to force different states and see what happens, but I consider this advanced usage, and anyway it often doesn’t work too well on my current codebase.

ipsento606 1y ago

I've been doing this professionally for over a decade and have basically never used a debugger I've often felt that I should, but never enough to actually learn how

demosthanos 1y ago

There was a good discussion on this topic years ago [0]. The top comment shares this quote from Brian Kernighan and Rob Pike, neither of whom I'd call a young grug: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient. I tend to agree with them on this. For almost all of the work that I do, this hypothesis-logs-exec loop gets me to the answer substantially faster. I'm not "trying to run the code forwards in my head". I already have a working model for the way that the code runs, I know what output I expect to see if the program is behaving according to that model, and I can usually quickly intuit what is actually happening based on the incorrect output from the prints. [0] The unreasonable effectiveness of print debugging (349 points, 354 comments) April 2021 https://news.ycombinator.com/item?id=26925570 https://news.ycombinator.com/item?id=26925570

samsepi01 1y ago
But can't you instead just set a breakpoint next to wherever you are gonna put that print stmt and inspect value once code hits? print stmt seems like extra overhead
- teaearlgraycold 1y ago
  That doesn’t necessarily give you a clean log to review
  - piva00 1y ago
    While also avoiding having to re-run cases to get new introspection when you forgot to add a print statement. I tend to do both, print statements when I don't feel I want to be stepping through some cumbersome interplay of calls but diving into the debugger to step through the nitty gritty, even better when I can evaluate code in the debugger to understand the state of the data at precise points. I don't think there's a better or worse version of doing it, you use the tool that is best for what introspection you need.

PaulHoule 1y ago

I would tend to say that printf debugging is widespread in the Linux-adjacent world because you can't trust a visual debugger to actually be working there because of the general brokenness of GUIs in the Linux world. I didn't really get into debuggers until (1) I was firmly in Windows, where you expect the GUI to work and the LI to be busted, and (2) I'd been burned too many times by adding debugging printfs() that got checked into version control and caused trouble. Since then I've had some adventures with CLI debuggers, such as using gdb to debug another gdb, using both jdb and gdb on the same process at the same time to debug a Java/C++ system, automating gdb, etc. But there is the thing, as you say, is that there is usually some investment required to get the debugger working for a particular system. With a good IDE I think Junit + debugging gives an experience in Java similar to using the REPL in a language like Python in that you can write some code that is experimental and experiment it, but in this case the code doesn't just scroll out of the terminal but ultimately gets checked in as a unit test.

ses1984 1y ago
Debuggers exist in the terminal, in vim, and in emacs.
bandrami 1y ago
Why would you want a GUI debugger?
- PaulHoule 1y ago
  Can see all your source code while you're debugging. And it's not like emacs where your termcap is 99.99% right which means it is 0.01% wrong. (Mac-ers get made when something is 1px out of place, in Linux culture they'll close a bug report if the window is 15000 px to the left of the screen and invisible because it's just some little fit and finish thing)
- ipdashc 1y ago
  Honestly, I consider myself pretty comfortable with the terminal and vim and whatnot, but I've never been able to get into using GDB. For me I feel like a debugger is one of those things that's just so much better as a proper GUI.

deleted 1y ago

[deleted]

nyarlathotep_ 1y ago

> and I’m usually the only one on my team using a debugger. Almost everyone in the real world (at least in web tech) seems to do print statement debugging. One of the first things I do in a codebase is get some working IDE/editor up where I can quickly run the program under a debugger, even if I'm not immediately troubleshooting something. It's never long before I need to use it. I was baffled when I too encountered this. Even working collaboratively with people they'd have no concept of how to use a debugger. "No, set a breakpoint there" "yeah now step into the function and inspect the state of those variables" "step over that" : blank stares at each instance :

joshvm 1y ago
For desktop GUI development I can't imagine not using breakpoints and stepping. Especially when you have several ways that some callback might be triggered. It's super helpful to break on a UI element signal (or slot) and then follow along to see why things aren't working. I don't use debuggers as often in Python, probably because it's eaiser to throw code in a notebook and run line by line to inspect variables, change/inject state and re-run. That's possible but a lot harder to do in C++. Also for embedded work, using a debugger and memory viewer is pretty powerful. It's not something people think about for Arduino but almost every commodity micro supports some sort of debugwire-like interface (which is usually simpler than JTAG).

bloomca 1y ago

Personally, I think that debugger is very helpful in understanding what is going on, but once you are familiar with the code and data structures, I am very often pretty close in my assessment, so scanning code and inserting multiple print lines is both faster and more productive. I only used debugger recently in C# and C, when I was learning and practicing them.

oh_my_goodness 1y ago
A lot of people think that. That's why it's important to read the essay.

geophile 1y ago

I am also in the camp that has very little use for debuggers. A point that may be pedantic: I don't add (and then remove) "print" statements. I add logging code, that stays forever. For a major interface, I'll usually start with INFO level debugging, to document function entry/exit, with param values. I add more detailed logging as I start to use the system and find out what needs extra scrutiny. This approach is very easy to get started with and maintain, and provides powerful insight into problems as they arise. I also put a lot of work into formatting log statements. I once worked on a distributed system, and getting the prefix of each log statement exactly right was very useful -- node id, pid, timestamp, all of it fixed width. I could download logs from across the cluster, sort, and have a single file that interleaved actions from across the cluster.

hobs 1y ago
A log is very different than a debugger though, one tells you what happened, one shows you the entire state and doesn't make you assemble it in your head.
- demosthanos 1y ago
  Your framing makes it sound like the log is worse in some way, but what the log gives you that the debugger makes you assemble in your head is a timeline of when things happen. Being able to see time is a pretty big benefit for most types of software. I can always drop an entire state object into the log if I need it, but the only way for a debugger to approximate what a log can give me is for me to step through a bunch of break points and hold the time stream in my head. The one place where a debugger is straight up better is if I know exactly which unit of code is failing and that unit has complicated logic that is worth stepping through line by line. That's what they were designed for, and they're very useful for that, but it's also not the most common kind of troubleshooting I run into.
  - hobs 1y ago
    It's not worse or better, but its not really comparable is all I am really saying, I would not use them for the same things.

wagwang 1y ago

I find that debuggers solve a very specific class of bugs of intense branching complexity in a self contained system. But the moment there's stuff going in and out of DBs, other services, multithreading, integrations, etc, the debugger becomes more of a liability without a really advanced tooling team.

eternityforest 1y ago
I think of "don't break the debugger" as a top important design heuristic. It's one point in favor of async, and language that make async debugging easy. And at the very least, you can encapsulate things so they can be debugged separately from the multi threading stuff. If you're always using the debugger, you learn to build around it as one of your primary tools for interacting with code, and you notice right away if the debugger can't help with something.

btreecat 1y ago

I've had more sr devs than I tell me they don't see a benefit to using a debugger, because they have a type system. Wtaf?

mlinhares 1y ago

I don't use debuggers in general development but use them a lot when writing and running automated tests, much faster and easier to see stuff than with print statements.

shadowgovt 1y ago

It has gotten to the point where when somebody wants to add a DSL to our architecture one of my first questions is "where is your specification for integrating it to the existing debuggers?" If there isn't one, I'd rather use a language with a debugger and write a thousand lines of code than 100 lines of code in a language I'm going to have to black box.

never_inline 1y ago

I am young grug who didn't use debuggers much until last year or so. What sold me on debugger is the things you can do with it * See values and eval expressions in calling frames. * Modify the course of execution by eval'ing a mutating expression. * Set exception breakpoints which stop deep where the exception is raised. One other such tool is REPL. I see REPL and debugger as complementary to each other, and have some success using both together in VSCode, which is pretty convenient with autoreload set. (https://mahesh-hegde.github.io/posts/vscode-ipython-debugging/ https://mahesh-hegde.github.io/posts/vscode-ipython-debuggin...)

mikepurvis 1y ago

The rise of virtualization, containers, microservices, etc has I think contributed to this being more difficult. Even local dev-test loops often have something other than you launching the executable, which can make it challenging to get the debugger attached to it. Not any excuse, but another factor to be considered when adding infra layers between the developer and the application.

bluefirebrand 1y ago
Debuggers are also brittle when working with asynchronous code Debuggers actually can hide entire categories of bugs caused by race conditions when breakpoints cause async functions to resolve in a different order than they would when running in realtime

Buttons840 1y ago

Another underutilized debugging superpower is debug-level logging. I've never worked somewhere where logging is taken seriously. Like, our AWS systems produce logs and they get collected somewhere, but none of our code ever does any serious logging. If people like print-statement debugging so much, then double down on it and do it right, with a proper logging framework and putting quality debug statements into all code.

mrkeen 1y ago
If you want to double-down on logging and do it right: make your logs fit for computer consumption and the source of truth. That's all event-sourcing is.

rendaw 1y ago

Are you more productive with a debugger? For all bugs? How so?

GrumpyYoungMan 1y ago

Debuggers are great until you have to work in a context where you can't attach a debugger. Good old printf works in every context. By all means, learn to use a debugger well but don't become overly dependent on them.

deleted 1y ago
[deleted]
mrngm 1y ago
I'll introduce you to our bespoke tool that automatically restarts processes when they exit... and redirects stdout/err by default to /dev/null :D

whateveracct 1y ago

I use a repl instead of a debugger. White box vs black box.

never_inline 1y ago
They can be used in conjunction. You can drop into debugger from REPL and vice versa.

ghiculescu 1y ago

I’m a debugger guy too, but print statements can be very powerful. I keep this bookmarked https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debuggerer/ https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debugger...

octo888 1y ago

My hypothesis is that because we generally don't/can't use debuggers in production but rather rely on logging and tracing, that extends to local dev.

Nezteb 1y ago
Agreed! If you usually aren't able/allowed to use a debugger in production and must rely on observability tools, it's helpful to know how to utilize those tools locally as effectively as possible when debugging.

MangoToupe 1y ago

> Breaking on an interesting line of code during a test run and studying the call stack that got me there is infinitely easier than trying to run the code forwards in my head. I really don't get this at all. To me it is infinitely easier to iterate and narrow the problem rather than trying to identify sight-unseen where the problem is—it's incredibly rare that the bug immediately crashes the program. And you can fit a far higher density of relevant information through print statements over execution of a reproduced bug than you can reproduce at any single point in the call stack. And 99% of the information you can access at any single point in the call stack will be irrelevant. To be sure, a debugger is an incredibly useful and irreplaceable tool.... but it's far too slow and buggy to rely on for daily debugging (unless, as you indicate, you don't know the codebase well enough to reason about it by reading the code). Things that complicate this: * highly mutable state * extremely complex control or data flow * not being able to access logs * the compiler lying to you or being incorrect * subtle instruction ordering issues

slt2021 1y ago

debugging is useful when your codebase is bad: imperative style, mutable state, weak type system, spaghetti code, state and control variables intermixed. i'd rather never use debugger, so that my coding style is enforced to be clean code, strong type system, immutable variables, explicit error control, explicit control flow etc

commandlinefan 1y ago
You've gotten downvoted but I think you're correct - if there were no debuggers, the developers would be forced to write (better) code that didn't need them.
- slt2021 1y ago
  Thank you for defending the common sense opinion. Some people here are too reactionary

nardi 1y ago

Having worked in many languages and debuggers across many kinds of backend and front end systems, I think what some folks miss here is that some debuggers are great and fast, and some suck and are extremely slow. For example, using LLDB with Swift is hot garbage. It lies to you and frequently takes 30 seconds or more to evaluate statements or show you local variable values. But e.g. JavaScript debuggers tend to be fantastic and very fast. In addition, some kinds of systems are very easy to exercise in a debugger, and some are very difficult. Some bugs resist debugging, and must be printf’d. In short, which is better? It depends, and varies wildly by domain.

scotty79 1y ago

What's insane is that debuggers could support at least 80-90% of print debugging workflow with a good UI. The only thing that's really missing is history of the values of the watches you added, all in one log. With filters because why not. For some reason I never seen this option in any debugger I tried.

scotty79 1y ago
UPDATE: Heh, who knew, debuggers already have this feature under the name tracepoints (VS) or logpoints (Viscose). https://code.visualstudio.com/blogs/2018/07/12/introducing-logpoints-and-auto-attach https://code.visualstudio.com/blogs/2018/07/12/introducing-l... It should be way more well known among print debug crowd.

pydry 1y ago

>Young grugs: learning this skill is a minor superpower. Take the time to get it working on your codebase, if you can. TIL Linus Torvald is a young grug.

thesz 1y ago

I used to use debugger when I was young - disk space was small, disks were slow and logging was expensive. Now, some 35 years later, I greatly prefer logs. This way I can compare execution paths of different use cases, I can compare outcomes of my changes, etc. I am not confined to a single point of time with tricky manual control as with debugger, I can see them all. To old grugs: learning to execute and rewind code in your head is a major superpower. And it works on any codebase.

fellatio 1y ago

I thought debugging was table stakes. It isn't always the answer. If a lot is going on logs can be excellent (plus grep or an observability tool) However debugging is an essential tool in the arsenal. If something is behaving oddly even the best REPL can't match debugging as a dev loop (maybe lisp excepted). I even miss the ability to move the current execution point back in .NET now I use Go and JS. That is a killer feature. Edit and continue even more so! Then next level is debugging unit tests. Saved me hours.

Cthulhu_ 1y ago

It's been years since I last used a debugger, but then, it's been years since I last worked on code that was complicated enough to warrant it. Which is a good thing! Easily comprehended code that you can reason about without stepping through it is good for grug brain.

ay 1y ago

There might be another factor at not using the debugger beyond the pure cluelessness: often you can’t really run it in production. Back when I started with coding (it was Turbo Pascal 3.0, so you get the idea :-), I enjoyed the use of the debugger quite a lot. But in 2000 I started working in a role which required understanding the misbehavior of embedded systems that were forwarding the live traffic, there was a technical possibility to do “target remote …” but almost never an option to stop a box that is forwarding the traffic. So you end up being dependent on debugs - and very occasional debug images with enhanced artisanal diagnostics code (the most fun was using gcc’s -finstrument-function to catch a memory corruption of an IPSec field by an unrelated IKE code in a use-after free scenario) Where the GDB shined though is the analysis of the crash dumps. Implementing a “fake” gdb stub in Perl, which was sucking in the crash dump data and allow to leisurely explore it with debugger rather than decoding hex by hand, was a huge productivity boon. So I would say - it’s better to have more than one tool in the toolbox and use the most appropriate one.

leojfc 1y ago
Wholeheartedly agree. There’s often good performance or security reasons why it’s hard to get a debugger running in prod, but it’s still worth figuring out how to do it IMO. Your experience sounds more sophisticated than mine, but the one time I was able to get even basic debugger support into a production Ruby app, it made fixing certain classes of bug absolutely trivial compared to what it would have been. The main challenge was getting this considered as a requirement up front rather than after the fact.

HPsquared 1y ago

Indeed. Let the machine do the work!

deleted 1y ago

[deleted]

lhamil64 1y ago

I work with some pretty niche tech where it's usually, ironically, easier to use a debugger than to add print statements. Unfortunately the debugger is pretty primitive, it can't really show the call stack for example. But even just stopping at a line of code and printing variables or poking around in memory is pretty powerful.

cyberax 1y ago

> Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow. Sigh. Same. To a large extent, this is caused by debuggers just sucking for async/await code. And just sucking in general for webdev.

sensanaty 1y ago
I try all the time, but I always end up having to wrestle a trillion calls into some library code that has 0 relevance to me, and if the issue is happening at some undetermined point in the chain, you basically have to step through it all to get an idea for where things are going wrong. On the other hand, the humble console.log() just works without requiring insanely tedious and frustrating debugger steps.
- cyberax 1y ago
  I mean, "step over" and "go to line" exist...

flmontpetit 1y ago

My current position has implemented a toolchain that essentially makes debugging either impossible or extremely unwieldy for any backend projects and nobody seems to think it's a problem.

perrygeo 1y ago

Running a debugger on test failure is a ridiculously effective workflow. Instead of getting a wall of text, you drop right into the call stack where the failure/error happened. `pytest --pdb` in python, worth its weight in shiny rocks for sure!

jmull 1y ago

I find the differences between printf debugging and line debuggers (or whatever you call them) unimportant in most circumstances. Line debuggers usually have some nice conveniences, but the major bottlenecks are between the ears, not in the tool.

voidUpdate 1y ago
I usually use a normal debugger to find a problem when I can see its symptoms but not the original caus. That way I can break on the line that is causing the symptom, check what the variables are like and go back up the call stack to find the origin of the incorrect state. I can do all that in one shot (maybe a couple if I need to break somewhere else instead) rather than putting prints everywhere to try and work out what the call stack is, and a load of prints to list off all the local variables

DangitBobby 1y ago

Sometimes I need a debugger because there's a ton of variables or I just have no idea what's wrong and that's the easiest way to see everything that's going on. It's really frustrating to feel like I need a debugger and don't have a good way to add the IDEs visual debugger (because I'm using a CLI on a remote session or something). It's also really frustrating to be inside a debugging session and wish you knew what the previous value for something was but you can't because you can't go backwards in time. That happens so often to me, in fact, that print debugging is actually more effective for me in the vast majority of cases.

connicpu 1y ago

I love debuggers, but unfortunately at my current job I've found that certain things we do to make our application more performant (mainly using giant structs full of fixed size arrays allocated at the start of the application) cause LLDB to slow to a crawl when `this` points to them. It really really doesn't like trying to read the state of a nearly 1GB struct...

oehpr 1y ago
This is one of those reasons why you really really need to get other people on board with your workflows. If you're the only one who works like that and someone does something insane, but it technically works, but it blows your workflow up... that's your problem. "You should just develop how I'm developing. Putting in a print statement for every line then waiting 5 minutes for the application to compile." So long as no one sees your workflow as valuable, they will happily destroy it if it means getting the ticket done.

TOGoS 1y ago

Some people are wizards with the debugger. Some people prefer printfs. I used to debug occasionally but haven't touched a debugger in years. I'm not sure exactly why this is, but I'm generally not concerned with exactly what's in the stack on a particular run, but more with some specific state and where something changes time after time, and it's easier to collect that data programatically in the program than to figure out how to do it in the debugger that's integrated with whatever IDE I'm using that day. And the codebase I deal with at work is Spring Boot. 90% of the stack is meaningless to me anyway. The debugger has been handy for finding out "what the f*$% is the caller doing to the transaction context" but that kind of thing is frustrating no matter what. Anyway, I think they're both valid ways to explore the runtime characteristics of your program. Depends on what you're comfortable with, how you think of the problem, and the type of codebase you're working on. I could see living in the debugger being more useful to me if I'm in some C++ codebase where every line potentially has implicit destructor calls or something.

profsummergig 1y ago

I want to master JS/React and Python debugging. Am an "advanced beginner" in both. What tools do you recommend?

steve_adams_86 1y ago
For JavaScript, you're actually able to debug fairly easily by default by adding a `debugger()` call in your code. Browsers will stop at that call, and start the debugger. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Another way (and probably a better idea) is creating a launch definition for VS Code in launch.json which attaches the IDE's debugger to Chrome. Here is an article describing how that works: https://profy.dev/article/debug-react-vscode https://profy.dev/article/debug-react-vscode Breakpoints are nice because they can't accidentally get shipped to production like debugger calls can. For Python I essentially do the same thing, minus involving Chrome. I run the entry point to my application from launch.json, and breakpoints in the IDE 'just work'. From there, you can experiment with how the debugger tools work, observe how state change as the application runs, etc. If you don't use VS Code, these conventions are similar in other IDEs as well.

Drew_ 1y ago

I'm looking around and I don't see anyone mentioning what I think is one of the biggest advantages of debugging: not having to recompile. Even assuming print statements and debuggers are equally effective (they're not), debuggers are better simply because they are faster. With print statements, you might need to recompile a dozen times before you find whatever it is you're looking for. Even with quick builds this is infuriating and a ton of wasted time.

norir 1y ago

Here is my circular argument against debuggers: if I learn to use a debugger, I will spend much, possibly most, of my time debugging. I'd rather learn how to write useful programs that don't have bugs. Most people believe this is impossible. The trouble of course is that there is always money to be made debugging. There is almost no incentive in industry to truly eliminate bugs and, indeed, I would argue that the incentives in the industry actively encourage bugs because they lead to lucrative support contracts and large dev teams that spend half their time chasing down bugs in a never-ending cycle. If a company actually shipped perfect software, how could they keep extracting more money from their customer?

deleted 1y ago
[deleted]
dieortin 1y ago
So you think that not knowing how to operate a debugger will exempt your code from having bugs, or you from having to debug them?

kakuri 1y ago

I loved Chrome's debugger for years, then build tools and React ruined debugging for me. Built code largely works with source maps, but it fails often enough, and in bizarre ways, that my workflow has simply gone back to console logs. React's frequent re-renders have also made breakpoints very unpleasant - I'd rather just look at the results of console logs. Are there ways I can learn to continue enjoying the debugger with TS+React? It is still occasionally useful and I'm glad its there, but I have reverted to defaulting to console logs.

dgb23 1y ago
Console logs in the browser have some unique advantages. You can assign the output to a variable, play with it etc. But yes, any code that is inside jsx generally sucks to debug with standard tooling. There are browser plugins that help you inspect the react ui tree though.
jesse__ 1y ago
Agreed, debugging tools for the browser are almost comically incapable, to the point of not even useful in most cases.
duderific 1y ago
I find myself doing a mix of both. Source maps are good enough most of the time, I haven't seen the bizarre failures you're seeing - maybe your bundling configuration needs some tweaking? But yes, the frequent re-renders are obnoxious. In those cases logging is generally better. Conditional breakpoints help alleviate the pain when there are frequent re-renders. Generally you can pinpoint a specific value that you're looking for and only pause when that condition is satisfied. Setting watch expressions helps a lot too.

mdavid626 1y ago

Nobody has time for that. Need time for prompting AI!

acureau 1y ago

I refuse to believe there are professional software developers who don't use debuggers. What are you all working on? How do you get your bearings in a new code-base? Do you read it like a book, and keep the whole thing in your mind? How do you specify all of the relevant state in your print statements? How do you verify your logic?

jalapenos 1y ago

Debuggers are great. I too have tried and failed to spread their use. But the reason is simple: they are always 100x harder to set up and keep working than just type a print statement and be done with it. Especially when you're in a typical situation where an app has a big convoluted docker based setup, and with umpteen packers & compilers & transpilers etc. This is why all software companies should have at least one person tasked with making sure there are working debuggers everywhere, and that everyone's been trained how to use them. There should also be some kind of automated testing that catches any failures in debugging tooling. But that effort's hard to link directly to shipped features, so if you started doing that, management would home in on that dev like a laser guided missile and task him to something with "business value", thereby wasting far more dev time and losing far more business value.