rusoblanco

I have a mixed background. For the past 20 years, I’ve worked as a professional programmer, but I started my career as a sound technician. Because of that experience, I still follow trends in the audio world. I watch production tutorials and read about mixing techniques.

Recently, I saw a video by Gregory Scott from Kush Audio titled “Is ‘Self Expression’ Limiting Your Art?” He mainly spoke to musicians, but I realized he was describing the same emotional trap I’ve faced in software development for two decades.

The Trap of “Code as Identity”

Scott mentions that artists often see their recordings as a reflection of their self-worth. If a vocal take doesn’t work out, they feel like they aren’t good enough. If a producer critiques the performance, the artist takes it as a critique of their soul.

Programmers do the same thing.

After two decades in this field, I know that coding is an art form. It serves as a canvas for self-expression. We stress over elegant architecture, take pride in clever one-liners, and protect our code as if it defines who we are. However, this attachment creates a fragile situation. When a QA tester spots a bug or a peer reviewer suggests a refactor, it hurts. We defend our code not because it’s the best or cleaner option, but because it’s ours.

For years, I experienced this with my engineering work. I created my own tools, libraries, and frameworks—many of which could compete with famous open-source and commercial solutions—but I never published or tried to sell them. I felt uneasy about their internal cohesion, thought some architectural choices weren’t elegant enough, or even worried the code would seem over-engineered. I viewed every line of code as part of my biography; if the code wasn’t perfect, I wasn’t a perfect programmer.

The “Speaker” Philosophy

Scott’s solution is to view work through the lens of pure utility. He argues that once sound leaves the instrument, it is no longer the artist’s. It’s just “sound coming out of the speakers.” It’s physics. It either evokes the right emotion or it doesn’t.

Applying this to programming: The code is not you.

Once you commit that code, it becomes an artifact. It’s just logic running on a machine. It either delivers an efficient, maintainable solution to the user’s problem or it doesn’t.

When Scott is in the studio, he doesn’t focus on the singer’s “intent”; he cares about the vibrations in the air. As developers, we need to stop worrying about how our code makes us feel about ourselves and focus solely on the results.

Use the Pitch Correction

To embrace this, Scott argues that we shouldn’t restrict our tools out of a sense of “integrity.” He uses pitch correction (Melodyne), aggressive quantization, and heavy compression freely. If it helps him achieve the sound he wants, he uses it.

In the development world, we often shame ourselves or others for using “crutches.” We might think that using an AI assistant (like Copilot), depending on a heavy framework, or relying on a no-code tool is “cheating.”

Take this blog, for example. I revived it after 15 years of silence because writing had become too difficult for me to maintain consistently. Now, I use language models to help draft and refine my thoughts. Some would view this as cheating—a kind of literary autotune. But it achieves the goal. Thanks to these tools, I now have a way to express thoughts that would otherwise stay locked in my head.

If we adopt the producer’s mindset, the only thing that matters is the output. Is the system stable? Is it fast? Is it maintainable? If the answer is yes, then the tools you used to achieve that are valid. Make the solution your god, and sacrifice your ego at its altar.

The Freedom to Fail

The most liberating part of this mindset is the freedom to fail. Scott talks about recording “stupid” takes just to see what happens. When we detach our ego from the code, we can prototype boldly. We can write “ugly” code to test an idea and not feel embarrassed to show it to others.

If you see your code as a reflection of your intelligence, you will be afraid to share it until it’s “perfect.” But if you treat it strictly as “sound coming out of the speakers,” you can do whatever is necessary to make it work.

Make More Art

This detachment is tough. It requires letting go of the belief that our work defines who we are. I found release in a quote from Andy Warhol that aligns perfectly with this idea:

“Don’t think about making art, just get it done. Let everyone else decide if it’s good or bad, whether they love it or hate it. While they are deciding, make even more art.”

This mindset changed how I work. I stopped fretting over whether my scripts were “good enough” for the public. I realized my hesitation was just vanity dressed up as high standards.

Don’t be precious. The code isn’t you. Ship it!, and let the internet decide if it’s “good” or “bad.” While they’re busy deciding, write the next one.