Jonathan Blow on pausing to polish vs taking shortcuts
- YT :: https://www.youtube.com/watch?v=423dpapK-7A
- Original title :: Jonathan Blow on software polish
A clip (from https://youtu.be/_NmfCLssHuI) in which Jonathan Blow and fellow programmers (incl. Casey Muratori) discuss deliberately stopping to polish parts of a project as a way to keep morale up, and how this contrasts with the "don't rat-hole" advice.
Shortcuts erode morale
- Blow's philosophy is to get things running as fast as possible, taking many deliberate shortcuts — "walls made of paper" that must be revisited later.
- They pile up, and the picture of the project shifts from "amazing thing" to "crappy thing of shortcuts". Morale drops, which makes it harder to keep going.
Periodic hardening
- On his compiler, Blow sometimes stops and refines a few areas far beyond what's needed: chasing every corner until he's proud of it.
- Demos help: freeze scope a week before, then spend the time hardening what already works. The result feels like quality rather than something that collapses when you look away, and that pride sustains motivation.
Features vs quality are separate axes
- A co-host: overbuilding is a real danger, but adding features and making a system good are unrelated.
- Limit the features axis to what's actually needed; push the quality axis further than you would by default.
Context decides which advice applies
- Styles differ: one approach gets the lowest-effort version on screen and elaborates later; another invests in infrastructure earlier.
- "Stop and make one piece high quality" is nearly the opposite of "don't rat-hole", yet both are right at different times and project stages.
- A good programmer knows when to swap one piece of advice for the other, or blend them (30/70). This is why newcomers get confused by seemingly contradictory advice.