Coding and Creative Growth by Chloe

Coding and Creative Growth by Chloe - July 2026 Scholarship Essay

When I signed up for AP Computer Science Principles, I expected it to be the outlier on my schedule — a technical requirement sitting next to a lineup of marketing, theatre, and design classes that actually pointed toward my future in advertising. I was right that it didn't come naturally. I was wrong to think it wouldn't matter.
The class centered on a capstone project: designing and building a functional app from scratch. I had a clear picture in my mind of what I wanted it to do and how I wanted it to feel, but translating that vision into working code was nothing like sketching a digital design on my iPad or writing social media content. My first attempts broke constantly. A button that was supposed to trigger one function would trigger nothing, or worse, trigger three unrelated things at once. I thought that the logic that seemed obvious on paper would grant me a polished app until the moment I tried to run it.
My instinct, my experience existing in the creative fields, had always been to iterate visually — adjust a layout, swap a color, refine the wording until it felt right. Coding demanded a different kind of iteration, one that did not come naturally to me. Every fix required isolating a single variable, testing it, watching it fail again, and narrowing down the problem line by line. There was no shortcut. I had to sit with confusion longer than I was used to, resist the urge to declare something "good enough," and accept that success would come only with repeated trials.
Rather than settle for a version that technically worked, I kept pushing toward the app I had originally envisioned. I asked my teacher for help when I hit walls I couldn't figure out alone, and I reached out to a friend whose father worked in computer science, who walked me through how to think about the logic structurally instead of just hunting for typos. Once the app was functional, I didn't consider the project finished. I put it in front of other students and my family, watched how they actually used it, and paid attention to where they hesitated or got confused. Their feedback sent me back into the code more than once, adjusting features that worked fine on paper but didn't hold up in real life.
That's also where my design background stopped being irrelevant and became what set my project apart. I could make functional code, but I could also make it intuitive — clean navigation, a visual approach that guided users without long-winded written instructions, and an interface that was thoughtfully put together rather than just assembled. The technical and creative sides of the project ended up depending on each other; neither alone would have produced something people actually wanted to use.
What the class ultimately taught me had less to do with computer science and more to do with how I think through problems. I learned to slow down and isolate variables instead of guessing at solutions, to treat user feedback as data rather than criticism, and to recognize that asking for help mid-process is part of good problem-solving. Those habits have shown up since in work that has nothing to do with code — in how I test whether a marketing message actually reached an audience, or whether a design choice serves the user or just looks appealing to me. The subject that felt furthest from my path ended up sharpening exactly the kind of thinking my path requires.