Byyyeeee Windows 11!
Hello #steamos!

Byyyyyeee Windows 11, hello #steamos

Wirth's Law: Software is getting slower more rapidly than hardware is getting faster.

Despite exponential improvements in hardware, software often feels slower than it did years ago. This happens because:
- Frameworks add layers of abstraction
- Features get added without removing old ones
- "Good enough" performance becomes the standard
- Memory and CPU seem "free" so efficiency is ignored

The solution isn't always faster hardware—sometimes it's writing more efficient software.

Dunning-Kruger Effect: People with low ability overestimate their competence in that domain.

In software engineering, this shows up as:
- Junior developers confident they can rewrite the entire codebase
- Engineers dismissing "legacy" code without understanding its complexity
- New team members suggesting major architectural changes on day one
- Developers convinced they don't need tests

The most dangerous phase is when you know enough to be confident but not enough to be cautious.

I have a rule: "don't speak ill of the dead."

I mean it in the sense about how you talked about people who are no longer at the company with you.

Early in my career, I found teams regularly blaming departed colleagues for the state of a system they were responsible for.

The criticism may have been valid or not. The person may have been responsible or not.

It didn't matter. It bothered me.

1/x

Kernighan's Law: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Write code for the person who has to debug it at 2 AM. It'll likely be you.

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/

Zawinski's Law: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

This law explains why:
- Text editors become IDEs
- Build tools become deployment platforms
- Chat apps become workflow management systems
- Simple utilities become Swiss Army knives

The pattern is feature creep driven by user requests and competitive pressure. The challenge is knowing when to say no to expansion.

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