Building code with Lego: The importance of teamwork.
The day started with a meeting with the coaches. It was week 6 and we were tasked with creating an AirBnb clone. With this announcement, a room, previously filled with laughter, became tainted with dread. We all sat befuddled by the challenge laid before us, staring intently at our coach, Ed, hoping he would retrieve the gauntlet he had carelessly dropped.
I must admit; I did panic. I was unsure if my current level of knowledge was sufficient enough to carry me through the task. I also wondered if everyone else felt the same. Taking notice of our worry, Ed walked us through the goals for the week. He reassured us that the aim was not to create the best site ever, or the next big startup, but to focus on improving our communication and team working skills.
When we hear the word ‘Teamwork’, we hold different worries. For some, insecurities manifest, fears of being labelled the ‘weak’ one in the group. For others, it’s the fear of being paired with ‘that guy’. Working in a difficult team may seem like a right of passage — a laborious task that we, as developers, all have to endure at some point or another. However, Ed assured us that this was not the case.
As an exercise, the cohort went through all the factors that were important while working in a team. The words ‘compromise’, ‘positivity’ and ‘fairness’ were all met with nods of agreement as they echoed across the room. It became apparent that we all knew what good teamwork looked like. However, were we able to embody these qualities? Ed, proposed the creation of a ‘Team Charter’ — a list of behaviours and expectations we could hold each other account to. It included things we would do, things we would not do, and things we deemed ok to do.
We would make each other feel valued and heard.
We would not dismiss the opinions of others.
It is ok to feel overwhelmed.
To accompany this, we were recommended retros — end of day meetings that allow people to discuss the happenings of said day. This included what had been achieved, what could be improved, and that which is still left to be done. With these new weapons in our arsenal, we were put in groups and left to chart our course.
Having a growth mindset.
At 11:10 the challenge began. The first task was creating a team charter. We decided to use this exercise also an opportunity to share any concerns we had during the week. Although we were different in age, personality and experience, there were feelings we all shared. Fears of not being good enough, feeling lost in a task, or being left behind. By laying all our cards on the table, we endeavoured to help one another through the challenge.
The next part of the hour was spent learning about each other’s strengths and weaknesses. Anyone who has worked in a team is aware of this question:
— ‘So what are you comfortable with?’
When this is asked, many are quick to breathe a sigh of relief, happy that they can work within their comfort zone with the tools they are most familiar with. I think several people are hesitant to state their weaknesses in fear of being termed ‘the weak link’. However, as someone once told me, it all depends on your mindset. I believe an equally important question to ask is: “What am I not so good at?”. This question requires an ounce of detachment, that provides the clarity needed to also ask:
— “What would like to get out of this session?”
I knew that I had little practice with databases, and saw this assignment as an opportunity to pair up with someone who had. A team should be perceived as an overflowing fountain of knowledge, one we drink from. To drink or not to drink is a voluntarily choice.
Nothing is difficult. You just haven’t learned it yet.
Imagine you were given the task of creating AirBnb. What is the first thing you would do?
From my six weeks at Makers, I have come to finally understand that everything (absolutely everything) can be broken down into manageable and easily digestible steps. All structures, no matter how elephantine, can be built with lego. Small individual, connecting blocks lego. For any one who has been on AirBnb, you would probably have noticed several functionalities — from the search bar, to the listing page, to the ‘add a room’ page. Just like with lego, we looked to this challenge and decided to break it down into manageable user stories — User stories that expressed the main functionalities we wanted to include into our app.
After listing these, the next challenge was to decide what the most important features were and how to incorporate them into a Minimum Viable Product (MVP). Now we had to adjust our perspective from that of a coder, to one of a practical user.
If I stumbled across this AirBnb-styled site, what would I as a coder, want the user to think is its Unique Selling Point (USP) ? What makes it different? What sets it apart? In its most elementary form, we concluded that the USP of our site could be summarised by 3 main functionalities
- You can add a listing
- You can view currently available listings
- You can book a listed room
These were then broken down into smaller user stories, allowing us to choose the appropriate tech stack needed to execute this MVP.
Later, we decided on a Node.js application and split the research tasks between one another. The setup was the first hurdle. None of us had ever worked on a Node.js project and we had no idea how to rectify the persistent errors we were facing. Each part of the project setup depended on the other, so we were stagnant, battling the same problems for hours on end. It would be a natural reaction to crumble under this pressure, but it was at this point that I learned what Makers was all about. Firstly, we had to adopt the ‘Makers mindset’ of ‘Nothing is difficult. You just haven’t learned it yet’. Secondly, every problem can be broken down into a series of steps — lego blocks, if you will. By soldiering on, we were able to interpret the error in our stack trace and get to the root of the matter.
The importance of checking in.
At the end of the day, we checked in with one another by conducting a retro. People are different. We think and feel things differently. Hence, why retros are important. They give everyone an opportunity to speak, air grievances, to vocalise the positives of the day and what they believe could be improved. It also allows the group to set a direction for the next few days. Although we all faced issues, what we realised was that continuous planning through the day made life a little easier. All in all, our initial fears of being in too deep were unwarranted. It seemed that, when called upon, the knowledge acquired in the last 6 weeks hastily appears in the light, guiding you through the task at hand.
All in all, the first day was fairly pleasant. But who knows what tomorrow holds?