[macromaniac]

You can use the debugger on low level api calls to get pretty much anywhere in the codebase. If you want to find whats changing a label to "foo" you can hook into every set_Text call and put a conditional breakpoint on all label changes to break on "foo", then just go up the callstack to find the logic. This strategy works on network interfaces and file interfaces as well. I abused this on our 2M+ SLOC legacy codebase and it has saved me many hours.

Also use version control to identify the most commonly edited files in the project. These are usually the files that are doing all the work (80/20 rule) and you likely need to know of them.

git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10

[MaulingMonkey]

A variation on this is instrumenting an codebase with profiler flamegraphs, which I find a lot more straightforward to drill in/out with than stepping through functions one at a time.

I normally use manual profiling libraries - I need an excuse to try out orbit, which uses automatic instrumentation for similar purpouses: https://www.youtube.com/watch?v=L8w0qI8qzvM

A little lower fidelity in some ways, but faster iteration than what I've been doing in others...

[to3m]

This isn’t abuse... it’s exactly how you’re supposed to use a debugger.

[jstanley]

I suppose the difference is you'd normally use a debugger to find out why the code isn't doing what it's supposed to, rather than using it to find out what the code is supposed to be doing in the first place.

I don't consider it abuse either, though.

[_dps]

Agreed, and riffing on that a bit — I find the name "debugger" is actually troublesome when teaching newcomers (I work with kids of various ages).

I see the debugger much more like a "REPL for a compiled language" than a "bug removal tool". I try to teach people to think of it as an interactive inspection tool, not as (merely) a thing to fix broken programs.

[ZenoArrow]

"REPL for a compiled language", or "Binary REPL", I like that.

Besides that, it's times like these when I realise how useful IDEs are. Instead of needing to use grep (or something similar), I can simply right click on a variable and choose 'Find all references' (this is in VS, but I'm sure many of the leading IDEs will have this feature). When I use the command line it's to save myself time.

[caseymarquis]

You can save even more time by pressing Shift + F12. CTRL + - goes really well with it (step back to previous code location). I'm a bit biased toward hotkeys as I'm using the fantastic vim extension, VSVim, so I barely ever have to take my hands off the keyboard. VS really is a great tool. Adding the Docker integration for dotnet core has really opened up deployment options for what was once a Windows only product for deploying to Windows only. It's still essentially a Windows only product (I've heard the Mac version isn't comparable), but you can deploy and debug in containers. Dotnet core is at v2 now, and seems stable enough to actually use in production (finally!). On a tangent here, but the point is it's a good time to be working with dotnet.

[shortoncash]

Appreciate the handy tip you tacked on at the end there. Thanks!