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.