I admit I was sometimes carried. In creative work this is bound to happen. All people firing on all cylinders and coordinating well is a rarity in creative work. It might work in a kitchen or sailing boat though.

At my university marks and course content was divided up between exams and group projects. Individuals would optimize their own scores by focusing on exam tested content and hoping someone else in the group would carry them. People who wanted top marks always had to carry the entire group as the other members knew they could get away with not contributing and holding the grade hostage. It was a fucking nightmare, and if you complained then you were not a team player. Instead of dealing with a stressful discovery process where people promise to deliver work but fail to at the last minute I would just let the group know upfront that I’ll be carrying them. A lot of people graduated that probably shouldn’t have and I’ve been resentful of group work ever since. This was a top tier university so I’d hate to think that other universities are somehow even less rigerous.

Whenever I taught a course with group work, I would have the students give all the other students in the group a score each week. All the scores had to add up to 100. They had no problem giving any student not participating a zero. There was a formula we would run the scores through to give each student a final score that was a percentage of the total score for the project and their group participation scores. It worked quite well to give those who worked the hardest the most points and those who didn’t do any work zero points.

They tried that, it turned into this metagame with reprisals where others would work together and gang up on you so it would end up being many against one. Basically step one was to find the sucker, step two is make it stick. If you had a rep for good grades then you were de facto the sucker. You could tank the group and hope to fair better in a reshuffle but it was a lemon market and the replacements would be just as bad and now everyone knows you have given your previous team members poor scores. People quickly learned to never do that. So part of the optimization was to present lecturers with what they want to see with only minor deviations between individual rankings, effectively a voting ring. Presenting a false projection of reality in order to metagame politics was accidentally good training for real world work - but it really sucks having to do the work of 4 people.

I’m sure if the lecturers cared they could have managed it properly but they didn’t I don’t know of any who did.

I should point out that I only taught online course. The students lived all over the world and never met in person.

This whole discussion is about that you should expect and embrace this experience because while it’s possible to not end up in an organization like that, it… doesn’t happen often. This is the rare case where uni grading and real life are actually in sync.

There's several types of "carrying".

You have the type where one person is the visionary, is capable, but doesn't have the patience to do the grunt work and only wants to do the most prestigous or "important" shit. They do it well, but expect the rest of the team to do the thankless stuff.

This is the type i hate, and i rather not have them.

The other type is someone who is self-less, and just does the work regardless of self-interest or agenda. They will do both prestigious work, and will also do thankless work, as long as it contributes to the success of the project. They will stay late, fix up other's mistakes, etc, without complaints or expectation that others do the same.

This is the type i admire and want to work with.

> The other type is someone who is self-less, and just does the work regardless of self-interest or agenda. They will do both prestigious work, and will also do thankless work, as long as it contributes to the success of the project. They will stay late, fix up other's mistakes, etc, without complaints or expectation that others do the same.

Been there, done that, it's a career dead-end.

I used to be that person, but the problem is that you’re creating an incentive structure that doesn’t enable the management chain to identify and correct problems. A company should not be standing on the shoulders of a single engineer doing thankless work to prevent catastrophe.

I know several who are in the second category. The problem with constantly fixing other's mistakes is the other people never learn to take responsibility. They know the people carrying the project are not going to let it fail. No matter what, whatever they did is going to get fixed.

Ye. "Super stars" are often just people that stampede the other devs. Like, working together is so inefficient in bigger teams that someone let loose will appear very productive, but he is slowing down everyone else.

That's a very succint description of the arrogant person and the one whom everyone mislabels as arrogant.

You have encountered Price’s Law. https://dariusforoux.com/prices-law/

> Price’s law says that 50% of the work is done by the square root of the total number of people who participate in the work.

Most people see this, and yet the reaction of many is to be deeply, passionately outraged that two people could ever be recognized or compensated differently.

The problem here is that once you have a metric for outsized compensation you make it 10x easier for a cheater to snatch it up merely by turning it into a target. (Lines of code, commits, etc.)

What's worse is that your metric is as likely to be out of sync as code comments. If you're lucky you can notice that a) a new "10x" is actually adding value in a way you never thought to measure, and b) you already spent that 10x money on the employees whose "10x" is hacking your metrics as targets. More likely, you just notice "a" and not "b."

I think the outrage over this goes all the way back to the Greeks. IIRC Plato had a Socratic dialogue about the politician generally beating the expert in debate because the politician is an expert in persuasion. "Being an engineer" isn't a solution because, as you imply, at some point the engineer has to pay the bills. And it's at that point they are out of their element and subject to the politician who specializes in persuading engineers to do things.

If I were wrong, engineers would have long used a web-of-trust to publicly post their salaries (or perhaps anonymized statistics derived from them) to ensure companies aren't taking advantage of anyone at scale.

Edit: clarification

Sure, it’s difficult for people outside the group to reliably ascertain who actually contributed what and how it relates to the final output’s quality. Collective grading in group projects is a sacrifice of a small bit of justice for a great deal of administrative convenience - not the last time that will happen in a student’s life.

But when a system does bother with individual differences in contribution, inequality is seen as necessarily unjust. I don’t see how you can live through a group project and believe that. Some people contributing much more than others or being much more competent than others is eminently plausible! That’s how most things go!

I think the idea that almost everything is a “group project” in life and that the things learned from school group projects carry over beyond to the rest of life holds true. It’s a simplification but has more than an ounce of truth.

Definitely! I had several university group projects where several of the team members did little-to-nothing. If you want to succeed you gotta drag people along. It's actually better if they're honest about it, telling you they're not going to be able to do the work either on time or to the expected standards. Instead, I find people pretend things are "going well", then produce crap other people, superstars or not, have to fix anyway. The top 20% is supporting the bottom 80%.

It took me a while to figure out the underlying problem with "group projects" in school, but I think what I eventually settled on is that there's no way for the grader to have any insight into the group dynamics. Or at least, after some non-trivial thought on the topic, I haven't come up with any. This creates certain inevitable pathologies; why shouldn't the whole group just sort of bet on one of their members doing all the work? Many of these people wouldn't even care if they only get a C out of it, really.

But that doesn't match the real world. In the real world managers dig into that all the time. They develop understandings of the performance of individual team members. If they don't, we call that a pathology and it's their fault because they have all the tools and time they need to do it. Certainly many fail at that and there are plenty of complaints about that in this discussion, but it isn't inevitable the way it is for a school grader.

I see no way to resolve this gap, and as a result, my recommendation, for all the zero good it will do, is that schools need to just accept they can't really simulate a group project and stop assigning them.

For those stuck in them in school, I have no particular advice. I'm not sure what I would do myself if I were placed in such a scenario again. Probably just grumble and be the guy doing the project again.

But for those in a work situation, you have a reasonably good chance of having an option you may not realize: Document, document, document! Document that your current task is blocked on $SLACKER's work. Document that you added unit tests to $SLACKER's work around your needs and they failed and you sent it back. Document that they broke the unit tests to make them pass and it still doesn't meet your needs. Document, document, document.

There's two reasons for this: One, it covers your own bum. You will find that even if at first you may be pushed into being a "team player" there does generally come a point where SLACKER needs to contribute something meaningful themselves to be of any value. Second, to get an employee fired nowadays, you need a solid documentation trail. If your manager does not or can not make one, well, they don't really have to. You can go a long ways towards providing HR with one yourself.

I don't guarantee that will work in every situation, but I would suggest that you not let your cynicism block you from at least trying here. And to be honest, if that just completely doesn't work and you are in a situation where HR is just perfectly OK with a paper trail of documented lack of performance over a period of time, well, maybe that's a signal it's time to leave. Even a cynic can see that paper makes the world go round and you can often turn that to your own advantage with just a bit of effort.

Great points about how managers can help, as it is their job. At a company, there are the incentives but the desired output by any means necessary (e.g. relying on the “superstar”) can supersede creating a solid team.

Regarding improving group projects in schools: This is not a good idea, but a thought: school groups have rotating “managers” that are made to mainly coordinate and communicate with the professor. This mirrors the dynamic in industry, but I can see it becoming a nightmare, far worse than the current paradigm.

Also, documentation is a great idea, and I think pull requests are useful way to track this and improve the situation - by taking action to fix a problem and create an artifact of the action (with comments on the why).

(the $SLACKER env var is a nice touch. The goal is to have never get defined, but alas.)

In my experience, it often does match the real world. Many dev managers are out-of-touch with day-to-day work. They often don't have the time to get into the details. Example: It's been 10 years since I last had one that helped with code reviews, or even looked at PRs. Direct complaints are often ignored because they don't want to rock the boat or deal with the additional work.