Read on Twitter
I really like the idea of what I call “product driven development” - the thing you’re making is a product and your goal is to make a product people want in a timely manner, not one that’s “correct”
it’s not super important that your code underneath the covers is elegant and satisfying - what’s important is that you can move fast enough to keep up when you figure out how your thing is bad
I deeply agree with the idea that you *will* build the wrong thing. I’d go further than this and say that full rewrites, where you’ve ostensibly learned important lessons, are doomed to the same issues
I have an essay about this that I need to iterate on but might publish tonight
Wrt code reuse: Geepaw Hill had a great thread the other day about incremental rewrites and a big chunk of that is knowing when to introduce redundancy in order to make the change you want
Something I’ve been thinking about recently is the space between deep convention/consistency versus exploration/loose constraints. Earlier in my career I was really big on consistency, but now I think it’s worth sacrificing if it lets you move faster or satisfies requirements
