The Creative Act and Code

Most programming advice comes from programmers. We read blog posts about clean code, watch talks about architecture patterns, and follow debates about which framework is best this week. But sometimes the most useful perspective comes from outside our field entirely.

Rick Rubin's The Creative Act: A Way of Being is a book about making music, art, and creative work. It's not about programming. There's no mention of Git, React, or TypeScript. And yet, reading it felt like someone finally put words to things I'd been feeling but couldn't name about writing code.

Everything is an experiment

This reframes everything about how we approach building software. That component you're writing isn't a final statement. It's an experiment. The architecture decision you're making isn't permanent. It's a hypothesis you're testing.

When you treat work as an experiment rather than a finished product, the pressure changes. You're not trying to build the perfect solution on the first try. You're trying to learn something. The code you write today will probably be rewritten. The patterns you choose might not be the ones you keep. And that's not failure—that's the process.

Rubin writes: "What you make doesn't have to be witnessed, recorded, sold, or encased in glass for it to be a work of art." A refactor that never ships still taught you something. A prototype that gets thrown away still moved your understanding forward. Every line of code is part of the experiment, whether it survives or not.

This mindset also removes the barrier to starting. You don't need the perfect architecture planned out. You don't need to know exactly how it will work. Start with what you know and let the experiment unfold. John Lennon's advice, as shared by Rubin: "If you start a song, write it through to the end in that sitting. The initial inspiration has a vitality in it that can carry you through the whole piece."

The same applies to code. When you have momentum, ride it. Write the rough version all the way through. Don't stop to perfect each function as you go. Get to the end, even if parts are messy. You can clean it up once you see the whole picture.

Failure is just information

"Failure is the information you need to get where you're going."

Every bug is information. Every broken build is information. Every approach that doesn't work is information that gets you closer to one that does. The stack trace isn't a judgment—it's data. The failed test isn't a setback—it's telling you something about your assumptions.

Rubin writes: "Each unsuccessful solution gets you closer to one that works. Avoid becoming attached to the particulars of the problem." This maps directly to debugging. When you get too attached to your theory of what's wrong, you stop seeing what's actually wrong. The bug isn't where you think it is. The solution isn't what you expected.

The best debugging sessions are the ones where you let go of being right and just follow the information. The error message is telling you something. The logs are pointing somewhere. Your job isn't to prove your theory—it's to listen to what the system is saying.

And when you're completely stuck? Rubin's advice: "If you reach a section of the work that gives you trouble, instead of letting this blockage stop you, work around it. Bypass the section where you're stuck, complete the other parts, then come back to it."

This works remarkably well in practice. Skip the function that's giving you trouble. Build the rest of the feature. Come back to the hard part when you have more context. Often the solution reveals itself once you see how the surrounding pieces fit together. The key is to keep moving rather than grinding away at the exact point where you're blocked.

If you're not breaking things occasionally, you're probably not trying anything interesting.

Distilling to essence

Rubin calls himself a "reducer, not a producer." His job isn't to add more—it's to strip away everything that isn't essential.

This is Charles Mingus, quoted in the book, but it captures what Rubin does. "Distilling a work to get it as close to its essence as possible is a useful and informative practice. Notice how many pieces you can remove before the work you're making ceases to be the work you're making."

In code, this is the refactor where you delete more than you add. The pull request that removes a feature. The architecture decision that eliminates an entire layer of complexity. The function that does one thing well instead of five things adequately.

The hardest part isn't writing clever solutions. It's having the discipline to delete them when a simpler approach exists. To resist the urge to add "just one more option" when the work already does what it needs to do.

Good code isn't about how much you can build into it. It's about how little you can get away with while still solving the problem. Every abstraction you don't add is one less thing to maintain. Every feature you don't build is one less thing to break.

Finishing beats perfecting

There's a particular kind of paralysis that happens with side projects. You keep refactoring, adding "just one more feature," tweaking the design. The project is never quite ready to ship because it feels like this one needs to be perfect. This one will define you.

Rubin addresses this directly: "When you believe the work before you is the single piece that will forever define you, it's difficult to let it go. The urge for perfection is overwhelming. It's too much."

But here's the thing: "Each piece can never be a total reflection of us, only a reflection of who we are in this moment. If we wait, it's no longer today's reflection."

The portfolio you're building right now isn't your final portfolio. The side project doesn't have to contain every idea you've ever had. Ship it as it is, move on, build the next thing.

Rubin writes: "In the abundant mindset, the river never runs dry. Ideas are always coming through. And an artist is free to release them with the faith that more will arrive."

The practice of finishing is more valuable than the pursuit of perfection. "Finishing our work is a good habit to develop. It boosts confidence." Every time you ship something, even something imperfect, you reinforce that you can complete things. That muscle matters more than any individual project.

Building this muscle requires practice, and practice requires showing up. Rubin writes: "Put the decision making into the work, not into when to work." Don't waste energy each day deciding whether to work on your side project or when the right time is. Just have a time. Show up then. Let the practice become automatic so your energy goes into the actual work.

And when you're stuck on what to ship: "If you're struggling with ten songs, narrow your focus to two. When we make the task more manageable and focused, a change occurs." Same with code. If the full project feels overwhelming, ship one feature. If one feature feels too big, ship a piece of it. Forward motion beats perfect planning.

None of this is groundbreaking programming advice. But sometimes it helps to hear it from outside the echo chamber of tech blogs and conference talks. Creativity is creativity, whether you're producing an album or building an interface. The principles are the same.

The work requires patience. It benefits from simplicity. It's never finished, only released. And sometimes the best way forward is to step away and come back later.

The Creative Act isn't a programming book. But it might be worth reading anyway.