AHA Programming

https://kentcdodds.com/blog/aha-programming

AHA means Avoid Hasty Abstractions and looks like an intermediate step between DRY (Don't Repeat Yourself) and WET (Write Everything Twice). The essential principle is to prefer duplication over the wrong abstraction, which means don't be too strict and use whatever fits right now.

I want to quote this part:

I think the key is that we don't know what the future of code will be. We could spend weeks optimizing code for performance, or coming up with the best API for our new abstraction, only to find out the next day that we made incorrect assumptions and the API needs a complete rework or the feature the code was written for is no longer needed.

We always hear some advice about writing code, e.g.:
1. Optimise for performance first
2. Optimise for change first
3. Optimise for reusing first
and so on and so forth

I want to add one more — optimise for deleting first.
This corresponds to the excerpt above. If we don't know what the future of code will be, it's possible that we'll need to change it completely.
Obviously, it's much easier to remove old code and write new instead, than try to add new functionality to existing legacy, trying to support all leaking abstractions.

We usually can't do this because existing code is tightly coupled with other parts of the system and simply isn't optimised for deleting.

Once again in the end:

1. Design better interfaces between subsystems
2. Duplicate when necessary
3. Avoid hasty abstractions

Epic List of Every Product Prioritization Framework

https://www.terem.com.au/blog/product-prioritization-framework-list/

This article has links to 17 (seventeen!) ways to prioritise features.
Some of them are trivial, and everybody knows it. Some are very sophisticated and hard to understand.

The key takeaway for me is simple: if there are 17 prioritisation frameworks, at least one of them would show that your favourite feature should be done first.
The concept is similar to "How to Lie with Statistics" but about priorities. Almost no limits for wasting time.

TechnicalDebtQuadrant

https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

This is an old (read classic) short article by Martin Fowler about different types of technical debt.

He splits it into two major categories: reckless and prudent.
Each of these two can be divided by intent to deliberate and inadvertent.

Now you can just say "deliberate reckless debt" instead of "copy-paste from StackOverflow", sounds much smarter.

A List of Post-mortems

https://github.com/danluu/post-mortems/blob/master/README.md

This is only the link because I've read only a few of it. Overall this is a catalog of post-mortems of which were written by different companies (e.g. Google has 8 right now, Facebook published only one).

Learn from others mistakes, dear crocodile.