Code Collaboration Jungle: Working In a Fearsome Four-Some

The October 2014 cohort is about to begin their final projects. The last assignment is Crowdfunder, a copy of Kickstarter, for which possible user stories total upto about 40. On this week's fateful Monday afternoon, when the assignment was introduced, we were explicitly instructed to work in groups. Most of my cohort opted to work with one other person in a pair. I decided to work in a group of four people. If you listen to the previous cohort's podcast here (, they will let you know that this probably won't be a good idea for the final project. But for experience's sake, I wanted to try it out on Crowdfunder, because it's the last assignment meant to prepare you for the project. And moreover, in today's work environments, especially in modern-day devshops, working in a team is near inevitable.

That being said, the challenges in working in a group of more than two aren't as monumental as I first expected. Today's the last day of the assignment. Throughout the days, it required clear commmunication, patience, and strategy. Sound GitHub practices will save your sanity, and keep the momentum going. I'd like to outline the most important difficulties and offer some words of encouragement.

Group Work

1) Working in a group of four means that you will be splitting up the work between two pairs of programmers. Hopefully you've already been working in pairs throughout the weeks Bitmaker. But regardless, work on a single computer together. Two brains are stronger than one! You will make less minor mistakes that bog down the coding process, such as typos and faulty syntax. You will be able to break down the logical steps needed to tackle a program's feature together. And explaining things the other person doesn't understand helps you process the information yourself, creating deeper associations in your mind.

2) Use Github well. Be a friend and describe (thoroughly!) what exactly you've just committed. We've been given lots of advice on this at Bitmaker, but essentially, you want other people to know what you're doing. The more information you offer, the more likely your group members will like you.

3) Do standups. Standups are like a pow-wow, where everyone regroups and goes over what he/she has been working on, what issues came up, and decide who should do what next. It's also useful if you're merging branches back into the master. If both pairs have branches to merge, and the two features are for similar areas of the app, there will be conflicts to deal with. Merging conflicts will work more fluidly if everyone in the group is present and ready to discuss the changes required to maintain your master branch in a deployment-ready state.

4) Do not be afraid of conflicts (in your code, specifically). The prospect of merge conflicts may be daunting at first. As long as you're in your own feature branch, and the master branch is in working order, there's no reason to hold back on foraying into unknown territory. If both pairs know which features are being worked on, you'll be able to communicate what changes need to take place later. Just tackle the next feature, and get your group members to sit with you and pull through the conflicts later.

All in all, it's been a rewarding week. I was initially very intimidated by merging conflicts, but when everyone's aware of each other's progress, it can go swimmingly. Because it's more difficult than having one workflow of your own, once it's all merged into the master again, it feels like a bigger win. And really, with all the communication and planning challenges that come with working in a bigger group, you should celebrate every one of these wins. So why not try out working in a bigger group? It'll prepare you for a future job in a devshop, and you'll find people who you can work well with. Wins all around.

By Stella Kim