[_benj]

> Implement twice; pick the better version.

This! I like most of the ideas and it sounds like a fun exercise to try a few for 1-2 weeks, but I think that implementing something twice could yield so much value!

In my role I prioritize code maintenance, probably because I hate work with painful codebases, probably because I’ve seen 5 years+millions of dollar projects fail as the tech debt piles up and the codebase grows too fragile to implement new features needed to go to market, probably because I’m lazy and don’t like to read much to know what the code is doing.

But one of the best architectures I’ve ever built was one that I had to implement 3 times. Now, this wasn’t because of my vast wisdom but because I literally coded myself in a corner the first two! (Go rigidity around circular dependencies is a double edged sword)

[leetrout]

Mythical Man Month: Build one to throw away

https://wiki.c2.com/?PlanToThrowOneAway or for iphone users https://archive.md/zdfXh (no idea why they are blocking iphone)

Quotes about Joe Armstrong say he solved the same problem in multiple iterations to refine the solution.

Some of his opinions: https://joearms.github.io/published/2014-02-07-why-programmi...

[burke]

I’ll frequently do this when I start large refactors or implementations. I’ll build a big ugly branch that kind of works, then, when I have a better idea of where I’m headed, start from master again, building a chain of sometimes a dozen or more PRs, mostly from scratch, that build to the same point as that big ugly branch. Along the way, the code and architecture tend to improve dramatically.

[MontagFTB]

I’ve followed a similar pattern before in large features as well. During each iteration my mental model improves dramatically, and I have no qualms about deleting everything and starting over, because I _know_ the next iteration will be that much more correct, performant, and/or maintainable.