back
162 comments
> Something I have noticed is that the more people join a project, the more it begins to go off the rails, and the less productive each member of the team becomes. [...] many of the newcomers spend the bulk of their time, if not actually sabotaging the project, doing the next best thing. They do their best to drive the project in the wrong direction. In so doing, they waste the valuable time of everyone around them who is forced to clean up the messes they leave behind. These are intelligent people, so I do not believe they are incapable of understanding the vision that caused the project to be born. I think, rather, they just don't care. Some call this "not being a team player", but I call it narcissism.

Er... reading this, I would rather suspect the author of "not being a team player". Of course, if other developers find your project interesting and want to contribute, they may have their own features and use cases in mind that don't necessarily overlap with what you have planned, which doesn't however mean that it has to be a "wrong direction". As the owner of the project, you are free to accept their contributions or not, and they are free to fork the project and take it into another direction if you don't like that direction.

>Er... reading this, I would rather suspect the author of "not being a team player"

If he's in charge of the project's direction and has a specific vision that must be accomplished, that's not his job.

Unfortunately, if random people passing by are able to steer the project into the ditch and cause it to fail its most basic requirements (as he describes) then he's bad at his job (which isn't 'being a team player').

He's bad at his job because what he describes seems like a total inability to sell people on WHY to pursue his end goals. If proliferation of devs leads to the project going more and more off the rails, he's getting people who are drawn in by something or other, and feel no connection to the basic purpose of the software. That's on him. His job is to make them understand why his purpose matters, and it's like he's producing a codebase easily adapted to other purposes, but it somehow doesn't get across his purpose.

Maybe he needs to hire a writer, not devs :)

> Er... reading this, I would rather suspect the author of "not being a team player".

I'd respectfully disagree on this. There are projects where you fixate on the outcome (i.e. success of the project and maintainability regardless of team turnover), and projects you fixate on technical aspects for yourself (i.e. I'll fit this thing into a Raspberry Pi 3).

I'd personally set first kind of projects free and accept help, and be a "trim tab" for them, however I'd never allow second type of projects to diverge from the vision I have set for them. Because the second type of projects are "what-if" projects, and engineering studies primarily.

Painting personality pictures from a single post looks like an overreaction, too.

There is a minor irony that the author has another blogpost on how micromanaging bosses are awful, because they insist that you should work their way rather than your own way.

Perhaps the learning here is just "managing engineers to deliver something cohesive isn't straightforward". It's obviously true that an open source project can have good coding standards with multiple contributors of different skill levels, but you get there by managing the project really well.

And while more engineers can mean that an individual engineer is slower, the idea is that with good management and engineering the aggregate output can increase with each engineer (i.e. Having 10 engineers who only work at 25% of the pace of a standalone engineer will still output 2.5x as much as a single engineer. At scale it is the teams output that matters, not the output of an individual engineer).

> Of course, if other developers find your project interesting and want to contribute, they may have their own features and use cases in mind that don't necessarily overlap with what you have planned, which doesn't however mean that it has to be a "wrong direction".

Yes it actually means exactly that -- it is the wrong direction. Since you have one person who wants to build something concrete and he doesn't owe it to anyone to support them if they want to change his thing to something else.

As I wrote in a deeper comment: if you want to build a shed in your back yard and your neighbor asks if he an help, you'll welcome them right? But then imagine the neighbor, for reasons unknown to you, wants to actually build a greenhouse and starts not doing what is asked of them and actively replaces building blocks and does stuff you don't want them to do. In your own back yard.

You will say this is not OK and want them to leave, I am certain of it.

Then somebody like you (the parent poster, a 3rd person in the picture) appear out of nowhere and claim that you are not a team player.

So I don't see how your comment follows logically at all and it's even more puzzling that it's the top comment. Makes me wonder if the people who blindly recite some theoretical democracy manifesto would be so generous if "the team players" you are defending started wanting to demand the right to change your back yard. :)

I agree that this passage says more about the author than about any fundamental law of organization.

It is true however that there is more organizational overhead if you have two people working on a thing than if you have one doing it solo.

But that is a problem that can be solved, e.g. by dividing responsibilities very clearly or by having clearly defined procedures that guarantee a decent handover. I have also experienced people that do better, more accurate and resonable work when they work together with someone else, because they will anticipate the other seeing their code.

The quoted passage tells me one thing: If you invite people to work on your project, no matter if it is a film, a garden party or a software product, the right casting is crucial. Don't invite people that won't understand the thing you're doing, and if you absolutely have to make sure there is something in it for them when they do their own job well and see your thing succeeding — but the crucial thing is, you should always know what is in it for the other person.

As someone who has been on a number of amateur film sets where nobody got paid the ones that really sucked where the ones where the initiator treated everybody like dumb paid labour that should just do as they were told, pushing people that might have cared into actively sabotaging the project.

If you want people to care about your project it is your task to find people who do and it is your task to keep them there, if they are needed for the project.

And very often that means not doing it 100% dictator-style, but letting people play and evolve within their own domain. From what I have seen the results of allowing this outshine micromanaging dictators nearly all of the times.

It seems to me that the author is talking about _personal_ projects, and people coming in to hijack them...not about working as part of a 'team' in a company.

Many of the replies here seem to conflate the two, which I think is either a poor reading or just ignoring the message I took from the article.

> I would rather suspect the author of "not being a team player"

Let's look at it: he's basically saying that teams are often bad, and the bigger they are, the worse. And, so, there are times he doesn't want to be in one.

He concludes the article with: "Sometimes the old saying is true. Sometimes, if you want something done right, you really do need to do it yourself."

That's not the parting shot you would use if you still wanted people to think you're a team player in spite of all the mostly negative things you wrote about teams.

> I would rather suspect the author of "not being a team player"

A team is a group of people all working toward the same goal. The author is talking about being wary of people who don't share the common goal. That, arguably, is being a team player, supporting the team by making sure that everyone rows in the same direction.

I cant say if he's a team player or not, but from what I read, it does seem that communication is key. If he was able to communicate his goals, requirements and objectives clearly to the "helper", he would have never gotten into this mess in the first place.

Leadership, communication and group by in are so important in any project. People who have mastered those soft skills tend to deliver quality good.

I recently forked a project to make some significant changes to make it more useful for my needs. The direction I took the fork is different from needs of the original author. My version is definitely much more useful for other people but wouldn't be any help to the goals of original project.

But I'm very thankful that the original author just posted his code to Github to make this possible.

Am I missing something? There is no lesson learned here. No offer of help was accepted and nothing went wrong. Why beware? He hasn't even tried it. Hell I can't even really parse if there ever was an offer to help, just some suggestions.
Software projects need a "Director" - much like a Film Director.

This person has ultimate control over what the software should be.

I'm always surprised to find software that is a really cohesive and appears to be the implementation of a clean and consistent vision, because software projects have so many people pulling it in so many directions.

This is, IMO, why MacOS is such a simple and clean and consistent implementation and Windows is just spaghetti soup. I don't know the truth of how these projects are run but I imagine at Apple there is someone at the top with a really clear vision of what MacOS should be.

This story sounds quite a lot like a few experiences I had. Years ago (more than I'd like to admit), I took to playing Travian with friends and coworkers. Travian is an RTS, where 'Realtime' really means 'Real-Time'! If you attack the town next to you, just a few squares away, it can take 5 hours for your troops to arrive and the battle to ensue.

It was the perfect game; you could play it casually, in between stuff at work during the day, or on break, or in the evening.

My friends started getting really into it and spending a lot more time on it. I did not want to spend more time playing it, but it was a fun game. The makers of Travian did something interesting, though - they would dump one database table with city data every night for people to do interesting things with. My friends were using a bunch of these tools already, but I perceived some opportunity to build tools which didn't yet exist - like a tool which let you discover inactive accounts to pillage. I starting building more and more tools, eventually starting to write a bot to play the game for me, by automatically raiding inactive accounts and automatically building up my current towns to avoid appearing inactive. My goal in doing this wasn't to play the game per se, but to learn and get better at programming.

So I made the mistake of mentioning all this to another friend who was playing Travian. He was interested. I told him if I ever finished, he could try out the bot, but in the meantime he could use the rest of my tools.

Well, he got impatient waiting for the bot (which btw, I never finished, but I did learn some cool stuff from the experience). He decided he was going to 'help' me, by group calling me with another programmer friend of his who first of all quizzed me on how I was building it, and telling me I was doing it the wrong way and that I needed to use different languages, frameworks, messaging layers, etc. Yeah, so now that I am way further in my career, that guy was dead wrong and an idiot who was trying to overcomplicate everything. But the point was - he didn't want to help, he wanted to stroke his own ego by fixing (or as the case may be, fucking up) some other idiot's project.

This actually really strained my relationship with my friend. Huge dick move, and one that took me a long time to forgive him for. Stay out of my personal projects! To me, it felt along the lines of hearing about an argument with my wife, and then unbidden forcing me to take a call with a relationship coach who told me I was a bad husband.

related: https://macwright.com/sites/polite.technology/preview

""" Responding to feature requests

Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution.

The maintainer does not owe their time to anyone The maintainer must treat everyone with respect Ignoring the first principle will lead to burnout: there are unlimited features to be requested and limited time to implement them. The sense of obligation quickly becomes an emotional burden.

Ignoring the second principle will damage the project

and reduce its chances of ever attracting additional contributors, which is the only way to succeed in the long term.

1.) Maintainers are the keepers of the project principles

2.) The goal of the software.

3.) The scope that defines problems that the software will try to fix and those it will not.

4.) The style of the project: which programming practices are used, which language.

5. The culture by which the project is managed.

6. Maintainers approve of changes to the software by these principles, and also manage discourse and which other contributors are allowed.

"""

Sometimes my 5 year old wants to build her block tower just the way she wants, and she says no thank you if someone offers to help. Other times she accepts help and then the tower takes a different form. Both ways are OK.
By the point of “It is being so wrapped up in yourself and your own goals that you cannot accept the fact that your goals are not more important that those of everyone around you.” I couldn’t help but think of the expression “Pot…Kettle…Black.”

I think most Engineering Managers know that doubling the number of engineers doesn’t double the speed of development, but you have the accept that sacrifice to actually get things to market.

The author seems to propose it is impossible for large teams to be productive. They even go so far as to claim most potential team mates have malice intent to “sabotage the project”.

Amazon is an example of an organization that does this well (i used to work there). Small teams are responsible for their own project(s). Project(s) can be composed to form higher level project(s). It’s certainly not impossible, and id rather put in effort to manage team(s) than to place an increasingly insurmountable amount of pressure on myself.

Perhaps the reason the author’s project has “few users” is that there are competing alternatives that have authors who understand how to leverage team work to deliver more value to users, and users go where they perceive value.

Also, if you worked for an organization that actually hired (and retained) people with malice intent, i dont think team size was the real issue. In that sense i do agree with the author that you should screen anyone and ensure your goals align before agreeing to invest time in trying to work together. If someone is offering to add a feature you dont think fits in the project, i have a hard time characterizing that as “malice intent”, though!

It’s not narcissism. Don’t use terms you’ve researched on Wikipedia to diagnose other people. If that’s narcissism, then what’s creating a project that is the unique extension of your own values?

I’ll answer: both are legitimate ways to approach the world, that may involve an acceptable and perhaps at times level of selfishness.

Sometimes things don’t work with other people because you don’t see things the same way. They are not Wrong and Bad.

This mostly sounds like the project owner doesn't have experience, or perhaps more importantly time, to manage the project and 3rd party contributions. Nothing is wrong with that, of course - but the framing here, I take issue with.

Placing the codebase on GitHub would allow folks to work and make contributions in the form of a Pull Request, which the OP can reject with explanation if it does not go in the direction they desire. They can even setup a roadmap and tickets (issues) to help guide eager-to-help offers.

For anyone wanting to take the project in a direction OP doesn't want - they can fork it and do just that.

So no, don't beware of offers to "help" - be aware of your time commitments and that not everyone's goals will always align with yours. That's just how open source works...

I think the author is taking a bit of the wrong lesson from his experience.

One of the challenges of coordinating a group of people is getting everyone to buy into the same vision. Fact is that other people see the world differently and may have different goals. Here the author is attributing that to narcissism and maliciousness when most of the time it isn't that.

So yes, as you add more people it gets more challenging to get everyone rowing in the same direction. This is why setting a clear direction and clear communication is key, but the increase in communication overhead as the team grows is always going to be difficult. In this case, as others have said, he could've just open-sourced his code so the people who had a different idea were free to run with it.

When it comes to new employees he is right.

We just have one that is quitting. Guy is smart of course but he could not understand refactoring all code he touches is not what we hired him for.

If you make 10-20 pages long PR with spelling corrections or renaming variables where functionality company asked you for is 5% then problem is you not understanding there will be 2 or more developers having to read that.

If you have a vision, and you make something noteworthy, people will show up with different visions, and try to take your project in a different direction. This happens when you found a company. The most dangerous employee to the life of the company is employee #2. This is why YCombinator doesn't like solo founders, and wants a more stable two-person team with a shared vision for the company. The third employee you hire is much less dangerous because they can be overruled by the majority (without even threatening to fire them).

Also note that wasn't an open-source project, so there's always the threat that someone will steal your code and your hard work. Don't allow someone to see your code unless you're ready to open-source it, or you have enough money to pay for a lawyer if the person steals your code. (I know the concept of software ownership is anathema to most of the HN crowd, but hopefully this makes it through the downvoters to reach its intended lurker audience).

Looks like we don't have any evidence of success of this project.

Having other people help your project might be bad for your ego, but it's also a great way to grow as a developer.

Such projects have phases of development. If too many people get involved too early, you easily create a "too many cooks in the kitchen" situation.

But once the long-term architecture is largely defined and implemented, there's usually enough inertia and established compartmentalization of modules that more developers can participate without ruining the soup.

I think the author is a little cynical. As someone with a handful of small open source projects, I know exactly what he is talking about but I wouldn't say it's driven by narcissism. It's mostly just people new to programming trying to contribute and usually learn something through the process of contributing. You can always just tell them they are free to fork your project, this may offend them but if you do it politely and explain that you do not feel like investing that much time in the project or that their changes are too complicated then they will understand.
I think this is why I often push help offers away in other things. If someone wants to help, they may be more experienced and willing to teach. That'd be great. If I was doing an electronics project and an EE found the idea interesting and wanted to help me get it done, fantastic. I'm not trained in that.

However, for many things either I have an idiosyncratic way of doing things or the offer comes from someone who needs me to teach them a lot to meaningfully help. My business bookkeeping is one of those things. Teaching people to do it is stressful and painful, and then I have to worry about the mistakes they make, as opposed to the ones I make.

This author adds a third case, where your project inspires them but they want to take some ownership of the design. Either they don't understand your idiosyncratic approach or they are more comfortable with their own patterns. However, it will be clear that there will be a lot of friction and that's bad for friendships.

I think there's an implicit fourth case, where the offer is coming from a person who doesn't really know how to help but wants to get involved in something they think is cool. These are the people who mix up their terminology in their rants on your forum about how your working software could be much better done.

Finally, there's the people you enjoy teaching, where it's rewarding to include them in your journey. Maybe it's good to consider that possibility from time to time.

As a maintainer (and product owner/pm) of OSS, I somewhat disagree with the OP. Beware of your over-attachment to a project that others are willing to contribute their ideas, time, and energy to. You are not an oracle; nor are you the only user of your product. Other people have better ideas than you do sometimes, especially when they're your users.

Give them latitude to take the project in ways you disagree with, even vehemently. Your project will be better for it, and you'll learn something along the way.

Just a tip: don't forget the nearly 50-year old book The Mythical Man-Month. It may have some lessons!
> "My primary goal for Xnet is to prove that--contrary to everything everyone else says--one does not need a huge, expensive server on a super-fast Internet connection to host a social network with tens of thousands of users"

I don't think "everyone else" believes that. In fact I believe a "social network with tens of thousands of users" can probably be served off a bash script running on a Raspberry pi over SQLite.

Sort of off topic but I’ve noticed that when push comes to shove a lot of people are very resistant to the notion that the road to hell is paved with good intentions.

The implication being: just because you have good intentions, or because you feel the positivity in your heart, doesn’t mean you’re actually doing good. “But surely”, we all think, “that applies to other people, not me. I would know.”

Blinkered and badly-written take on Open Source, and - to a larger extent - team work in general.

Obviously there are potentially problems with any development model but if you don't have the skill or motivation to be a maintainer in the open or work in good faith without ego within a team, that's cool - but maybe don't assume everybody has the same limitations as you in that regard.

Not much wisdom from this article besides "keep other out, they don't understand your vision".
In this case, the help offered didn't align to the project owner's vision and wasn't accepted as a result. However, that doesn't mean that offers of help should always be ignored - they can often lead to improvements, opportunities, and welcome collaborations.
The author claims that people's offering of help is not true help since it's for selfish reasons. I would like to argue that this is natural and necessary to some extent. People are motivated by what benefits them personally.

All your relationships, pretty much everything you do, has a selfish aspect to it. You're not in a relationship with someone because you're being kind towards them, you're in a relationship because it benefits you, and hopefully it's mutually beneficial.

So, you need to let people be just a little bit selfish, because you need them to be motivated. Without people working for the sake of personal motivation, open source wouldn't work.

Everyone cares about himself and everyone wants the limelight for himself. Divide and rule works perfectly in an egocentered environment. Especially for the work for free, beg for money, fork for yourself os ecosystem.
It is good that the writer could discern that his and the would-be helper's goals were not aligned.

I wonder what the best ways of discovering (and perhaps verifying) alignment-or-not could be.

The mythical man-month is just as true (or even more true) of open source than closed. Just because something is open source doesn't mean it has to be a free for all.
I think the way engineers help open source projects is to send a PR. ‘Offering to help’ without contributing anything seems somewhat suspicious.
Anyone have a link to the post the author referenced here? "A couple of weeks ago, someone else <posted> his desire to help code Xnet, and he included his vision of the direction it should go" (emphasis added)

The way this story was presented makes me curious to see the dialog (if there was any) between the author and the guy who offered to help.

This article talks about two main things. Accepting "help" applies more broadly than engineering or software.

And I agree with his overall goals of his project..I believe the same. We get trapped into this bigger and better and more complicated stacks and the hardware resources required, but you can reach a lot of folks with simplicity and the basics.

I've been finding myself less and less inclined to read semi-long articles so here is Kagi's summary:

The author warns against accepting help from people who are not genuinely interested in helping further the goals of a project. While the offers may seem helpful, these people often waste time driving the project in the wrong direction to suit their own goals. They do not care about the original vision of the project, but instead want the project owner to help them. This was evident when someone offered to help scale up the author's social network, Xnet, without understanding that the author's goals were the opposite - to prove a social network can run on a tiny, low-power server. While scaling up Xnet may have been fun, it was not the purpose of the project. Therefore, the author advises to be wary of offers of "help" and sometimes it is best to do the project yourself.

I'll admit I was going into this thinking it was a warning against some kind of hostile takeover ig said project.

Instead it just reminded me of yanderedevs excuse of not allowing tiny build help him finish yandere simulator, which was very similar to this.

This is literally why git exists.

I wouldn't say 'beware', rather, just say 'fork it and have fun'.

Obviously you have to be a bit selective over who can contribute to a small project.

Or OP could post it on GitHub with integration tests around eg memory footprint.

There’s a mindset shift between “senior engineer” and “tech lead” that OP seems to be struggling with…

This is terrible anti-social advice. Getting projects to work is about organizing people to work together. Unless your DJB, software is a team sport. If it is a one person project it will fail.

Now when somebody offers to help, be welcoming because it's amazing. But also remember that most of the time their desire to help won't translate in to something useful. That's ok, eventually people will show up who are helpful. Keep being open.

Also, what the hell is somebody doing making a social network if they don't like people.... WTF!?

Linus was able to do it. We all benefit from the fact that Linus is a jerk that knows what he is doing and cares about the result.
Now I want to see the unnamed social network.