This is the second part of my blog mini-series of things university doesn't teach you about software development. Today I've written about group working at university, why it mostly sucks, and what you can try to get out of it.
Thing 2 - Proper teamwork
Very often, computer science courses like to inflict group work on their students, under the guise of teaching (or attempting to force) key skills in working as a team. In terms of results, I view this as an unmitigated disaster.
In the real world, you're motivated to do a good job by many factors - career progression, money, long term commitment to the job/company/product/service, personal pride, respect amongst peers and so on. At university, only the last two really apply, as everything you're doing is unpaid and short-term, and you can almost guarantee that at least one person in any given pre-determined group doesn't care about either.
Not once was I put in the situation where everyone in a project group at university completely pulled their weight, even when we got to choose our own group members (which was rare).
Course tutors often come up with interesting, creative ways to combat these issues - such as making everyone write down what their contribution was - but the problem is that the hard workers want a good grade, not to screw over someone else. Lies go undetected and free-loading is largely unreported, why take the risk of lowering your own grade by admitting that your group didn't work well together?
Why is this better in the real world?
If you find yourself in a real world project team where you're the only one pulling your weight - you can find a better job.
At university you have little choice but to work with what (or whom) you're given, but in the real world, freeloaders get fired and/or good people move to better jobs or companies.
Simply put, freeloading is not a viable long-term strategy in the IT industry. I'm sure there are big companies where you can coast along being an average programmer, but there aren't really any places to hide for those that contribute nothing, and any company with many such people is destined for failure or mediocrity.
Don't take on all the work yourself
Ok, so you might be forced into a group work situation at university, and it sucks, sorry, I don't have any real advice for you. You'll have to make the best of it, and maybe the one thing you might get out of it is some amount of leadership skill (while you try and motivate your group into action).
That said, all I really learned from university group working is that to get a good grade, just take everything on your own shoulders with the other hard working members of the group.
At university this may be the sad reality, but it sets an awful precedent for future employment, where new starters end up keen to work extra hours and try to do everything themselves. I've seen this so often and have had to intervene many times to stop them working 12+ hour days for no reason!
If you get nothing else from this blog post, please don't do this, it impresses nobody and is completely unnecessary. I would be way more impressed with a fresh graduate if on their first day they asked where their responsibilities begin and end, and properly understood their work commitments.
How could group work at university be improved?
I have a few thoughts on this, but the first and most important is: don't intertwine it with grades for other pieces of work, even if it's really convenient. All this does is detract from the task you're asking students to work on, and by my reckoning saddles just about every group with the above problems.
Not only is it unreasonable and likely damaging to grade group work as part of some other project, I would suggest that in fact, it shouldn't be graded at all. Group work / teamwork is a fundamentally qualitative skill and I'm not sure if one could assign any meaningful grade to an individuals contribution to a task without relying fundamentally on honesty and fairness (which are proven to be unreliable in such a setting).
Teamwork should be treated as its own lesson, and used as an opportunity to teach the tools that are relied on in the real world; tools such as:
- version control
- bug / issue trackers
- code reviews and pull requests
- group chat (IRC, Slack, HipChat, Hangouts)
- screen sharing and video conferencing
- daily stand-ups, sprint cycles, retrospectives
- wiki / documentation tools
- pairing or group programming
- web forums
These are all things that are useful to learn about and have experience of. Many of them are free and you could get benefit from them immediately.
In the non-academic world they're all commonplace (nay, essential) and students would benefit from using them right from the start of their studies. I look back now and imagine how much easier and more effective a lot of my learning would have been if we'd used these tools to collaborate as a matter of course.
What about soft skills?
It's possible to directly teach soft skills, but a lot them will come out naturally if the above tools are learned and used.
Sprint cycles encourage planning, retrospectives encourage people to give open feedback, the various development tools encourage negotiation, division of labour, and communication. This is all great stuff you get more-or-less for free given the right setting.
What universities should take away from this
It's a waste of everyone's time forcing faux-teamwork into normal coursework assignments, or worse, dissertations (yes, apparently group dissertations are a thing). All it really accomplishes is increasing the stress levels of those within a group who want good grades, who end up putting in a disproportionate amount of effort, and letting the weaker group members coast on the effort of others. Surely nobody wants to see that.
If you want to grade individuals, grade them as individuals.
Teamwork is, however, something that should be taken seriously, and teaching and encouraging the use of tools to facilitate it would be hugely beneficial, even if not directly measurable.
What students and graduates should take away from this
I've listed a bunch of tools above that are useful in the real world, and would also be hugely useful in an academic setting. I would encourage you to use them at the earliest opportunity. Work together not because you're forced to, but because you will learn faster and pick up new skills at the same time. Work together because you want to.
Even if you can't find an academic use for teamwork tools or teamwork skills in general, try contributing to an open source project. Many projects will use some or all of these tools and would be happy to help you learn new skills in return for your contributions.
Next up
Next week I'll be writing about regression (the type of bug, not the mathematical modelling kind) and why it's important to know about the risks of making changes to different areas of your software.