Episode 25: The beginnings of the Dream Team (The AIRBNB challenge)

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:

• Individually, we all are good at different things. Most of my team members are back end people so it definitely shines a glimmer as the person who’s just keen on front-end. I have a legit role, yay!
• We have a balance of chill people and a balance of energetic people when it comes to our workflow
• All of us are aim to do a great job and all of us aim to be great at our break ritual, ping-pong.

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…

RESEARCH.

Why is research at this stage important?

• We might think AIRBNB is a simple platform where hosts and customers find each other and benefit from each other. However, there are so many considerations of what goes into that website
• We might think the workflow is to find a property and click pay, but the workflow has several steps with different attributes and different elements to consider
• The workflow of the consumer and the host might seem either fuzzy or something we conjure up in our heads for us to make sense. This clears the air.
• We get a map of what’s happening and choose the directions of where we want to go, what we want to achieve and spread the task across the weeks

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.

CHOOSING FOCUSES:

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

• The home page listing the propeties
• Search by city
• The single property view when you click on the property

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.

SETTING THE FOUNDATION:

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.

It was great to understand the workflow of our code as we needed to know how the Front end was going to connect to our Back end. This was a lesson last week, in Javascript week where most of us couldn’t get to (as we were struggling with other stuff). Hence, it was a benefit for all of us to go through this again as majority of us didn’t.

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.

MVP requirements and overall code workflow

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.

MORE ON WORKFLOWS:

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

• Step 1: Pull Github
• Step 2: Make a branch and checkout to the branch
• Step 3: Do your code and commit it
• Step 4: Checkout the branch back to the master
• Step 5: Pull from the GITHUB to get the latest one (If you get conflicts or errors, and want to keep both, you want to delete the conflict lines…they look like random lines, and not choose or use one over the other piece of code)
• Step 6: Merge the local 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.

WHY EXPLAINING THINGS IS WORTH A TEAM’S TIME?

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.

• We coders are inputting the data of propeties that gets stored in the database
• We are using Ruby to connect to our rentals so we can see the rentals
• Our json file is our controller that will lead us to the front end where we connect with javascript to output those rentals. (Hence why it goes back to rentals.

However, what will we do when a customer becomes a host and puts their own property on the list. The host will then have to interact with our front-end to create a rental, that rental would have to be communicated from our javascript to the back end. The back end will have to connect to our database to store it and if wants to be seen by a customer, or extracted by a customer, it follows on the flow we did earlier!

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.

Reflection:

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.

New things I learnt:

The concept I just explained, i’m kidding haha!

1. This apparently when you use it in your ruby controller, checks the data before it’s coming in. It’s used as a security protocol/precaution of when we are grabbing data. Once it checks it, it kinda says “all-right it’s fine let it pass through, nothing is wrong”

I hope this is right, as I indulged it from Rob’s explanation.

Fun fact of the day

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?