I am deliberately eclectic.
I write mostly about software engineering, and I also post #programminghumor, #gaming, #writing, #gamdev, and lots of other stuff.
I tend to write stuff in #python these days with bits of #js / #go / #rust tossed in. Playing with #godot too!
Engineer and manager at https://unstructured.io
“The way things are” is phrase almost never applied to physics or some fundamental reality.
It’s a defense of the status quo. Be it law, custom, habit, culture, practice, or received wisdom.
It exists because each morning we wake up and collectively decide that we’re “ok” with it.
We decide it “is” through our own collective indifference.
If tomorrow we wake and say, “things will be different.” They would change.
Slowly at first. And then all in a rush.
The Five Categories of BS Jobs by David Graeber
1. Flunkies - make someone else look or feel important
2. Goons - exist only because other organizations also employ people in these roles
3. Duct Tapers - fix problems that shouldn't exist in the first place
4. Box Tickers - exist primarily to allow an organization to claim it's doing something it isn't actually doing
5. Taskmasters - assign work to others or create BS jobs for others
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.
