In the last blog, I wrote a few things that software is for:
- putting people on the moon
- safely deploying airbags
- making my bank account add up
…
In the last blog, I wrote a few things that software is for:
- putting people on the moon
- safely deploying airbags
- making my bank account add up
…
Once a month or so, this idea comes rambling out of the programming community1:
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
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.
— Dan Luu (@danluu) August 31, 2022
Those are things that could go into a staff promo packet as a major project.
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.1