| ▲ | old_bayes 5 days ago |
| It may sound obvious to folks who already use a debugger, but in my experience a decent chunk of people don't use them because they just don't know about them. Spread the good word! |
|
| ▲ | makeitdouble 5 days ago | parent | next [-] |
| Depending on the language or setup debuggers can be really crappy. I think people here would just flee away and go find a better fitting stack, but for more pragmatic workers they'll just learn to debug with the other tools (REPL, structured logging, APMs etc.) |
| |
| ▲ | adgjlsfhk1 4 days ago | parent [-] | | if your repl is good enough and the bug isn't a crash, repl based debugging can be excellent (especially if the language has good introspection capabilities) |
|
|
| ▲ | giveita 5 days ago | parent | prev | next [-] |
| I had a think about where I first learned to use a debugger. The combo of M$ making it easy for .NET and VB6 and working professionally and learning from others was key. Surprised it is less popular. Tests have made it less necessary perhaps BUT debugging a unit test is a killer move. You quickly get to the breakpoint and can tweak the scenario. |
| |
| ▲ | NitpickLawyer 5 days ago | parent | next [-] | | > I had a think about where I first learned to use a debugger Is this not taught anymore? I started on borland C (the blue one, dos interface) and debugging was in the curriculum, 25+ years ago. Then moving to visual studio felt natural with the same concepts, even the same shortcuts mostly. | | |
| ▲ | giveita 5 days ago | parent [-] | | Nothing useful I do in my job was taught by another person in a classroom. | | |
| |
| ▲ | robertfw 4 days ago | parent | prev [-] | | my development workflow with python often boils down to repeatedly running `pytest --ff --pdb -x`... - run my tests, running any previous failures first
- drop into the debugger when a test fails (or of course, hits a breakpoint)
- end the test run after the first failure use debugger to figure out what went wrong, fix it, wash, rinse, repeat |
|
|
| ▲ | nchmy 5 days ago | parent | prev | next [-] |
| yeah, tons dont know they exist. But there's also a lot of people - new and veteran - who are just allergic to them, for various reasons. Setting up a debugger is the very first thing i do when i start working with a new language, and always use it to explore the code on new projects. |
| |
| ▲ | DrSiemer 5 days ago | parent | next [-] | | These days I'll just dump all relevant code into an LLM and have it explained to me instantly. Being able to ask questions about the parts that are unclear (or just plain wrong) is so much easier than trying to cram the entire thing into my brain RAM. In my experience it actually helps me learn faster too, since I rarely get stumped on random gotcha's anymore. | | |
| ▲ | nchmy 4 days ago | parent [-] | | Nah, i use debuggers all the time despite also using LLM agent all the time. They are great, but limited and often just go into a perpetual loop of not being able to debug something. I toss in some breakpoints and figure out exactly what is going on. |
| |
| ▲ | giveita 5 days ago | parent | prev [-] | | With VSCode it's often a 10 minute job to set up. We are spoiled! Back in the VS days using a Microsoft stack it was just there. Click to add breakpoint then F5. | | |
| ▲ | nchmy 4 days ago | parent | next [-] | | when i first started programming, with php, it took me literally weeks to figure out how to get xdebug set up. (pro tip: just use DDEV - it makes it all simple). Not a second of that was a waste because xdebug (like all debuggers) is just that amazing. | |
| ▲ | 5 days ago | parent | prev [-] | | [deleted] |
|
|
|
| ▲ | gonzo41 5 days ago | parent | prev [-] |
| This also applies to testing. So much legacy code out there that's untested. |
