Intro

Lots more AI stuff this week I read and watched. I went to a few talks too around AI and again some of the same themes came up. I’m really not sure what this all means but reading around change is the only real guarantee.

Highlights of the Week

He Was a Supreme Court Lawyer. Then His Double Life Caught Up With Him.

https://www.nytimes.com/2025/12/28/magazine/thomas-goldstein-supreme-court-gambling.html

During this run he won a total of about $50 million, and even though he had sold roughly 75 percent of his stakes to investors, he still personally cleared about $12 million. Flush with his success against Gores, Goldstein sat down to a heads-up match with a real estate magnate named Bob Safai — and this time he didn’t spread the risk by taking on backers. “I just have convinced myself, because I won $50 million in heads-up poker, that I am a savant at heads-up poker,” Goldstein told me. He promptly lost $14 million to Safai, all out of his own pocket.

Nothing really to take away from this more just a really good story. Well bad if you’re him or someone close to him, but a good story all the same. Warning sign about getting too caught up in gambling or thinking you’re way better than all others. He believed in himself, and still does by all accounts, but often that is not enough. Hedge your bets too I guess, or at least don’t bet everything you have without hedging.

The Bitter Lesson

http://www.incompleteideas.net/IncIdeas/BitterLesson.html

One thing that should be learned from the

At some point, or multiple points, anyone working with or using AI tools has an oh shit moment where it does something magical or amazing that makes you stop and think for a minute. Here’s one of mine I had recently

The Backstory

We’ve a microservices setup where there’s a few different services running all together, talking to each other on a kubernetes cluster. Standard fare for a lot of software companies these days. Recently we’ve been adding a new one which is deployed to production but hidden behind feature flags so is internal use only for now. It is actively being developed so there’s lots of churn with loads of changes going on and the full pipelines and checks haven’t yet been set up. Some things are still yet to be done but we’ll get there.

We also run this locally for local dev. There’s not many services, not yet anyway, so it’s not too much of a burden to run the three or four services on the local machine. All this could and should be improved but it is what it is for now. We’ll get there.

The Problem

Anyway this story begins when someone deployed a change which broke the service without anyone noticing for a day or two. Because those checks are not done yet. Again I said this is a new thing so nothing unexpected for this stage of the project. After some initial debugging and looking at logs nothing was showing up, the pod just failed immediately after a deploy and was

Intro

I’ve started trying to take up this week notes habit for a while anyway. Inspired by Simon Willison’s now defunct habit, I’m going to try keep this up for a while. I’ll try out a few different ways of doing it but for now the main will be to take what I’ve read in Readwise Reader, highlighted in Readwise, and noted down in Obsidian and try collate them all to one post. Rough and ready is what they’ll be until I can figure out what I’m doing.

Other than that I’ve read lots of the roundup posts this week which cover a lot of AI stuff. I don’t understand a lot of the technical details of it all but going forward I’m going to rely more on Anki to help get an understanding of some of these technical topics so I can maybe start understanding and be able to read the more technical ones. Of course understanding is nothing without using so more doing things is on the cards. I see a few using tools repos where they’ve created repos with loads of random tools for random things and that is probably one of the best ways of using AI. Get it to do what it is good at which is a small defined tool and scale linearly rather than a monolith that grows over and over. I want to think more about that though

Highlights of the Week

The Great Engineering Divergence

https://x.com/pauldix/status/2006423514446749965

Looking at software delivery, you could break it down into a number of

This is a bit of a rant piece but I feel like the term devops, though good in its original fundamental meaning, is misused so much to the point of becoming meaningless these days.

I believe the term itself is good in the original sense. It is a concept where the same person is responsible for developing and operating the application. You write the code to create the features, create the monitoring for those features, make sure it is running, and most importantly you fix it if it breaks. If something stops working at 2am, you are woken up to fix it. All the incentives are aligned for you to make reliable software which should be the goal for all software.

The bear case for Devops is that having the same people doing all these things is nowhere near as efficient as having a specialised person for each skill. All the tasks in software engineering are enormous fields of their own and expecting the same person to be as skilled on each level is too much to ask. However in reality with modern platforms and services, they are mostly able to offload enough of these things you should only have to set them up initially and figure out the correct configuration for your app, which only you will know how to do. I mean, who knows better what metrics are important: the expert in the code or the expert in observability? The principle of Devops is the code expert knows best. For some apps CPU might be

This is a book I read recently. I’m not sure what prompted me to start but is is a relatively concise book that doesn’t take too much time to get through. The core premise is that code health is something you should care about and want to improve. It lays out some things you should focus on. The biggest inspirations of the book are philosophy of software design and pragmatic programmer. The author even calls this out so if you’ve internalised those you probably know a lot of what goes on here but seeing the same information in a new light with a new shape around it can help a lot to learn it.

One thing I do want to pick on though is it is not a book about AI, despite being in the subtitle. I didn’t pick it up to learn about AI so wasn’t a big deal, just I think tacking on AI to get more interest in it is not what I like. AI is changing so rapidly that whatever goes in print is going to go stale quickly so it is probably a good thing that the subtitle is almost the only mention of AI in the whole book.

Why care about Code Complexity?

Finally, the worst thing about the codebase complexity is that there is almost no way back. Complexity grows incrementally, making it extremely hard to reverse the damage. At some point, you may decide to win it back—to refactor your code into something reasonably simple, but after multiple weeks

You’re consuming too much content. There’s way too much stuff out there and you’ll never get to it all. Focus instead on creating more. Create from what you consume. This goes for reading or watching or anything really. Once that core idea is internalised here’s a 3 step process for trying to get more out of the information you’ve read.

Capture

The first thing is to capture the good ideas and thoughts you come across. For reading this can be highlighting or taking notes. Highlights should be selective. Add notes to the highlights you do take to capture the “why” you want to remember it

The main thing is to be selective about what you read. Instead of reading whatever you come across as it passes by you, be selective and instead maybe save others for later. Read by groups or themes and focus on select areas.

Process

This is how you process the highlights and notes from the capture stage. Here you’re going to compile them into atomic notes about the source. Use your own words and focus on what you want to remember from it. Use it to answer questions you had about it. Try link this to other things you’ve written or read about.

Create

Create something, anything. Explain a topic or your thoughts about it. Review what you’ve read through the last week and write about the best ones. A more ambitious one but more worthwhile is to do a synthesis essay of connecting ideas from multiple sources and writing about how they interrelate.

https://bigdata.2minutestreaming.com/p/how-aws-s3-scales-with-tens-of-millions-of-hard-drives

Interesting deep dive into how S3 has scaled up on a cheap but limiting storage medium of HDDs. Lots of little tricks add up to a performant service

What is this?

This shows how to automatically insert properties to your note in Obsidian. Rather than having to type out or copy/paste each time, you can create a shortcut to do this automatically. This example will create the following properties:

---
title: note-title
date: 2025-05-10
tags:
  - publish
---

Step 1: Install the Templater plugin

https://github.com/SilentVoid13/Templater Make sure you’ve plugins enabled then search for this and install it. There’s loads of resources to do this

Step 2: Configure the plugin

The only thing you need to do here is configure the “Template Folder Location” to be a specific folder. You can name it anything but choose a name of a folder that’s not already in your vault. I’ve chosen templates

Step 3: Create your template

Now create the templates folder and create a new file in it, called properties

---
title: <% tp.file.title %>
date: <% tp.date.now("YYYY-MM-DD") %>
tags:
  - publish
---

You can edit this to add whatever properties and tags you wish.

Step 4: Test it out

In a new or existing note, place your cursor at the very start of the file. Now execute the template by opening the command pane (cmd/ctrl + P) and searching for Templater: Open insert template model and then select the properties function

Going further

You can specify an exact hotkey for your template so you don’t even need to go via the command pane. This can be done via the Templater settings

Improving tooling, documentation, or dev loops. A tiny amount of time fixing a papercut in the right way can save hundreds of users hours of debugging or schlepping through inefficient workflows. https://www.benkuhn.net/impact/

Often it is way too easy to look past these papercuts or just accept them for being “the way things are”. They all add up but when the focus of the task is on something else, often you forget these things. Sometimes though they’re things that are just that little bit too difficult to fix or the solution is unclear so they go unfixed for a long time, sometimes forever. For example a proper dev environment is a huge multiplier for everyone on the team but setting it up correctly is a serious undertaking and if it is not done correctly from the start then it can be ignored often to the detriment of everyone. But because it is not a simple fix then everyone is unhappily going along with it because they can’t see a better way out

I agree with a lot of the stuff in the original post and is well worth the read.