Coding With Someone Else
When I initially became acquainted with programming, I had never considered how large projects were made. I hadn’t considered how there were so many different features and pages to an application and how a group of people had to come together to build such a project.
That’s why before I worked on something with a friend of mine, I thought things would be easy. I’ll just do the front end and she can do the back end (or vice versa). Little did I know that that mindset was extremely naive and impossible to accomplish with just two people.
We were working on building OHUTU, an app that allowed users to drop pins on dangerous streets nearby. These pins would have descriptions of what the user saw and would allow other users on the app to see these pins and avoid certain streets based on the descriptions. It was a simple idea we had come up with, influenced by our personal experience in SF for the summer, and we were excited to implement something relatable.
So the first thing we did was set up our Expo environment, first mistake. If you know anything about React Native, you know that there aren’t a lot of platforms to code it on. Expo is the only one we were familiar with so we decided to deal with it and its many bugs (one the most annoying bug being that it crashes almost every other test run).
Then we thought about how to divide up the work. My friend said she’d start playing around with the login forms since we wanted this app to be something only users could use. Now that she had something to work on, I decided to start playing around with the actual map and figuring out how the user could drop pins, edit descriptions, track user location, etc. Since my friend had to deal with users, logins, and authentication, I figured she’d handle the back end and I would do all of the front end, second mistake.
My Initial Part
I began by looking at React Native documentation (as I’ve learned is the best way to start something). I knew I needed something maps related and figured I’d be using some implementation of Google Maps API. After looking through the docs, I realized that there wasn’t much information that was helpful for me. That’s when I stumbled upon Airbnb’s implementation of React Native’s Mapview component (https://github.com/airbnb/react-native-maps).
Though some of the documentation here was very vague for specific features, Airbnb did a good job explaining how to initialize markers and how to add different props and events for the map component. Once I was comfortable with the documentation (and after extensively googling previous examples of how other people implemented these props), I started slowly adding features to my map.
After having built the Slackbot, I knew that I had to approach this incrementally. First I accomplished tracking the user’s current location, then figured out how to add a pin on a tap, and then worked my way up to being able to drop multiple pins, adding descriptions, and dragging the pins around.
Now this is when I hit my first major annoyance. On Expo, for some reason, it wouldn’t let me easily zoom in and out of the map with the zooming gesture. I had to almost hard code this feature by setting up two buttons (a zoom-in one and a zoom-out one). When you clicked the button, it would call a function that manually altered the latitudeDelta and longitudeDelta to create a zooming effect, third mistake (which kind of goes with the first mistake).
Anyway, after all this, I had a feature to add markers, edit their descriptions, drag markers, delete markers, zooming capabilities, and tracking capabilities.
More To My Part
Here is when the “I’m only doing front end” part bit me. I realized that once the user logged in and dropped a marker, how were other users supposed to see these markers? How were these markers supposed to stay once the user logs out and logs back in? I too needed to work on back end.
To reiterate my point, I had thought that the way people split up code was by splitting it by design, front end, and back end. Now I had finally realized this was wrong. Building projects in a team is dependent on splitting the code by features instead.
My friend was working on user authentication and login which had both front end and backend. She needed to save the users on back end but also create the forms the users see on the front end. Similarly, I had to create a map interface in which users could play around with pins and such but also have a back end in which all the markers were stored in accordance to he particular user and save the descriptions and coordinates of the markers as well.
Knowing this, things became a lot easier for us when we started integrating our two parts together. However, a new issue came up. Expo didn’t support a lot of libraries that we could use to make our app look pretty. This is when we realized that no matter what, there had to be another option.
In hindsight we probably should have started this project by exploring all options before settling for what we were comfortable with. This would have prevented me spending time on the zooming buttons as well as Xcode automatically allowed you to zoom in and out. Regardless, we had now implemented a better looking app.
Now came another obstacle we had to face, integration. Both our code worked separately — however, there was some definite tension that arose when we had to work together to combine our code into one project. For instance, I’m old school and more experienced in C++ so I like my for loops. My friend on the other hand preferred forEachs (which I soon realized was correct on her part as it’s a lot more efficient in the long run). When we both tried changing little things like this on each other’s code, problems arose and bugs were created.
We had to realize that maybe only one person should work on integration for a certain file and the other person work on integration for another file. This worked a lot better for us and ultimately, we were able to create OHUTU just as envisioned.
We had successfully pushed our server onto Heroku (I finally learned how to do this) and we had a simple app running. From the outside, the concept of OHUTU doesn’t sound too complicated. It’s just dropping pins right? However, it was a lot harder to implement. Now that I’ve crossed the finish line, here are some of the things I’ve learned:
- You can always learn something from your partner. I tried to be somewhat close-minded and protective over my code when my friend was changing it around a bit. It took some time but I now appreciate this because as much as I hate to admit it, we made each other’s code better — isn’t that why we work in groups anyway?
- Don’t settle for comfort. If we had pushed for something better in the beginning, we wouldn’t have had to dealt with Expo’s bugs and implementing extra functions to work around Expo’s limitations.
- It’s better to go into a project splitting up work by specific actions and features.
- Integration is hard, I thought it would take hours but it ended up taking days. Things somehow broke and we had to rewrite a lot of code. Be efficient and smart about how you integrate different people’s code.
- We definitely didn’t utilize the merge capabilities on Github and this is something we want to fix in the future. We pushed our code to our own branches but ended up copying and pasting code into a new file, making things even more inefficient.
We’ll definitely add more features to this app as time goes by and hopefully make it public on the app store. But for now, I’m proud of the final result my friend and I have worked hard to accomplish. We both have different strengths and they ended up meshing well. Be sure to keep an eye out for OHUTU soon.