Agreed - There's a certain thing about greenfield development in particular(which is quite fully the realm of startup coding) where you have to approach the fir

Agreed - There's a certain thing about greenfield development in particular(which is quite fully the realm of startup coding) where you have to approach the first, second, maybe third iteration as one that will be thrown away, so when it does get thrown away, you make it easy to do so. And that leads towards some pretty dumb code, often "copy-paste-modify, sort it out later" code. A lot of "best practice" ideas that get made into blogposts impose a structure that hinders disposability in favor of a certain aesthetic goal: to do the thing with less repetition and slightly cleaner abstractions. The goal is often not unreasonable, but it conflicts with the action of rapid iteration. So I tend to write now with an eye towards trying to keep the code disposable until I face a certain class of error to eliminate, that needs the more abstract method. Often part of the disposability is in not actually solving the entire problem, but cheating and returning a wrong answer, e.g: Instead of fancyAlgorithm() being written in a way that creates any dependencies I write a skeleton "function fancyAlgorithm() {return true;}" and then later upgrade it to a lookup table, and then to the algorithm. Because most of the code that matters to the app won't be in the algorithm, but in how all the other data is being passed around. The sooner I can get that piece to return a wrong answer with known error, the sooner I can arrive at a complete but wrong app, which can be corrected into a higher quality one. When not all the pieces of the app are there, it's not clear what error you need to be solving for, which leads to squeezing effort onto code that isn't important.