Music production taught me to write better code

I’ve been making music on and off since my teens. At some point I realised that the skills I was developing in the DAW were the same ones I was developing as a programmer. The languages are different. The discipline is the same.

Arrangement is architecture

In music production, arrangement is the structure of a track - where the verse goes, when the chorus hits, how the breakdown is spaced. Good arrangement means each section earns its place. Bad arrangement is a track that overstays its welcome or collapses before it gets going.

Software architecture is the same thing. Where does the logic live? How do the components relate? What belongs in this layer, and what belongs in another?

When I’m designing a system and something feels wrong, the instinct I reach for is the same one I use when a track doesn’t land: is the structure right, or is the problem actually here?

Abstraction and the sample

A sample in music is an abstraction. You take a piece of something - a drum hit, a vocal chop, a bass line - and you lift it out of its original context to use somewhere new.

Good sampling means understanding what made the original work, and knowing which parts to carry forward. The same is true for code abstraction. You’re extracting the useful thing and leaving the context-specific noise behind.

The iteration loop

The most important thing music production taught me is comfort with iteration.

No track is good on the first version. You make a loop, you live with it, you come back, you notice something wrong, you fix it. Repeat for weeks. The finished thing looks nothing like the first sketch.

Writing software is the same. The first version solves the problem; the second version solves it more clearly; the third version makes the right tradeoffs. Expecting the first version to be the final version is how you get stuck.

The ear test and the code review

In music, the test is: does it sound right? You can know all the theory and still make something that doesn’t work. The ear doesn’t lie.

In code, the equivalent is: does this feel right to read? You can have correct, performant, well-tested code that is still unpleasant to work in. The reader doesn’t lie either.

Both crafts reward patience, taste, and a willingness to throw away what isn’t working.