[cryptica]

Wow, the premise of this article is very wrong; it's deeply concerning that people are falling for this.

Those who make a lot of commits are not top performers, they are mostly engineers who are overly concerned with their 'optics'; they are engineers who are good at projecting themselves as 'top performers' but if you actually look at the results of their work a few years down the line, you will see that they are in fact low performers of the worst kind because they tend to add a lot of unnecessary complexity and technical debt because they don't think through things enough and just implement.

I'm absolutely shocked to learn that people are falling for this.

[atraac]

That's why there's 'most' in the title. Noone here assumes that more commits = better, but the article simply points out a correlation that MOST top performers, tend to have most git activity, and I see a similar thing in my professional experience. That doesn't mean I think that anyone with a lot of PR reviews or commits is better than other people...

[cryptica]

I disagree with the 'most' premise as well. Totally a false signal. In my view, the opposite is true. The top performers tend to commit less. People who are genuinely passionate about coding don't tend to put that much effort into the more pedantic aspects of the process; they're more focused on big ideas such as the structurally important parts of the architecture.

The developers who make a lot of commits are often more concerned with optics and they will argue for hours over unimportant tedium while sometimes missing the big very important ideas (the ones which will have real impact and flow-on effects for years to come). Basically they can't tell the distinction between what is important and what is not. They can't tell apart bureaucracy from value creation. Obsessive focus on commit size and other tedium is a key signal that someone doesn't know what is really important. They tend to be conventional thinkers (driven by peer pressure and peer approval) and their idea of productivity is distorted by false consensus (like the one this article attempts to instigate).

[daxfohl]

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).

[cryptica]

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.

[daxfohl]

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.