Exactly. All the arguments that have the word "productivity" are probably off. It's not about "productivity" as in "which programmer produces more code" or even "more programs" or whatever. It's about the person being able to recognize what matters, on one side, versus those that can even make such decisions to finally cause the doom of the project. I have such experiences, and some huge failures can really be caused by the disconnection on the lower levels (programmers) and the managers who can't recognize what's going on (accepting the wrong arguments of these doom-causing programmers). Some of stories like that are also in the book "In Search Of Stupidity"
The author calls them "marketing disasters" but I recognized several purely technical disastrous decisions there, like "let's rewrite the product from scratch, but ignore the way the users use the product (to print) and ignore the printer drivers existing in the earlier version." Then wonder why nobody wants to use the new version, and the competition takes over. These things are eternal in tech.
On another side, if we claim that as soon somebody is making any design decisions is not "just a programmer" then sure, all the programmers are "good enough."
The way I understand it, antirez probably considers himself a programmer and for what he produced he really made most of the design decisions himself?
But if you factor in the design decisions: they can make the product great or kill it. What's the difference then between the best and the worst? Much more than 10 times, if we compare the survival vs. the death, it's even infinite.
My favourite programming anecdote[0]. How many lines of code did you produce today? -2000. Indeed it's not about lines of code. A 10x programmer might produce a solution that would take a team of three 1x programmers twice as long to implement and is twice as 'good' (fast, compact, stable, elegant, maintainable, etc).
It's interesting that this anecdote is from Apple, as Steve Jobs was a famous proponent of the 10x or 20x programmer and hiring only the best available. In contrast at Microsoft Charles Simonyi took completely the opposite approach, with a highly stratified organizational structure dependent on hiring large numbers of drone programmers[1] and reducing programming tasks down to easily implementable essentially rote modules.
I don't think it's a matter of one model or the other 'winning' though as the Simonyi strategy certainly seemed to work for MS.
Thanks for a hint! Reading [1], there the "programmer actually making decisions" was called a "metaprogrammer":
"the metaprogrammer was the designer, decision maker, and communication controller in a software development group.... individual progammers were allowed to make no design decisions about the project. All they did was write the code as described by the metaprogrammer."
In that case, the differences between programmers can't be too big and surely matter little. It's the "metaprogrammers" that are important and influence the faith of the project. And those that Jobs praised were, by that definition, surely "metaprogrammers" who also did the tasks of "programmers."
The meta programmer model is very different though. How the programmers implement their code is not addressed. Fast? Compact? Memory efficient? Maintainable? Doesn't matter, perhaps as long as the code meets some pre-determined criteria.
In the metaprogrammer model, as far as I understand, the programmers don't even decide "how the programmers implement their code," that's what the metaprogrammer decides: if what they produced is acceptable and according to his exact instructions or is to be rejected. So they don't decide: "Fast? Compact? Memory efficient? Maintainable?" they do it exactly the way the metaprogrammer said.
What I wanted to point is that as soon as we define that the programmer doesn't decide, we have a system where the "quality" of the programmer doesn't matter much as the programmers by that definition do more-or-less a mechanical task.
However that "metaprogrammer" term is probably not so common.
How are metaprogrammers called otherwise? What are their job titles?
> However that "metaprogrammer" term is probably not so common. How are metaprogrammers called otherwise? What are their job titles?
In places that use this approach the people filling that role are sometimes called Architects, Principal Engineers, and sometimes Product Managers or Technical Product Managers.
http://www.insearchofstupidity.com/
The author calls them "marketing disasters" but I recognized several purely technical disastrous decisions there, like "let's rewrite the product from scratch, but ignore the way the users use the product (to print) and ignore the printer drivers existing in the earlier version." Then wonder why nobody wants to use the new version, and the competition takes over. These things are eternal in tech.
On another side, if we claim that as soon somebody is making any design decisions is not "just a programmer" then sure, all the programmers are "good enough."
The way I understand it, antirez probably considers himself a programmer and for what he produced he really made most of the design decisions himself?
But if you factor in the design decisions: they can make the product great or kill it. What's the difference then between the best and the worst? Much more than 10 times, if we compare the survival vs. the death, it's even infinite.