For more than 15 years I thought that I loved writing code, that I loved typing out code by hand, that I loved the “cadence of typing”, as Gary Bernhardt once called it, when sitting in front of my editor and my fingers click-clacking on my keyboard.
Now, I’m not so sure anymore.
2025 was the year in which I deeply reconsidered my relationship to programming. In previous years I had the occasional “should I become a Lisp guy?”, sure, but not the “do I even like typing out code?” from last year.
What I learned over the course of the year is that typing out code by hand now frustrates me. It frustrates me in the same way that filling out a printed form by hand frustrates me. Writing my name and middle name and last name and my street address and my zip code in capital letters with this stupid pencil when all of this could’ve been done by a computer, god, why do I have to do this, why do you punish me? This is so stupid, so laborious, this shouldn’t exist. I once considered not taking the 50 Euros of reimbursement that Deutsche Bahn offered after a train was delayed for two hours because I would have had to fill out a form by hand.
Amp is now faster and better at writing code than I am and whenever I do have to go in and type some code it feels like I’m pulling out the sewing needle after the sewing machine broke down, like hammering nails by hand after the nail gun’s battery died.
And yet it was fun! It was fun to write code by hand, for many, many years, and when it stopped being fun I was sad. Do I even love programming and building software if the actual writing of code is now a nuisance?
And the sadness went away when I found my answer to that question. Learning new things, making computers do things, making computers do things in new and fascinating and previously thought impossible ways, sharing what I built, sharing excitement, learning from others, understanding more of the world by putting something and myself out there and seeing how it resonates — that, I realized, is what actually makes me get up in the morning, not the typing, and all of that is still there.
One of the best things I’ve read in the past few weeks: Two Years After Cormac McCarthy’s Death, Rare Access to His Personal Library Reveals the Man Behind the Myth. I’ve only ever read Blood Meridian and All the Pretty Horses by McCarthy, but became fascinated by McCarthy, read his Wikipedia article many times and, wow, does this article deepen the fascination. I mean: “Trying to take it all in, I felt both fascinated and overwhelmed. It seemed almost inconceivable that an author who produced 12 novels, two plays and five screenplays had also found the time, energy and brainpower to master architecture, woodworking, stonemasonry and a wide range of intellectual disciplines. Some of his math books were nearly all equations.” And this part made me really happy: “When I asked Dennis about his brother’s reputation as a recluse, he said it was totally inaccurate. ‘He was very sociable and could get along with anybody. Well, almost anybody. He didn’t suffer fools gladly, or people who rushed up to him gushing about his books. But he had a lot of friends, and he loved dining and conversation, and five-hour lunches that sometimes turned into ten-hour lunches.’”
Kent Beck on the changing context around code reviews. I fully agree with him that the old process was already breaking: “The theory was synchronous-ish collaboration. The practice was PRs sitting for days while context decayed. Reviewers skimming because they had their own work to do. ‘LGTM’ culture—rubber stamping dressed up as process. […] The feedback loop got too slow to catch the things it was supposed to catch. By the time someone noticed a structural problem, three more features had been built on top of it. This isn’t a criticism of any particular team. It’s a recognition that the economics were already strained, the incentives skewed.” It took working at Zed for me and pairing instead of asynchronous code reviews to see it, though. And I very much agree with Beck on all the points he makes after that analysis. Things are changing and all the tooling around code reviews is built on the assumption that the code was written by a human, that it took a lot of time, that it took a lot of effort, that it would be painful to reorder the commits, that it would be demotivating having to redo the whole change, that the change is is very valuable. But what if it wasn’t? What if it wasn’t written by a human and what if it’s just one of, say, give proposed changes that all try to do the same thing, because you started five agents and raced them against each other? What if we don’t have to worry about how often someone or something would have to redo a contribution? What if we don’t have to worry about in which order they produced which lines and can change that? We’ve always treated auto-generated code different from typed-out code, is now the time to treat agent-generated PRs and commits different? What would tooling look like then?
Chris Loy on the rise of industrial software. The analysis is spot on: “Traditionally, software has been expensive to produce, with expense driven largely by the labour costs of a highly skilled and specialised workforce. This workforce has also constituted a bottleneck for the possible scale of production, making software a valuable commodity to produce effectively.” And now, with AI the “first order effect of this change is a disruption in the supply chain of high quality, working products. Labour is disintermediated, barriers to entry are lowered, competition rises, and rate of change accelerates. All of these effects are starting to be in evidence today, with the traditional software industry grappling with the ramifications.” I think this is happening, 100%, and I also think that most people who disagree are only thinking about the 1% of software, about the 1% of software engineers, but not about the industry, which has been held up $150/hour (“the labour costs of a highly skilled and specialised workforce”). What I don’t agree with is the negative view of industralisation. There’s too many mentions of “slop” and “cheap” in a negative sense. But industrialisation also gave us cheap calories, and fridges, and medicine, and transportation, and to address his point directly: I think paperbacks are great! I only bought paperbacks as a teenager because I couldn’t afford hard-cover books.
Aaron Levie on the same point: “Jevons paradox is coming to knowledge work. By making it far cheaper to take on any type of task that we can possibly imagine, we’re ultimately going to be doing far more. The vast majority of AI tokens in the future will be used on things we don't even do today as workers.”
Paul Dix, CTO of InfluxDB, on how 2026 will be a pivotal year for software engineering: “once coding speed jumps, everything around it becomes the constraint. Your throughput gets capped by whatever is slowest—clarifying requirements, reviewing changes, validating correctness and performance, getting to production safely, and operating what you shipped. In 2026, the great engineering divergence will be determined by who raises that ceiling end-to-end.” Highly recommend reading it. I agree with everything here.
I always enjoy reading Fogus’ end-of-year lists and this one, in particular, contained a lot of good stuff: The Best Things and Stuff of 2025. Quite a few of the things he’s linked to have made it into this list here, but there’s a lot more in the post. In fact, I saved the post for this issue even before I made it to the very smart, very true, very thought-provoking paragraph on LLMs at the end: “I’ve had zero success leveraging it in my work maintaining and evolving Clojure. For problem formation in the face of novelty, LLMs have been more frustrating than helpful and the little gains that I’ve found were in the very early phases of problem solving requiring a bare minimum of experimental code. […] In my work, the bottleneck is absolutely not the code.” I’m glad that he doesn’t fall into the trap that seemingly caught a lot of other programmers and declare that, well, I am a programmer and it can’t help me, so everybody else who is a programmer must also do the same things I do and LLMs can’t help them either. And the bit on LLMs failing as Socratic partners is spot-on.
And here’s Rich Hickey himself on AI: “When did we stop considering things failures that create more problems than they solve?” I’m not sure whether I agree with parts of it, but it also seems like Rich Hickey and I have very different views of the world and I’m glad I read this and I think you should too.
Solidly in the Curiosity column: I Was Kidnapped by Deutsche Bahn and All I Got Was 1.50 EUR. One hell of a ride. Read through the HackerNews comments too, there’s more anecdotes in there. I’ll save mine, I’m in too good of a mood today.
“Google hired Hans-J. Boehm, of the ‘Boehm garbage collector’ fame. They needed an elite coder to fix garbage collection and concurrent programming. He led the effort to define C++ shared variable semantics. But then they gave him an impossible task: write a calculator app.” This article made the rounds in February 2025 but I had never read it. Now I did and I’m very, very glad about that. Amazing.
This was the first Christmas Day I can remember on which we didn’t have any appointments or people to visit or places to be and so while the kids played with their presents, so I sat down, opened up this list, The Top Twenty-five New Yorker Stories of 2025, and read five or six of them.
This one, from the list, was great and finally made me understand the whole idea of “ultra-processed foods” (a term I’ve read and read about many, many times.)
Here’s another one from the same list that I loved: the New Yorker profile of Lorne Michaels. It has so much in it. Yes, it’s a profile, but, man, it does inspire thoughts about creativity, and comedy, and management, and working with other people, and working with other creative people on the same thing, and processes and decision making,… It’s just very good.
This one wasn’t on the list, it’s from 2014: Does It Help to Know History? I really don’t know why, but somehow knowing that it’s from 2014 made reading it even better. “But the best argument for reading history is not that it will show us the right thing to do in one case or the other, but rather that it will show us why even doing the right thing rarely works out. The advantage of having a historical sense is not that it will lead you to some quarry of instructions, the way that Superman can regularly return to the Fortress of Solitude to get instructions from his dad, but that it will teach you that no such crystal cave exists. What history generally ‘teaches’ is how hard it is for anyone to control it, including the people who think they’re making it.” (Anecdote: I wrote a tweet about this article in roughly 20 seconds and it ended up being three words and then, while I was sleeping, something happened and I woke up to the tweet having five thousand likes and then Grimes retweeted it and then I muted it and then the whole Internet left weird comments on it and now it has twelve thousands likes and one point two million views. What the fuck.)
This also wasn’t on the list, but hey, it has my vote to be: The Real Housewives of Moscow.
Mergiraf is a tool to help with merge conflicts, which is interesting, but, dude, man, click on that link and look at those comics. It’s so absurd — fantastic.
Great: Three ways to solve problems.
I Program on the Subway. As someone who essentially wrote two books while on the train, I enjoyed this a lot. Yes, even though I’d never even consider affixing keyboards to my pants.
I had a very good time reading this and pasting snippets into ChatGPT and asking it follow-up and side-questions: I’ve been writing ring buffers wrong all these years. (Then, the next day, in a restaurant, I played Hangman with my 8-year-old daughter and when it was my turn to guess, I thought, hey why not, and took a photo and asked ChatGPT, just to see whether it could find all the 5 missing letters. And you know what GPT-5.2 Thinking did? It proudly proclaimed that yes, it can solve this, because what we’re looking at — these letters and lines — is clearly a diagram showing a ring buffer! So much for ChatGPT’s memory system, eh?)
“In the four passages above, the first and fourth were mine; the second and third were A.I.-generated. Dana described an A.I.-produced line that seemed hokey to me as ‘especially your style.’ Another reader referred to an A.I.-generated quip as ‘your distinct style of wry humor.’ I also got plenty of insults about passages that were legitimately mine: ‘verbose and heavy on cliché,’ ‘weirdly elliptical,’ ‘sounds like a book report,’ ‘a lot of extra commas.’ Most hated the passage about writing for an audience; only one attributed it to me. Karan called it ‘some hive mind’s “idea” of literature.’ Surprisingly, I wasn’t hurt that my friends and fans couldn’t tell the difference. [...] Still, I couldn’t avoid the truth. Seven excellent readers had mistaken an A.I. model for me. Seven excellent readers had mistaken me for an A.I. model.” Even a year ago, I’d say, this was unimaginable for everyone except the strongest believers, wasn’t it? And now this is in The New Yorker. The whole thing is excellent and thought-provoking, especially because it’s much more unpredictable than you would assume.
A Call for New Aesthetics by Patrick Collison and Tyler Cowen.
Austin Henley on cancelling the deal he’s had with a publisher to write a book that’s “a collection of tutorials on building these projects, each self-contained and teach fundamental computing concepts along the way”, where “projects” means “classic programming projects that were relevant 30 years ago and will be just as fun 30 years from now”, like this list that Austin made and that I’ve referred to quite a few times. As someone who’s self-published and who has an allergic reaction to the idea of working with a traditional publisher: quite the interesting post. And as someone who’s thought about releasing a 10-year anniversary editions of his book this year, this paragraph resonates with something I’ve been thinking about: “There was also a daunting voice in the back of my head that LLMs have eliminated the need for books like this. Why buy this book when ChatGPT can generate the same style of tutorial for ANY project that is customized to you?”
Samuel Albanie’s Reflections on 2025. He’s the Evals Lead for Gemini at DeepMind and, apparently, a very entertaining writer. This was great. For example, this sentence about the bitter lesson, after his explanation of the bitter lesson and how it relates to his work and how it made a lot of the things he previously did invalid, is fantastic and cherry-on-top-y: “The lesson is bitter because it means our most sophisticated ideas often fail to compound.” And then there’s this bit, where he compares his experience of being an assistant professor and grading papers to now doing evals: “The job is effectively the same, except the student has read the entire internet, hallucinates with the confidence of a mid-tier management consultant, and I cannot deduct marks for illegible handwriting. The comfort of my simple handwritten rubrics is behind me. Instead, I find myself staring at a proposed refactor of a distributed training loop, trying to calibrate my skepticism. Is this a brilliant optimization, or a subtle race condition that would only manifest seventy-two hours after deployment, likely on a Sunday evening?” Good writing. Very good.
“every year i make new years resolutions, the generic fitness, discipline, reading, etc. but really, i can and will trade all of those to be truly, completely, absolutely creatively consumed by something. there is nothing better”
In case your New Year’s resolutions include checking out Jujutsu and being consumed by it, this series by Andre Arko is a good, short intro: part 1, part 2, part 3, part 4. And then here are “stupid jj tricks” and here’s a very sophisticated jj prompt for the shell that I’m likely going to steal by pointing Amp at the post and my zshrc. After reading through these posts, I also ended up re-reading this official primer on working with jj and GitHub, which I find very good, and I also ended up reading through this jj configuration, which contains some very interesting bits.
Ian’s Shoelace Site made the rounds again and let me tell you something: if you haven’t, click through it! You must! This is the Internet at its best. This will make you smile, I promise.
what-dan-read.com — Impressive.
I managed to catch up at least a little bit with Dan Hollick’s Making Software book and read the chapter on shaders. Fantastic stuff. The illustrations, the design, the sound effects — go look at it and you’ll end up reading. And while I did that, I kept thinking that it would be nice to play around with some shaders. So I asked Amp to create a shader playground with WebGPU for me and it did and it took 2min and then I had another browser tab open and played around with the concepts explained in the chapter. Wild times. Here’s the playground in case you too want to click around.
Will Larson on “Code-driven vs LLM-driven workflows”. Rule of thumb, I’d say: you want your control flow to be deterministic and you want the fuzzy parts to be fuzzy. Don’t make the control flow fuzzy.
I personally found this post by Ivan Zhao, CEO of Notion, very, very interesting. Yes, long-form Twitter posts have a certain patina to them that’s hard to overcome, especially when paired with prediciations of the future, but it does reveal something about Notion’s strategy, does it not? It reads to me like they (or Zhao, at least) see themselves as the tool for knowledge workers in a future in which AI glues everything together. I wonder what Anthropic would say to that. The other interesting perspective is his view on how AI will change business. There’s been many voices saying that the future belongs to the 1-person startup, which is now feasible thanks to AI, but here’s Zhao saying that, nuh-uh, actually, we can now build even larger corporations.
Peter Steinberger’s Shipping at Inference-Speed is a great snapshot of what one could do with agents at the end of 2025. And it’s still funny to me that the oracle as a name and idea was adopted by him.
Dan Wang’s 2025 letter. It’s very long and I’ve never read one of his annual letters before so I didn’t know what to expect, but it pulled me right in by asking: “Which of the tech titans are funny?” But the letter is, of course, about a lot more: China, US, China vs. US, Silicon Valley, manufacturing, AI, Europe and its future or non-future, books. I read the whole thing yesterday evening and it’s great, yes, but the analysis of Europe’s state (which I can’t disagree with) is depressing. One for the Curiosity, not the Joy column. This section here, though, I’ll hopefully always remember fondly, I love that picture: “Alexander Grothendieck used an analogy of a walnut to describe different approaches to mathematics, which might also apply to technology development. Some mathematicians crack their problems by finding the right spot to insert a chisel before making a clean strike. Grothendieck described his own approach as coming up with general solutions, as if he were immersing the walnut in a bath for such a long time that mere hand pressure would be enough to open it.” Reminds me of Kent Beck’s “make the change easy, then make the change”, reminds me of some of the best engineer’s I worked with who did so many small, easy-looking things in preparation for the big thing that once they were ready to tackle it, the big thing no longer looked big, but just as small as all the other things they did before. Reminds me of…
… Aaron Patterson wrote down his answer to: Can Bundler Be as Fast as uv? The whole post is great. This is, I’d say, thoughtful engineering. The fake Gemserver he built to test the hypothesis for parallel downloads? He soaked that walnut there, didn’t he?
Dix and Fogus make a useful pair here: one says the surrounding validation loop becomes the constraint; the other says the hard part may be formulating the problem at all. The same distinction applies to visual prototypes. A tool such as https://spritefuse.com/ can generate a character animation, but deciding what one pose needs to communicate, and checking that it still reads in the exported frames, is a separate task. Faster production seems most useful when it buys more small, testable revisions rather than a larger unreviewed batch.
> He soaked that walnut there, didn’t he?
Great callback! Definitely include that in your writing packet for The New Yorker, someday.