Examples of The Eponymous Trifecta:
- “Black Sabbath” by Black Sabbath from the album Black Sabbath
- “Motörhead” by Motörhead from the album Motörhead
- “Iron Maiden” by Iron Maiden from the album Iron Maiden
Hopefully you’re starting to see the pattern. (There’s way more of these out there. Let me know your favorite!)
Let me throw some variety in:
- 🤷♂️ by Metallica from the album Metallica
- “Bo Diddley” by Bo Diddley from the album Bo Diddley
Ergo: You’re not metal if you don’t have a trifecta. Metallica is not metal. This is probably some kind of paperwork mistake.
But, Bo Diddley is metal. Just listen to the music, I think you’ll agree.
git-spice – stacked diffs, but without another (SaaS) tool to provision and pay for. Excellent ergonomics, if you’re comfortable with the git CLI as-is. I’ve tried this for one project so far, things went as hoped. Moving between commit ‘stacks’ is easy, and rebasing changes from the main branch is straightforward. This is the quality of tool I’d hope to see in git in the first place. But maybe that’s a 2026 expectation. 😇
When you’re stuck or uninspired, reach for your spark file:
This is why for the past eight years or so I’ve been maintaining a single document where I keep all my hunches: ideas for articles, speeches, software features, startups, ways of framing a chapter I know I’m going to write, even whole books. I now keep it as a Google document so I can update it from wherever I happen to be. There’s no organizing principle to it, no taxonomy–just a chronological list of semi-random ideas that I’ve managed to capture before I forgot them. I call it the spark file.
Steven Johnson, The Spark File
It’s a productive trick that doesn’t have an ecosystem of applications, courseware, and influencers wrapped around it. I dig that.
Adjacent: swipe files and commonplace books.
If you were wondering, “could anyone make OAuth2 an even more involved, jargon-filled process?”, the answer is yes. AT Protocol and Bluesky sure did. 🙃
RIP my vim muscle memory
I bet a lot of the grumbling about coding agents is really about losing out on the joy of moving quickly through code via a deeply learned text editor. I’m feeling it too, but I’m not so great at vim that my whole coding identity is wrapped up in it.
As goes the complaint about the decline of manual transmissions, even in sports cars, so goes the decline of emacs/vi/etc. “No connection”, “not enough focus”. Not wrong, but the toothpaste is out of the tube here.
That said, there’s a legitimate complaint to make here about software slowing down! We were almost getting to the point that raw latency was a virtue in software. And then we got uncanny, but not fast, intelligence. 🤷
It strikes me that my text editor is now, effectively, a quasi-natural language interface onto bulk and sometimes quite intelligent text operations. Well, sometimes entirely not what I want. But still, bulk and natural language.
Lately, I try Cursor every several weeks. Mostly to see if the grass is greener. But it’s not for me. Jetbrains-flavored tools are more holistic and more right for me. Regardless of the grass.
I think Cursor is an intriguing team and a good product. The best version of VS Code you could possibly use, the easiest possible onramp to coding with agents. Nonetheless, I want to be using Zed for everything. However, I think the writing is on the wall for pure, even principled, text editors. Typing in code is no longer the bottleneck. Memorizing keystroke optimizations is doubling down on a sunk cost.
Looking at the functionality of an integrated environment like RubyMine or PyCharm, I think the value of its git integration has gone up by a lot. This is essentially why I went back to PyCharm from Cursor. I can’t be bothered with simplistic, non-excellent git interfaces. (I wonder if Sublime Merge sales will start to exceed Sublime Text sales. 🤔)
VS Code, and Cursor by literal extension, seem like the keybindings were invented by 3 different people ten years apart. Which they probably were, literally. I can’t abide this.
The other thing that brought me back to PyCharm is browsing/discovering data alongside code alongside revision changes. It stands to reason that if writing code is less critical in the future, understanding the data will grow in importance. Even better, understanding your code and data in the same tool, with sensible affordances to jump between the two. This is why I’m betting on IDEs gaining ground.
Let’s not mention the part where now we’re paying for code, from our new-found editors, by the line. I’m surprised I’m not more salty about this.😬
The future of code is understanding the whole system, not constructing each part in exquisite detail. The IDE of the future probably looks more like code review alongside a debugger, than a code editor with version control and data management attached as sidecars. A bunch of Slacks and GitHubs mashed together.
Yeah, I’ve locked in to a few writing and coding sessions with The Social Network soundtrack. But, have you ever tried locking in to something you can move your hips to?
Related: currently compiling a list of Soundtracks That Didn’t Have To Go So Hard, and Prince’s Batman is way up there.