Back when I was in university, I was working as a software engineering student at Intel. At any given point, there was a real software engineer that was my responsible adult. It so happened that I was lucky to work with several engineers and got to experience different approaches to programming.
Very nice post, Amir!
I can definitely see how annoying I could be (sometimes) when I started out as a junior software engineer 
I guess that with experience, we all tend to become more humble, and wiser!
Nice article.
But I have trouble sharing it, isn’t there a twitter share button around, is it?
Drilling down into the difference between experienced debuggers and… less experienced ones, from my own introspection I think it comes down to having better-honed heuristics, more of them, and being able to apply them faster. So when I help less experienced debuggers, what I try to do, more and more, is force myself to slow down a bit and step through my stack of heuristics and talk about them aloud. Instead of taking control of the mouse and zooming around, I’ll say “okay, can you show me a bit of context: the code immediately around, the code that’s calling this, the code that’s being called.” I’ll point to the screen and run through what the code is doing “taking that, calling this, extracting value foo, mapping over bar.”
I’ll go through my and their expectation of what it should do, match those together, and then match that to the code: “so, we want to bind that modal to that row, right?” I find that starting by stating what I think is the precise goal is better than asking what they think it should do, because I can establish scope and level-of-detail and avoid having to drill down (“What do we want to do?” “Well, for it to work.” That’s too little level-of-detail, so: “Okay, but what exactly do we want?” [and around here they skip through their assumptions] “Well, I want this data but it’s not there, I think it’s a scoping error but I can’t see it.” That’s too much level-of-detail, and perhaps wrong, and now I have to backtrack them and it’s just confusing.) And if my expectation is not their expectation, we can start by discussing that.
In all that, I try to expose my thought process and teach by showing exactly what heuristics I’m using and how I’m exploring the problem. And after a few times, they usually start doing some themselves, and when I’ll come over they’ll start by running through the process without prompting, which considerably hastens the session and allows us to be more effective together at debugging.