When I became an assistant volleyball coach, I wasn’t sure how effective I’d be. To compensate for my lack of experience, I decided to contribute in a different way: by taking detailed stats during games. If I couldn’t give great coaching tips, I could at least provide meaningful data. However, as a stats minor, I quickly realized the existing apps didn’t meet my needs—none of them allowed me to assess whether trends were statistically significant. So, I decided to build the best tool for the job myself.

    I had never built an app before and didn’t know where to start. After researching my options, I decided on React Native as the framework. I wanted to learn React, and this seemed like a great opportunity to do so. Next, I needed to figure out how to get the app running on an iPad for development. That’s when I discovered Expo, an open-source platform for building, deploying, and testing React Native apps. Expo’s tools helped me get up and running quickly, and I dove into the project.
    This project taught me more about building software than any other I’ve undertaken. I began with what I knew best: designing the SQLite database. This gave me a solid foundation with tables for players, teams, matches, and stats. However, when I transitioned to building the app’s front end, I ran into trouble. I simply didn’t know enough about React Native. My first big lesson was realizing that it’s okay to pause and prepare more before jumping into development. A simple tutorial on React Native wasn’t enough—I needed to build a stronger foundation first.
    About midway through development, I discovered Redux, which simplified state management significantly. But by then, I had already implemented state management manually in much of the app. Instead of going back and refactoring the older code, I decided to push forward with Redux from that point onward. My second big lesson: Always go back and align older code with new standards to ensure consistency.
    Early in the project, I skipped commenting, thinking I could remember everything I’d written. But when I revisited that code later, I had no idea what I was looking at. While I don’t comment excessively in personal projects, I’ve since learned to document methods that are important, confusing, or likely to need revisiting.
    The hardest lesson came at the end of the project. I had completed most of the app when my hard drive failed, and I lost nearly all of my work. Unfortunately, I hadn’t been pushing updates to GitHub frequently enough. Losing the project was a tough pill to swallow, but it taught me the critical importance of version control and frequent backups.

    In the end, I discovered I knew more about volleyball than I gave myself credit for—and that I was more effective as a coach during matches than as a statistician. While the project didn’t result in a polished app, it became a touchstone for my development practices. Every time I consider skipping code comments, avoiding a refactor, or delaying a GitHub push, I think about this project. It shaped the way I approach software development, turning hard-earned lessons into habits that make me a better programmer today.