Week 6. What an exciting week this is. How is exciting you may ask? Aren’t you just pairing like you did before. My friends, this week is when we actually do our first group project together. It will be an exciting adventure of laughs and sorrows, of ping-pong and code and of a bond between four people.
The group challenge this week is to re-create a version of Airbnb. It requires a lot of combination between back-end, front-end. It requires a lot of decision making throughout. It requires a lot of planning before-hand that might seem useless when you say it but more handy when you think about it.
I called this post “The Dream Team” because it’s literally a Dream Team any coding group would want for this challenge. The reasons are listed below:
First day as a kick-off was amazing although it was a lot of planning. However, the planning I believe was a good strategy to start with as many teams I found jumped into the deep end. I never thought my design practice would come to good use but it definitely did when it came to our process. Given we were re-creating a popular app that something made, the first key thing is…
Why is research at this stage important?
A lot goes into a website or an app, more than we think! Look at those vital and useful benefits we have that boosts the team! It’s amazing what research can do if we’re going to look into this. This was our first step beyond anything was to create a map for what we wanted to achieve.
Our research for our AIRBNB like app was to go through the workflow of AIRBNB. We realised there were two perspectives initialised which was the client and the host. Whilst we did that, we also listed all the data elements that was presented or used in each page. Listing the step from 1–9 for a user was useful to create this map. This map was useful because then we could start conjuring possible ideas of how we could tackle one section of code.
For instance, we chose the “Instant Book” method was simpler to execute for the core of the idea than have that as a separate feature. I wouldn’t say this was us jumping into ideas. It was more of us putting our thoughts on what we had on our research that we made.
If we’re researching a project, most of the time, we have found a bunch of stuff. It’s a bunch of stuff where there are many directions we could go with. In a week, it’s impossible to re-create the entire functionality of what AIRBNB can do. Thus, from here our next step is to choose our focus.
In code, this is what we call MVP for our User stories. MVP kinda means the core function of the website that is authentic.
At this stage, whilst we mentioned the workflow, it’s also good to list our user stories so that we could track what functionalities were needed for the creation. Doing one for the customer and the host, given they were two separate sections, were important as there were different needs.
In the end, our MVP came down to three user stories
I found that this process was effective because we took time to plan it out and that we were working from the core, then expanding. What I like this approach is that our progress is not linear where we are hitting a mountain tip. It’s a spread from the core where we are seeing how far we can expand. The approaches make a big difference on the mood and chemistry of the team.
Hence, our goal was to start setting up the foundation (the core) and expanding our reach to how far we can go with it.
I believe in every group, the two key things are communication and that everyone is on the same page. No one can move forward effectively or with ease unless this is happening.
Hence, it’s always good to re-explain or diagram out how we see the workflow of not just our entire code but also to the specifics of our MVP. Having both front-end developers and back-end developers in the room, this was vital.
So, setting our foundation was laying out the image on the right at the bottom. It was laying out front end and back end together, with a simple piece or code or test. We knew then at this point, it would be easier to implement the other extensions depending how far we could expand this week.
Although we did not finish setting up the entire foundation, the important thing is that we got majority of it done. There might have been one error in it, but as a team, we should be proud of our progress.
This project was quite challenging because not only did we have to plan everything out, but also made sure that our ways of working was the same in everyone’s understanding.
This was when we came across learning GIT BRANCHING
Intimidating topic, as many seniors above us dreaded it. We had heard the suffering stories and the tears of pain when it came to code conflicts. Hence, a smart solution was to definitely add this to our to do list. To experiment with GIT BRANCHING, we created a README and experimented with that.
The more we practiced, the more we could list down the seven steps on how a person should work with GIT BRANCH
The first time we did it, I documented how the process would look like to get a better idea. As you can see in the diagram below, I had merged my branch first. Then followed my other team mates. We each took turns to merge our branches and we did it with success and ease.
What was beneficial about this is that we did it twice to make sure that all of us were on the same page. As the project is highly likely to expand quite large, we wanted to set this foundation of how all of us were gonna work. It is definitely beneficial for team synchronisation.
We first started with the back end, creating Databases and then working our way to the Front end. The biggest problem or hole in our understanding was definitely understanding how the details of the property get posted to a website. Although we could simply just get the data of the property and print it, we also have to consider our code when we expanding.
This particularly arrived when we were thinking about the flow of when the customer was a host or a renter.
Right now, in terms of our MVP, we had achieved what we set out to do for the customer. This is because as coders, we had hard-coded properties onto the website. Let me give you the flow here.
If that explanation makes sense, score for me to have the ability to explain it.
What’s really good for a team to do to keep everyone on the same page, is to explain or practice explaining what they think. So, if no one knows what it is but one person does, one person will explain it. From then, take the courage to just re-explain what the person just said to do and that will solidify it in your head. If you get it right, explain it to someone else in the team!
Sometimes, this approach might not work out but it’s practice at the end of the day for you. Although people might not get it whether it be explaining through words or diagrams, it’s good to have that intent of wanting your team to be on the same page.
If you are someone who has come to this blog, trying to figure out the answer to the AIRBNB challenge by MAKERS, I’m sorry that you’ve been disappointed. However, these techniques are something that teams I think forget to consider whilst suddenly jumping into all the code…
I would say, this is very HEALTHY, delicious, juicy foods for thought.
The concept I just explained, i’m kidding haha!
I hope this is right, as I indulged it from Rob’s explanation.
When signing up to a bootcamp, you expect that the experience that you’ll be having is just about code. However, the experiences could grandly be about life experience as well. It even can teach you what kind of person you are.
From experience, it could get really bad to the point of when your heart gets broken or that you break someone else’s but like many say, it’s part of the experience and part of your learning whilst your there. Crazy, am I right?