I have shipped a lot of software and finished very few songs. For a long time I assumed that was a discipline problem, and that the discipline I already had would fix it.
The pitch to myself was reasonable. I spend my working life on the argument that a small thing released beats a large thing polished forever, that scope is the lever you pull, that work sitting unfinished is not an asset. I had a folder of forty-odd song fragments doing nothing. Obviously the answer was to apply the same rules.
What actually transferred
Three things, and they helped more than I expected.
Cutting scope works. Most of my unfinished songs were unfinished because I had decided in advance that they needed a bridge, a second verse of equal weight, and a resolution. Deciding a song is allowed to be ninety seconds long with two parts finished a lot of them. Nobody has ever complained that a song they liked was too short.
Limiting work in progress works. Forty fragments is not a catalogue, it is a graveyard with good intentions. Holding two or three at a time and refusing to start a fourth is uncomfortable in exactly the way it is uncomfortable at work, and produces the same result: things start reaching an end state.
An external date works, which is where busking earns its place. A song that has to be playable in public on a specific afternoon stops being a permanent draft. The deadline does not have to matter to anyone else. It only has to be real to me.
Where the analogy breaks
Then it stops working, and it stops working in a specific way that took me embarrassingly long to see.
Software gets to iterate after release. That is the whole basis of shipping small: the thing goes out, you learn, you change it, the changed version replaces the old one everywhere. A song does not behave like that. Once you have played a song a few dozen times, the arrangement sets. Not because you cannot change it, but because your hands have learned it and every subsequent version is a fight against muscle memory. Shipping early on a song is closer to pouring concrete than to pushing a commit.
Second, "done" has no definition. In software, done is a set of conditions you can write down and check. A song is done when it feels done, and that judgment is the actual skill, the thing I do not have much of. Treating it as a requirements problem just moves the vagueness somewhere else. I spent a while writing myself checklists for song completion. They produced songs that satisfied the checklist and were dead.
Third, and this is the one that stung: velocity is not the constraint. My songs are not bad because I write too few of them. They are bad because my ear is ordinary, my chord vocabulary is small, and my lyrics reach for the obvious image first. Volume does help with that, slowly, but the shipping mindset let me feel productive while avoiding the slower work of getting better at hearing. Finishing thirty mediocre songs is not thirty steps toward a good one unless you are actually listening to what was mediocre about them.
Where that leaves it
I kept the scope cuts, the limit on parallel drafts, and the external date. I dropped the completion checklist and the idea that throughput fixes taste. What replaced them is duller: play the thing to someone who does not care about my feelings, notice what I skip past when I listen back, and sit with the uncomfortable bar rather than routing around it.
The off-the-clock framing in the tagline of this section is not modesty. It is accurate, and it is also the reason any of this is enjoyable. Nothing here has to be good. It only has to be finished, honest about what it is, and occasionally played to a stranger who owes me nothing.
More in this pillar: Music · The instruments, and what each one is for
Ready to Train Smarter?
Get personalized training zones, race predictions, and performance insights with our free calculators.
