I don’t understand this very well, but my sense is that “crunch time” is often not a pure option, one where you can trade taking more time for experiencing less stress. If Apple spent two years on every iOS release instead of one, you’d get a substantially different outcome, which I expect would be better in some ways and worse in others.
Rob Ochshorn points out that architecture students often wait until the night before a project is due to start building. This isn’t just procrastination or laziness: waiting gives them the maximum amount of time to ponder and sketch before finally making that idea physical. Because the remaining time is short, they prevent themselves from “editing” too much further conceptually, so they can focus on execution. Sort of related to Premature scaling can stunt system iteration.
At Apple, I noticed that a polish issue needed to get filed and go through normal Radar queueing procedure, it’d probably never get fixed. The program office would (probably correctly) decide that we could ship at a point where that issue wasn’t yet fixed, and after that, there’d be new features to build. Better to fix such issues “in the moment,” while you already have all the relevant context in mind. Often this means working more intensely. Chris Beiser summarized this with the phrase “So unimportant that you have to do it right now.”
Vaguely related: Effective deep work depends on both time and intensity
Q. According to Rob Ochshorn, what might explain why architecture students wait until the night before an assignment is due before they start building?
A. They’re “late binding,” giving themselves more time to think conceptually before committing to physical materials.
what is timeboxing? short, structured
Act like you’re speed-dating until you run out of time.