Today I LearnedRSS

March 2024

2024-04-01
Unix terminals and shells - 1 of 5

Part 1/5 on better understanding what a terminal is and how it works.

2024-03-25
Safe Ways To Do Things In Bash

I still don't think you should, but if you're going to write programs in bash, you should at least try and know what you're doing to prevent shooting yourself in the foot.

2024-03-22
Lecture Friday: Simplicity: Not Just For Beginners

On a simplicity kick. Seriously, stop complicating things when they're too simple for you. A program really can just be a series of nested function calls and no more. Resist the temptation to "simplify" an already simple problem.

2024-03-21
The Rise of Worse is Better

One of the older essays with interesting things to discuss. Worth a read and deep contemplation.

2024-03-20
The Evolution of a Programmer

Less practical and more comedic.

2024-03-19
The Grug Brained Developer

This is the only software philosophy you need.

No, really. It will make you as smart as Socrates. To know that you know nothing is the beginning of true wisdom.

Update (2024-12-14): I've actually written an entire post similar to this in my piece discussing Knowledge vs. Wisdom. That's how important an idea I think this is.

2024-03-18
I'm A Programmer And I'm Stupid

I've rarely felt more like I could have written a post than this. Stop over complicating everything.

2024-03-15
Lecture Friday: Keep Your Crises Small

Absolutely invaluable insights into managing and creativity.

2024-03-08
Lecture Friday: A Taste of GPU Compute

Great introduction to many core computing.

2024-03-07
Shitlist Driven Development

Such a simple concept that gives you so much return. I've used this to great effect in many large projects.

2024-03-06
The Tao of Programming

A fun combination of Taoism and software development. Truly something valuable to the career programmer.

2024-03-05
Steve Yegge's Google Platform Rant

If you're writing SaaS you really need to understand these concepts.

2024-03-04
Write Code That Is Easy To Delete, Not Easy To Extend

The amount of time it takes to remove code you didn't write in most code bases is way too high. Too many people think the source code is the valuable part of the company when it is quite clearly the mental model in the heads of the programmers that provides at least ten times the value.

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.