Once a month or so, this idea comes rambling out of the programming community¹:

Software is prose. It is written to communicate ideas to others, it has the interesting side effect that it can be transformed into something a computer can execute.
- Chet Hendrickson

This sounds nice on paper. It makes for a good conference talk about how to structure software, how to design programming languages, and how to collaborate. I agree with what I think is the intent: write software so that other people can understand it and change it as they need to.

At work I’ve been building a new program on top of an SDK that’s under very active development. After about 6 weeks without updating the version, the SDK had deleted some code I was using and had a ton of breaking changes. If I’d simply updated the library, my entire program would fail to build, and it also wouldn’t be clear how to get it back to a good state. Following in the spirit of Branch by Abstraction, I’d rather introduce the new code side-by-side with the old and incrementally migrate without breaking the program.

I recently read this Washington Post Article (archive.org) titled Caroline Ellison wanted to make a difference. Now she’s facing prison. After the first read-through I was incredulous at the sympathetic presentation in the biography. It reads like a resume, like a “it all spun out of control!” story about someone who got in over her head. I tweeted:

Lol how do you get such a sympathetic bio after stealing billions of dollars @GerritD

JSON deserialization is Go seems easy, but there are a lot of tricky parts. Come and see!

I was reading about Phoenix today, looking at guides and documentation. It’s great to see in a guide when it’s easy to quickly set up a project, that makes it fun to get started and explore. The most exciting thing about Phoenix is that “reactivity”, or live updates, are a core part of the system, not an add-on. Nowadays I find any software without reactive updates frustrating and annoying to use.

There’s been a lot of restrospecting lately, lamenting the loss of the “indie web” and its subsumption by content platforms like Facebook, Instagram, Reddit and Twitter. (I’ve always wondered where Tumblr fit in - more indie than any of these, but still - owned by Yahoo!). A few casualties that fell by the wayside: blogs, web comics, and independent, topic specific forums.

All of these media still exist, much diminished and publishing social posts to route you to their sites, but they are still self-hosted, free of editorial control and in their author’s hands. To some degree, these forms will probably stay on the web until millenials die out.

I love squash merging. I think it’s the simplest way to maintain a legible commit history on main, a shared dev branch, etc. It’s easy for most people to follow, and it doesn’t require you to be too Big Brained about git. GitHub even provides a convenient interface for doing this, right in the pull request UI!

But GitHub’s squash merge workflow undermines the biggest benefits of squash merges: clear, simple, atomic commit messages that explain what each commit does.

Dan Luu tweeted about some great work interns that he has mentored accomplished at Twitter:

One intern did https://t.co/nsFW20j9Hm and another did interesting data analysis then built a working prototype for across the fleet profiling that others were able to use to find real inefficiencies.

Those are things that could go into a staff promo packet as a major project.

— Dan Luu (@danluu) August 31, 2022

OKRs are one of those business ideas that are just simple enough to be dangerous. You think you understand it in a day, and you can see where your company is falling short: lacking focus and underdelivering. You see how clear, measurable goals could improve the situation.

Here’s the one sentence version: You set objectives, and for each objective come up with several key results that you can measure to see if you met the objectives. There’s a whole book for implementing this process in large organizations, and a mystique because of its association with Google’s early and frightening effectiveness.¹

Every so often I’ll see a meme on Twitter like:

and it makes me so mad. For good reason! OSS project repositories that support merge commits to main are usually littered with useless comments like: “Merge change from $USER, $PR”. It makes the commit history on main utterly useless and you get to check the various feature branches in a never ending snake of commits to find out what the hell changed.