Menu

Interdependence is My New Retirement Plan

Ok I love this story.

I’ve been reading a lot of Robin Wall Kimmerer lately. She tells a story in The Serviceberry that’s become a sort of guiding star for me, about the experience of a linguist who was studying a hunter-gatherer community in the Brazilian rainforest.

“He observes that a hunter had brought home a sizable kill, far too much to be eaten by his family. The researcher asked how he would store the excess. Smoking and drying technologies were well known; storing was possible. The hunter was puzzled by the question […]‘Store my meat? I store my meat in the belly of my brother,’ replied the hunter.”

And yes to this:

I’ve been thinking so much about what it would mean for me to “store my meat in the belly of my brother”—to give to my loved ones and communities and trust that my generosity will circle back to me when I need it. I know it’s how I want to live. It’s how I want us all to be able to live.

Interdependence is My New Retirement Plan

My AI Workflow for Understanding Any Codebase

Great tip!

Convert GitHub repos to markdown with repo2txt, drag into Google AI Studio, and ask questions. Gemini’s massive context window makes it amazing for code comprehension.

The rest of the article goes into Peter’s AI coding workflow. I’ve mostly been using ChatGPT o3 for spec creation, but this is another compelling alternative.

My AI Workflow for Understanding Any Codebase

Field Notes From Shipping Real Code With Claude

I know we’re drowning in vibe coding stuff right now, but this extensive post about shipping code with Claude is a fantastic resource. Great prompt rules and tips, and also solid advice for what the humans are for…

Your role as a senior engineer has fundamentally shifted. You’re no longer just writing code—you’re curating knowledge, setting boundaries, and teaching both humans and AI systems how to work effectively.

Lean management and continuous delivery practices help improve software delivery performance, which in turn improves organizational performance—and this includes how you manage AI collaboration.

Field Notes From Shipping Real Code With Claude

How to provide feedback on documents.

This is great advice on providing feedback on docs. This especially resonated:

Before starting, remember that the goal of providing feedback on a document is to help the author. Optimizing for anything else, even if it’s a worthy cause, discourages authors from sharing their future writing. If you prioritize something other than helping the author, you are discouraging them from sharing future work.

How to provide feedback on documents.

In Praise of “Normal” Engineers

I love this take on the “10x engineer” phenomenon. Ubuntu (the African concept, not the operating system…) strikes again. “I am because you are.”

Individual engineers don’t own software; engineering teams own software. It doesn’t matter how fast an individual engineer can write software. What matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.

In Praise of “Normal” Engineers

Platform reality

Robin Sloan discusses Substack, and platforms in general, in another excellent post:

Expect enclosure; expect a few big winners; expect advertising, with all the attention-hacking that will demand. Expect, also, that writers will con­tinue to mold their work to fit Sub­stack’s par­tic­ular ecology, rather than “merely” use the tools to pursue their inde­pen­dent visions and ambitions. We learned this about plat­forms a long time ago.

Platform reality

Product Management: The Good, the Hard, and How to Know If It's Right for You

An engineer recently sent me some questions about the Product Management role. I took a long time to respond because I saw it as a great opportunity to reflect on the role and what it means to me. I decided to share my answers below, in case it’s useful for anyone else!

What did you like the most about your job as a PM? (I say past tense because Director can be different)

The joy of shipping, and shepherding products and features from ideas all the way through execution and user feedback and continuous iteration.

To me, the PM role is a people job. How do we get people to work together to do amazing work? How do we get the best ideas out, how do we make them real? How do we build things that people genuinely enjoy using, and don’t mind paying for? How can we understand how our products make people feel, and how can we make that better?

If you’re able to get into a product loop that does that over and over, it’s the best job in the world. You get to understand complex user, business, and technical needs, make sense of it all, and support a team of people to get useful products into the world. And then you get to talk to the people who use those products about how to make them even better.

Daniel Pink says we are all motivated by 3 things: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). At the best of times, I can’t think of another job that combines those 3 things as thoroughly as Product Management does.

What is the one aspect of the role that makes you from time to time (but consistently) say “I don’t think I want to do this any longer”? Or “I need a break from this”?

When we get caught up in the human tendency to forget about what we’re trying to do (that purpose from the previous question), and focus on our own needs instead. When I interact with teams and people who find their identity in their work to such an extent that it overshadows how cool it is that we get to do this stuff together. In short: when internal politics take over.

I don’t resent this tendency any more, to be honest. I used to, but not any more. This is normal human behavior—I am not immune to it, no one is. We want to feel heard, we want to feel useful, we want to be seen as competent and smart. But I now recognize very quickly when a discussion about a project or a product becomes about self-preservation vs. what is best for the team and the product and its users, and I am allergic to it. It makes everything more stressful. It requires having to “read between the lines” every minute of the day. It slows everything down. It makes everyone grumpy and wary of each other. It is poison to healthy teams and products, and it affects me deeply (too much).

I deal with it by losing myself in side projects, and spending deliberate time with the work people who don’t succumb to that behavior.

How do you advise me if I were considering either an EM or PM role to decide on which is more suitable to try out first?

I think the best starting point is to reflect on where you naturally find energy, especially when things get hard. Do you find satisfaction in crafting elegant systems and seeing the architecture click into place? Or do you come alive when you hear someone articulate a pain point and you can immediately imagine a better experience? Do you find yourself trying to optimize team throughput and code quality, or do you have an interest in clarifying ambiguity, getting people to work together happily and effectively, and shaping decisions through influence rather than control?

PMs and EMs both lead, but in different ways. Engineering Managers lead through technical insight, mentorship, and a responsibility for the velocity, health, and growth of the team. Their scope is often constrained by the product strategy/roadmap and what’s possible technically, and their main outcome is helping the team build the right thing in the right way.

Product Managers lead through context, clarity, and storytelling. They untangle complex ambiguity, and they create clarity when everyone sees the world differently (which happens on every project…). Their main outcomes are making sense out of too many chaotic inputs, aligning everyone on the problem to be solved (and how to solve it), and keeping the team connected to each other and customers.

Career advice in 2025

If you’re currently in the job market I highly recommend this post by Will Larson:

If you pull all those things together, you’re essentially in a market where profit and pace are fixed, and you have to figure out how you personally want to optimize between people, prestige and learning. Whereas a few years ago, I think these variables were much more decoupled, that is not what I hear from folks today, even if their jobs were quite cozy a few years ago.

It’s a sobering—and imo necessary—read, even for folks who are not currently look for a new job.

Garbage

This is a lovely post by Craig Mod about the Japanese approach to garbage, and what that means for other things in our lives…

This obsession with the immediate “unburdening” of a thing you created is common in non-Japanese contexts, but I posit: The Japanese way is the correct way. Be an adult. Own your garbage. […]

Personally, I don’t love carrying my garbage around with me, but I recognize that it wouldn’t exist without my intervention. Nobody ran up and asked me to hold an empty cup. I thoughtlessly bought something. Thoughtlessly consumed it, and now I have to hold onto the detritus for a little while? Great. It’s easy. Easy to embrace that modicum of responsibility for your own waste. This is my protest song, the world’s lamest: I will attend to my garbage without complaint.

Huh? The valuable role of interjections

I love this deep-dive on the little interjections we use in everyday speech. One example:

Other interjections serve as what some linguists call ‘continuers,’ such as ‘mm-hmm’—signals from the listener that they’re paying attention and the speaker should keep going. The form of the word is well suited to its function: Because ‘mm-hmm’ is made with a closed mouth, it’s clear that the signaler does not intend to speak.