Be Comfortable Not Knowing

Somewhat orthogonal to the previous section is the idea that you need to be comfortable not knowing implementation details, in particular when you are troubleshooting.

Having the ability to read and examine all third party code does not mean that you should actually do it. If you choose your libraries carefully, which you definitely should do, when bugs arise, chances are they are bugs in your code, not in third party libraries[1]. So the temptation to “let me go see what they are doing over there” may lead to much lost time, similar to the situation you have with using the debugger mindlessly.

Being comfortable with not knowing implementation details is symmetric to the concept of abstraction. We take a bunch of code, give it a name, parametrize it, and going forward, use only the name and parameters, not concerning ourselves with the internals anymore. Abstraction is the single most powerful tool in the programmers toolbox, it’s the reason why we got beyond coding in assembly, and can put together a web app in a matter of minutes now.

When troubleshooting, instead of doubting every local and third party implementation, and verifying their code by hand just because you can and feel comfortable doing so, use mental modelling, build a hypothesis, and then derisk it. This will allow you to save much time, by reading the riskiest, most likely problematic code first.

Psychologically, being comfortable not knowing is a strong position to be in, because it is essentially the belief that that when necessary, you can crack open the code. It allows you to troubleshoot precisely, instead of using the scattershot approach.

Next: Differentiate Proximate and Root Causes ⇒

[1] Though as you get better and better at building software, and the frequency of your bugs reduces, it is inevitable that correspondingly the probability that when you are facing a bug, it's a bug in third party code, increases.