I would phrase it slightly differently. I would phrase it as "able to consider multiple levels of abstraction simultaneously".
When I see code execute I almost unconsciously understand what the code is doing at a procedural and sometimes assembly level, as well as what it is doing at an architectural level. It's the skill you need if you are going to work on intentionally undocumented code. It means when I encounter a bug, I know what construct I'm looking for: "ah, yes, there it is." When I architect something it is as simple as it needs to be to do the right thing and I don't have to put any extra effort in to have it communicate meaning through structure.
My challenge is to provide guide posts to other programmers coming later to help them swap between those levels, because I don't need them myself, or do what I do now and work with other people who's minds also work this way.
If I come back to code I wrote five years ago I still grasp exactly what is going on, and the chances are pretty good I remember the exact code.
I'm still not one of the greatest programmers I know, though. Those can both simultaneously consider multiple levels of abstraction and leave that aside to consider tiny pieces. I can sit down and carve away marble to leave a program; they can sit down and merge tiny chips of marble into something that looks exactly like I would have created out of whole cloth.
For them, unit testing is easy. For me it is challenging and a necessary chore.
On the other hand, at least 40% of my job doesn't benefit from this, mostly because of missing tools. Moving into CMake was fantastic, because finally I could apply the same approach to release engineering I applied to writing code. There are definitely roles for which this is massive overkill, and lots of people who work this way spend all their time building tools to support it rather than producing software used by consumers.
When I see code execute I almost unconsciously understand what the code is doing at a procedural and sometimes assembly level, as well as what it is doing at an architectural level. It's the skill you need if you are going to work on intentionally undocumented code. It means when I encounter a bug, I know what construct I'm looking for: "ah, yes, there it is." When I architect something it is as simple as it needs to be to do the right thing and I don't have to put any extra effort in to have it communicate meaning through structure. My challenge is to provide guide posts to other programmers coming later to help them swap between those levels, because I don't need them myself, or do what I do now and work with other people who's minds also work this way. If I come back to code I wrote five years ago I still grasp exactly what is going on, and the chances are pretty good I remember the exact code.
I'm still not one of the greatest programmers I know, though. Those can both simultaneously consider multiple levels of abstraction and leave that aside to consider tiny pieces. I can sit down and carve away marble to leave a program; they can sit down and merge tiny chips of marble into something that looks exactly like I would have created out of whole cloth.
For them, unit testing is easy. For me it is challenging and a necessary chore.
On the other hand, at least 40% of my job doesn't benefit from this, mostly because of missing tools. Moving into CMake was fantastic, because finally I could apply the same approach to release engineering I applied to writing code. There are definitely roles for which this is massive overkill, and lots of people who work this way spend all their time building tools to support it rather than producing software used by consumers.