My experience is the same as the author's. If one defines top performer as you did, those who are "more focused on big ideas such as the structurally important parts of the architecture", and you run the numbers, you'll find most of these people will also be outliers in commit count.
This is true in just about every team I've worked in. And it makes sense too. The person who best understands the design would be the fastest to implement it. They can both do the design and implement 2/3 of it in the time it takes the other engineer to grok the design and fumble through the other third.
Frankly, I think the role of "design architect" is make-believe. A project only has so much "design work" to be done, so the top dev isn't going to be sitting around twiddling their thumbs through the implementation phase. Even people like Jeff Dean still write a ton of code, to my understanding.
What you describe in the second paragraph sounds like something that would occur only in a dysfunctional workplace with dysfunctional manager and dysfunctional colleagues. (And even then I have a hard time seeing it happen for long -- someone is going to get annoyed doing all those code reviews of pointless changes and put a stop to it).
If you have to work on a very complex project, you need to plan the architecture at a high level or else it will be a disaster. I've seen the code-as-you-go approach fail miserably over and over.
Try coding a decentralized P2P system where multiple instances of the same code running on many different kinds of machines communicates with itself in a scalable and DoS-resistant way. There is no way anyone can implement this properly without careful architecture planning. You would never get it right the first time unless you plan and analyze all the main use cases carefully.
Or try to design a distributed pub/sub system or message queue with automatic sharding across the cluster. Also needs a lot of planning. You can't just code along and hope to get it right.
Yep, I agree completely. I'm just saying that in my experience, the person who leads that planning also does a whole lot of the implementation. I've been around the business 20 years from startups to enterprise to FAANG, from embedded life support devices to dev tooling to cloud services, and I can't recall an instance where there was a dedicated "architect" role that didn't dig pretty heavily into the codebase as well.
This is true in just about every team I've worked in. And it makes sense too. The person who best understands the design would be the fastest to implement it. They can both do the design and implement 2/3 of it in the time it takes the other engineer to grok the design and fumble through the other third.
Frankly, I think the role of "design architect" is make-believe. A project only has so much "design work" to be done, so the top dev isn't going to be sitting around twiddling their thumbs through the implementation phase. Even people like Jeff Dean still write a ton of code, to my understanding.
What you describe in the second paragraph sounds like something that would occur only in a dysfunctional workplace with dysfunctional manager and dysfunctional colleagues. (And even then I have a hard time seeing it happen for long -- someone is going to get annoyed doing all those code reviews of pointless changes and put a stop to it).