The reason I'm picky - and getting pickier - each year about what I read is that what I read is what's available to think.

I walk a fair amount: 10,000+ steps a day. If your goal is having more time to think, I recommend a 20-30 minute walk each day. And then there's the question of what to think about. For me, I either give my mind something to think about, or it picks something out of the Worry Stack. Iterating your Worry Stack regularly is important when done intentionally, but do it consistently and/or continuously and/or mindlessly, and you'll burn out on whatever's causing the worries. If you've got a job as a software engineering leader, that'll probably be the source of many of the worries on the stack, and a thing to guard against is hating/resenting "the job" through lack of discipline to control our thoughts.

So an antidote is to choose. Reading provides my conscious mind choices, and the subconscious better paths to influence the choice.

Attention, awareness of agency and the mechanics of the mind were primary themes again this year, as you'll see. Here are the best things I read in 2025:

Rao Reading Algorithm by Arun Rao

I've been thinking a lot about how the machinery of my systems & regular activities works, and also how complacency hinders it, and then finally what effortful outcomes look like. This might be it for reading: "...reading is practice directing attention, causing your awareness to curate what comes into that awareness, for a purpose... I’ve rewired my brain so reading to learn is highly pleasurable"

The essay also offers an answer to Why Read The Classics, via Jacques Barzun who lived to 104 and, if you follow just that Wikipedia link and the author's advice to build out your semantic tree of knowledge, offers at least an afternoon's worth of new nodes, "in order to live in a wider world".

The AI Reflex by Blake Graham

Another post about technique and foundational machinery. This time it's the toolset used while working. Work as in coding and writing.

Speaking of writing: One thing I realized this year is how many of us work as professional writers, or at least the core output at work is writing to persuade. Whether it's short form on Slack/Discord, responding to a customer email, or a longform doc describing a problem and remediation plan, or a well crafted series of prompts that causes code to be written or reviewed, writing well is the primary method we use to affect change and ultimately deliver value.

The author on why his git commit graph has trended up by an order of magnitude: "Yes, the models improved, but that is not why my commit graph changed. I built a reflex. I stopped deciding whether to use AI and started reaching for it the way I reach for a light switch. The better models enabled the transformation. The reflex made it automatic."

Cognitive load is what matters by Artem Zakirullin

A deep dive into developing architecture and writing code that's optimized for reasoning and comprehensibility.

One of the odd things about making software is how averse we are to admit when the software is getting too complex, because of what it implies: that you are struggling, that you can't handle the load, maybe not smart enough.

In most shops, the people who get things done couple raw horsepower with time in seat and good long term storage. I was blessed with really good recall . Especially when I try. So I can remember how the thing works, either because I wrote it myself or I spent an afternoon tracing through a callstack and developing a dependency hierarchy in my head.

But long term storage is not working memory. Even amongst those who can get in there and work the lines as they say in chess, there is a reluctance to do so unless/until absolutely needed. A piece that just missed this list is actually a comment on Reddit, and this quote: "Chess is a constant struggle between my desire not to lose and my desire not to think."

"Good engineering management" is a fad by Will Larson

Software engineering management is weird. By engineering management I - and I think most authors - mean any role, regardless of title (Director, etc) where you (a) have people who report to you (b) are not in the leadership room with the CEO (aka you're not an executive).

I've been focused on these roles for the last seven years of my career now, after a decade or so of working as an IC, an executive and a founder. Mid-level management roles are exciting, and also weird in a specific way: They're all similar, but also they're all different, and nobody tells you that, nor does anyone typically tell you exactly what's expected of you until it's too late.

When a peer or friend or mentee asks a question about performance reviews etc, I usually answer this: Engineering Leaders deliver the product roadmap (aka their squads/teams ship projects on time), maintain their systems (aka minimize bugs and user frustrations and don't get hacked) and develop their people (aka hire, fire and promote people). Very few do all three well. If you are doing all three well, you're probably getting at least a decent perf review.

During ZIRP, you could get away with doing two or even one of these well; while my favorite leaders to report to are good at all three, I've had quite a few peers who fit what the author calls "orchestrators". As he points out, the specific post-ZIRP expectations are different. And they always will be, as tides turn and conditions change and expectations for a startup shift.

As an industry, venture funded SaaS has just been through one of the most severe shifts I've ever seen in my career: From prioritizing topline growth at nearly all costs to prioritizing profitability at the expense of nearly all growth.

This is easily the most immediately useful piece on this list: a steal & adapt framework for guiding your own focus and skillbuilding.

a simple mechanistic theory of jhanas by Bayes

Most of these pieces are pure pleasure to reread and re-parse. I realized this year that I don't even know what the best things I read are until I reread them and process them in close contact with each other. So a primary reason I write and post the best things I read each year? It's to know what the best things I read are. See also this and also this for more on that topic.

Rereading this piece bummed me out at first, and it's because another year has gone by that I haven't progressed into the jhanas. I still can only do the first one, and even that only sometimes. I still think this is a fantastic guide to getting into the jhanas, and it's totally on me for not making the time to practice.

So why is this piece on here? Because it unlocked for me two things. One, a way of diagnosing negative feedback loops as they're beginning in my mind. And two, a mechanistic way of hacking my own pleasure system. That's all: just a simple mental model that the author presents that led to two big insights. The second of which was key to me for enabling action related to the next item on the list...

Viscerality by Simon Sarris and How to like everything more by Sasha Chapin and The Consolation Of Apricots by Diane Ackerman

A trio on cultivating pleasure.

Of all the things we learn from our parents and school in the primordial brain soup called "growing up", there's one that I think would have the maximum impact to humanity if introduced broardly: Liking things is a skill that can be built, emotionally reacting to art, circumstance and deliciousness can be cultivated and programmed, and you can "develop a crush on the creator".

Focusing attention and awareness on pleasure can also be a way to keep the Worry Stack at bay.

What To Do by Paul Graham

My eldest niece turned 21 this year, and is graduating college next year. Class of 26. Over Christmas I tried my best not to give unsolicited advice or ask too many questions like so what are you going to do next. Maybe the most curious reaction though is thinking about the world through a young person's eyes has inspired me to think about what my long trajectory looks like. This is a foolish statement, but here goes: Deep into my 40s, I feel youthful, and as though life will take many new interesting turns and possibilities.

One thing I've never been good at: Asking for advice. I feel as though I'm burdening the recipient with my own failure to comprehend. "Feel" is the right word there - my belly aches and I have a tinge of vertigo just sitting here thinking of asking someone for advice. But people really like being asked for advice! It's not a burden for them at all. Especially if they're given a moment to think. Being asked for advice gives the recipient free range to talk about themselves and share stories.

Anyway, when I'm lucky enough to be asked for advice by a young person, my go to is to ask "Have you read Paul Graham's essays yet?"

Dandelion Wine by Ray Bradbury

The story of a summer 100 years ago. Though I read several novels this year, this is the one that really moved and stuck with me. Fascinating as a comparison with today, a reminder of things that have changed and things that haven't. Beautiful for its deep sadness amid an underlying optimism. A reviewer on Good Reads has already said exactly what I want to say concisely: "I've never thought so much about my own mortality without running away from the subject in fear and forced-naivete. I've never felt more fulfilled by a reading experience on both an intellectual and spiritual level as I was with Dandelion Wine."

How The System Works by Charles C. Mann

The intro essay We Live Like Royalty and Don’t Know It offers a free preview to the one and only paywalled piece on my list. I fit squarely into the author's Most People These Days, as I understand only superficially what it takes to create civilization from scratch. One of the things I continuously wonder about - even working as I do so closely to real estate lending - is why real estate has become so expensive.

A lot of this I feel is my own ignorance: I failed at a goal. In 2009 when I moved to the Pacific Northwest, one of my intentions was to buy some land and build a cabin. One reason for doing that is the satisfaction of doing a thing like that. But the biggest aspect for me is that I primarily learn by doing. And by building a cabin from scratch, I supposed I would learn how all the things like power and water and sewage work, at least at the scale of one. 

Moving from purely building with bits into being able to reason about building with atoms too was a theme of 2025 for me, and while I'd like to explore 3D printing, I'm increasingly becoming interesting in ways that mechanical control flow and system orchestration can be handled with code.

Cities are routers in network society by Gordon Brander

A piece of writing usually makes my end of year list primarily because it either catalyzed a new way of looking at something, or because it provided a launching point for an order of magnitude or more of exploration.

This piece is very much in the latter camp. To start, any story whose timeline traces back to Westphalia has my attention. That's a tree I've been building for a while: Western Civ II, the last 500 years. And then references Stewart Brand and Marshall McLuhan. If you've never explored Brand or the Whole Earth Catalog, there's an afternoon of branch-building for you - one that'll probably include Amazoning a book that just missed this list, What The Dormouse Said by John Markoff.

Most of all, I've always loved cities. I live in a West Coast city at a time when a lot of my friends and family, having long abandoned city life for the peace of the suburbs, wonder what's wrong with me. They appreciate aspects of cities - especially the job opportunities - but they like to keep the mess at arms length. A lot of that has been by design, sadly.

Long explorations of interesting subjects is another way of avoiding spending time on the Worry Stack. I'll close with a partial list of a few branches from this piece that turned into hours of exploration:

• Dark Factories
• The intersection of bits (which I've spent my career manipulating) and atoms (kind of like the dark side of the moon to me, a fascination)
• Jugaad and really this whole paragraph: "AI and automation increasingly absorb the scalable aspects of production. That leaves us to putty over the cracks. “Work” takes on a DIY/jugaad quality, focused on creatively hacking together powerful resources to solve contextual problems." - which actually describes what I'm really good at really well.
• “The line is blurring between remote workers and tourists,” - I was doing this in 2004. I had a laptop and I would fly to San Francisco on a Thursday night, by myself, and instead of taking time off I would work from coffee shops. People thought I was crazy.
• https://ephemerisle.org/index.php/Ephemerisle & https://www.mars.college/

That's it, the best things I read in 2025. Tempting to include a list of pieces that just missed the list, but I'm going to resist that. Besides, your LLM of choice can probably generate a great related list if you liked any of these. Find previous years here. Happy 2026!

Whatever problem has you frustrated today, it's almost certainly worth a few moments to consider "what would need to be true for us to not have this problem at all?".

Generally speaking, the way to not have a problem is to look upstream, and see what conditions lead to you having the problem in the first place.

Running out of gas is a real world example of a problem best solved by not having the problem at all. Upstream of running out of gas is habitually stopping to get gas when the tank is below half.

That example calls out something else: There's problems, and there's problem patterns. Looking upstream doesn't solve the acute problem of being out of gas right now. Too late for that, now the problem must be solved with a call to AAA or a walk to a gas station or a helpful Samaritan in a pickup. But the pattern can be curtailed: always getting gas when the tank is below half will make it so you never have to solve this "I'm out of gas" problem ever again.

Heading upstream is also good at preventing related problems you don't have. I think of this as preventing families of problems. Lets say a natural disaster hits your community. Hurricane, fire, flood, take your pick. Authorities issue "GO NOW". If you habitually fill the gas tank when it dips below half, you're good. If you don't, you might now be running out of gas somewhere AAA isn't going to help you, and now you have a Life In Danger problem on your hands.

ChatGPT, Claude and Gemini are all really good at helping us brainstorm ideas. What would need to be true for this to not be a problem in the first place is a great prompt to wrap up a thread with an LLM on how to solve a problem.

Part of that is being willing to timebox outlandish-sounding ideas and earnestly consider them before (usually) discarding them. Twenty minutes is often enough. If you do that five times a month, you'll have spent a little over an hour and a half. If you think you're good at generating ideas now, it's a good test. Ninety minutes is less than 1% of a standard work month.

You can be a great problem solver, and great problem solvers are almost always rewarded in software development. But much more valuable is the one who prevents problems or whole families of problems from needing solving at all. if you're interested in your job being AI-proof as an engineering leader - and I don't know if we should or shouldn't be worried about that, but plenty of people seem to be - I can't think of an easier way. 

TLDR: 2023 Oregon Pinot to me will be remembered for wines that are open and beautiful at release. An echo of 2012, 2014, 2015.

Not a lot of things in wine get me as excited as the variability between Oregon pinot noir vintages. Living here for 16 years now means each one conjures memories of that year.

The movements between vintages can be as elegant and surprising as the movement on the palate in the wines themselves. 2021s with their massive (for Oregon) structures, the smaller 2022s when so many lead with their earth or savory notes, and now 2023.

I've heard some pooh-pohing of the 2023s - they're all the same! said to me by more than one winemaker or distributor - but I'm always aware that even in my own mind there's a bit of a contrarian tendency to claim love for the unloved and to snub the easily loved. 2007, 2011, 2019, those were hard vintages to love at release. Now they're favorites for many of us.

How I'm approaching 2023 so far is contextual to what I've done with the previous two vintages:

2021s: I bought good quantities of my favorite single-vineyard wines to hold.

2022s: I mostly avoided this year, which I acknowledge that I may regret if they evolve like 2007s, 2011s and 2019s.

I really enjoy 2023, and have been buying them in reasonable quantities, quite a bit more than 2022. I'm especially excited about the entry level wines - ~$25 and sometimes blessedly still below that - and have bought a reasonable quantity to PnP over the next 2-3 years.

A few specific standouts:

• Evesham's 2023 WV. Ridiculously multi-dimensional for this price: prettiness, ruggedness, brightness, balance, length. This is one you can (or could) get outside the region at Whole Foods around $25.
• Cameron's 2023 Clos Electrique is more open at this point than any vintage I remember. Maybe 2015. Their WV and Dundee Hills are both ready to rock as well.
• Walter Scott's 2023 La Combe Verte. Such bright red fruit, herbal, wide open.

Some winemakers' notes on 2023

• Willamette Valley Wineries Association
• Goodfellow
• Kelley Fox

A coworker shared this video called 12-Factor Agents: Patterns of reliable LLM applications which for me was a total "ah ha!" moment. Not so much as any of it was new, but a concise synthesis of lots of loose thoughts I've been having while designing and building AI systems over the last few years, which to me is even more exciting. If you're building or thinking of building an AI system, I highly recommend watching it. It's 17 minutes well spent.

Here are the three most important ideas / principles that I wish I'd known before I started designing and developing agentic systems:

Key idea: Effective AI systems are built using a series of agents - distinct prompts and models - with each agent given specific context - broad or deep but rarely both - and the system composed of multiple in both dimensions. The "monoprompt" approach is very rarely going to work well.

For a simple example: In a bot designed to discuss the pros and cons of various retirement planning strategies, one agent might summarize a user query broadly, while another dives deeply into financial datasets relevant to the asset classes being discussed, and a third would dive deep into the user's own specific profile and goals. Only the first agent would be given broad user and multi-domain context in its prompt. The other two would be isolated to context that supports depth in their focus areas.

Key idea: AI product development skateboard-level prototyping is really easy, almost too easy. It's really simple to get the first 80% going and assume that the next 20% will be just as easy as the first 80%. In a way it follows most software development in that most competent web developers could build 80% of Facebook in a couple weeks - CRUD with persistence on a handful of entities being a very solved problem - but getting the full next 20% - an app that scales to billions of users - takes thousands of engineers upwards of a decade.

Again, be wary of the monoprompt. It's really easy to get 80% of the way there with one and assume the other 20% is simply edge case handling.

Key idea: Not every problem is a good problem for an agent-driven system. In the video the presenter frames it as "realize this isn't a good problem for agents". My experience is that there's more nuance, and that it's actually more of a distinction between building an AI-driven system with a human-in-the-loop, or a human-driven system with AI-in-the-loop. I've touched on this before, but I'll write an updated post soon. 

Someone's trying to chop down a tree in their yard. You're out on a walk, and feeling neighborly, so you stop to watch, and you notice something: their axe is barely making a dent, and they're making little to no progress on getting through a thick trunk.

"Mornin' neighbor," you pipe up pluckily, "I was watching you, and, I couldn't help noticing, you got a really dull axe there. If you stop and sharpen it, you'll be having a much better time. Get that tree chopped down in no time."

Your neighbor looks at you with a mix of surprise, anguish and anger. "I need to get this tree chopped down, right away! I don't have time to stop and work on my axe."

Oh.

I imagine President Lincoln having a similar experience, and using it as the catalyst for his quote (as commonly attributed to him) "Give me six hours to chop down a tree and I will spend the first four sharpening the axe."

This all seems relevant today, in the middle of 2025, with software development tools having achieved what feels to me like a step change at least equivalent to IDEs or Stack. Yet when I talk to web software engineers and other people who do software development for a living, they often tell me they're too busy doing their work to learn about them...

An experiment: Could OpenAI's o1 model recreate the 80s Nintendo classic Duck Hunt using JavaScript, CSS and an HTML canvas element, my prompts, and no other help from me (I'm not allowed to edit the code).

As you can see above, while missing quite a few features and animations, o1 and I were able to get to working code that runs the core of the game in about 30 minutes of wall time, not including the additional 30 minutes I used to capture the deltas as git commits and make notes.

Not bad for an hour's work. I estimate it would have taken me 4 hours working without o1, with most of that time being spent understanding the canvas api which is not an area of experience for me.

What you see above represents five prompts, with a correction made after the last prompts. You can see the code that o1 produced along with my prompts here.

When I tried to give it a sixth prompt, o1 started making a series of mistakes that I can only attribute to reaching its limit of the complexity it can juggle.

The mistakes started innocently enough: ~200 lines of code hand waved away with a comment "the rest of the code omitted for brevity".

From that point on, however, I wasn't able to get o1 to reconcile its mistakes and get the game back to where it was. Trying to add another feature, starting with introducing a reloading sequence, broke several other features.

Rather than take over on the coding, I let it stand: forever in o1's version of Duck Hunt, you will be able to machine gun ducks into submission.

Other thoughts:

o1 is likely currently better suited to writing classes or functions with defined inputs and outputs than the entire program. This is how I use Cursor these days, coding specs and letting it fill in an initial implementation.

One obvious exception to that is APIs you don't know. Here it might be best, if like me you learn best through experimenting with a real world example, to let a model write a program that fully exercises the API, providing you with a working example that you can tinker with.

While the game works, several of the architectural decisions make me question extensibility and maintainability. Specifically, placing the checkCollisions() function and all its logic in the Game class seems likely to cause Game to fall into the God Class anti-pattern https://en.wikipedia.org/wiki/God_object as more and more physical interactions are added to the system.

I fired up Cursor after the session and asked Claude Sonnet 3.5 to criticize the code with regard to maintainability and extensibility. Here are the highlights:

Class Dependencies

• Tight coupling between classes

Collision Detection

• Collision logic is tightly coupled with game logic
• No separate physics system
• Hard to extend for different types of collisions

Code Organization

• Mixed concerns (game logic, rendering, input handling)

There were other critiques but most of them were either things I didn't ask o1 to consider, like error handling, or relatively easy things to fix later like magic numbers & string constants.

Even with AI doing all the coding, it's still a tool that will likely increase the surface area an individual engineer can work on without eliminating the need for software engineering.

My contrarian guess is that AI coding tools will make more work for software engineers; In an instantiation of Jevons paradox, more low quality code will be written because AI tools lower the barrier to entry for a lot of code to be created by people who don't know how to recognize high quality code.

It seems possible that with enough competent models, day to day software engineering looks like defining an interface and requirements, then asking 3-10 different models for their implementations that you look over, weigh against each other, and choose the best. Because a lazy developer is a good developer, most will opt to be on the low end of that range, and a way of standing out from your peers will be rigorously testing using more models.

Last thought: That was fun, can't wait to try the same thing using o3.

If 2021 was the year of the late June Heat Dome, 2022 stands out for a mid-April cold snap that hit vines right at or immediately after bud break. Just like 2021, one of the most interesting questions has been what effects this outlier event would have on the wines.

My impression so far is that the elements that made up 2022 - whatever percentage of it was that cold snap - have created an uneven and bifurcated vintage that reminds me of 2013, where there's a set of wines that seem "normal" and unaffected, and a set of wines that just seem less than they should be, and it's hard to predict which camp a wine will be in until you spend time with it

Because of this, as much as it pains me as a fan of the home team, and as much as it hurts to say this on the back of the disastrous 2020 vintage, I'm passing on most 2022 offers and planning to buy the least of any vintage since 2013.

A lot of people might disagree. I just find the wines too uneven, a bit meh, or both.

I'll get a good laugh if I'm proven wrong on this, by the way. 2011 really caught me out and I ended up scrambling to buy back vintages because I didn't understand what cold vintage wines were like on release. Maybe this will be a repeat. That would delight me. After all, we primarily learn from being wrong.

For now though - and maybe this is a guy with an overloaded cellar talking - I'm saving my money and the cellar space to overweight on 2023 which, based on a few Willamette Valley bottlings I've tasted so far, I have a feeling is going to be killer.