5 ms·

> 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 becom

by rob74 3y ago

> 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.

atoav 3y ago
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.
- Applejinx 3y ago
  This hugely assumes that the point of an open source project is to have other people do it, and 'caring about it' means doing the work of it. Not always true. My own open source world operates on different principles: I'm there to explore in a particular direction, not always fruitfully. Near as I can tell there isn't anybody else walking that particular beat, which among other things implies that it's a really niche interest, and that suits me just fine. But it means I can't get other devs in to pursue this direction, because they simply won't. So my use of open source turns into a one-way faucet: rarely is there a situation where I'm able to take anything back, it's always about facilitating other people to build THEIR projects making use of whatever they find useful in my codebase. I almost never get any help with my project, and this is fine. Maybe it works better for everyone that I don't try to get people to do my will, don't treat them as dumb paid labor. People are often very clever but caught up in doing things I don't find at all useful, not unlike the author's objections as a 'helper' tries to convert his social-media-democratization project into a much more elaborate creation that fails all the author's requirements. This is where the other person would fork and be done with it: seems rude to try and shake the original dev from his fundamental motivations with the project. Question. If the original person is so niche that they'll create something original but unhelpful to most people, and the interloper is far more in tune with popular demand and will create something that is meh but popular, is forking the project and making two projects, the niche one and the meh popular one, bad? If this is done and it upsets the original dev, who sees his vision desecrated by a garbage knock-off, and he quits and goes and jumps off a cliff, is THAT bad? The latter is an extreme, but I'm reminded of so many stories from history and media along these lines. The most popular comic strip in history is named 'Peanuts', and was always the work of one man, Charles Schulz. Everything about it was him on the page… except the name, which was forced on him by the syndicate, over his preferred Lil' Folks. Schulz never came to terms with the name Peanuts. He saw it as 'little worthless things, things of little value'. This of course echoed the neuroticism of his very intelligent and fretful characters, forever worrying about their own value, and so lampshading that in the title of the strip has probably helped its popularity, as it's a guide to the kind of humor within. Let's postulate that Schulz was able to use Lil' Folks, or even 'these are awesome self-actualized people worthy of love and respect, just like me the cartoonist', and let's imagine that he could do this and totally nerf the adoption of the strip, allowing the cartoonist's needs to intrude on the art. Should he have? What's more important, his ownership of the project, or what it could become?
oreally 3y ago
Well he has a vision for his project, and so by his own definitions he is essentially as narcissistic as the newcomer is by accepting all new contributors without setting expectations. Not setting expectations from the outset, especially in an 'open' setting, leads to more problems down the line. This would deter newcomers of course, but you'll probably not want those types anyway.
- SkipperCat 3y ago
  100% agree. Communication and setting expectations are key in making any project with 2 or more people successful.
  - JohnFen 3y ago
    I think the point is that this is a project with 1 person.
- mannykannot 3y ago
  > ...he is essentially as narcissistic as the newcomer is by accepting all new contributors without setting expectations. But the whole point of the article is to explain why he does not do that! Setting expectations is no panacea. A non-trivial fraction of volunteers will nominally accept the expectations but do what they want anyway. Another non-trivial fraction will also accept the expectations but then go along with anything those of the first group suggest. These are universal facts of organizations of any type, not just technical development teams.
Closi 3y ago
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).
- stakhanov 3y ago
  > There is a minor irony that the author has another blogpost on how micromanaging bosses are awful... It's not as contradictory as it sounds, to complain both about micromanaging bosses and about underlings kidnapping projects. But one needs to switch the framing from universal truths about team organization to psychology. I can relate to the situation quite closely because I think it's the same overall situation that I find myself in. I might be totally off the mark here because, like anyone, I can't read minds, but let me engage in some speculation. The ability to have truly peer-to-peer relationships that are not based on any one side dominating the other is very rare. One needs to have a highly developed psyche to be capable of such relationships, so only a small minority of people have this ability. The vast majority of all human relationships work on a "dominate or be dominated" principle. If you consistently find yourself on the losing end of power struggle, you start to see everyone as a threat to your autonomy. The result is that you work alone. Obviously, that's extremely limiting, and, for myself, I find it extremely painful to try to develop through that.
- kazinator 3y ago
  Well, yes; his way is the best. Not the boss's way, and not the way of some meddling coworkers that want to form a team around the project. It's perfectly consistent. The centre of the org chart is the (ME) bubble, surrounded by meddlers and interlopers.
civilized 3y ago
> Er... reading this, I would rather suspect the author of "not being a team player". Of what team?
- Closi 3y ago
  I assume OP is referring to all the teams the author said he worked on in the article, as referenced in the second paragraph: > As an engineer, I have worked with many, many other engineers on dozens of projects.
- bratbag 3y ago
  Any team they happen to be in. Teamwork is collaborative and new people always bring new ideas. One of the challenges of looking after a team of engineers is setting up a team culture that allows ego-free analysis of that, rather than rigidly sticking to one approach no matter what. Ego-heavy engineers are quick to treat anything but their personal opinion as the wrong approach.
  - marginalia_nu 3y ago
    You desperately need to let go of that oompa-loompa mentality when it's your own project. You need vision and ego if you're going to successfully lead a software project. You can't treat everyone who happens to pass by as a team-member whose opinions are as valuable as your own. Listen and let yourself be convinced, sure, but it's crucially important to be able to say "no, this feature is not in line with the vision for the project". Say yes sometimes too, by all means, but when you're in the position of the primary author and leader of the project, it's your call to make. If you say yes to every idea anyone brings by, you'll end up with The Homer[1]. [1] https://simpsonswiki.com/wiki/File:The_Homer.png https://simpsonswiki.com/wiki/File:The_Homer.png
    - OJFord 3y ago
      > If you say yes to every idea anyone brings by, you'll end up with The Homer[1]. Judging by the description of it/the episode (https://simpsonswiki.com/wiki/The_Homer https://simpsonswiki.com/wiki/The_Homer), it seems to convey the opposite message? It was one person's (Homer's) vision, no input from others?
Kiro 3y ago
> and they are free to fork the project and take it into another direction What makes you think this is open source?
- Applejinx 3y ago
  If it isn't, and it's working great for what it is, that would explain a lot of outside pressure and people pitching him on their inappropriate visions :)
davisoneee 3y ago
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.
- Mizoguchi 3y ago
  "As an engineer, I have worked with many, many other engineers on dozens of projects." Maybe I don't know how to read, but that suggests a corporate setting to me.
  - kazinator 3y ago
    While the author mentions having this corporate experience, the article's point is organized around the author's social network project code-named "XNet", which seems personal. He wrote it in 2000 lines initially and put it on the Internet; if that was on the job somewhere using company machines and network, he'd be fired.
  - davisoneee 3y ago
    The initial paragraph talks about {author} creating a project and not putting it on github. That seems directly to me to be personal, and related more strongly to the idea that you have a direction for the project. The followup seems like a bit of context to combat the idea that additional manpower does not just give free productivity. If its corporate, your 'direction' doesnt matter. Your boss, and their boss, tell you what the direction is and the discussion is around implementation. Therefore, arguing direction change from project newcomers doesnt make sense.
- deleted 3y ago
  [deleted]
- HelloNurse 3y ago
  Experimental projects tend to be personal, even in a corporate setting, because team projects are usually too large to be a mere experiment (for example, they can become serious product prototypes rather than pure testbeds).
bayindirh 3y ago
> 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.
- HelloNurse 3y ago
  In the article's example the original "small" Xnet and the other person's vision for "big" Xnet are two projects of the second type, but their vastly different objectives might be at least partly trascended and reconciled by adding a project of the first type: common standards and interfaces that allow both Xnet incarnations to serve the same content and substitute each other, thus providing practical value to actual users rather than experience to the authors.
  - bayindirh 3y ago
    > thus providing practical value to actual users rather than experience to the authors. Do we need to convert everything we develop to something which provides practical value to actual users? Some of us code for fun, and put what we do out there. If it's used, we're happy. If not, it doesn't matter since we're the primary users of our code anyway. Novell (IIRC) provided MyRealBox e-mails as a free service for beta testing their mail servers. The web interface was crude, but it worked flawlessly over the years they provided the service. The practical value was secondary, and we provided lots of data for the developers of the stack. We were happy even though we knew what it was. One day we received a mail about EOL'ing the thing, we migrated away, and it's gone. No hard feelings whatsoever. I think we should stop putting frames and projecting our ideals on anything which looks similar to something we have on our minds.
kazinator 3y ago
> 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.
mannykannot 3y ago
In my experience, the behaviors listed in the passage you quote are not uncommon (though, also in my experience, not common enough to justify characterizing "most of the newcomers" as such.) They are objectively harmful to the goals of the project, and if being a team player requires accommodating them unconditionally, you can count me out, too.
Applejinx 3y ago
>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 :)
- bayindirh 3y ago
  Maybe he's a great team player and loves his projects with a passion and doesn't want people to touch what he builds for himself, no? He's talking about his personal projects, and many comments are projecting how he behaves for his personal projects to his career? Does everyone know who he's personally and I'm the only stranger?
  - tuxie_ 3y ago
    > Maybe he's a great team player (...) and doesn't want people to touch what he builds for himself Isn't that the exact opposite of being a great team player? I had a boss who was "a great team player" once. We were both working for a rapidly growing startup and he was very open to suggestions on how to improve the system. So naturally when he started his own project I was very much eager to work with him again. Turns out that it's easy to be a great team player when you are spending someone else's money and changing someone else's code. When I proposed changes to the system he built himself he took it very personal and all of a sudden he was not so open anymore. It's easy to be generous with other people's money.
    - pdimitar 3y ago
SkipperCat 3y ago
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.
marvinblum 3y ago
This reminds me of Gogs [0], where the original author refused a lot of good ideas and improvements, eventually leading to a fork [1] that's now a lot more popular and active than the original. [0] https://gogs.io/ https://gogs.io/ [1] https://gitea.io/en-us/ https://gitea.io/en-us/
JohnFen 3y ago
> 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.
pdimitar 3y ago
> 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. :)
loa_in_ 3y ago
A perfect use case for git branches (one for each developer) and cherry picking features into the main branch. Git makes it almost impossible to make a negative contribution, except maybe for security stuff.

by rob74 3y ago

atoav 3y ago

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.

Applejinx 3y ago
This hugely assumes that the point of an open source project is to have other people do it, and 'caring about it' means doing the work of it. Not always true. My own open source world operates on different principles: I'm there to explore in a particular direction, not always fruitfully. Near as I can tell there isn't anybody else walking that particular beat, which among other things implies that it's a really niche interest, and that suits me just fine. But it means I can't get other devs in to pursue this direction, because they simply won't. So my use of open source turns into a one-way faucet: rarely is there a situation where I'm able to take anything back, it's always about facilitating other people to build THEIR projects making use of whatever they find useful in my codebase. I almost never get any help with my project, and this is fine. Maybe it works better for everyone that I don't try to get people to do my will, don't treat them as dumb paid labor. People are often very clever but caught up in doing things I don't find at all useful, not unlike the author's objections as a 'helper' tries to convert his social-media-democratization project into a much more elaborate creation that fails all the author's requirements. This is where the other person would fork and be done with it: seems rude to try and shake the original dev from his fundamental motivations with the project. Question. If the original person is so niche that they'll create something original but unhelpful to most people, and the interloper is far more in tune with popular demand and will create something that is meh but popular, is forking the project and making two projects, the niche one and the meh popular one, bad? If this is done and it upsets the original dev, who sees his vision desecrated by a garbage knock-off, and he quits and goes and jumps off a cliff, is THAT bad? The latter is an extreme, but I'm reminded of so many stories from history and media along these lines. The most popular comic strip in history is named 'Peanuts', and was always the work of one man, Charles Schulz. Everything about it was him on the page… except the name, which was forced on him by the syndicate, over his preferred Lil' Folks. Schulz never came to terms with the name Peanuts. He saw it as 'little worthless things, things of little value'. This of course echoed the neuroticism of his very intelligent and fretful characters, forever worrying about their own value, and so lampshading that in the title of the strip has probably helped its popularity, as it's a guide to the kind of humor within. Let's postulate that Schulz was able to use Lil' Folks, or even 'these are awesome self-actualized people worthy of love and respect, just like me the cartoonist', and let's imagine that he could do this and totally nerf the adoption of the strip, allowing the cartoonist's needs to intrude on the art. Should he have? What's more important, his ownership of the project, or what it could become?

oreally 3y ago

Well he has a vision for his project, and so by his own definitions he is essentially as narcissistic as the newcomer is by accepting all new contributors without setting expectations. Not setting expectations from the outset, especially in an 'open' setting, leads to more problems down the line. This would deter newcomers of course, but you'll probably not want those types anyway.

SkipperCat 3y ago
100% agree. Communication and setting expectations are key in making any project with 2 or more people successful.
- JohnFen 3y ago
  I think the point is that this is a project with 1 person.
mannykannot 3y ago
> ...he is essentially as narcissistic as the newcomer is by accepting all new contributors without setting expectations. But the whole point of the article is to explain why he does not do that! Setting expectations is no panacea. A non-trivial fraction of volunteers will nominally accept the expectations but do what they want anyway. Another non-trivial fraction will also accept the expectations but then go along with anything those of the first group suggest. These are universal facts of organizations of any type, not just technical development teams.

Closi 3y ago

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).

stakhanov 3y ago
> There is a minor irony that the author has another blogpost on how micromanaging bosses are awful... It's not as contradictory as it sounds, to complain both about micromanaging bosses and about underlings kidnapping projects. But one needs to switch the framing from universal truths about team organization to psychology. I can relate to the situation quite closely because I think it's the same overall situation that I find myself in. I might be totally off the mark here because, like anyone, I can't read minds, but let me engage in some speculation. The ability to have truly peer-to-peer relationships that are not based on any one side dominating the other is very rare. One needs to have a highly developed psyche to be capable of such relationships, so only a small minority of people have this ability. The vast majority of all human relationships work on a "dominate or be dominated" principle. If you consistently find yourself on the losing end of power struggle, you start to see everyone as a threat to your autonomy. The result is that you work alone. Obviously, that's extremely limiting, and, for myself, I find it extremely painful to try to develop through that.
kazinator 3y ago
Well, yes; his way is the best. Not the boss's way, and not the way of some meddling coworkers that want to form a team around the project. It's perfectly consistent. The centre of the org chart is the (ME) bubble, surrounded by meddlers and interlopers.

civilized 3y ago

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

Closi 3y ago
I assume OP is referring to all the teams the author said he worked on in the article, as referenced in the second paragraph: > As an engineer, I have worked with many, many other engineers on dozens of projects.
bratbag 3y ago
Any team they happen to be in. Teamwork is collaborative and new people always bring new ideas. One of the challenges of looking after a team of engineers is setting up a team culture that allows ego-free analysis of that, rather than rigidly sticking to one approach no matter what. Ego-heavy engineers are quick to treat anything but their personal opinion as the wrong approach.
- marginalia_nu 3y ago
  You desperately need to let go of that oompa-loompa mentality when it's your own project. You need vision and ego if you're going to successfully lead a software project. You can't treat everyone who happens to pass by as a team-member whose opinions are as valuable as your own. Listen and let yourself be convinced, sure, but it's crucially important to be able to say "no, this feature is not in line with the vision for the project". Say yes sometimes too, by all means, but when you're in the position of the primary author and leader of the project, it's your call to make. If you say yes to every idea anyone brings by, you'll end up with The Homer[1]. [1] https://simpsonswiki.com/wiki/File:The_Homer.png https://simpsonswiki.com/wiki/File:The_Homer.png
  - OJFord 3y ago
    > If you say yes to every idea anyone brings by, you'll end up with The Homer[1]. Judging by the description of it/the episode (https://simpsonswiki.com/wiki/The_Homer https://simpsonswiki.com/wiki/The_Homer), it seems to convey the opposite message? It was one person's (Homer's) vision, no input from others?

Kiro 3y ago

> and they are free to fork the project and take it into another direction What makes you think this is open source?

Applejinx 3y ago
If it isn't, and it's working great for what it is, that would explain a lot of outside pressure and people pitching him on their inappropriate visions :)

davisoneee 3y ago

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.

Mizoguchi 3y ago
"As an engineer, I have worked with many, many other engineers on dozens of projects." Maybe I don't know how to read, but that suggests a corporate setting to me.
- kazinator 3y ago
  While the author mentions having this corporate experience, the article's point is organized around the author's social network project code-named "XNet", which seems personal. He wrote it in 2000 lines initially and put it on the Internet; if that was on the job somewhere using company machines and network, he'd be fired.
- davisoneee 3y ago
  The initial paragraph talks about {author} creating a project and not putting it on github. That seems directly to me to be personal, and related more strongly to the idea that you have a direction for the project. The followup seems like a bit of context to combat the idea that additional manpower does not just give free productivity. If its corporate, your 'direction' doesnt matter. Your boss, and their boss, tell you what the direction is and the discussion is around implementation. Therefore, arguing direction change from project newcomers doesnt make sense.
deleted 3y ago
[deleted]
HelloNurse 3y ago
Experimental projects tend to be personal, even in a corporate setting, because team projects are usually too large to be a mere experiment (for example, they can become serious product prototypes rather than pure testbeds).

bayindirh 3y ago

> 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.

HelloNurse 3y ago
In the article's example the original "small" Xnet and the other person's vision for "big" Xnet are two projects of the second type, but their vastly different objectives might be at least partly trascended and reconciled by adding a project of the first type: common standards and interfaces that allow both Xnet incarnations to serve the same content and substitute each other, thus providing practical value to actual users rather than experience to the authors.
- bayindirh 3y ago
  > thus providing practical value to actual users rather than experience to the authors. Do we need to convert everything we develop to something which provides practical value to actual users? Some of us code for fun, and put what we do out there. If it's used, we're happy. If not, it doesn't matter since we're the primary users of our code anyway. Novell (IIRC) provided MyRealBox e-mails as a free service for beta testing their mail servers. The web interface was crude, but it worked flawlessly over the years they provided the service. The practical value was secondary, and we provided lots of data for the developers of the stack. We were happy even though we knew what it was. One day we received a mail about EOL'ing the thing, we migrated away, and it's gone. No hard feelings whatsoever. I think we should stop putting frames and projecting our ideals on anything which looks similar to something we have on our minds.

kazinator 3y ago

> 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.

mannykannot 3y ago

In my experience, the behaviors listed in the passage you quote are not uncommon (though, also in my experience, not common enough to justify characterizing "most of the newcomers" as such.) They are objectively harmful to the goals of the project, and if being a team player requires accommodating them unconditionally, you can count me out, too.

Applejinx 3y ago

>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 :)

bayindirh 3y ago
Maybe he's a great team player and loves his projects with a passion and doesn't want people to touch what he builds for himself, no? He's talking about his personal projects, and many comments are projecting how he behaves for his personal projects to his career? Does everyone know who he's personally and I'm the only stranger?
- tuxie_ 3y ago
  > Maybe he's a great team player (...) and doesn't want people to touch what he builds for himself Isn't that the exact opposite of being a great team player? I had a boss who was "a great team player" once. We were both working for a rapidly growing startup and he was very open to suggestions on how to improve the system. So naturally when he started his own project I was very much eager to work with him again. Turns out that it's easy to be a great team player when you are spending someone else's money and changing someone else's code. When I proposed changes to the system he built himself he took it very personal and all of a sudden he was not so open anymore. It's easy to be generous with other people's money.
  - pdimitar 3y ago

SkipperCat 3y ago

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.

marvinblum 3y ago

This reminds me of Gogs [0], where the original author refused a lot of good ideas and improvements, eventually leading to a fork [1] that's now a lot more popular and active than the original. [0] https://gogs.io/ https://gogs.io/ [1] https://gitea.io/en-us/ https://gitea.io/en-us/

JohnFen 3y ago

> 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.

pdimitar 3y ago

> 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. :)

loa_in_ 3y ago

A perfect use case for git branches (one for each developer) and cherry picking features into the main branch. Git makes it almost impossible to make a negative contribution, except maybe for security stuff.