“You should put this on the App Store so you could make all of us millionaires.” My biology teacher said this after trying a game I had built. Her enthusiasm meant a lot to me. A project that began with my own curiosity had become something other people enjoyed enough to imagine sharing more widely. Block Blast was popular at my school, and I enjoyed its puzzle mechanics. Players receive three shapes to fit into a grid. While teaching myself Python, I decided to build a version that doubled as a study tool: after every three shapes, a multiple-choice question would appear. I wanted to explore how a familiar game could make room for studying within an experience people already enjoyed. Making that idea playable required more than adding questions. One frustrating problem was the interaction with the blocks. Picking them up did not always work, and placing them on the grid could take several attempts. The puzzle was supposed to challenge the player’s thinking; the controls were becoming a challenge of their own. I redesigned the interface so blocks would snap into place on the grid instead of relying on a fixed placement radius. That change made the interaction smoother. It also pushed me to consider how much effort someone had to spend getting the program to do what they wanted. A feature that worked awkwardly still needed work. Other students and teachers tried the game and loved it. Block Blast’s popularity helped draw their attention, and my version gave them a new way to experience it. Something I had been working on while learning Python had become something people around me could play, study with, and enjoy. That response gave the tinkering a purpose beyond learning a programming language. I had taken something familiar, experimented with its possibilities, and shared the result. The questions gave the game a new use, while the snapping feature made it easier to play. Both changes required me to think about the person using what I built. I want to carry that attention into a career as an autonomous systems engineer, developing perception and navigation software that helps make roads safer. Pursuing that goal will require deeper study of algorithms and machine learning. It will also require the willingness to investigate what is going wrong and rethink a design when it makes life harder for the people depending on it. My teacher’s joke stayed with me because it suggested that something I built could matter beyond my own screen. I want to keep developing the skills to follow ideas like this one further, and to keep finding ways to make technology useful and enjoyable for the people around me.

The robot’s movements looked right. Its final position did not. During tests of our VEX robot’s autonomous routine, one run would land on target, and the next would finish far off. I watched it perform the expected motions without understanding why it ended somewhere different. It did not make sense, and I wanted to know what I was missing. Making that routine more reliable became a project I pursued beyond our club’s basic programming expectations. I learned C++ through documentation, videos, and programming communities, then implemented PID controllers to correct movement errors and odometry to track position. I spent nights debugging code and deciphering explanations because I wanted to see how precisely our robot could move. When the inconsistent results persisted, I examined the odometry readings more closely. The numbers did not match what I was seeing on the field. Investigating that discrepancy led me to an overlooked setting: the tracking wheel’s size had changed, but the nominal wheel diameter in the code had not. The program was calculating distance using a wheel that was no longer there. That mismatch introduced a systematic distance error. After I corrected the wheel-size setting, the routine became much more consistent. I estimated its success rate at about 80%. There were still unsuccessful runs, but identifying the mismatch gave me an explanation for a problem that had seemed unpredictable. Across my work on the autonomous routine, watching the robot hold a straight line, turn to the correct heading, and reach its scoring position made me smile. I could see the purpose of the concepts I had struggled to understand. Finding the wheel-size error also showed me how much their usefulness depended on checking the physical assumptions underneath the code. That is what inspires me about working in technology. A confusing result becomes something I can investigate, and learning gives me more ways to ask questions and test my understanding. This project helped clarify my goal of becoming an autonomous systems engineer. Reports of preventable crashes in my community had already drawn me toward safer transportation. Robotics gave me a technical starting point and showed me how much more I need to understand before working on systems people depend on. A vehicle on a public road encounters uncertainty far beyond a competition field. When should it trust a sensor? How can it recognize that its understanding of its surroundings is wrong? Through a computer science degree, I want to study algorithms and machine learning and develop perception and navigation systems that address those questions. I began by wanting our robot to reach its scoring position reliably. I now want to apply that same care to technology that helps people get home safely.

The first program I wrote existed because my computer could not run someone else's. My friends used software to automate repetitive actions in a game, but it was incompatible with my old machine. I wanted to keep up with them, so I spent a week teaching myself to code and building my own version. When it worked, the computer had not changed. What I knew how to do with it had. In VEX Robotics, that curiosity became a need to understand why something worked. Our autonomous routine behaved differently when the battery ran low or field conditions changed. I learned C++ through documentation, videos, and programming communities, then implemented PID controllers to correct movement errors and odometry to track position. The robot began holding a straight line, turning to the correct heading, and consistently reaching its scoring position. Watching it adjust to conditions that previously threw it off made the nights spent deciphering documentation worthwhile. I also learned to question my own approach. When our intake jammed, I added rollers, adjusted angles, and slowed the motors. What finally worked was a non-slip mat that provided enough friction to grip the objects. I had been changing the design without understanding the failure. Those experiences drive my interest in autonomous vehicle engineering. Reports of preventable crashes in my community make me think about what reliable navigation demands beyond a robotics field. When should a machine trust a sensor? What happens when it encounters something its designer never anticipated? I want to study computer science to build the foundations in algorithms and machine learning needed to investigate those questions. My goal is to develop perception and navigation software, gaining the experience to eventually found an autonomous vehicle company. I have also begun sharing what I know. In summer 2024, I designed and taught a thirty-hour Python bootcamp for seven students. We worked through programming fundamentals by building to-do lists and coding VEX robots. Preparing a curriculum required me to organize knowledge I had gathered through separate projects into a sequence someone else could follow. I want helping others learn to remain part of my education. My family cannot fully fund college, and I expect to work to help cover the cost. This scholarship would protect time I would otherwise spend working, so I can put it into coursework and autonomous systems research. I have already put my learning to work in a robot and a classroom. With further education, I want to take on a greater responsibility: helping a vehicle navigate safely through changing conditions, with someone's family inside.