Post

accelerating iteration only leads to better solutions faster if you approach the iteration methodically, with intention and goals. shitty first drafts are useful only insomuch as they force you to wrestle with what you actually want to say

rain 🌦️@sunshowers.io

Look this is sometimes true but also most of nextest's core architecture is basically the same as it was day 1. Plenty has changed around it but this page, extracted from the first design doc I wrote for it, has not nexte.st/docs/design/...

this is a thing that comes up a lot in design innovation practices, where the goal is to iterate into a problem-solution pair: a misguided belief that since your first proposal is unlikely to be correct (usually true) it’s always most effective to accelerate iteration

and like, my spicy take is that sometimes it is better to wait and do nothing, to let an idea simmer or ferment until you have a clear enough idea of what you want to say, walking the edges of something till you understand it and can get it out in the first go. sometimes that is worth doing.

0 reposts1 like

and other times you do want to move fast, to create a velocity that pulls you through a learning process. a first draft, your own critical eye, peers, friends, a second round of edits, another attempt… “co-evolution of the problem and solution space” by way of interventions and stimuli

anyway the point here is it’s all well and good to be like “okay your first ten will be bad so just get to eleven as fast as possible” but the first ten are only bad and the eleventh good because *the work of making them* helps you figure shit out

i am currently fighting this battle against designers who want to prototype faster with vibe coding and my position has been and will remain “lots of cheap high fidelity prototypes” only help you skip a bunch of foundational problems that will eventually bite you in the ass