The Mundanity of Excellence, Small Wins, and Why You Should Fix Bugs Before Writing New Features | Probably Dance

The core argument is straightforward: excellent software doesn't come from flashy new features but from relentless attention to small details. Malte Skarupke points out that once software reaches a certain complexity level, you can't improve it through major wins anymore—you need hundreds of tiny improvements locked in place. These are the unglamorous things: tooltips that work, keyboard shortcuts, responsive performance, correct edge case handling. Without constant maintenance, these slip away and your software erodes back to mediocrity. Most organizations don't operate this way, which is why most software feels half-finished. The practical implication is that bug fixes should outrank new feature work, even when those bugs affect low-priority features. This isn't intuitive to many programmers, who naturally want to build something new rather than maintain what exists. But Skarupke argues that if you don't lock these improvements in through tests and consistent processes, they'll vanish the moment pressure mounts. The organizations that ship genuinely good products have better processes—more code review, shorter feedback loops, higher standards for what's acceptable to push, and a cultural commitment to fixing things rather than letting them accumulate. The real skill isn't in having brilliant ideas; it's in doing ordinary things consistently and correctly. Skarupke borrows language from game developers like Blizzard to frame excellence as "a confluence of hundreds of small polishes." Nothing superhuman about any single piece. The difference between software people tolerate and software people actually enjoy using comes down to whether an organization has the discipline to maintain quality through small, accumulated wins rather than expecting one breakthrough feature to save the day.