I can't remember where I heard about this, but isn't there some kind of "surgeon model" where you have one star player do the majority of work, and everyone else is support staff? It's a pattern that emerges, and not a bad thing to encourage, as long as it's acknowledged. Everyone has their strengths and weaknesses. But in college, usually everyone has to be graded equally (akin to everyone being paid equally). Administrative and support work is still important, because without it, a surgery or a project won't succeed. Kinda like the 10x dev thing, but for group dynamics in general.

That's the Fred Brooks "chief programmer" model that the post mentions in the first paragraph. Brooks describes it in one chapter of _The Mythical Man Month_, which is one of those rare cases of a book in the tech field that's still interesting and readable decades after it was written. If you haven't read it yet and you like that kind of book that's about the underlying principles of the craft of writing software rather than specific technical detail, I recommend it.

This blog post is a short read on the the book: https://medium.com/@dvxwang/book-lessons-the-mythical-man-mo...

That's an exagerrated take. I think schools assigns group projects to students, so that they can learn all kinds of group dynamics, mooching off of harder working people being merely one of them.

When I first saw that a local tech school was emphasizing group projects, my thought was: "Great. Now they will have ten additional years to tire of corporate-style work, even before they start."

well it's a cynical, misanthropic take on how the world works, but I would be interested in seeing anyone finding a manual on teaching suggesting this as the lesson to be learned from group work.

It accurately represents at least 60% of the group projects I was involved in school, though usually the rule wasn't 1, but 2 people that cared with most others not caring. What it taught me is that the most important thing to be successful in group work is to be able to select the group members.

Chose those with a panicked look in there eyes, who want to limit scope when asked and ask ahead of how "last years projects went".

Ask who is willing to do documentation, do not chose anyone volunteering for that.

yeah, I think that is closer to what it teaches. I think there will be at most 2 or three top people in the project, and then some lesser contributors who are skating - maybe because they are not that interested in that project and they are the leads in some other project that is running concurrently.

It is accurate description of group projects in school.

Real teamwork on the job does not work that way, unless management sux. When management checks out and stops managing/leading, it can descent there too.