Understanding an Existing Codebase
Working with an existing codebase as a new developer can often be extremely daunting, at least for me it was. Sorting through the state management system(s), the API calls, the database queries, etc., to understand how the application is connected can be frustrating. But that’s exactly what you’re going to be expected to do on the job.
My first opportunity to dive into a large code base came right as I was finishing up my full-stack web development training at Lambda School. For our final project, I joined a small group of three developers to work on a children’s reading, writing, and drawing game called Story Squad. Story Squad is a web application that allows parents to sign up their children and monitor their progress, children to upload their creative work and vote on other players creative work, and moderators to review and approve content each step of the way.
Our goal was to create a developer operations tool pack to decrease the time of onboarding as well as any confusion that comes with understanding flow of the game in the codebase.
Creating a Developer Operations Tool Pack
The stakeholders of Story Squad wanted web developers to spend less time understanding the code base, and more time optimizing the application. Over the course of four weeks, my team and I dove into the unknown realm of creating a developer operations tool pack. The developer operations tool pack allows developers to choose which slices of state they want to see in game play throughout the 5 stages, inspect bugs, test changes before pushing to production, and understand the moving parts that are the meat and potatoes behind this application.
In order for the developer operations tool pack to get off the ground we needed to begin by implementing the following: UI, a developer database, new API calls, new functions, global and local state, and more. My team and I decided to hit the ground running by creating a developer database. Having a developer database will allow the developer operations tool pack to be fully functioning while the application is production.
We began this task by creating an exact copy of the production database and deployed it to Heroku, thus creating a development database. We implemented a “staging” branch that future developers will push changes to and merge into, before merging into the “main” branch. Having a “staging” branch allows developers to keep the developer database up-to-date and gives them the opportunity to test changes in the developer database before sending it to the live production database. This makes the developer operations and developer database ideal for testing bugs and implementing new features.
We wanted to make the developer operations tool pack as easy as possible for future developers to understand. Each day of the week, at a specific time, a new stage in the game is unlocked, i.e. the creative stages (reading, writing, and drawing), squad assignment, point allocation, match-ups, and voting. We wrote detailed descriptions for each of these stages including the name of the stage, the day the stage happens, and a chronological play-by-play of what is unlocked for the user that day. We created buttons with all options of state a user can have in a specific stage. A developer can choose what state they want to see in game play, manipulate the state, click “Simulate Game Play”, and see the state they selected in game play.
Lastly, we wanted the developer operations to be secure so we implemented an “Activate Developer Mode” button. When this button is clicked, a developer mode slice of state is set to true and a dropdown with the different days of the week is unlocked to allow a developer to move forward to manipulate state in the developer database. To ensure developers know they are in developer mode, my team and I implemented universal developer mode header across the entire app.
The Future of the Developer Operations Tool Pack
My team and I put our blood, sweat, and tears into this application throughout the past four weeks and made great progress, but there more to be implemented and improved upon. We connected the backend repository to the data science repository and set-up a developer database with a staging branch to merge to before merging into main. We created a function that can spoof the day as well as the hour, allowing different stages of the game to be unlocked in developer mode aside from the true date and hour. We fleshed out the reading, drawing, and writing stages, as well as the point share and matchup stages. As is, the developer operations tool pack is a powerful tool, but will be even more powerful when it is fully functioning.
Moving forward these are a few of the features I would improve and implement: the UI, adding a required pin when a developer clicks on activate developer mode for added security, fleshing out submission errors on the backend coming from the data science endpoint, and changing the developer database so multiple developers can make changes at one time without affecting another developers changes.
How This Project Changed Me
Coding is a skill, and like everything else, the only way to get good at it is through repetition. I learned that helping my teammates solve issues they’re struggling with is a great opportunity to strengthen what I know, be exposed to new material, and be a supportive teammate. Working on a remote team of 3 web developers and 5 data scientists taught me how to cross-collaborate, to communicate effectively, and to be a creative problem solver. I actively participated in daily team stand-ups, Slack channels, stake holder meetings, and squad programming sessions. I gained a better understanding of what it may feel like to work on a team in the workforce. I feel more confident in my abilities to share my ideas, express my opinion, take on challenging tasks, and explain what I’ve implemented in the codebase in a way that all can understand.
Working on Story Squad was an amazing experience and the perfect transition into the workforce that I will be forever grateful for.
