In my experience, if you have a medium sized task with multiple unknowns, it is best to prototype aggressively without a thought about quality, and then start a second iteration with quality in mind. The purpose of the prototyping is <i>learning</i>.<p>It’s <i>faster</i> (yes) than prototype-then-fixup. Why? Because the ”live refactor” is harder than the greenfield writing phase. The new knowledge often makes the impl straightforward.<p>It’s also <i>better quality</i> than design-then-build. The optimal architecture and modularization <i>change</i> with knowledge increase, which is best to get via experience. You can design fully upfront but it’s riddled with analysis paralysis - it’s notoriously hard (and slow) to predict unknowns.<p>Sounds like good advice? Well, the hardest part isn’t to follow it – it’s to know upfront what size of task it is. If it turns out to be easier, you waste a bit of work (prototype-fixup is faster). However, if it’s bigger than you thought – you’re in the best possible position to break down the new problem into subtasks, with no wasted work.
Create a ~/Archive and throw it in there.<p>A quick grep every blue moon can be faster than wrangling a LLM into place, and as an added bonus you can look back and laugh at how big of an idiot you were.
I don't think the author is necessarily advocating the throwing away of code here, they're advocating the value of being able to rapidly prototype and move on from seemingly incomplete things.<p>The whole value proposition of the digital world is that we can store and manipulate it for virtually nothing: there isn't the same cost to having digital stuff, and so there isn't the same gains from throwing it away IMO.
We need better words for the different code written for different purposes.<p>Code written to learn and explore a problem space? Sure.<p>Code written in response to a prompt, which could easily be rewritten - things like a throwaway “please tell me a story about the contents of this CSV for me and also write code to graph it”. Yep throw it away.<p>Or keep it as an example for a later model.<p>That’s very different to code written to high standards intended for others’ use.<p>We need different words for all of those 3 varieties of code.
There’s something beautiful about not being riddled with previous artifacts and starting clean with how you imagine you want to build your system. If the system is large enough, you can’t do it that often.
Ive got a million messy files saved up, honestly, even when I know just letting go could help me think clearer. Ever wonder if holding onto old stuff slows you down or actually helps you get smarter over time?