For a long time my debugging process stopped at the boundary of my own code. If the problem seemed to be in the framework, I'd search for the error message, read some issues, and try things. Opening the source felt like something other people did.
That was a bad instinct, and dropping it made me considerably more effective.
The realisation
Two things changed my mind.
The first was noticing how often the answer was *right there*. A confusing error message usually has exactly one throw site, and the surrounding twenty lines explain the condition better than any blog post. Finding it takes about a minute.
The second was realising how ordinary most framework code is. There's more indirection and more edge-case handling than in application code, but it's the same language and the same patterns. The mystique is unearned.
How to actually do it
The trick is to navigate, not to read. Nobody reads a framework.
- Start from the error string. Grep your
node_modulesfor it. Not the interpolated version — the static part. - Read the stack trace properly. Past your own frames there are usually two or three framework frames that tell you which subsystem you're in.
- Use your editor's go-to-definition into `node_modules`. It works, and it beats browsing the repo on GitHub because you're looking at the version you actually have installed.
- Check the tests. Framework test suites are the best documentation for edge-case behaviour, because they encode the intended answer to exactly the question you're asking.
- Read the source for your installed version. Behaviour changes, and the
mainbranch on GitHub may not be what's running.
What you get beyond the fix
The immediate payoff is solving the bug. The compounding one is a mental model that makes the next problem easier: after a few of these you have a rough map of how the thing works, and your guesses get much better.
It also recalibrates how you read documentation. Docs describe intended use. Source describes actual behaviour. Most genuinely confusing bugs live in the gap.
The obvious caveat
This is a debugging technique, not an architecture strategy. Relying on internals in production code is how you get broken by a patch release. Understand the internals; depend on the public API.