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.
Wrapping up lil’ document editor “research”, starting to write more on it. In short: cross-platform in the Apple ecosystem is possible, but tricky once you get into third-party libraries. Agent coding makes a lot possible, but doesn’t make anything trivial. Prototypes without a plan for using it regularly, at least in the process of building the thing, are not going to generate useful insight.
False spring has passed in Portland, real spring is coming up soon. Our yard is starting to bloom. I’m fine with trading off an hour of sleep tomorrow for later sunsets.
📚 Iberia / James Michener, Liberation Day / George Saunders
🎧 Jill Scott, To Whom This May Concern. First album of hers I’ve listened to, it is excellent.
📺 Wonder Man, Ponies. The latter is great but somehow over-complicated the season finale.
🎮 Marathon, somewhat surprising to me. But, I’ve played a lot of Halo and entirely too much Destiny, so this tracks.
💻 Amp and Paper are pretty dang good, Claude Opus 4.6 is as good as they all say. I’ve bounced off Cursor, VS Code and its forks just aren’t for me.
✈️ Visited my parents in Dallas, had literally too much Tex-Mex. Happened to sit at the table next to Randy Travis at dinner one night. We rented a new Ford Bronco, and that is a large car. Perfect for Texas highways, though, if you don’t mind the wind noise.
Behind every guitar god there is, literally, a drummer making the odd 7/8 or 5/4 bar sound like 4/4. Paraphrasing Einstein, true guitar gods don’t play at dice or outside of a strict 4/4. (Inspired by: what the heck even is “Black Dog”?)
Squeeze out the trickiest part of the problem, another part of the problem becomes the trickiest. A tale as old as time.
Today, it seems like the biggest opportunities will be in the third of my opening statements. Building systems remains hard. Can I assume you’re familiar with Amdahl’s Law? That’s what’s going on: a massive speed up on a portion of the problem, but as that portion speeds up it becomes less and less of a contributor to the overall speedup. Lowering the costs of the rest of the problem is work that remains to be done. It’s going to take a long time, because the real world is fully of sticky problems, surprising feedback loops, human stubbornness, and the occasional adversary.
– Marc Brooker, You Are Here
You squeeze out coding time, you’re still left with open problems like:
- Running software in isolated, trusted environments (sandboxes) and coordinating work between programs (agents, databases, etc.).
- Human think time, which generates things like taste, and deciding to include this feature instead of that feature because intuition says it will improve the software.
- Coordination and collaboration between humans, which generates recurring meetings (no, thanks) but also great ideas out of nowhere (that’s why we’re here!)
- Verifying what you’ve built and vetting that what you’re proposing to integrate (merge) into the software is any good.
Be careful not to squeeze out the costs that are actually valuable. Otherwise, you might end up with inversions like banks that operate vast airborne transit networks at a loss.
I love when/what Matt Webb builds:
It should be SO EASY to share + collaborate on Markdown text files. The AI world runs on .md files. Yet frictionless Google Docs-style collab is so hard… UNTIL NOW, and how about that for a tease.
We need more “this (thing) should be as easy to collaborate on as Google Docs” sort of things in the world. Granted, I’m not a fan of writing in or using Google Docs! But the collaboration model is right and people know how to use it. May many more bloom.
Contra my optimism on software estimates, some realism:
I gather as much political context as possible before I even look at the code. How much pressure is on this project? Is it a casual ask, or do we have to find a way to do this? What kind of estimate is my management chain looking for? There’s a huge difference between “the CTO really wants this in one week” and “we were looking for work for your team and this seemed like it could fit”.
Ideally, I go to the code with an estimate already in hand. Instead of asking myself “how long would it take to do this”, where “this” could be any one of a hundred different software designs, I ask myself “which approaches could be done in one week?“. – Sean Goedecke, How I estimate work as a staff software engineer
Folks with the best intentions have asked me “How long would this project take? Please say two weeks, that’s how much time we have.” Well maybe I embellished the second part. Point is, too often I interpreted this as asking the question, and not asking for an answer in the time-is-scarce context we were actually operating in.
We often didn’t like the answer. Too much scope cut to fit in their time frame (aka appetite) or not enough detail to decide where to trade scope for time.
In other words, I don’t “break down the work to determine how long it will take”. My management chain already knows how long they want it to take. My job is to figure out the set of software approaches that match that estimate.
Sometimes, you make your coin by delivering exactly what was asked for, sometimes you make it by solving the problem in a novel way. Every so often, you make it by saying no and choosing to do something with better trade-offs.
Astronomy is perhaps the science whose discoveries owe least to change, in which human understanding appears in its whole magnitude, and through which man can best learn how small he is. – Georg Christoph Lichtenberg, The Waste Books
You can’t argue with a star!
I went to see an elephant about a birthday.
Dave Rupert, Write about the future you want:
There’s a lot that’s not going well; politics, tech bubbles, the economy, and so on. I spend most of my day reading angry tweets and blog posts. There’s a lot to be upset about, so that’s understandable. But in the interest of fostering better discourse, I’d like to offer a challenge that I think the world desperately needs right now: It’s cheap and easy to complain and say “[Thing] is bad”, but it’s also free to share what you think would be better.
Co-signed.
I’ve been reading Power Broker on and off throughout the year (brag). I’m almost five hundred pages in (brag again) and it’s worth it. The writing is as good as the research is deep. Which is to say, it manages to maintain a great pace even though it’s a huge book (brag the third). Caro’s pacing, by alternating between moving the Robert Moses story ahead and adding color by telling the brief story of the minor characters involved in Moses’ story at the time.
Furthermore, Robert Moses was a real jerk. And, a bully. 🤦♂️ Same as it ever was.
I’m continuing with the Dune chronicles. Children of Dune seemed like all setup and only perfunctory pay-off. God Emperor felt like it had more to say, whether it’s philosophical or political. The three thousand year jump ahead is a lot, though!
As a palate cleanser between Dune novels and Power Broker chapters: just started Liberation Day by George Saunders and Iberia by James Michener. 📈
If you have significant previous coding experience - even if it’s a few years stale - you can drive these things really effectively. Especially if you have management experience, quite a lot of which transfers to “managing” coding agents - communicate clearly, set achievable goals, provide all relevant context.
Based on my own experience and the industry news, it’s not a great time to look for engineering management work. But, based on a sample size of one, it’s a good time for engineering leaders/managers to ride the EM/IC pendulum back to IC work, with a leadership twist.
I’ve been calling this “engineering leadership, the good parts”. More of the activities that produce software, for people, amongst teams, less of the activities that allow software teams to exist within larger organizations and business hierarchies. Pairing those skills with teams of people and coding agent collaborators is pretty potent these days.
Pro-tip: if you’re an IC who is really enjoying this agent stuff, you could be a future engineering leader!
Processes should serve outcomes, not the other way ‘round
In moments where process overwhelms a team’s ability to get stuff done, I’ve been fond of saying we’re not here to:
- Push Trello cards around.
- Guess if a coding task is more like a small t-shirt or a large burrito.
- Arrange our git commits in just the right order.
- Write long-lived documentation.
I’d suggest that, instead, we’re here to ship code.
Now that writing code isn’t the tricky part, I’m more convinced than ever we are both not here to operate a process and that activities like these are more important.
I never claimed my aphorisms were consistent or even logical!
Somehow, it was only within the last month that I stumbled upon a better saying. We’re not here to write code, operate processes, recite our statuses in meetings, etc.; we’re in the software development game to make outcomes. In particular, the outcomes you might expect of a software-technology company, if you’ll pardon some light hype-y jargon. Shipping code is a small part of that, but it’s in service of fixing problems, improving efficiency, solving new problems for customers, or putting an invention into the world.
I was going to include checklists in the list of things we’re not here to do. But, checklists are a pretty great way of thinking, and often lead to their intended outcomes. When they don’t lead to those outcomes, it’s typically easy to look at the items in the list and see why! “Oh, we skipped this safety check and things went sideways” or “we didn’t do the user research and, predictably, users weren’t sure what this feature is for.”
By contrast, documents, processes, and quality gates typically obscure your organization’s intended outcome. They’re too frequently a trade-off to prevent getting burnt in the same way as before. Which is probably why they correlate so frequently with failing to hit or losing track of the positive outcomes that matter.
“We’re here to learn” is a good proxy for “we’re here to generate outcomes”. If a checklist (or process or document, if you must) helps you learn more about customers/markets/your design/the world/etc. faster, it’s probably a good thing for you. If it prevents success and failure in equal probability density, it’s likely overhead.
I (was) back at Destiny 2, since they’ve fixed many of the daily gameplay loops and put Star Wars in there. (Not even the most bonkers statement of 2026, somehow.) The odd thing about Bungie nailing the landing of a ten-year video game saga is that years 11 and 12 leave me wondering if I now is the time to bow out, even if years 19 and 20 prove as solid as years 9 and 10.
I took up autocross over the summer, enjoyed the challenge and community therein. I am a pretty slow driver, but it’s the best way to enjoy a sports car I’ve yet found. There’s always a few seconds to find!
Since the season is over here in the cold and rainy northwest, Gran Turismo 7 is filling in. Again, I’m not the fastest, but the practice-like activity ain’t bad. Again, there’s always seconds to find. The “let’s do longer races” add-on released in November to Gran Turismo 7 is pretty good too. But, as of lately, I’m trying to do stuff other than video games, so the PlayStation stands idle.
Recently good shows: The Lowdown, Alien: Earth, Pluribus. Currently, re-watching Better Call Saul. I don’t really like the Chuck and Jimmy arc, but the Jimmy becomes Saul arc is one of my favorite out there.
Bobcat, a document editor prototype
Wherein I’ve been making my own little text editors. Sometimes, even cozy ones.
Joining a new crew amidst a sea change
Wherein types, agents, and quality-of-life matter a lot for software development these days.
Three great clarinet-adjacent sentences
I DID NOT KNOW what was going to come from Angela’s clarinet. No one could have imagined what was going to come from there. I expected something pathological, but I did not expect the depth, the violence, and the almost intolerable beauty of the disease.
– Kurt Vonnegut, Cat’s Cradle