In my experience, this is a common characteristic of the 10x programmer. It is not about frameworks, it is not about patterns; both things help, but it is really about to be able to run the system in your head.
IMO, the hope is that tooling can somehow obviate the need for 10x programmers (and their annoying salary requirements) by putting enough guard rails in place. But the reality is additional layers of abstraction all come at a cost (computational/cognitive), systems thinking is still required (the core trait of effective programmers), and, most importantly, great programs aren't made by distilling current best practices into tools.
As much as the industry tries, it can't replicate hard-won experience.
Once you have that understanding, actually fixing the problem is straightforward.
I think this extends to users as well. Well before I knew how to program I'd approach new software as if I'd designed it myself, unconsciously putting myself in the mind of the designer. The applications I struggled to learn were those where I couldn't build a mental model of what it was doing and why.
Hell, even when I'm not familiar I can guess what's happening based on past experience.
It's some sort of spatial ability, like navigating a map (though I recently found out I'm terrible at visualizing and almost completely lack a 'mind's eye'). I also find I rarely get lost in computer games and very rapidly learn FPS maps.
Maybe's it's one of those weird skills you don't even realise some of the population lack.
Personally I've always thought using traces are a massive crutch that are too expensive in cost vs benefit ratio, I don't get the point. Far too many extra lines of code for too little gain.
You run idealized versions of systems in your head.
Definitely true but running idealized approximations of systems [1] are also sufficient, at least in my experience, to get a rough idea of where a bug might be a majority of the time.
[1] We're basically describing https://en.wikipedia.org/wiki/Systems_modeling
Yes, they're idealised versions, but that still has value. The point at which the idealised model doesn't match up with reality is the point at which further investigation is required.
It's an effective way of filtering out the parts of the system that you already have a reasonable grasp on so that you can focus on parts that you don't.
On a more general point, almost all models are idealised approximations. The whole idea with modelling a system is to abstract away the rough edges by encapsulating complex behaviour in discrete groups. By working with these simplified models, the idea is that you gain a better intuition of the activity found within a system.
In short, the whole purpose of models is to guide intuition.
i.e. bugs that were due to compiler/bare metal/etc. problems. I remember a bug in old-skool asp that would only surface due to some weird code condition, a bug with an IMAP server we made used by Outlook that was caused by them using an int16 to store ids, and a race condition bug.
I've worked almost entirely in web dev with a mix or enterprise, b2b and b2c systems, with some of those having millions of users, some of them being intensive SQL.
It's affected my design philosophy too, I always try to design software such that I could draw it as a series of discrete components with input/output arrows between them (and, of course, the assumption that could theoretically zoom in to a component to see whats inside of it)
Of course, you need to learn enough about the system to be able to do it, I am glad you wait for that.
> "Thinking if I hit that key what should happen if I hit that key..."
The answer to what should happen is not rooted in thinking about the code. Programming is taking meaningful thoughts and turning them into thoughtless instructions that can be executed by a machine. And that is hard!
We take it for granted now, but something as basic as the idea to use on- and off-switches (which is what bits are) as representations of numbers, let alone strings of letters, is a ridiculous leap of thought. Then we built more complex software on top of that more similar ridiculous leaps of thought. None of those leaps came directly from the code itself.
Similar to plotting a trip to the grocery. You don't think of the effort your body is doing to stay balanced. Nor of reading labels Yet you probably have a decent idea how long the trip will take.
You can relatively accurately predict that when you press "OK", the dialog will close. You can maybe assume and envision a future where calling "closeDialogBox(box)" will close the dialog box. Maybe the lines in it that which simply call "box->close()" and return "STATUS_OK" can be assumed to do what you think it will do. The underlying machine code, too. The CPU, sure.
In the end the whole system is beyond your control and is subject to random input like cosmic rays flipping bits, power outages, leaking caps. Before that you have the operating system, the compiler, the overall codebase, perhaps more likely sources of mental model mismatches. I certainly wouldn't draw the line of "accurate simulation" at the source code base.
IMO one of our strengths as humans is that we can easily create these simplified models based on rough probabilities founded on previous experience, "gut feelings" and weighing risks and go great lengths without accurate simulation.
That is, we are primarily discussing how people use that phrase in informal communication. And the you'd be surprised just how far many can take the simulations in their head.
To think, you have to write. If you're thinking without writing, you only think you're thinking. - Leslie Lamport