Learning to code … as part of a team!
Our routine at Makers has been shaken up a little bit over the past couple of weeks. Up until now, we’ve had a pretty standard routine of working through a weekly challenge in rotating pairs — with our pairs changing every day and standard steps to guide us through the content.
However, I’ve now spent the last two weeks working in teams of four with just user stories (no challenges or walkthroughs) as guides. During week 5, we were all put into teams and had no choice on the matter, and since then, we’ve had the option to continue working in teams or go back to pairing.
These team projects have been a really fun experience and opened up lots of insight into the advantages and challenges of teamwork — with merge conflicts, planning processes and communication being major themes. Hopefully, this learning will stand us in good stead for the world of work.
Getting to grips with merging
The biggest area of learning has to be git. We’d never really worked with branches before and resolving merge conflicts was a steep learning curve. As any junior developer knows, git can be a bit scary and when it goes wrong, it can be tempting to just fire commands at it until you’re back on safe ground.
When working in pairs, the general approach to merge conflicts, for example, was just been to git push -force your way out of it (bad, right?). But when you’re working as part of a team on different branches, you can’t really do this. You actually need to resolve the conflicts.
During the first few days, we stuck with merging branches and resolving merge conflicts in Github. It’s a little friendlier! But by the end of the second week, we were doing it in the command line — and with a slight air of confidence. Another major technical skill down!
Spending the first day planning
We also paid a lot of attention to planning — which worked in our favour. Teams that skimped on planning at the beginning of the week definitely paid for it later on. Thankfully, we were lucky enough to have a start-up founder and a user experience designer in our team, so they knew to plan.
During the first day of the project, we expanded out the user stories from the specifications with full acceptance criteria, diagrammed our domain model and database associations and defined our MVP (Minimum Viable Product). When we reached the end, it seemed like a daunting task.
Yet, despite seeing the list of thirty plus user stories and wanting to run in terror, it actually really helped having such manageable bitesized steps. Once we got started, we realised that we could race through them as they were so well-defined. We reached MVP by the end of the second day!
Debugging with four brains is better than two
By having this opportunity to work in a team, we were also able to start figuring out our own processes that worked for us. One thing that we decided to do during the middle of the week was to regroup if anyone got particularly stuck on a bug.
We had a few instances in which one of the pairs in the team got blocked on a tricky bug that kept them back for a good few hours while the other pair raced ahead. It was not only inefficient, but could be quite disheartening if you’re in the pair that’s feeling left behind.
So, we decided to have a system in which the stuck pair could raise their hand to ask for help and all four of us would sit around together at one computer until the problem was solved. It worked really well! It held us together as a group and solved problems faster.
Finding ourselves one down
Nonetheless, it wasn’t all plain sailing. During the second week, we had some issues with attendance with myself ending up off sick on both the Tuesday and Wednesday and then another team member getting ill on Thursday and Friday.
It was a bit of a shame for many reasons. It was obviously not ideal having a reduced team. But we hadn’t anticipated some of the issues that it would raise. It created problems, for example, with dividing up the work as we then had an odd number of team members which prohibited pairing.
We decided to work in threes, but it wasn’t ideal as the communication broke down when the directions from the two navigators contradicted. It was also difficult engaging the remote team members when they wanted to participate — as it’s hard to give real detail over instant message.
Being motivated by the buzz
Still, despite these challenges, teamwork was really, really fun! It was an immensely fulfilling way of working, as well as an educational experience for us all. And ultimately, working as part of a team was a lot more motivating than working through exercises with different people each day.
When you’re working in a team with just a brief specification, you have a sense of a common goal and a degree of influence in the nature of the final product. It really fires you up to make something of the opportunity and not let your other team members down.
We pushed ourselves and ended up with really fine end products in both the first and second week. During the first week, we went above and beyond the specs to figure out image upload and, in the second week, we finished the first project and moved onto a second one.
Conclusions
I’m excited to work as part of a team again — which is handy, as next week, it’s “practice project week”. I’d taken a break for one week to go back to pairing for learning Ruby on Rails. It seemed to me that when learning a whole load of concretes, some exercises might be welcome guides.
But, we’re now (with four weeks left of the course), going to spend three more of those working as part of a team. So, even more chance to hone my processes, approaches and git skills. It is really good that Makers Academy give us this opportunity, as it’s much more how it works in the real world!
