While I agree with almost everything you wrote - I found that original post awesome and there are many great lessons in it - I don't see what this has to do with my comment.
Also, I don't get what I seemingly did not realize (mostly helping clients with legacy code on legacy platforms in legacy organizations to improve their quality and teamwork), or why this is disrespectful...
> For most of my past clients, the skill / output of their programmers was not the bottleneck
Of course it was not. If you are antirez, you will mostly work with people on projects which, by nature, will involve talented programmers.
> Improving how the team works together / how work flows through the system probably has a bigger impact than raw programmer output
But only a person good enough can do that. This is catch-22
> Improving the quality of your software (minimizing defects and rework) will improve the output of everyone in the team
Yes, but it requires a really good dev to create and execute a plan to progressively enhance it. Instead of doing another from scratch which will also fail.
> I have heard of cases where removing the "top programmer" from a team made the whole team more productive
Yeah I heard of people stopping vegetables and living fine as well. And "top programmer" <=> "top dev". You can be very good at software and terrible with people.
My point is, the entire article is build on assumptions from the "top programmer" perspective.
All that goes to the water when your team is composed of:
- a senor waiting for retirement
- an apprentice fresh out of a community college
- a new dad who needs money and hates his job
- a legacy spaghetti code project coded by 3 different teams 10 years ago
- and no 10x programmer to be found
It will work. But say goodbye to best practices, and all the rules Antirez is stating.
Also, I don't get what I seemingly did not realize (mostly helping clients with legacy code on legacy platforms in legacy organizations to improve their quality and teamwork), or why this is disrespectful...