Coding Is Art

Growing up, many of us were fed the same tired narrative: if you like solving equations, you’re analytical. If you like painting, you’re creative. STEM? Numbers and logic. Arts? Expression and imagination. The binary was cemented in classrooms, career counseling sessions, and dinner-table debates. Academia was quick to slap labels on our interests, boxing us into categories where our perceived talents defined the limits of our potential.

I bought into it for years. I loved logic puzzles, devoured math problems, and thrived on solving what the world called “analytical” challenges. By the time I encountered coding, it felt like the next logical step in my academic trajectory. I approached it expecting a rules-based discipline: find the algorithm, solve the problem, get the answer.

But I didn’t anticipate how wrong I would get it.

When I first started learning to code, I thought my job was to find the right answer. I was constantly hunting for a singular solution, obsessively checking and re-checking, sure that if my code didn’t work, I had fundamentally failed. What I didn’t understand at the time was that I wasn’t struggling with problem-solving; I was confusing syntax correctness with success. Every error message felt like proof I wasn’t cut out for coding. I couldn’t see the bigger picture because I was too caught up in the punctuation.

Here’s what I didn’t realize back then: syntax is the grammar, not the story. It’s a tool, not the masterpiece. I was so fixated on whether my brackets matched or if I’d placed a semicolon correctly that I missed the forest for the trees. Solving problems in code isn’t about typing out the perfect string of characters on the first try—it’s about experimenting, iterating, and embracing the mess.

It took me a long time to stop seeing error messages as failures and start seeing them as feedback. Debugging became less of a punishment and more of a process, an essential step toward understanding how my ideas translated into functionality. As I learned to let go of the need for the “right” answer, I started to uncover what coding was really about: creativity.

Coding isn’t a single-track solution; it’s a maze of possibilities. There are infinite ways to approach a problem, each with its own merits and quirks. You might write a function that’s bloated but works. Someone else might pare it down into something sleek and elegant. Both are valid. Both solve the problem. And both are reflections of the choices you make as a coder.

This shift in perspective was liberating, but it also revealed a bigger issue: the way modern academia had trained me to think. I realized how much my education had conditioned me to look for “correct” answers instead of understanding that many disciplines—especially in STEM—thrive in the space between ambiguity and exploration. Academia had reduced coding, like so much of STEM, to a rote exercise in compliance: memorize the syntax, write the function, check the box.

But coding isn’t about compliance. It’s about invention. It’s about taking a blank screen and building something that didn’t exist before. And yes, sometimes that means smashing your head against the keyboard as you chase down a bug that refuses to die. But it also means asking yourself questions like: What could this look like? How could I make this better? What if I tried something completely different?

Coding is a creative process not because it’s easy, but because it demands that you think differently. It forces you to confront your assumptions, embrace trial and error, and see every problem as a puzzle waiting for a solution only you can design.

Once I stopped seeing syntax as the end goal and started treating it as a tool, my relationship with coding transformed. It wasn’t about perfection—it was about possibility. It wasn’t about whether my code was “right”—it was about whether it worked, whether it did what I wanted it to, and whether I could make it do even more.

So here’s the thing academia doesn’t want you to know: coding isn’t a science of absolutes. It’s not about following rules—it’s about breaking them. It’s about designing systems, solving puzzles, and weaving logic into something uniquely yours. It’s about creating. And if that’s not art, I don’t know what is.