Hacker News Reader

Comment by gilbetron | Hacker News Reader

In my 40 years of professional software development, rarely have I seen such an uninformed post. And ignorant. Did I mention ignorant? I've been the "10x" developer, multiple times. And there certainly are poor performers and exceptional performers, but great teams makes great software, not great individuals. The analogies are numerous. You can look at a great (american) football team and see the Quarterback as the 10x programmer, but only if you ignore everyone else on the team that allows the QB to shine. Same with software. Software is a team sport, and if you don't get that, you should get that.

View on HN

> but great teams makes great software, not great individuals.

For a long time, OpenSSL, the standard encryption library used in everything from global banking systems to embedded devices, was built and maintained by two full-time engineers. It took the Heartbleed episode in 2014 to publicly acknowledge that potentially millions of technical projects stood (at least in part) on the backs of two nameless individuals along with the contributions of a small number of itinerant volunteers. While teamwork can be an important if fickle instrument, it tends to be a lightning rod for inviting too many cooks into the kitchen. What is often downplayed or goes unsaid in these commendations of teamwork is the place of an individual mind as the wellspring, the sine qua non, of great ideas and projects, including software. As is often the case, one person can solve an issue that has stumped thousands of others. Such individuals tend to work at a faster pace alone than the de facto committees that teams often become as they lose their agility, foresight, and focus. Unlike a football team, coding doesn't require a minimum number of people to achieve greatness. On the contrary, the opposite appears to be true - that there's a Dunbar's number for doing good work.

This example proves the exact opposite of the point you intended to make.

In what way?

https://openssl-library.org/post/2018-12-20-20years/

OpenSSL was made by a team, just read the history.

As per your own source:

> For the first 15 years, OpenSSL membership was mostly a small collection of individuals working on a part time basis and the membership fluctuated and changed through those years.

I never claimed OpenSSL was the product of a lone wolf or that teams have no place in coding. The essence of my point is that the invocation of "teamwork", often as a concept and practice distinct from the sum of its parts, obscures the significance of individual contributors who making great software. After all, code is a mirror of the mind. That one can distinguish between great and not-so-great code implies that one can distinguish between a great and not-so-great coder.

that's a bad analogy because a single football player cannot ever deliver a match entirely on his own. A single developer can absolutely deliver a full product on his own, it's not inherently a team sport whatsoever. You could make this claim about many things, "blacksmithing is a team sport!" Nonsense.

While a single talented developer can conceptually complete a whole project (of some kind) on their own, the concrete reality is that they're often being tasked to do so in the context of some time and resource bounded opportunity.

There's only so much code they write per unit time, only so many designs they can consider, only so many meetings they can attend, only so many demonstrations they can perform, only so many regressions they can debug, and really, only so many domains they can master.

Solo projects written by excellent engineers can be stunning works of craft. Many of us prefer to work that way, and accept the compromises of scale or time that are associated with it.

But most projects that you're familiar with need a team to produce them in a way that meets their real-world time and resource requirements. That's where the sports analogy comes in.

(And the same is true for the blacksmith and tailor. One master blacksmith or tailor might do stunning work, but they can't outfit and army or dress a court ball on their own. They need support, and that support often needs to be of a different level of mastery than themselves, if for no reason but to facilitate needed coordination and deference.)

Nobody is seriously claiming that all work on earth can be done by individuals. Obviously the master blacksmith that designs and leads the outfitting of the entire king's army with superior weaponry thanks to his personal leadership and expertise and care ... is not hammering every sword himself. But to call it a team sport is also highly misleading and to say that he hasn't been x10 is also just flat out wrong.

I think it is more like an NBA situation where a single superstar player can pull up the whole team just look Nuggets but still most likely thing is that the Cavs, Boston, or OCK wins the championship because those teams have a superstar player + a great team.

The big question is, can we find counterexamples to your model of reality in actual reality. And if we can easily do that, what does your apparent over-confidence about your statement say about you?

E.g. https://bellard.org/

To add to the insult, I'd challenge you to think of how many "great teams" of "normal" engineers, whatever any of these terms means, could pull off most of these projects in any amount of time.

Great professionals exist. They produce great work that is tough to reproduce. Your "helping" them does not mean they couldn't have done it without you.

Fabrice Bellard is not a counterexample you think he is. He is brilliant, but he doesn't stick around the projects he starts off. Someone has to triage bugs, setup CI, tag releases, keep the website running and all the other boring stuff.

I have contributed to one of the projects he originally authored, and my mundane contributions along with other volunteers not as brilliant as him have ensured the continued success of the project. I'm with gp: teams ship software, not individuals. Individuals may ship bug-fixes or largish features, but for software in the large, that is the realm of teams.

I've been there & done that: I've been the person that crunches and turns around impossible situations, and I have also spent months cleaning up after a 10x engineer who shipped a feature in "record time" that made the company lots of money but caused countless support calls and bugfixes for months on end until it stabilized. Many so-called 10x aren't, and rely a lot on a supporting cast of regulars to enable their "outstanding" work

My main frustration with the person I was responding to is that a lot of the terms we are arguing about are ill-defined, and yet he's arguing them with a lot of vigor.

There is also a time dimension to software. I have been on some occasions the only developer of pieces software that were tackling hairy problems that teams of "normal" developers would avoid. I always wanted to solve those problems in a way that would make everyone's life easier. To do that I had to spend a ton of deep focus time on modeling the problems effectively, and if I was successful, people who were put off by the problem space would come and contribute, because they found the model amenable. Or they thought it'd benefit them to be a part of a project that's picking up steam. A lot of these people would fix small issues here and there, but some of them actually donated a lot of focus and helped take these projects to new levels. The ones making the deep changes always cared deeply about the problem space, or brought a lot of knowledge from another subset of cs, and I wouldn't call them "normal". I think it is a disservice to the sacrifices they made to do what nobody else felt like doing and throw a blanket statement like "teams of mundane contributors do the really important work".

This is not a dig at "normal" devs - I have been the "normal" dev on many projects, but because of my experiences I try to give credit where credit is due.

I also detest the 10x thing exactly for the reasons you pointed out.

Great teams are made of great individuals. All of the policies and trust and rituals and expectations are based on the performance of the bottom quintile of the team. If the bottom quintile of the team is still the top quintile of "engineers applicable to this problem" you will have a radically different and improved culture and performance than if the bottom quintile of the team is a median engineer, and especially a bottom quintile of "engineers applicable to solving this problem".

A great quarterback with an otherwise average team is still going to beat an average quarterback with an otherwise average team every time. That a team is more than the sum of its parts just means that adding great team members can lead to more overall gain than their skill alone would imply as they boost those around them.

Even in the examples he gives, I'm sure Linus would be the first to admit that Linux has a lot of maintainers that have been essential for the project.

Reply on news.ycombinator.com