
Software Projects and Heroes: Lessons Learned from GitHub Projects - gmolau
https://arxiv.org/abs/1904.09954
======
benkuhn
Everyone who's interpreting this in the context of full-time work / the
traditional notion of "10x programmer" (i.e. ~every toplevel commenter) should
read the abstract:

> A "hero" project is one where 80% or more of the contributions are made by
> the 20% of the developers... We identify the heroes developer communities in
> 1100+ _open source GitHub projects._

(emphasis mine)

Of course nearly every Github project is going to have heroes--we call them
"maintainers." This study is totally unsurprising and totally non-
generalizable to professional teams working on proprietary software.

The use of the term "heroes" in the abstract is massively misleading and
tendentious, IMO.

~~~
dang
Ok, we've added "Github" to the title above.

Edit: and maybe we can make the phrasing a bit less tendentious. Bad sign when
paper titles need debaiting, but that's the trend.

~~~
gmolau
This was my first submission here, but is it really helpful to change the
title of a published research paper? Just because some commenters didn't like
it, and at the cost of this discussion now being harder to find when people
google the paper?

~~~
dang
The site guidelines say: "Please use the original title, unless it is
misleading or linkbait"
([https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)).
Being the title of a published research paper doesn't immunize against those
things, unfortunately, and based on the comments posted here, that title was
arguably both.

We know from long experience why it's helpful to make such a change: if we
don't, people will keep complaining about and bickering about the title.
Editing it is the only way to soothe the fever.
[https://hn.algolia.com/?query=by:dang%20title%20fever&sort=b...](https://hn.algolia.com/?query=by:dang%20title%20fever&sort=byDate&dateRange=all&type=comment&storyText=false&prefix=false&page=0)

This thread still comes up if I google the paper's original title, and is the
#1 result if I google "software project heroes".

p.s. Welcome to HN!

~~~
gmolau
Not trying to start an argument over words, but that seems a bit unfair to the
authors. Their title promised they would analyze 1100 projects, and that is
what they did. Being accused of misleading or even linkbaiting their readers
by (let's be honest) armchair scientists imho doesn't reflect well on this
platform.

~~~
dang
The number of projects analyzed was not the issue, though "1100+" does add to
the impression of the title being hotrodded a bit. The criticisms HN users
made of the title, that I heard, were first that the paper looks only at open-
source projects on Github, which is not representative of software projects in
general, while the title refers to software projects in general. Second, "Why
X needs Y" (where Y is a sensational word like "heroes") is a linkbait trope,
easily recognized by anyone who spends time around internet articles, as well
as an overselling of the finding. An analysis of commit rates on Github does
not explain _why_ , it shows _that_ —which is great, and which we edited the
title to represent more clearly.

On HN, an article does not get a pass to use these tricks just because it's a
paper on Arxiv. The internet game is to inflate titles to oversell the body,
and the HN game is to rejig them back to scale, so there isn't a disappointing
delta between what the title promises and the body delivers. We did that in
two ways: by adding Github, and by replacing the "Why" bit with a simple
mention of the relationship explored by the article. I'm sure it is possible
to come up with something better, i.e. more accurate and neutral, and if
anybody suggests better we can change it again. But if a paper is going to
play the internet game—which, dismayingly, we're seeing more of, as academics
increasingly have to fight for clicks in their own right—then HN is going to
play the HN game. Your authors are expert in their domain and the HN community
is expert in its.

I wouldn't say this change is unfair to the authors. The purpose is to steer
the thread toward a substantive discussion of their work, just what any good
scientist wants, and away from title nitpicks and complaints, which is boring
and no one wants. I can tell you from years of experience that once these
complaints start appearing, they continue unless and until the title is edited
to bring down the inflammation. We can't fight it, we can only heed it—it's a
force of nature. Why would that be? I think it's that people come to HN for
relief from the onslaught of bait and manipulation that plagues them on most
of the internet. The implicit contract here is that the front page will be a
bit calmer, more neutral, more accurate. HN doesn't do that perfectly by any
means, but if it's noticeably quieter and more bookish than what is typical
elsewhere, that's the main thing.

You can call HN users armchair scientists if you like, but I think you'd be
surprised by how many working scientists participate in this community, not to
mention many who have had scientific careers before moving into industry. They
are humble and don't flaunt their credentials, but when something relevant to
their work comes up they mention it, and it always surprises me how many there
are. It seems a good sign for the health of the community.

~~~
dentemple
As a casual reader of HN, thank you for your efforts.

------
kartan
> A "hero" project is one where 80% or more of the contributions are made by
> the 20% of the developers.

If that 20% leave, the other 80% would contribute equally or the ration 20/80
will be preserved?

This seams a feedback loop. Once a developer has written more code than others
is in a better position to write even more. If that is the case "hero
developer" is a floating position, depending so much on your skill and how
much time you have been working in a project and other circumstances.

> Organizationsshould reflect on better ways to find and retain more ofthese
> software heroes.

I had this discussion recently. If you create a team of "heroes" all become
way slower than when they were in different teams.

My personal conclusion, and the way of working that I try to implement at work
is that small independent projects allow for developers to be fast and
reliable. If your project is correctly divided, anyone can contribute ( at
their level of expertise). If you have a big complex projects then old-timers
that created originally the code are the only ones that can work with it
efficiently if no other developers make big changes (reducing the ability of
other developers to contribute independently of their level of skill).

So, before going in search of "heroes" think if your projects are correctly
divided. And think about the risk that you create when a "hero developer" is
needed and leaves.

~~~
svaha1728
I recently left a company organized in this way. It was quite disheartening:
small changes would break the code in multiple ways, hundreds of public
functions, no interfaces. The architect was seen as a ‘super’ developer...

~~~
timClicks
Perhaps an ideal scenario would be to have a single 'super' developer have
relatively free reign, under the condition that she can explain the
code/architecture to others effectively also.

~~~
duncan-donuts
Yeah, definitely not an ideal scenario.

------
jackconnor
Having worked on many, many software projects myself, this is 100% accurate.
One good programmer who is intensely focused and interested in a project is
worth 20 - 50 (or more) programmers who are just code monkeying it without
really giving a shit. This is why a small, passionate startup team can
consistently build better products than large corporations. Much better
products.

~~~
Data_Junkie
There is no substitute for caring, and people consistently, dramatically
underestimate the difference in thought that happens in people who care and
people who don't. Anytime I'm asked why someone should listen to me and not
someone else I tell them "because I care". It is really all it takes to
separate from the incompetent, so few understand what caring does.

~~~
jackconnor
Absolutely. I'm sure there are many reasons for this, but a big one i always
see is attention to detail. People who really care are obsessed with getting
all the details right, and hate bugginess, bad ux, and other issues typical of
crappy software. Big projects with no real owner may have lots of programmers,
but none of them care so much that they want to get in the really deep weeds
to make the thing a truly amazing software experience.

~~~
Data_Junkie
And that is because there is always more to care about, just as true love has
no end.

------
taeric
I find it silly they designate these as heroes. Seems simpler to say that most
projects are small enough that a single person can do the majority of the
work. Not shockingly, most smaller projects don't fail that heavily.

Add in the extra work that collaboration necessarily brings to the table, and
it isn't that shocking that things both slow down and get more error prone. At
a certain size, though, this is worth the cost of admission.

More, it isn't like we call all projects done by fewer individuals heroes. We
have authors, not "writing heroes."

And the author joke is meant to point out that the vast majority of what you
read has a single person's name on it, but without the editors and other
workers involved, that book would never have come about.

~~~
bjourne
Yes, but that brings into question how large a project needs to be for the
hero model not to be feasible anymore. They surveyed over 1 100 projects and I
would guess a significant portion of them would be counted as "large". I found
their raw data on github here, [https://github.com/ai-
se/Git_miner](https://github.com/ai-se/Git_miner), although it is in some
weird .xlsx format so I can't verify if my guess is true.

~~~
reboog711
.xlsx is a Microsoft Excel file. I bet you can open it with Google Docs,
LibreOffice, or something similar.

~~~
mr__y
You can also change extension to .zip, unzip it and read individual xml files
from worksheets/ subdirectory. However, because of the horrible schema in
those xml this is probably a really bad idea to go that way. It's way better
to use the software that parent mentioned

------
xrd
This is really fascinating.

If true, it suggests that big companies with huge teams that try to force the
entire team into equal contribution metrics are creating stress that might not
help the team, nor lead to fewer bugs (big surprise).

I've never been on a team which was set up to truly recognize the value
different forms of contribution, like writing tests, or removing code, or
simplifying it, or other things which would not count towards the hero metric
presented here. As an industry we just don't think about alternative
narratives to "let's make sure everyone is an equal contributor..."

~~~
asimpletune
Yeah that’s a very interesting observation, and sort of corroborates my own
anecdata. More specifically, when projects are in there infancy, and there’s a
lot of risk associated with working on them, I feel that management tends to
stay away, which is how these heroes originate. Then, after it’s obvious that
project will succeed and it’s merits are overwhelming, you see this shift in
project governance/responsibility towards a more corporate mode. However, like
you said, that’s probably counter productive and just creates stress and
tension. If anything, I think sometimes management has an uncontrollable
tendency to position itself strategically in these gatekeeper roles, whereas
in open source they don’t get to do that simply by virtue of being someone’s
boss, so you don’t see that same trend, as the paper argues.

Not sure if that makes sense, I quickly typed this on my phone.

~~~
Data_Junkie
That is the untalented who are interested in the rewards of success moving to
gain what is possible to get from talent. They have none, so they have to see
it manifested and then they capture it for their benefit. They have no other
access to the good stuff. All industries, human endevors, work this way. All
power structures, all groups.

------
revvx
It's the second time I mention Fred Brooks on HN today, but he dedicates a
chapter in Mythical Man-Month that agrees with the assertion of the article:

> Much as a surgical team during surgery is led by one surgeon performing the
> most critical work, while directing the team to assist with less critical
> parts, it seems reasonable to have a "good" programmer develop critical
> system components while the rest of a team provides what is needed at the
> right time.

Other team members perform other tasks, and some of those even administrative
(!), but all of them supporting the "vision" of the surgeon.

IMO this is a healthier way of communicating roles, avoiding fights and
training juniors. It's better than the "everyone is replaceable" mindset
companies have this day.

~~~
taeric
Surgery is a dangerous comparison to make. Most surgeons get to their
seniority by doing a lot of surgery. Most of which are near identical to each
other.

Programmers? We, for some reason pride ourselves on doing something new every
time around, it seems. I've argued before with my leadership that, if we
really wanted something done better/faster, we shouldn't be promoting the
folks that did it out of the position for the next go around. Rather, we
should have them do it again. And then again. And then again. Not only would
they be learning from their experiences, but benefiting much more directly.

~~~
revvx
> I've argued before with my leadership that, if we really wanted something
> done better/faster, we shouldn't be promoting the folks that did it out of
> the position for the next go around

This is similar to what Fred Brooks suggests in the "Surgical Team" chapter of
"Mythical Man Month", although he's a bit harsh, I'll grant that:

> if a 200-man project has 25 managers who are the most competent and
> experienced programmers, fire the 175 troops and put the managers back to
> programming.

EDIT: We were also talking about it yesterday here at HN:
[https://news.ycombinator.com/item?id=19763562](https://news.ycombinator.com/item?id=19763562)

~~~
bartimus
And not forget to fire those other managers who never wrote a single line of
code.

Or anyone who thinks in terms like 'programmers' and 'resources'.

~~~
revvx
Brooks idea was even more radical:

Put non-coders to work under the chief programmer. Let them help instead of
control.

~~~
bartimus
That makes total sense to me. Having engineers in charge of the challenges
that require engineering.

------
yuhe00
Maybe I've just been unfortunate/fortunate, but in 6 years as a software
developer on all kinds of projects, I've never once worked on a project where
even two people share the major contributions to a single repo. Either I run
away with one part of the project or someone else does while I work on some
other part. Usually split between frontend/backend/devops (webstuff) or
app/libraries/tooling. We obviously plan and discuss how the different parts
of the projects work together, and we do make contributions to the other
repos, but these are usually minor.

I don't necessarily see it as a bad thing. It just feels the most natural,
reduces friction and the need to communicate minute details. Ownership is also
important. The downside of this is that some part of the project might fall
apart if someone leaves, because no one else can take over.

~~~
pojzon
> The downside of this is that some part of the project might fall apart if
> someone leaves, because no one else can take over.

This is the reason, i think, corporate world HATES with passion such devs.
Even tho they need them to meet deadlines.

It also gives a bit too much power in negotiating to the employee which is
also seen as "bad" in corpo.

~~~
luckylion
> This is the reason, i think, corporate world HATES with passion such devs.

Which is the right attitude, imho. Even if that person loves the company and
would never leave - what if a bus runs them over?

On a large scale, consistency is more important than excellence. You need to
be able to plan, "if that guy stays, the project will be done in 4 weeks, but
if he leaves, it will take four years" just won't work, because you cannot
rely on it. It's much better to be able to say "it will be done in 12-14
weeks" with high confidence. Sure, your whole dev team might get run over and
spoil your plans, but that's really a case of force majeur.

~~~
rabidrat
Okay, so let's be optimistic and say a team of 4 can do in 12 weeks what that
one dev could do in 4 weeks. 48 dev-weeks vs 4 dev-weeks. Do you think it's
reasonable for a project to cost 10x as much just for that precious
consistency? Not to mention that longer projects with larger teams have higher
variability in outcome, with most projects overshooting by 100% or more. Is
this really the right attitude then?

~~~
luckylion
> Do you think it's reasonable for a project to cost 10x as much just for that
> precious consistency?

Somewhat, yes. You want to be able to plan. Inefficiency is often the price
for being able to plan. Since it's often not only about this one project, a
higher price is just fine - you may have to coordinate with marketing, legal,
sales, manufacturing etc, then the total price will often be so large that the
10x of the software project doesn't really matter, but if it falls flat and
gets everything delayed, the damage may be huge (think global launch date
missed).

------
cookiecaper
> A "hero" project is one where 80% or more of the contributions are made by
> the 20% of the developers.

Where does this definition come from? It sounds quite typical to me. Even in
large projects like the Linux kernel, if you break them down into
comprehensible units and subsystems, I would expect you'd find essentially the
same thing.

The vast majority of projects likely meet the "hero project" threshold defined
above, whether they're good or bad. I don't know of any movement to
specifically prevent having primary contributors; the main interest from the
corporate world is ensuring that primary contributors can be cycled as
necessary.

This doesn't seem like news in any way. I don't want to be unduly dismissive
as I haven't read the paper, but I think I'm catching a distinctive whiff of
"publish or perish" in the vicinity...

------
iandanforth
This is a poor argument attacking a straw man. Each of the cited papers
discussing "hero" projects are in the context of medium to large
organisations. While open source GitHub projects are frequently self-contained
tools or libraries. Equating the two is a monumental and unsupported jump.

~~~
bartread
I'm glad I'm not the only one who thinks this is nonsense. I wrote a fairly
long comment, which you (might) find elsewhere in the discussion, then started
reading the other comments and was starting to wonder what other people were
seeing that I wasn't.

Short version: the OSS versus every other type of software project comparison
seems very apples and oranges.

------
stevebmark
I wonder _why_ hero projects are more bug free. I could probably write lots of
terrible but bug free code on a personal project, because I know where all the
flaws are and avoid them. If I invited more developers to work on this
codebase, of course there would be more bugs, because the code quality is so
bad. If I wrote good abstractions, types, and documentation, theoretically
others contributing to the code would write less bugs too.

~~~
LoSboccacc
> and documentation

that's the gist of it, abstractions are _always_ imperfect in some way and
leave the door open for interpretation, at which point if team member don't
communicate each module intent efficiently code responsibilities get mixed and
entropy rise dramatically, causing more bug per line of code written.

imho an important figure on large projects that is largely ignored or
conflated with "the architects" is the oracle, or the guy people ask where new
feature/code should go. not in term of application structure or component
design, but at a lower level, at modules and interfaces level.

------
m0zg
"Hero" is a bad name for it, but one or two people on the team need to
_really_ understand what is it that needs to be done, and the management needs
to understand that those people _understand_, and support them. At least 80%
of any given team either don't understand what needs to be done or don't give
a shit, or both. Leaving such folks to their own devices is a very wasteful
and counterproductive exercise.

------
myth2018
That matter has caught my attention some other times. I'm aware of dozens of
projects where such "hero developer" phenomenon happened and it's really
interesting (some I worked for, some I knew by other people).

I ask myself why that happens. No doubt that variations in developers' talents
is a factor. But I think there are some social forces operating there as well.

I have become the hero of four projects after the previous hero had left. And
I have also already arrived in projects with pre-established heroes.

Despite I've been able to be a reasonable hero whenever I ended in such
position, the other times when I worked with established heroes, they were
condescending over me and the rest of the team. There has always been that
trend to patronize and to be a plain jerk. That was annoying.

I knew I could contribute more and maybe even to help to herorize the project.
But, simply put, there weren't minimal social conditions for that to happen.

Maybe the heroing concentration would dilute a bit by improving social
conditions.

------
peter_d_sherman
This is the 80/20 rule, except applied to the proportional contributions made
by a group of developers on a given project, rather than how time is allocated
relative to problem solving related to software development...

You know, a similar argument could be made for history... that 80% of societal
progress was created by 20% of the individuals living in that society...

------
3xblah
"The real hero of programming is the one who writes negative code." \- Doug
McIlroy

"[T]he meaning of negative code is taken to be similar to the famous Apple
developer team anecdote (i.e., when a change in a program source makes the
number of lines of code decrease ('negative' code), while its overall quality,
readability or speed improves)." \-
[http://en.wikipedia.org/wiki/Douglas_McIlroy](http://en.wikipedia.org/wiki/Douglas_McIlroy)

"When the Lisa team was pushing to finalize their software in 1982, project
managers started requiring programmers to submit weekly forms reporting on the
number of lines of code they had written. Bill Atkinson thought that was
silly. For the week in which he had rewritten QuickDraw's region calculation
routines to be six times faster and 2000 lines shorter, he put "-2000" on the
form. After a few more weeks the managers stopped asking him to fill out the
form, and he gladly complied." \-
[http://www.computerhistory.org/highlights/macpaint/](http://www.computerhistory.org/highlights/macpaint/)

"One of my most productive days was throwing away 1000 lines of code." \- Ken
Thompson

"Measuring programming progress by lines of code is like measuring aircraft
building progress by weight." \- Pete Kirkham

------
bartread
> A "hero" project is one where 80% or more of the contributions are made by
> the 20% of the developers. ... We identify the heroes developer communities
> in 1100+ open source GitHub projects.

My scepticism has been piqued to the extent that I call b######t.

Open source projects. Projects contributed to by people in their spare time,
or perhaps with some corporate backing with developers on the payroll, and
often with quite different governance models.

Should we therefore be surprised at the widely varying levels of contribution?
Should we be surprised that those who do more work on the projects tend to
make contributions resulting in fewer bugs, perhaps because they have a much
better understanding of the projects due to their greater familiarity with
them?

Whatever: OSS projects with contributions coming in from all manner of sources
outside the core team aren't necessarily terribly similar to having a team of
6 - 8 working on a project full time within a company. The only similarity
being that a relatively small core team do most (or all) of the work.

Colour me not even slightly surprised. My blunt conclusion is that the idea
software projects "need" so-called "hero" developers is extremely questionable
based on the data presented[1].

 _[1] Granted I 've done no more than skim the paper but this comment, from
page 3, amused me: "Most prior researchers deprecate heroism in software
projects." Really? Do they now?_

~~~
falcongod082
You're calling bullshit on a paper defining the terms that it is using in the
paper?

~~~
bartread
The headline's been changed since I submitted.

I was calling bullshit on the fact that it appeared to be drawing general
conclusions about all software projects based on a survey of open source
software projects, which often operate under different conditions to those in
commercial organisations.

The abstract and title of the paper are somewhat baity, as others have pointed
out, but the headline here now reflects the fact that the paper only
represents OSS projects hosted in GitHub.

~~~
falcongod082
It would be interesting indeed to apply the same study to commercial products.

------
euske
The result itself is unsurprising, but I'm curious of what caused their low
bug rate ("code quality" in their term). They haven't looked at the actual
code, but I guess that code consistency plays a big role for reducing
potential bugs, and it's easily achieved with having fewer developers in a
team. Also this is not contradictory to sayings like "a lot of eyeballs make
software better" because I believe eyeballs mainly contribute to bug
_detection_ , but not bug prevention.

Edit: After posting this, I dug into this problem a bit more. I think code
consistency is less important between modules (in a large project). But this
requires a premise that these modules are independent enough and they don't
need much communication each other. This line of thought is pointed out by
this SO question.
[https://softwareengineering.stackexchange.com/questions/1906...](https://softwareengineering.stackexchange.com/questions/190649/whats-
the-right-balance-between-code-consistency-and-code-improvement/190658#190658)

------
qznc
There is certainly some survivorship bias involved. The filter (50+ weeks of
activity, 8+ contributors, etc) only selects somewhat successful software
projects.

Big professional software development also emphasizes reliable planning,
requirements engineering, and documented processes. In contrast, most open
source projects begin in a cowboy style with a single person starting to code
without requirements and processes and often not even much of a plan. This
lightweight process implies a lot more risk and indeed most of these projects
fail. That is fine. The free software world rather goes with this evolutionary
approach.

I wonder if there is any company which works in a similar way. Start lots of
projects with a fraction of the resources. Be fine with most projects failing.
I guess not because this approach is hardly compatible with career
development. Googles 20% rule might be considered a step in that direction.

------
dlkf
I believe the conclusion is basically true, but I also feel that sampling from
the Github project showcase list induces a selection bias that is going to
support it. The analysis would be more convincing if the authors had gained
access to some enterprise codebases whose contribution graphs were more evenly
distributed than their open source counterparts.

------
gchamonlive
In larger projects, each module or discrete functionality works like what's
being described in the article. There will always be a handful of programmers,
most likely coordinating other programmers, that intimately know that module.
That is OK and in many occasions development and intervention, from concept to
implementation and then test and release to production, can be sped up, but it
must be taken into account that it also lowers the so called truck factor (I
like to call it lottery factor, in which a developer wins a lottery ticket,
becomes a multi millionaire overnight and leaves the project, rendering
hopeless all those parts he had exclusive knowledge)

I guess then the goal is to find balance between having heroes and increasing
the lottery factor of the team.

------
phlimflam
It's obvious that the projects with the lowest bug counts are maintained by
one person with a vision. Projects that accept any drive-by pull request
without serious scrutiny inevitably suffer code quality and consistency
issues. It is often more important to know what features to exclude from a
project as knowing what to include. The "heroes" know the history of the
project and are responsible for a consistent design.

------
eshch
apart from questionable choices of data to analyze (open-source has its own
specific), the study proves only that heroes are good in hero projects.
perfect.

------
killjoywashere
Probably tangential, but I think this ties in nicely with the study about the
effectiveness of Reddit deleting toxic subs (1). Leadership does in fact
matter. But at the same time, all politics are local.

(1)
[https://news.ycombinator.com/item?id=19770237](https://news.ycombinator.com/item?id=19770237)

------
jeandejean
Very interesting. But that probably doesn't translate to professional projects
where people have more incentive to contribute and core contributors the
obligation to onboard and mentor new hires...

~~~
falcongod082
If you think that "why" someone contributes is meaningful, I'm curious how you
think that professional projects (whatever that means) and whatever arbitrary
metric is being used to encourage incentive would give a different result.

~~~
jrumbut
For instance, on a minuscule open source project of mine, I wrote all the code
and another developer has (kindly) stepped up and managed upgrades to one of
the dependencies, bumping the version number when it's time to do so.

If he and I were employed together to work on this project, a workload
distribution of me writing and maintaining the entire codebase (minus one
line) and him coming by every couple months to update a version number would
not be a very fair or realistic division of labor.

The open source development process is very different from anything else. None
of my projects at work have a long tail of contributors submitting comment
typo fixes.

~~~
diminoten
It'd be much more fair if the project at your job started out as a proof-of-
concept that you wrote, while the other dev worked on other things.

Once your proof-of-concept grew into something management wanted, you'd
probably still be writing a lot of the code, and the other developer would be
contributing, but in the realm of 20% of the codebase, at least to start (and
according to this article, that wouldn't change).

~~~
jrumbut
You're right, and I don't doubt the value of studying open source projects or
that it's the best that can be done given the data available, but there are
limitations on how much light this data can shed on the great mass of code
being written within organizations.

Maybe the results do apply to the situation you describe, I'd be curious to
know that.

------
tanilama
What is the opposite of hero project? I didn't see one project in my life that
doesn't have a BDFL style person in charge for my 10 years programming
experience...

------
graphememes
Did we really need a study to come to this conclusion?

Heros are called maintainers, or creators.

This is every project. This is what this study concludes. Does the world not
understand this?

------
Data_Junkie
All good teams revolve around stars. Talented brains can create more value
that two hands can do, and the organization exist to help them win. Nothing
new.

------
Guthur
I feel this is the Pareto efficiency Isa play which is a very common
phenomenon.

------
yawniek
likely this is also one of the core reasons why microservices are so
successful these days. they allow having many small hero developers that
create replaceable components fast.

