[noisy_boy]

But what about navigating the code by the call stack? I didn't know that GitHub has a way to do that. Or maybe I'm probably coming across as being dumb enough to be talking about still trying to have a mental model of what calls what.

[r3trohack3r]

Personally, I use a debug agent for that.

I've never used breakpoint debugging, was always a printf debugger. And now an agent can do that loop for me.

Prompt is usually something along the lines of:

>I would expect the behavior of this to be [X] - instead I'm observing [Y]

And the agent will form hypothesis, place printf statements, compile, and scrape logs on loop - each loop ruling out hypothesis or narrowing down what portion of the code is responsible for the unexpected behavior.

It has been able to pin-point the exact line(s) of code responsible every time I've reached for it so far.

[jaggederest]

For what it's worth, generally speaking I read all of the code and keep it in my brain - I have some uncommon assets in that regard like a high reading speed and great memory. `git grep` is the other tool I use often.

I rarely find that the call stack is the limiting factor, to me, and I suppose I do something similar to what you're talking about but just in my head - I know where a file is referenced via imports, what a function does, and what the flow of control is like.