To write code that's easy to delete: repeat yourself to avoid creating dependencies, but don't repeat yourself to manage them. (#)
At 17 minutes "How do you change your software? Well, maybe you should just plan to throw it away. ... Let's just plan to throw our stuff away, so when you write it there's a little bit less stress. You can also try out new things because there's less stress about trying out the new things. And not only can we throw away the new pieces of code, but we should, because you need to be able to change your software. ... If you need to be able to change it. If you do it all the time and you plan to do it, then it becomes easy to throw stuff away." (#)
Developers should avoid writing big programs. This rule aims to prevent overinvestment of development time in failed or suboptimal approaches caused by the owners of the program's reluctance to throw away visibly large pieces of work. Smaller programs are not only easier to optimize and maintain; they are easier to delete when deprecated. (#)
By default, good code tends to be modular and easy to replace, while bad code is excessively coupled and hard to get rid of. So bad code has a disproportionate impact on long-lived codebases. I wonder if one way around this is to force modularity, even when it's unnatural. Functional programming seems to be one way of doing this, microservices are another. A related principle would be not to take DRY too seriously, favoring decoupling over deduplication. (#)
At 22 - No shared code (shared code is also permanent code) (#)
At 3120 he talks about making his code disposable (#)
"The first principal of this approach is, unsurprisingly, to keep the components of the software system small–just as complex organisms like human beings are constituted from billions of tiny cells which are constantly undergoing a process of renewal." (#)