Another season, another newsletter compilation in your inbox. Thanks for hanging around!

Herein, on futures. Imagining them and making them. Spending tokens, using tools to do so. Keeping our eyes on the outcomes and ends, rather than losing ourselves in the means.

Generations, clarinets, stars

I think about the generational differences in the world’s legibility vs. predictability. Personal and collective agency, the pace of change, stability. The world my parents grew up in is almost foreign to us now, and what my generation will leave their children, even more so.

There are days I wish my generation wasn’t foisting ever-changing button locations and corner radii on my parents, and hadn’t wrought algorithmic culture on the following generations. But, I try not to judge predecessor and successor generations too much. We’re all out here reacting to the hand we were dealt and trying to make something that seemed better, at the time.

On the other hand, you can get out there and write/summon the future you want. I find reading or writing, with vigor and at length, about what’s wrong in the world pretty draining. Even if it’s great writing! Better to call your shot than skate to the puck, per se.

If the world is just miserable, it’s helpful (and hopefully) to recall the things that generate wonder and joy in the world, as it is. Like three great clarinet-adjacent sentences or the futility of arguing with stars.

Good to the last token

I haven’t changed my mind about the future of typing. I still think, for example, that knowing how to record and execute macros in emacs, vim, or any other editor is a losing game now. But, I have changed my mind in how we message it.

I don’t think browbeating is how either side crosses the bridge. The folks lamenting their enthusiasm for code are going to have to meet somewhere in the middle with the folks who are excited about forgetting the correct order of xUnit assertions (expected, actual), symlinks (source, destination), or how to calmly rebase a git branch (unpossible).

Here’s a suggestion: we can all feel a little unnerved by the idea that if coding agents are replacing our text editors, we’re now paying code to code by the token. 😬

Even more so, I think that the value of humans in the loop is exercising taste, holding high standards, thinking holistically about the system and product, using intuition when making trade-offs, and identifying the trouble and opportunities in our software projects. In other words, if you like the idea of engineering leadership, the good parts, now is a pretty dang great time.

I turned all those free tokens that the model labs were offering over the holiday break into a document editor prototype. I highly recommend thinking about how to realize ideas, via coding agents, you’ve wanted to tinker with but never got around to. It turns out, you can just build/research/do things. It’s a lot of fun!

What (still) matters in software development

“We’re not here to push Trello cards around” is one of the sharper things I ever did say. It’s a snappy quote, plus it’s wrong and right. Many teams live and die by pushing cards around. On the other hand, focusing on the cards is losing the forest for the trees.

Luckily, I haven’t been asked to “guess if a coding task is more like a small t-shirt or a large burrito” in a couple of years. Even though that’s a dinger of a saying, I think coding agents have largely obviated a lot of tedious, risky, and day-to-day estimation. If a task is worth doing, build it out and see how it goes. If it happens the code or feature needs replacing later, you throw that at the coding agent too.

People are still worrying about the quality implications of coding agents. I’m starting to think it’s all dancing around an even trickier question: why did we allow humans to produce questionable code, or induce tech debt, or compromise on quality back then? Maybe the standards were low in us the whole time?

Optimistically: now that code is far easier to produce and iterate upon, perhaps we can hold ourselves to the standards we wanted to all along.

That’s a long-winded way of saying: I think the following piece has enough dingers in it that I’m going to re-post it verbatim:

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.

Onward, to the future!

Matt Webb, Austin Kleon, and NetNewsWire are Blogging (Classic).

If what I’ve (attempted to) put in words resonated, but you don’t know where to start or what future to make, start with blogs. Read your favorite people, gather the links and ideas that are most exciting or intriguing. Try to connect the dots, collect good ideas, or put into words what you’re excited about. Publish those words or make something like those words.

Now you’re building a future to call your own!