I’ve been making music on hardware sequencers for years, and at some point the two halves of my brain — the one that designs software systems and the one that patches synths — started talking to each other. The conversation they’re having is more interesting than I expected.
The obvious overlap is sequencers. A step sequencer is a state machine. It has a cursor, a set of steps with associated values, a clock driving transitions, and output that depends on current state. If you described this to an engineer without mentioning music, they’d call it a finite automaton running on a fixed-interval scheduler. They wouldn’t be wrong. The fact that the output goes to a VCO instead of a database doesn’t change the underlying structure.
Palette as mood
But the deeper overlap isn’t structural, it’s intentional. When I’m composing, the first decision is always mood: what is this piece supposed to feel like? That decision propagates everywhere. It constrains the key, the tempo range, the timbral palette, the dynamic arc. Every subsequent choice either serves the mood or fights it.
Software systems have the same thing, even when nobody names it. A system designed for latency-sensitive trading has a different texture than one designed for batch scientific compute. The constraints cascade the same way — from the top-level intention down to whether you’re using async I/O or blocking calls, whether errors are logged or surfaced, whether state lives in memory or on disk. The palette shapes everything even when you think you’re just making local decisions.
I try to be explicit about this now when I’m architecting. Not just “what does this system do” but “what should it feel like to operate it?” The answer changes the design in ways that pure requirements analysis misses.
Emergent complexity from simple rules
The drone engine running on this site is a good example of what I mean by emergent complexity. The rules are genuinely simple: a base frequency, a set of interval ratios derived from the active palette, an LFO with a slow random walk, a reverb tail that accumulates. No composition, no predetermined structure. But the output sounds composed — it has movement, texture, and a sense of intention.
This is the same thing that happens in good software architecture. The individual rules — keep functions small, separate concerns, make state explicit, handle errors at the boundary — don’t individually produce elegant systems. But applied consistently, they produce systems that feel designed even when they weren’t planned in detail. The elegance is emergent, not specified.
I think this is why both disciplines reward obsessive attention to the small things. In music, the attack shape on a single envelope can change whether a patch feels nervous or settled. In software, the exact contract of a single function can change whether a module feels trustworthy or brittle. The craft is in noticing these small things and caring about them before anyone else has to.
Transitions
One last overlap: both are about transitions as much as states. A piece of music lives in the movement between chords, not just the chords themselves. A system’s character is revealed in how it handles load spikes, failures, and schema migrations — the transitions — not in how it behaves under steady-state nominal conditions.
If you’ve ever heard a song where the chorus is good but the verse-to-chorus transition is awkward, you know how much that seam costs. The chorus doesn’t matter yet because you’re still stuck on the stumble. Same with systems. Get the transitions right. The states will follow.