Working as a team

Week 6 at Makers was dedicated to projects - in particular, creating Makersbnb; a site where hosts can list ‘spaces’ that can be booked by users looking to holiday. We worked in teams, so for the entire week, my pairing buddies were Jack, Ruan and Jess. Although we only worked on this for four days, I felt like I learned a huge amount about working in a development team that wasn’t involved in the pairing we had done up until now. One of the most notable of these was Github management: in the first few weeks of pairing, we would swap pairs every day despite working on the same task throughout the week. We would pick up on the repo of the person who was furthest behind each day, which meant that by the end of the week, any work we could meaningfully take ownership of was spread across four or five repositories and in a bit of a mess. The idea of using branching and merging to rationalise this mess was terrifying. Working in teams this week meant that we learned how to make use of Git as a collaboration tool, which was extremely useful. By the of the week I felt like we had a product we were all proud of, and realised how much can be accomplished in a short space of time by a group of people.

“Stick to what you know.” This was the advice Roi gave us at the beginning of the week. We could ostensibly use whatever method we liked to build our product, but given the timeframe and the purpose of the task, it was clear we would be building a Sinatra app with a PostgreSQL database. I actually really enjoyed the opportunity this week to revisit Ruby, Sinatra and databases, as it let us consolidate what we have already learned. After spending a lot of the weekend wrestling with Javascript, I began the week instinctively littering my Ruby with semicolons and empty parentheses before remembering that it was unnecessary. It felt very natural to move back to coding in Ruby, and now feel much more confident with it.

The most valuable takeaway from this week for me was the experience of working in a team to build something. Working on weekly assignments had so far involved following a set of exercises rather than planning out the structure of the plan ourselves. Our group project involved four days of independent work where we planned out what we were going to build and how we were going to build it ourselves. This meant that good communication was essential for us to coordinate effectively. We spent the first morning planning out what we were going to build, and proceeded to have check-ins twice a day to discuss the tasks we would work on next and who would do them. We used Waffle to manage the tasks, which enabled us to clearly visualise what had yet to be done, what was in progress and who was responsible for each task. This style of work made me feel like I was part of something bigger, with a specific purpose, rather than being solely responsible for the creation of something, as I had been in the weekend challenges. This was a good feeling, as it allowed us to collectively build something more ambitious than could have been attempted independently, and to play to our strengths, so each task was accomplished competently.

The week started with the four of us working in pairs, and this is the style we maintained throughout the project. We pair programmed every day, always with the same partner as we had started the week with. This had seemed like the most logical choice for me, and I was surprised to hear that other teams had frequently been switching pair partners. I am relatively confident that our style was the best suited to a project like this, as feedback from others suggested that regular switching involved a lot of extra legwork to get people up to speed on the new task they had started on. While my group worked in consistent pairs for most of the week, there was a point somewhere around the beginning of the last day when we actually started to work independently. We had had our morning check-in, and decided that we were happy enough with how our app was working to enable us to work on its design all day before the deadline. There was a lot to accomplish, and as it became closer to finished, each task we took on became smaller and with a tighter timeframe to get it right. This led to a scenario for a few hours where each team member worked independently on a specific task. In practice, on the day, this was quite effective. It enabled us to work very quickly, and to focus exclusively on getting the task at hand achieved, rather than navigating the task through another person’s hands. I can see however how this might be hazardous were we working on a bigger project. While debugging the work each of us was completing, we occasionally encountered errors related to a function another person had written, and frequently came close to making changes that genuinely conflicted with other people’s work. I can see why constant communication and fastidious code reviews are a necessary part of ensuring that larger projects stay on track and cause fewer problems than they solve.


By the end of the week we had a product we were genuinely proud of. Ruan’s attention to the functionality in the last few hours had ensured that users of our app were able to update the listings they created - a feature we had planned to jettison when we reviewed our MVP - and Jess’ eye for design meant that we had a product that looked slick and professional, including a signup page fit for use on Linkedin. It has been a great experience to spend a week consolidating our knowledge of Ruby and databases while getting familiar with working in teams, and I feel like I got more out of it than had I spent an additional week learning another language as quickly as possible. I am aware that in four weeks’ time we will have a final project to work on, involving a fortnight’s work in a team, on an idea of our own. I can’t wait to get to the stage where we get together to build something again.