How do YOU debug?
Posted by stayoungodancing@reddit | ExperiencedDevs | View on Reddit | 41 comments
Generally curious about others’ approaches to it, either favorite tools, processes, checklists, etc.
I recently took a look at building a plugin to integrate two frameworks but a core issue comes down to something funky with the internals of one of them. Tried logs, step-throughs, other investigations, but figured it’d be better to formalize it.
So…how do YOU debug?
sebf@reddit
Data::Printer, a "colored & full-featured pretty print of data structures and objects".
nasanu@reddit
When I was in backend it was always using the vs studio step through debugger. Now on the FE it's just a matter of putting console logs all over the place.
Pretty much all bugs are an incorrect value somewhere. So go to the component where the bug is happening and log out the value related... Go from there.
ultraDross@reddit
Can you not use a debugger on the FE? I'm a BE entirely so really don't know
nasanu@reddit
You can do a form of it in chrome using breakpoints.. Never seen anyone bother with it to be honest. I just find it faster to go in and type console.log(variable)..
bstamour@reddit
Mostly just gdb: setting breakpoints and stepping through things. Occasionally setting up watch variables etc. I'm pretty simple.
BaldingWhiteMale@reddit
I’m hoping to write a book about it, here’s my blog post series. I hope to have part 2 out soon
ExperiencedDevs-ModTeam@reddit
Rule 8: No Surveys/Advertisements
If you think this shouldn't apply to you, get approval from moderators first.
stayoungodancing@reddit (OP)
Awesome — you should post this for more visibility in r/programming. I’ll have to give it a read this weekend.
Sensitive-Ear-3896@reddit
Look at the stack trace, put a break point there and look at different variables/arguments till I find one with a value I don't inspect
im-ba@reddit
Yeah, why is this even a question in this sub 😂
Far_Archer_4234@reddit
I push F5,F9,F10, and F11 repeatedly until the bug magically appears.
stayoungodancing@reddit (OP)
No Alt-F4 in the mix?
Far_Archer_4234@reddit
That's reserved for when I hear someone's footsteps nearby and I need to close reddit quickly.
Sheldor5@reddit
excuse me but what the fuck? what does that even mean?
stayoungodancing@reddit (OP)
It’s exactly what it says. It’s something similar to a build tool. Not sure what’s more confusing about it than writing about debugging.
Sheldor5@reddit
the fact that a plugin integrates different frameworks
you write a plugin for a framework
you don't integrate frameworks into a plugin
where does the plugin even run so that it integrates other frameworks?
you run a single framework and the framework defines how it loads/runs plugins
either you have a flaw in your post or you are doing something severely wrong
marssaxman@reddit
Logging, almost exclusively. Think about what might have gone wrong, read the code and formulate a hypothesis; look in the trace for evidence; if it's not there, add more logging to the code and run it again. Repeat, narrowing in, until you find whatever it was you didn't understand about your code.
I used interactive debuggers earlier in my career, and once even wrote one (for an IDE you've never heard of), but after working on enough projects where debuggers were not an option, and logging was the only way forward, I learned to love it and now it's about all I do.
stayoungodancing@reddit (OP)
That’s really cool. A large part of what I’ve been reading in this thread really comes down to the basics of logging so much more than I expect. I was thinking there’s something extra I’m missing.
How did you build one by the way — I’d love to hear more.
almarcTheSun@reddit
The simplest and fastest logging I can do first. If nothing out of the ordinary I can notice (or the amount of data to log would be too much), breakpoints and examining all the data and logic step-by-step. If that fails, uh.. prostitution?
james__jam@reddit
Logs + trace. Recreate the issue with tests
AnAwkwardSemicolon@reddit
Narrowing down to the interesting spots using a mix of logging & breakpoints. I'll use logging first to get a high level idea what's going on, break in interesting parts, narrow down with further logging & breakpoints. Once I get a good handle on what the flow is, I'll start setting up some conditional breakpoints and stepping through the problem areas. Search, refine, search, refine, and so on.
Only-Fisherman5788@reddit
the step most people skip: write down what "working" looks like before you start reading logs. half the debugging i've wasted time on turned out to be systems doing what they were told, just not what i'd assumed. if you can state the expected outcome in one sentence before touching anything, the trace tells you a lot faster where reality diverged.
for plugin-integrating two frameworks specifically, i'd trace what each framework thinks the input contract is at the handoff point. most cross-framework bugs live in that seam.
marssaxman@reddit
In an ideal sense one can say that all bugs are really about your own expectations, and exist in your own mind rather than the code: the code, after all, does exactly what it was built to do; the bug is the fact that you expected it to do something else.
supercoach@reddit
I used to use a lot of breakpoints, but these days I tend to just make sure that debug level logging is good enough to identify bugs. I prefer to have to remove logs than add them.
evincarofautumn@reddit
If I control the codebase: make the types better until the bug is impossible
If I don’t: obtain logs by any means necessary, then bisect
publicclassobject@reddit
Idk if I have debugged anything manually since Claude code came out
boring_pants@reddit
I don't have a formalized checklist, and it depends hugely on the problem and the environment. Debugging, reading logs, trying to reproduce it locally, reading the source code, usually a mix of all of these.
Most-Bookkeeper-950@reddit
printf and sometimes gdb
ConstructionBoth6461@reddit
creaturefeature16@reddit
CodelinesNL@reddit
I try to formulate a hypothesis on what could be going wrong, and then try to validate that hypothesis. That's basically the code of any kind of problem solving. If the hypothesis is wrong, I formulate a new one. Until I find the root cause of the problem.
HOW I do that depends on the problem. Is a service not deploying which deployed before, is it not deploying the first time, or is there some kind of subtle bug in a UI? Completely different situations and there's no one-size-fits-all solution.
Nezrann@reddit
Depends on what you are debugging - but generally I'm pretty old-fashioned and use breakpoints to step through lmao.
But for log ingest I usually have some kind of LLM parsing during testing.
stayoungodancing@reddit (OP)
Yeah I feel that. For me, step-throughs generally work best when it’s on the immediate system, but for compiled/transpiled things like JS node modules, it gets to be quite unruly the deeper it goes…
Nezrann@reddit
I know most people are kind of put off by AI, as am I, but setting up a feedback loop where an agent is monitoring logs as you run as part of a pipeline is actually incredibly useful.
I wouldn't go as far as some people where you have an agent watching for bugs, an agent implementing a fix, and then an agent reviewing the MR, but if your company has access to the frontier models I would definitely look into some kind of MCP-based system to ingest logs for you.
disposepriority@reddit
Could you explain what an agent watching for logs achieves, compared to having standard alerts on error logs, logger names, and whatever other criteria you want on the log fields/tags?
Nezrann@reddit
Yeah, it's a good question.
It removes the toil of having to do RCA on whatever feature/fix caused the bug.
Just having an error doesn't tell you why that error happened. I manage the pipelines for multiple teams, and their needs are different; one team uses an agent to monitor fully during the build stage, and then, when errors are thrown, it tries to do RCA and write basically a bug draft in Jira.
Another team uses it to do self-healing on build failures and low-impact errors. Think type errors, null errors, stuff that is just syntactically wrong or breaking changes caused by small things. This is flagged post-build with an explanation and MR of the fix after it gets it back to a working state.
c1rclez@reddit
On the IBM i, there is a debugging strategy that is really incredible if you run into an issue in production and logs don’t cut it. Not sure if this is possible on other systems - but you can do what’s called a service entry breakpoint or service job debug like I call it.
You can take an actively running job (e.g. process) then do a command called start service job. You can take over a running process, then jump into a debugger on the system once you’ve begun servicing the job. This effectively allows you to take over and debug a live process remotely without ending or restarting it.
AdministrativeHost15@reddit
I took a C++ a long time ago with an instructor who said he didn't use any debugger; just pure logic. Of course people were hardcore back in those days.
droi86@reddit
Java/kotlin and android with intellij debugger, it works pretty well, for race conditions I use logs
hurricaneseason@reddit
Output (logs, stacktrace, console print statements, whatever), breakpoints, and a debugger. Step through, make runtime adjustments, experiment and write down results.
ccb621@reddit
In production: look at logs and traces.
Local?