undefined | Better HN

0 pointshinkley2y ago0 comments

Philosophically, if a lead developer is doing most of the commits on a project, then they are monopolizing both the code and the decision making process, which is a sure way to kill a project.

If the basketball or soccer team captain were also a ball hog, they'd have trouble keeping the bench full.

When you become lead, you have to let some of the code go, and the best way I know to do it is to only put your fingers into the things that require your contextual knowledge not to fuck up. If you own more than 10% of the code at this point, you need to start gift-wrapping parts of the code to give away to other people. If you own more than 20%, then you're the one fucking up.

Obviously this breaks down on a team size of 2, but then so do concerns about group and team dynamics.

0 comments

Capricorn24812y ago

> which is a sure way to kill a project

Nginx is one of the most widely used open source projects in the world. It's hard to read this without laughing, as if it's still to be determined whether Nginx could be considered successful.

delfinom2y ago

>Philosophically, if a lead developer is doing most of the commits on a project, then they are monopolizing both the code and the decision making process, which is a sure way to kill a project.

Or, just follow me here, a open source project really doesn't get that many dedicated contributors beyond the leads and everyone else may casually drive-by.

hsbauauvhabzb2y ago

I think there are problems where this will apply to, such as crud applications, and projects where deep understanding of core components makes it difficult to scale teams horizontally as it will effectively require a hive-mind.

hinkleyOP2y ago

If the 'core components' are half of the project, there's no core. It's just important and less important components.

And in all likelihood if you are expecting a core competency in enough domains for the situation you reference to be true, it's because you have a bad case of NIH, you aren't concentrating your efforts in the areas your company is purportedly focused on. That makes it difficult not only to scale up a team, but also to scale it down. The first major revenue hiccup you encounter may be your last.

If you are concentrating on a narrow domain you intend to be experts in, then that will be 15-25% of the code. Meaning to maintain a decent bus number, you only need to be primary on about 10%, if you have half a dozen people or so.

xorcist2y ago

What does "doing" a commit mean?

Crafting the change? Applying the commit?

The former is where we should strive for heterogeneousity. The latter is a janitorial duty that should be guarded and centralized.

Do not underestimate the importance of janitorial duties though! That is the way we build culture and community, and that is the only scalable way to build any quality above that it compiles.

Reluctance to accepting commits and keeping a strong culture is something that is common to all successfully scalable open source projects.

rvba2y ago

Philosophically and realistically if there is no clear management then everyone will do whatever they want and the project will fail.

And yes, there are lots od companies with bad management, bad decisions, or even surviving despitr bad management. But most of the time thr management at least gives some direction.

You sound like one of those freeloader types, who dont contribute.

account422y ago

What an absurd thing to say. You do realize that a single active main developer + a bunch of drive by contributors is the NORM for most open-source projects, right?

bhaney2y ago

> which is a sure way to kill a project

Nonsense

hinkleyOP2y ago

Good luck with your empire building sans team building.

1 more reply

j / k navigate · click thread line to collapse

0 comments

Capricorn24812y ago

> which is a sure way to kill a project

Nginx is one of the most widely used open source projects in the world. It's hard to read this without laughing, as if it's still to be determined whether Nginx could be considered successful.

delfinom2y ago

>Philosophically, if a lead developer is doing most of the commits on a project, then they are monopolizing both the code and the decision making process, which is a sure way to kill a project.

Or, just follow me here, a open source project really doesn't get that many dedicated contributors beyond the leads and everyone else may casually drive-by.

hsbauauvhabzb2y ago

hinkleyOP2y ago

If the 'core components' are half of the project, there's no core. It's just important and less important components.

xorcist2y ago

What does "doing" a commit mean?

Crafting the change? Applying the commit?

The former is where we should strive for heterogeneousity. The latter is a janitorial duty that should be guarded and centralized.

Do not underestimate the importance of janitorial duties though! That is the way we build culture and community, and that is the only scalable way to build any quality above that it compiles.

Reluctance to accepting commits and keeping a strong culture is something that is common to all successfully scalable open source projects.

rvba2y ago

Philosophically and realistically if there is no clear management then everyone will do whatever they want and the project will fail.

And yes, there are lots od companies with bad management, bad decisions, or even surviving despitr bad management. But most of the time thr management at least gives some direction.

You sound like one of those freeloader types, who dont contribute.

account422y ago

What an absurd thing to say. You do realize that a single active main developer + a bunch of drive by contributors is the NORM for most open-source projects, right?

bhaney2y ago

> which is a sure way to kill a project

Nonsense

hinkleyOP2y ago

Good luck with your empire building sans team building.

1 more reply

j / k navigate · click thread line to collapse