My First Experience Working on a Real Software Product
As a code boot camp student trying to break into the world of software development, one thing that was most daunting for me was not having any experience on a team that was developing a real-life product. I was so excited when at the end of my boot camp, we had the opportunity to work with stakeholders on a product that would be utilized by consumers one day.
The product that I was selected to work on was an app by the name of Story Squad, founded by our stakeholder Graig Peterson. Story Squad is an interactive learning platform that aims to build students’ creative and critical thinking skills through gamification and friendly competition. One of the problems that the founder, Graig, is trying to address with this app is the increasing amount of screen time that children are getting nowadays, especially with all of the remote learning that students are currently undergoing. Story Squad encourages students to write stories and draw pictures using pencil and paper, providing a much-needed break from staring at their screens.
Planning is key
At the time of being assigned to this project, I was nervous about the complexity of the user flow, and I was worried that I wouldn’t be able to fully understand the codebase, as it was larger and more complex than any project that I had previously worked on during my time as a student. However, as I was able to explore the app more and figure things out on my own, it became much more clear to me what was happening within the code.
The first step our team took to plan out the features that we needed to implement was to break each feature down into small, manageable tasks that were a little bit less intimidating. This is a crucial step in getting started on any project because as a developer, it is much easier to begin a task when there is something feasible and actionable to jump into.
Features are outlined, now what?
Now is the time to get started on coding! This is the part that I, as a developer, was the most anxious to get to because this is when real change starts happening. Writing code is the most frustrating, yet satisfying part of the production cycle because no matter how experienced or competent of a developer you are, you will definitely run into something that stumps you. There may be times when we are forced to stray from our initial plans because of unforeseen issues, and this is when critical thinking is really important.
One of my favorite features that I was able to work on was actually something that the future users of the product will never actually see or interact with. It was a simple reset button that wipes the game state clean, and it would only ever be used for testing the game flow, but I really enjoyed working on it because of the challenges that emerged and were overcome.
The reason that this reset button was necessary was because of the way that the game flowed, it could only be run once before everything broke, in which case we would have to re-seed the database and start from scratch every single time we needed to test a change. This was an arduous process and it quickly became clear that there had to be a better way.
One of the challenges that arose during the process of creating this functionality was actually deleting the data that I needed to in order to reset the game state. Many of the tables that I was wiping were connected to other tables via foreign keys, which were throwing errors when I tried to truncate tables that were dependent on them. Normally, this would not be an issue because I would just need to truncate the tables in an order where I would not be violating any foreign key constraints. However, several of the tables had foreign keys that referenced each other, meaning that I would have to delete all of the data in these tables at the same time. This was an issue for me because I had never had to query multiple tables in one Knex statement before. I only knew how to write one query at a time (as shown below).
After many Google searches and combing through the Knex documentation, I finally figured out how I could write all of these statements in a single query, and it felt so good to see my work finally functional. All I had to do was change my code ever so slightly, but all of the efforts that went into figuring out exactly how to do that made the feeling afterward so much sweeter.
The finished product
After four weeks of working on Story Squad, our team was able to deliver everything that was asked of us and more. In order to meet the minimum requirements of the stakeholder, we had to complete the user flow through the game, which we were able to accomplish. Users are now able to play the game and get all the way to the results screen which displays the winners. We also had some time to implement some additional features that we as a team felt would be very useful. Some of the biggest new features we were able to add were a lock system during voting that builds anticipation for students as to what their opponents' submissions look like, as well as a revamped avatar system so that users can have more choice about their in-game appearance.
Although we accomplished a lot, there was not enough time to finish everything that we would have liked to. One of the most interesting bugs that would have been interesting to look at is what we call “The Remainder Problem”. As of the time of this blog post, the game only works if the number of users who join the game is a multiple of four. Any other number and the gameplay breaks down. One fascinating solution to this problem might be to create “bot” users to join the game and fill up any teams that didn’t get enough players. These bots could use submissions from other teams and seamlessly integrate without disrupting the game flow for any other users who are a part of that matchup. Even though we were not able to fix this problem, I am still very proud of everything that we were able to complete within our deadline.
What did I learn?
Seeing as how this was my first time working on a real-life production application, I was able to learn a lot about being an effective and supportive team member, as well as how to understand a large, complex codebase. One of the most important lessons that I gleaned from working on this project is that it is so important to document everything as thoroughly as you can so that future developers who will be working on this project can quickly get up to speed. When I started on the project, I found that the documentation was not very clear about some important pieces of information, and that led to our whole team spending a lot of time searching for answers.
Another great lesson that became clear was that communication is key in order for the team to thrive. This was something that our whole team agreed on at the start, and we made sure to do the best that we could in letting each other know what we were working on, pair programming, and reviewing one another’s code. I believe that it was our great communication that allowed us to accomplish all that we did in the time that we had.
Overall, I think that this experience working on a real development team was an amazing growth opportunity and I am eager to join another team and work on challenging and rewarding projects.