Hyrum's Law: With a sufficient number of users of an API, it does not matter what you promise in the contract; all observable behaviors of your system will be depended on by somebody.

This means:
- Users depend on bugs
- Implementation details suddenly are the spec
- Breaking changes are always breaking for someone
- Documentation is a suggestion of intent rather than reality

Also, relevant XKCD: https://xkcd.com/1172/

Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity.

In engineering contexts, I try to add on the idea of "constraints you can't see."

- That incoherent API design
- The terrible code
- The irrational architecture

Before assuming incompetence or malice, try to understand the context.

Awwwww…I missed that Django turned 20 yesterday.

Happy Birthday @django !

How many programming languages do you use on your average day in your current role?

The strongest engineers write things down in a place where others can find them.

This is important enough that Gitlab has it one of their core values.

You hear lots about why writing is good for yourself, and it is.

But the kind of writing I’m talking about now is fundamentally not for you, because software engineering is a team sport.

Continued here: https://raiderrobert.substack.com/p/why-writing-is-an-engineering-superpower