Hacker News Reader

Comment by literallyaduck | Hacker News Reader

In school they assign group projects to teach students that given a group one sucker will be stuck with all the work. That sucker is the one that cares the most to get a good grade.

At work it can be the developer who is pissed off the most about the code quality causing development pain or just naive enough to believe they might be rewarded if they care about the code.

In open source it is the pet project owner that often wants to see the project succeed.

It all comes down to who cares the most.

If you care you lay down industry best practices as the fundamentals, you tend the garden of knowledge and encourage pride in making your code the best. You mentor junior devs and put gates around your code to protect it. Fill your seats with developers who are willing to learn, challenge one another to greatness and when you find a hero, don't let them commit again until they have mentored two devs to take on the mantel.

View on HN

> If you care you lay down industry best practices as the fundamentals

Gonna stop you right there. Ever consider industry best practices as not for everything and anything? 'The best' is very subjective.

I’m skeptical anytime someone’s first argument about why to do X is “it’s best practice”. When their second argument is also “it’s best practice” that skepticism deepens significantly.

Yes and no. "Best practices" (if they are indeed best practices, e.g. SOLID) one violates at their own peril. I liken it to an apprentice learning to paint. Once one has mastered the rules of the game, then one can become Picasso and know which rules to break.

Completely agree. "Best practices in our industry" is usually just used to dodge responsibility, or as a cudgel to impose your view on others.

> they assign group projects to teach students that

That’s a pretty curious take. But in some way, it makes a lot of sense.

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.

If you're gonna have the cynical take on group projects, take the one that makes sense.

They require a fraction of the resources to assess.

The problem is that work is lumpy. Sharing work is difficult. To split work among two people they both need to be equally skilled and informed about the task otherwise the faster person will sit idle and take work from others leading to the appearance of a superstar when the truth is that everyone could have done their part even if it's slightly less efficient.

Reply on news.ycombinator.com