Learning to collaborate is learning to be employable

We help our software engineering students by helping them learn to collaborate effectively.

A lot of what we teach computing science students is domain knowledge, that only works in CS. I’m thinking of programming paradigms for specific languages, and knowing how to put an application together. These are interesting to us, but less useful in day-to-day life.

Some things we teach students work across different domains though. For example, Boolean logic is useful in search engines, and some search algorithms help when trying to find a specific spot in a digital file, or when looking through record bins for an LP.

Collaboration is a life-long transferable skill that works in software engineering as well as other types of projects where you collaborate as a team member. The key to collaboration is process, and this is transferable across any project as you’ll see.

With this in mind, the more opportunities we provide our students to practice collaboration, then the more employable they are as graduates. By providing collaboration opportunities students can learn how to do this better and better with each time they practice.

All developers are collaborators

Solo developers are rare these days in software development. The only one that comes to mind is the person who came up with Wordle, before selling it to the New York Times. All indie developers also have clients, and often collaborate with graphics people, so again: not really solo. This means it is important to teach our students how to collaborate effectively.

Even those few students who go onto do PhDs and join the ranks of academia should learn to collaborate. The will work in teams of researchers, and write papers with collaborators. All of this applies to them too.

Teaching students the collaboration rules helps make all students more employable. By teaching them the human-side of software development, we help make them more likely to succeed in whatever they do after they graduate.

1. Always be collaborating, instead of working on your own. Students learn how to work with others on the same task by pairing, or mobbing as a team.
2. Aim for diversity to improve your work. Students learn to take the time and make the effort to understand the issues being raised by the person, who sees something others on the team are missing. This means seeing the value of the patience involved in making this work.
3. Work in the open so the team can see your work sooner. The student will be able to explain why working solo, and keeping their work to themselves in separate branches of code slows the team down. Some will also be able to explain what happened after they changed to more open work.
4. Be humble and ask for help and feedback. Students should learn they aren’t expected to always know the answer, and that asking for help is normal. They should also learn the value of early feedback, and steps to shorted feedback loops in teams.
5. Meet regularly with a suitable cadence for your context. Student teams should learn how frequently they need to meet to set up work to do as a team.
6. Accept that it’s all guesswork and start small to learn more. Students should also learn that estimating is always a challenge, and that is it often better to just start doing something in small, vertical slices (as below) so that they can start to learn more.
7. Build deployable small vertical slices to learn more quickly. This should be something they all learn and can explain to employers, as it is a key issue in all work and is extremely transferable across domains.
8. Keep doing the next riskiest item in order to reduce risks quickly. This too should be done as part of the thin vertical slice so that they learn to de-risk application development.
9. Shorten your feedback loops, so that you learn faster. Students should learn that feedback comes in many forms and has many purposes. Sometimes it is tests for your code telling you something is wrong, other times it is a colleague pointing out that you’ve not merged your code recently, or your client asking about possible changes.
10. Always be pausing to review your collaboration. No collaboration is perfect. Students should learn to pause to reflect on how they might improve their team’s collaboration processes.

By applying the collaboration rules in their team software engineering product development course, each student will have experience to use. They can tell stories of how they applied each of these principles in their team. Even if it didn’t go great for the team, they will be able to explain what they tried, and why they tried what they did to improve the collaboration.

Go over these collaboration rules with your students

You helping your students to collaborate makes them more employable. Create as many opportunities to practice them as you can in your degrees. They will thank you later. You too just need to start, and you can review, and improve as you learn too. As noted below, you can find more about the collaboration rules in the book.

---