Comment by tonyarkles

From a software perspective at least, my rule has always been "know that what you're looking at is an abstraction, and know that there's details underneath". Most of the time you can get by using the abstraction (e.g. walking up and down the stairs), but once in a while you're going to have to peel the abstraction back and look a bit deeper to understand what's going on (e.g. replacing a cracked stringer).

I personally took this to an extreme... I learned to program at quite a young age, and dual-majored in EE and CS specifically so that I could understand the systems that ran my software. I'm happy writing Python, but if I need to dig into the CPython run-time to figure out a bug I'm ok with that. And if I need to run tcpdump to figure out why a TCP stream is stalling, I'm good with that. The abstractions are beautiful and work 99.9% of the time, but if you don't know how the abstractions are built, you're going to have a hard time figuring out what's wrong when they break down.