Today I LearnedRSS

February 2024

2024-03-01
Lecture Friday: Spec-ulation Keynote

A Rich Hickey talk is always a good time.

Here I think he's right on in understanding the real problems of versioning and communicating what we've done to our code that someone else depends on. I also love the attention to the real semantics through set operations. I also think he's right. Every time someone breaks something I depend on, I'm forced to do a bunch of work because of someone else. Not work I wanted to do, work they made me do. And that makes me want to instead do the work to delete that dependency. It's costing me extra work to maintain it. Work that's usually not improving my work in any meaningful way to me and my users.

Telling developers building dependencies, building platforms, that it's fine to break things as long as you change the left most number invites them to break things. It says it's fine as long as you let me know. It's not fine. Stop breaking things! If you want people to depend on you, be dependable. "The spec says I'm allowed to. I changed the number."

No. Just because you can doesn't mean you should. My favourite dependencies don't break things. They continue to work, they know when to stop. My favourites haven't been updated in years. When did we get this insane idea that everything needs updating to add new things I don't care about all the time? I blame Microsoft but we all need to stop it. Build new things when you want to add something. It's fine to create a new package that depends on the first if you're adding new things. The vast majority of people using the first thing, by definition, don't need the new thing.

2024-02-23
Lecture Friday: Intro to Empirical Software Engineering: What We Know We Don't Know

Facts? Get out of here! We rely on sophistry alone in this field, sir.

2024-02-19
The Performance Inequality Gap, 2024

I keep talking about performance, this is exactly what I'm talking about.

2024-02-16
Lecture Friday: Barely succeed! It's easier!

I really like this mental model. It's not that hard to succeed if your idea of success is reasonable.

2024-02-15
Don't Do This

Huge list of great tidbits.

2024-02-14
PostgreSQL Subtransactions Considered Harmful

Great explanation on why carelessly wrapping and rewrapping things with transactions in your ORM will cause you problems.

2024-02-12
Common DB Schema Change Mistakes

Know your tools.

2024-02-09
Lecture Friday: BEST WAY To Read And Understand Code

The trick to reading code is to stop trying to play computer in your head. It's also how you debug code, modify other's code, etc.. You're sitting in front of a computer. Let it compute things for you. Said another way, don't think when you should compute and don't compute when you should think.

2024-02-06
The Influence Of Organizational Structure On Software Quality: An Empirical Case Study

Design for Conway's Law, not against it. Seriously, what this shows is that software that has multiple people working on it who's lowest common manager is high up in the org (i.e.. they don't share direct manager but only a director or worse vice president) have the highest number of bugs in them.

2024-02-05
Squeeze The Hell Out Of The System You Have

Getting performance right is important. Deciding to change everything and rewrite it all because you can't be bothered to measure and try and fix things is an all too common hubris.

2024-02-02
Lecture Friday: Writing Beyond the Academy

Very simple concept, if your writing isn't obviously valuable to the reader it's worthless. Acting on this is much harder, but at least with the right direction you can aim to improve.