Mindless Rambling Nonsense

Let's plan that

Fri, 13 Mar 2026 10:00:00 +0000

My favourite quote is "The plans are useless, the planning is essential"

Since the plans are useless, why do we run planning sessions at all?

It's planning season at work. We are high trust, high agency, and minimise collaboration. It is pretty common for folk to change their plans and they do so without needing to seek approval.

Without shared context and an understanding of the broader picture, people would change plans but be pulling in different directions. Having the big picture means you can rely more on instinct and curiosity rather than rigid plans.

Torture a metaphor? If you insist…

The landscape you're building software in probably doesn't look like this:

We're generally operating under imperfect conditions. Trying to figure out where we are is more like being in the fog:

A friend was for a while a member of mountain rescue (who are incidentally incredible - you should give them money). They once described to me how they navigate when they have very low visibility.

In pairs:

use the map to figure out where you are
use that information to figure out what direction to go
using a compass one of you slowly walks in that direction
the other stays still and calls out when the walker is about to disappear into the fog
then that person catches up with the walker
repeat

Looking at the context of where they are against what they know about the world. Working together to understand what that means, right then. Watching each other and relying on communication. Chopping the journey into many safer parts.

The short loop of frequent interactions with your colleagues, your users, your analytics are the small steps in the fog. But you have to plan to have the destination and route. This navigation completely falls apart without the map. It requires the wider context.

But surely you can't keep going with this metaphor?

Once we were hiking on Maiden moor and within a half an hour we went from clear skies to low visibility in fog. My wife who is a competent navigator asked me: "why is your thumb there (on the map)?". I explained it's where we were. And she pointed out distant landmarks to triangulate how wrong I am.

My error made it into a much longer and more challenging walk than we had planned.

Her navigation is better because she is looking at the bigger picture. Whereas I'm counting field boundaries.

Even once we have the map and the route, we still need to navigate by looking at the landscape and landmarks to stay on course.

Your customers and your competitors don't stand still so you have to keep looking up to see if the world changed under your plan.

OK, we're done now with the hiking metaphor now, surely?

Well, why was I counting field boundaries? Once we have the map and the route we have our plan. But when you try to follow it, you discover all the things that make it difficult. A copse of trees was cleared. A farmer moved a stile. A path is impassable because of thorns or mud.

The route very quickly becomes a series of small decisions and adjustments as you navigate around obstacles. You can't make those adjustments with a static plan. You can make them because you have practised making the route. You know why it is the route and so you can adapt it to changing conditions.

The actual plan is the starting point. The thing we thought would meet our goal before reality hit us over the head. What you learn on the way will often change your plan. Ignoring that is as silly as not having any goal to head towards.

Please no more metaphor

In all of these scenarios the planning doesn't get you anything without execution - no point planning a hike and not walking. But the planning has to happen to make the route any good.

That's what good teams do. They have a series of nested loops and they check themselves at each point. Short term loops like daily standups that focus on the next few hours. And long term loops like quarterly planning that focus on the next few months.

You have to plan but be receptive to changing plan. If you stuck to a plan despite what you learn you'll get stuck in a bog, but if you never plan you wouldn't avoid any.

How I use LLMs? - four

Tue, 10 Mar 2026 08:00:00 +0000

I remain very cynical about the current high-water mark for LLMs and augmented coding… but at the same time I use them every day and I don't think they're finished improving.

Let's ~~growth hack blog visitor numbers~~ record how I use them today as a little reflection on where I think they work and where they don't. Something I can revisit as the tech (and my skill with it) improves

This is update number three, or entry number four, depending on how you want to count it.

in today's edition of AI hot takes

basically never braincode
it's still about your brain
hot take

First, a necessary but brief diversion into how I use tools generally

I was largely self-taught as a developer and (after vbscript 😱) I started with DotNet. I found JetBrains Resharper early on and never looked back. The assistance in the IDE to write, refactor, and improve code was game-changing. I don't begrudge anybody any tool they want to use to level-up. Wanna use a graphical git client, or emacs, or anything else… go for it, go make cool things

Because of that entry to the industry I'm also not super keen on VSCode (you love it? great, see above, you do you, go make cool things). I'm too used to clever interventions helping me and VSCode is too barebones (and so much slower than SublimeText)

So, I like having tools directly involved in my workflow. I learned LINQ more quickly and more thoroughly because I had resharper prompting me inline, at write-time: "hey, why not like this?"

basically never braincode

Recent improvements to agents and their UX has meant I only have to actively write code when I choose to. It would be possible to completely work via agents.

It really is only necessary to "braincode" when it is easier for me to sketch a solution than to prompt an LLM to write it. Even then I would quickly fall back to "hey agent, here's what i mean. finish this off"

Having the agent in slack is chef's-kiss-dot-reacji. Someone says "hey, should the foo be wider" and you reply "@agent, make the foo wider" Like having a super eager and precocious intern sat waiting for the next task.

it's still about your brain

You'll see a lot of people saying variations on "it was never about the code" or "it was always about what you chose to make not how you made it". And tbh I 90% agree with them. The code was a hard part but it wasn't the only hard part.

We've automated a big chunk of code understanding and generation but we still need to choose the direction. Reaching through the system of systems you can affect to try and deliver value.

Astronaut-with-pistol-dot-meme

hot take

Code is no longer for humans.

We are seeing the end of the era of code needing to be in a format that humans can directly parse. Languages are already abstractions on top of what is really being executed. The format being determined by the available technology to let humans create code. And by the needs of the humans at understanding the code.

In a world where we can say "hey robot, how does the Foo component manage the ClinkExpander interactions". It no longer matters what the underlying code looks like.

My expectation is that there are already folk working on a storage format that is accessible to agents but loses the trade-offs it had to make for human readability. Maybe a binary DAG format since we don't really need the translation from an abstract syntax tree in memory into text anymore.

If the agents keep getting better, my expectation is that I need to be able to ask for representations of the code that help me and them interact with it way more than I need a flat text file.

I shipped 1000 PRs in a year, AMA

Wed, 11 Feb 2026 08:00:00 +0000

I shipped 1000 PRs in the last 12 months at PostHog. And someone asked me how I do it… let's see if i know.

preamble

yes, yes, I know you don't think I should count PRs
when a measure becomes a target it stops being a useful measure
embrace yourself

advice

it is running not cycling
small steps ftw
practice like a jazz musician
love making things
one more iteration

yes, yes, I know you don't think I should count PRs

So, first something important…

Counting PRs is a very poor metric for measuring progress. Someone who ships 10 PRs has not provided a guaranteed ten times the value of someone who ships one PR.

I'm not telling you to count PRs. Or to worship the github tile graph.

But….

Yes, weighing yourself is a bad way of checking if your last meal was healthy. Yes, merging a PR is a bad way of checking if you just provided any value.

But not weighing yourself is a great way to put on weight without noticing.

And not measuring what you ship is a great way to accidentally ship less value.

However………..

"when a measure becomes a target it stops being a useful measure": Charles Goodhart in preparation for my birth

Taking a look at how many PRs or lines of code people ship is a measure of what people are doing. It's vague and lossy but it's a starting point.

And, yes, of course, someone could ship lots of PRs but they're no good or only ship one thing a week but it's super impactful.

So even if you use it as a measure it should not be your only measure of progress

But, importantly, if you tell people "number of PRs is related to promotion review" then they will damn well make sure they ship more PRs without that being related to actual value to users.

It is no longer a useful measure of progress because it became a target.

embrace yourself

didn't that feel nice?

no, not like that

Throughout my career I've been told I spin too many plates and to try and reduce my work in progress. I tried really hard to lower personal WIP and it was sooooo much effort.

My colleague Marius at PostHog said (roughly): "you always apologise for spinning plates, but you're good at it. why don't you try to get better?"

So, I've done that. I've accepted that I am easily distracted and that I will start many things. And I've concentrated on getting better at making sure the plates I'm spinning are moving forward. And throwing away the ones that are just distraction.

I've started more than 1000 PRs but recognised the ones that aren't going anywhere.

For you this will look different. You might have to not listen to music with lyrics. You might need to make sure you go for a walk in the morning. Or plan blocks of the day with zero distractions.

My advice would be - stop listening to advice that makes you fight your nature. Just because someone else wants to work on one thing at a time doesn't mean you should. And just because I can have 23 open PRs right now and be on top of my work doesn't mean you should.

Ok, now that I've told you to not listen to other people's advice.

I will dress in a robe, walk down from the holy mountain of the github tile graph, and hand down my advice of what I believe contributes to my productivity:

it is running not cycling

I used to cycle a lot and having struggled up a big hill it was super cool to stop pedalling and coast down the other side. Then I started running, and having struggled up the big hill I discovered I still had to put in effort to run downhill. Even if gravity was helping me if I stopped moving my legs I stopped moving.

Delivering valuable software to users is running, not cycling. If you stop shipping your momentum is quickly lost.

It is up to you to move your legs. To bring the appropriate intensity and effort.

Want to ship a lot? Just do the work…

small steps ftw

I have seen time and time again that small, concrete steps that you can explain, complete, and measure are the best way to make progress.

See "But why regularly measure" in one of my earlier weblogs

If you feel stuck with the coding, break it into a smaller piece. Not sure how to do the work? Figure out what the simple pieces are and start with those. If the remaining pieces are "too big" or "too hard" figure out how to change the system so the solution changes and is smaller or easier.

Often, I will make one big PR that covers the whole change to prove it works. Then break that into smaller pieces that refer back to the whole. To make it easier to review or deploy.

practice like a jazz musician

When I was younger I was labouring under the misapprehension that I was going to change the world of music. And I was lucky to spend some time with some people who were amazing musicians.

They would practice frequently and deliberately. They were purposefully aiming to get better at the little things that made them better at the whole.

Later I spent time with folks talking about the craft of software engineering. Practising skills like TDD and refactoring.

The little things that make you better at the whole.

Ah, but Paul this new world of agentic software engineering makes skills like that outdated and unnecessary.

I love this quote from Andrej Karpathy

And I've found the same… If the prompt is important then knowing what to prompt is important.

And when the prompt isn't enough to get the job done being able to sketch enough code to give a better start to the agent is important.

In both cases you actually have to know what you want. And practicing what good software, or good architecture looks like is still a differentiator.

I'd add practicing writing good prompts and managing context well as new skills that it is worth practicing.

Be purposeful about improving your ability as a person that provides value through creating and changing software. Watch what you do, see what makes it better, double down on those things.

Avoid through practice and diligence ever doing the wrong thing harder.

love making things

I make things all the time. I am sad when I don't get to make things. This is a vocation for me.

Nobody points at the musician that plays music for the sheer joy of it and says: "ha, look at that loser. playing music even though they're not getting paid for it"

So, in the evening when I've finished getting the kids to bed. I sit and fiddle with software while I watch TV or listen to music.

I am incredibly lucky to have found something that gives me joy and makes me money.

Not a vocation for you - ok, cool. Live your life as you see fit. But one of the ways that I am productive is that this is a joyful vocation. Also, if software is not your vocation, why the heck are you reading about how to ship 1000 PRs in twelve months?! Go, ride horses or fix gates or whatever the thing is that does bring you joy 💖

one more iteration

It feels like it goes without saying that iteration is good… but…

Iteration is the process of repeating a set of steps or instructions multiple times, often to reach a specific goal, solve a problem, or improve a result.

"One more iteration" is a phrase that Tim at work uses to push us to think about the quality of what we build…

OK, you did something. Stop and ask: "am I really finished?"

How do I know if I'm really finished?

are people using it?
do they like it?
did it move the needle the way I expected?
would I know if it was broken?
now it is functional does it need to also be delightful?
does it help me see what should come next?

I think this sits really wonderfully with "small steps ftw". Iteration of large blocks of work is inherently slower than iteration of small steps.

The benefit of small steps is you can be nimble in response to what you learn.

Worse… Something that takes a month to put together will build up a lot of weight in your subconscious. It's hard to throw it away or change it because of the time you have sunk into it. Not only are you less nimble, you're less likely to correct your course.

A concrete example of how i do small steps and iteration…

A customer reported they were unhappy with filtering in our tool. It was multiple clicks to get to the point where they had type-ahead search. And that was frustrating for them.

Frustration is no bueno, so I started spinning a new plate. I mocked up a solution for them very quickly and shared a video.

They loved it.

BUT I OPTIMISE FOR ITERATION AND SO I DID NOT SIMPLY SHIP IT

I wrapped it in a flag and released it just for our team and that specific user that I was talking to

I got fast feedback that they did not like it. They liked the description, and they liked the demo. But what people think they will like and use is not always what they will actually like and use.

In practice by optimising for one journey through the filtering UX I had made other journeys harder. I wouldn't have known that if I didn't think about how to release this in a way that meant I could check if it was any good.

In the end, this took four attempts to get right.

And now I have rolled out the flag to all users. After an experiment over those multiple iterations showed folk came back and searched more using the new versions of this change.

But rolling out the flag isn't the end of the work. I'm now working on tidying up the code that was there so that I could dual run and measure the change. I've got to finish updating the documentation. I need to check that users behaviour really does change over coming weeks and react to that. So there are still more PRs to come from this work.

An inspirational sign-off?

The value here isn't that I shipped lots of PRs. The value is that I work in small steps, and I check direction in between them. That I can loop between what I learn and what I can do next to learn more.

How you do that might be different, perfect! But my advice: do that.

How I do user interviews

Wed, 11 Feb 2026 08:00:00 +0000

I've been lucky to watch some excellent engineers, product managers, and user researchers carry out user interviews.

And had the opportunity at PostHog to practice that skill. I've explained all this a couple of times to different people, so thought I'd write it down.

set expectations
write down quotes
show > tell
compound interest
sometimes stop
be a Labrador
this is the redesign that will kill the the Facebook

set expectations

Whenever I'm starting a user interview I try to set very clear expectations for the person. I will say something like:

Thanks for your time today. And importantly it's your time. So, while I'm mostly interested in $feature_X if you want to talk about other parts of the product, that's fine - we can cover the things you're interested in. I'd really love you to share your screen so I can see what you're doing as well as hear you talk about it. To start out can you show me how you use $feature_X?

You might want to constrain what they talk about to a specific feature or topic. So your intro would be different. But I find it's generally better to hear what they're thinking and feeling even if it doesn't relate to what I'm focused on.

write down quotes

I had the great privilege of working with user interviewers with a GDS background and was always impressed by their skill.

One thing I learned from the wonderful Simon Hurst was to write down quotes when you're taking notes. And to editorialise them later.

You're aiming to capture the user's statement not what you thought about it at the time.

The benefit of having the quote is that you don't have to remember what they said later when you're grouping.

This is also a great way to introduce colleagues to the process. They can shadow your user interviews and capture quotes as they listen.

Of course, if you're doing these remotely it's trivial to record or transcribe the interview. But I still think there's value in going through and pulling out the quotes to capture them. I love to talk to a team and find that they know their users by name and can refer back to specific quotes.

You might worry about acting on anecdotal evidence, and you should test and measure your changes, but that kind of human understanding will guide you to better decisions.

show > tell

It is super powerful to get users to show you what they mean.

If you're interviewing someone and they say "I wish your software let me do Y" (sometimes the software already does do that). The amazing Neil Kakkar would ask "can you show me where you'd look in the UI to do that?"

Whether the feature exists or not already, you now know what the UI for discovering it might look like.

Or a user will say something like "competitor X does this better." the important response is to ask "can you show me how to do it in competitor X?". Sometimes you'll see that it really is better, sometimes that it is just more familiar to them in the other UI.

The insight isn't that you should copy what the competitor does. You should try to understand why they prefer it, across multiple users this will help you understand how to position that feature or introduce that user flow.

compound interest

Setting up and running user interviews can take a lot of time. And so people often skip them. But 1 interview is better than none. 2 is better than 1. And so on.

And this compounds over time. Before you know it you've met tens or hundreds of users.

The knowledge you accumulate about your users (individually and organisationally) will give you instincts on what to build and how to build it.

Decide how many interviews you want to run each month. And stick to it… there's always something more to learn.

sometimes stop

Sometimes you think it's going to be a user interview. But it turns out this is a user that's unhappy with the product. Or doesn't understand the platform and just needs help. I used to struggle through a bunch of open questions trying to "stay in interview mode".

Then I observed Annika Schmid on one call recognise it for what it was and shift into training/explaining mode. It already wasn't going to be a great user interview. So, may as well make it a good experience for the user.

be a Labrador

Importantly, you are there to learn. So, you need to be as interested in their opinions as a Labrador is in cheese.

"I'd love to know more about…" "Can you show me…" "Oh wow, that's not how we expected folk to use this! Can you dive into…"

One thing I've picked up from the fabulous Eric Duong is the phrase "out of interest…"

Not just in user interviews but in every customer interaction. You can drop it in… "Ah, it doesn't work like that… you can workaround by x, y, and z… out of interest what does it unlock for you if we support this?"

I love that framing. "Out of interest what does it unlock for you if we support this?"

That user might not commit to 30 minutes for a user interview. But I bet they'll spend 30 seconds replying to a slack message. And since these things compound over time, you'll learn a lot from accruing all these tiny insights.

this is the redesign that will kill the Facebook

Related to "competitor X does it better" i remember at least three occasions where Facebook changed their UI and everyone was wild in the comments talking about how it would kill Facebook.

Twitter changing the star to a heart made the national news.

With enough users you'll discover that you will get negative feedback no matter what you do. And if you chase every user, you'll end up with a product that no one wants.

Even though, if you don't listen to the users, you'll end up with a product that no one wants.

Gathering all this feedback isn't so that you can just make all the changes people tell you they want. It's to get an instinct for how and why they use your product. You will be asked for conflicting things and without the gut-feeling for what users want, you'll end up with Homer's car.

How I use LLMs? - three

Fri, 30 Jan 2026 08:00:00 +0000

I remain very cynical about the current high-water mark for LLMs and augmented coding… but at the same time I use them every day and I don't think they're finished improving.

This is update number two, or entry number three, depending on how you want to count it.

the first entry is here the second entry is here

XP pedant agent
primarily using LLMs
throw away way more work
be very strict with what i do type
i approach understanding code differently

First, a necessary but brief diversion into how I use tools generally

So, I like having tools directly involved in my workflow. I learned LINQ more quickly and more thoroughly because I had resharper prompting me inline, at write-time: "hey, why not like this?"

XP pedant agent

I love the XP simplicity rules for guiding decision making…

Passes all the tests.
Expresses every idea that we need to express.
Says everything OnceAndOnlyOnce.
Has no superfluous parts.

I like that they're in tension with each other.

I've added them to my AGENTS.md and if it forgets I can prompt it "hey, apply the simplicity rules".

Often the change it makes is the one I would have manually made.

Primarily using LLMs

Over the last three months particularly the capability of LLMs has transformed. I can now go whole days mostly prompting an LLM and writing only a fraction of the code myself. This is… fine.

I've been working on super complex, tricky to find memory leak problems. I would not have had the patience to notice some of the things that the robot can when i provide it with context from my investigations.

And while it's working on the next step I can be improving my investigation, or catching up on Slack, or taking my kids to school.

I don't feel like I've lost anything by not (always) typing out the code directly. And since I taught the robot some extreme programming techniques, i find i don't need to re-work much at all.

I genuinely didn't think I'd switch this much… and like all sticky tools I didn't have to think about it. The tool hooked me.

That said… i don't like vibe coding… I'm not asleep at the wheel and do care about the diff that's being generated. So I feel slightly vindicated by this research from Anthropic https://www.anthropic.com/research/AI-assistance-coding-skills

In a randomized controlled trial, we examined 1) how quickly software developers picked up a new skill (in this case, a Python library) with and without AI assistance; and 2) whether using AI made them less likely to understand the code they’d just written. We found that using AI assistance led to a statistically significant decrease in mastery. … Importantly, using AI assistance didn’t guarantee a lower score. How someone used AI influenced how much information they retained.

throw away way more work

Since I didn't type it, I don't feel invested. I dump a prompt in. Come back, see what came out. And sometimes I just throw it away. It doesn't help as much as I expected, or a UI change doesn't look as good as I hoped.

Without feeling invested in the creation I am a little more rational about whether to throw it away.

It's cheap to do many things at once and keep the useful things.

be very strict with what I do type

This is an addition to "manage context".

Sometimes I find myself writing a huge prompt. I have low tolerance for this. Or I find the task is spinning and churning and going nowhere. So, instead, when I recognise that I stop, I clear the prompt, and I spike the work. Then when I have a good enough sketch I point the robot at the changes and say "hey, like this". I believe we do understand some problems better through trying to solve them.

The robot is still more stupid than it is clever. So, giving it code is a good way to clever it up.

It is still valuable to be a decent software engineer. But it might be more valuable to be a decent software engineer who dumps a sketch into an LLM. (if it isn't now, and they can keep improving, then it will be soon)

I approach understanding code differently

This one is difficult for me to accept, but it's snuck up on me and over the last few months changed how I work.

The cost of writing code is falling and the cost of understanding code is falling.

When the cost of a thing fundamentally changes, you have to change your approach.

"Hey robot, write a script to validate the blah does thingy (or not) when the wotsit is twanged"

"Hey robot, why does the clinkexpander accept a boolean?"

"Hey robot, how does the clinkexpander work?"

"Hey robot, what does the clinkexpander actually do?"

Tasks that would have taken me hours or days or weeks in the past are genuinely done in minutes now.

I've spent a big chunk of time recently feeding heap snapshots to the robot. I can only give huge thanks I've not had to manually grok this myself.

Is the robot perfect? No. not even.

Is the robot a good software engineer? No. not even.

Is it silly to ignore the fact that the robot does not need to be perfect or good for it to be a fantastic tool?

yes, veryeven.

the game has changed. pandora's box is open. the robot is here to stay.

It reminds me of once… I used to work with someone who had worked mostly with signal processing baked into hardware. Very painful to discover a bug after release. We were sat together and I changed a field in a JSON response. He asked in a mid-panic: "but how many bytes will that add to the payload?". Genuinely confused, I said: "I've barely ever had to care… I don't think it matters"

We're on the verge of that kind of change. We're not there ffs but some point down the road someone is going to ask "but isn't that AI slop" and their colleague will answer, genuinely confused: "yes, why?"

Will some of that software be bad? yes always-has-been-dot-meme

Things that a different me would have been tipped into psychosis by

Wed, 03 Dec 2025 08:00:00 +0000

There are a few memes (in the original sense) that have got stuck in my head. They feel like the beginning of madness. I'm going to track them, to see how many I accumulate

water isn't real
old people are time travellers

Each of them feels like something that would tip a different me over the edge into madness.

Water isn't real

I could be easily convinced that water isn't real.

Sit in a boat, look over the edge at the water.

It's obviously CGI. Can't possibly be real.

Old people are time travellers

Whenever I've had a baby (a common thing I've done) I'll be walking with the baby in the pram, and very sleep deprived.

An old person passing by will say something like: "Oh, what a lovely baby". Some similar nice thing to that.

In my sleep deprived state it once occurred to me that a very lucrative business - if time travel existed - would be to let you travel back and see your grandparent as a baby.

Can't get that out of my head now. Whenever an old person is nice to me, i'm a little odd with them… because at the back of my mind there's a voice saying "that's exactly what a time traveller would say".

How I use LLMs - two?

Fri, 24 Oct 2025 08:00:00 +0000

I remain very cynical about the current high-water mark for LLMs and augmented coding… but at the same time I use them every day and I don't think they're finished improving.

This is update number one, or entry number two, depending on how you want to count it. So, here are the changes in how I'm using LLMs

(we had a brownbag on this at work yesterday, so it's been on my mind)

the first entry is here

manage context
track longer tasks in a structured file
smallest prompt that describes how you want to work
be sparing with auto-accept edits

First, a necessary but brief diversion into how I use tools generally

REMINDER: I don't begruge anybody any tool they want to use to level-up. Wanna use a graphical git client, or emacs, or anything else… go for it, go make cool things.

You don't use LLMs, or not like this, cool… go make cool things.

So, I like having tools directly involved in my workflow. I learned LINQ more quickly and more thoroughly because I had resharper prompting me inline, at write-time: "hey, why not like this?"

Anything removed from entry one?

Being your army of interns

I don't believe in having a personal WIP of one item in progress. So, I like that I can have a higher WIP without exhausting my own kreplets

But… I find the background work is best as tasks like

"upgrade Jest to the next major version"

"why is this component rendering too much"

very, very constrained yak shavey tasks.

otherwise I find that the LLM needs a lot of attention to complete the task well, and so my kreplets are being used up - and because I'm not doing the work I'm learning more slowly.

Manage context

I'm pretty vicious about managing context. If I start a new task I'll clear the context completely. If I get even the slightest inkling that the LLM is going off on a tangent, I'll clear the context completely.

It isn't thinking despite all the cognitive biases that make us think it is. It's just churning out tokens based on the tokens in its context. So, if the context gets screwey so does the output.

Longer tasks, track them in a file

If we're doing a big change or exploring something complex. I tell it to make a markdown file with a to-do list and what we're working on.

For example, i asked it to track down and edit every event listener in our front end. There are ~350 files it would need to touch. It regularly would partially edit around 30 of them and then we'd hit a "you're absolutely right" loop.

So, clear the context. And step 1 "make a file with a markdown table of every logic.ts file that has an event listener in it".

Some checks to be sure that was correct… and now step 2 "for each line in the table {do the thing} and then update the table with the result".

That was way better

Smallest prompt I can get away with

I'm not doing evals with my prompts so it's a little like some pagan weather magic ritural but I did add a custom prompt in my home directory. Which I believe is helping.

# Approach to work

I like "Simple code" that means:

* Passes all the tests.
* Expresses every idea that we need to express.
* Says everything OnceAndOnlyOnce.
* has no superfluous parts

These rules are in conflict with each other. Sometimes to express every idea we can't say everything only once. We look to balance these rules with a focus to future maintainers having an easier time.

Also... it means we work in three stages

* make it work
* make it right
* make it fast

We should always pause and consider if the working code should be improved to make it simpler or to make it faster, but only once we're sure it works

# tests

* IMPORTANT prefer parameterized tests

# validating this file has been read

if i say "cuckoo", you say "Phil Haack has taught me well"

The cuckoo thing is useful to check if the file has been read at all.

But, otherwise, I can now periodically prompt: "ok, review the work so far using the simplicity rules and suggest improvements"

And it will write me a mini-report that is much more like the type of self-review that I would write.

It was also an interesting exercise to try to write the smallest description of how I like to work.

Sparing with auto-accept edits

Reviewing code is essential but boring. And even more so with an LLM that might go off the rails…

So, I will tend to manually accept edits on the task I give it. But, yesterday I asked it to update a major release of Jest. Turned on auto-accept and went and collected #4 from school, made flapjacks with her, and then checked in.

A little fangling but otherwise it was dull work I would have had to do. That has relatively little value (particularly compared to making flapjacks with #4 daughter)

Here's the PR: https://github.com/PostHog/posthog-js/pull/2413

Four things in four years at PostHog

Tue, 16 Sep 2025 08:00:00 +0000

I've been at PostHog for four years. After having the best four years of my career at Co-op Digital, I'm privileged to have then also had the best four years of my career at PostHog. Surely, I've learned something that I can cram into a cliche format?!

Don't look for a family, look for a team
Talk to users all the time
You can YOLO and strangle your figs at the same time
Trust is a super power

Don't look for a family, look for a team

The more I've experienced this, the more I'm convinced it's genius.

At home, for sure, look for (and build) an environment where you are unconditionally accepted and celebrated, But at work, look for a group formed around a shared (probably competitive) purpose.

A team is somewhere folks expect the best from me and they expect me to own my part in achieving that. They also help me to get there. But I have to own it for me.

Being surrounded by people who reinforce your good behaviours and model good behaviours you can learn from is 💯. Enough so, that I can't imagine being willing to accept an environment without that now I've had it.

An old colleague would share a video of Barcelona football team. Multiple times someone would score and the player would celebrate. Soon another player would come over, tap them on the shoulder, and they'd go back to the game. They knew that the behaviours that correlated with success were important and they had little rituals to reinforce them. In this case, "don't celebrate too long, we're still playing, we need more goals, and we don't get them by celebrating".

At PostHog the company values are used the same way. Like the Barcelona shoulder tap, they're not just aspirational words on a page. They're the behaviours we see correlate with success and reinforce by living them, and by holding each other accountable to them.

Talk to users all the time

I have never once regretted talking to our users. Either on tooterweb, in support tickets, in a user interview, or asking for email / screenshare feedback. It is hands-down the best thing. It has consistently levelled up what I've been able to do at PostHog.

I used to get frustrated with teams using user stories that would write "as a user" and would push them to have a particular group of users in mind. I don't like the trad user story format. But if you are using it try and think of the group of users: "as a busy shopper" or "as an owner of a small business". But a million times better IMHO is "Sam wants…" or "Jane couldn't…". Not an imaginary Sam or Jane. People you have talked to, that you can empathize with, and follow-up with.

The important counterpoint is that just building everything users ask you for is not the goal. Understanding their needs and problems and how it shapes and relates to your instinct for the product is the goal.

The classic example of this is that when users say something is cluttered they are only rarely asking to see less information, instead they are really asking to see different information.

You can YOLO and strangle your figs at the same time

Two of the things I've loved about working at PostHog…

One) it is totally fine to push something to prod, discover its a mistake, and fix forward or rollback. So long as it is done with purpose - it's not fine to be careless but it is fine and desirable to be bold.

Two) it is also totally fine to change something slowly over multiple releases. Increasing the mix of traffic to a new feature until you are confident it is ready for everyone.

Often people talk about a company culture as if you have to choose between these things, but you don't. You can drive your car in different gears on different slopes. Choosing the approach that is right for the situation.

Trust is a superpower

My first pull request at PostHog was before I started. A change to the docs to increase the budget for an engineering laptop purchase because the cost had gone up. Then buying the laptop. All before I'd met anybody or had my first day.

The default was to expect me to do the right thing and assume that I would.

Similarly, when I wasn't sure what to work on after I'd started. I booked user interviews with customers. Talked to them, and then decided what to work on. No approval process, no fuss, no need to queue on anybody else, nothing in my way.

Or in my second week when the kids were ill and I said I wouldn't be able to work that day but would "catch up on Saturday". Marius, the tech lead said: "that sounds stupid, take the day off". No worries that I would hack the system and take too much time off.

And, honestly, most every day since then. It is incredibly motivating and rewarding to be trusted to do the right thing.

(yes, "do the right thing" is loose and open to interpretation, but that's the great thing about trust, i can interpret what the right thing is)

The thing that works so well alongside this is a culture of feedback. I've been told when I've done well, and when I've not. And then trusted to take that information and do the right thing with it.

Things I've learned that didn't make the cut of the four in four cliche format

typescript enums are useless, just use string union types
writing tests is the best, writing the fewest tests for the most benefit is besterer
react was a mistake, but there's no good alternative yet
a one word copy change can have a 100x impact on clickthrough rate
giolitti is the best gelato in rome

How I use LLMs?

Thu, 24 Jul 2025 08:00:00 +0000

I remain very cynical about the current high-water mark for LLMs and augmented coding… but at the same time I use them every day and I don't think they're finished improving.

First, a necessary but brief diversion into how I use tools generally

I was largely self-taught as a developer and (after vbscript 😱) I started with DotNet. I found JetBrains Resharper early on and never looked back. The assistance in the IDE to write, refactor, and improve code was game-changing. I don't begruge anybody any tool they want to use to level-up. Wanna use a graphical git client, or emacs, or anything else… go for it, go make cool things

So, I like having tools directly involved in my workflow. I learned LINQ more quickly and more thoroughly because I had resharper prompting me inline, at write-time: "hey, why not like this?"

Do I think LLMs do good work?

It's like having a startlingly talented, but very overconfident, inexperienced colleague

They will swing from correcting you on the intricacies of some detail of technology to doing blindingly stupid things like naming variables with one of your competitors company names in them

And just like the work of any colleague where you bear more responsibility. It is on you to own making sure the work is good. If you're helping someone with less experience than you the mistakes are yours, don't blame the colleague / LLM

And just like working with any colleague… you can do more together than you could before - once you know how to work together

As an example, while I'm writing this Claude Code is writing some tests for me. I just did a "mean colleague" trick. I went in and commented out the implementation - and the tests carried on passing.

The LLM fixed that and we shipped the PR.

I find faking timers in Jest super confusing and couldn't figure it out… the LLM could 🤝

Things I'm totally sold on

Research for me

I tend to use ChatGPT for this but only out of habit. I not-very-fondly remember days of sweating over documentation and blog posts while trying to figure out something.

Or, even worse, searching for your problem and finding a single hit…

a stack overflow question…

with no answers…

from years ago…

that you asked and have no memory of

🫠

Now, I can delegate that to the LLM. It does that groundwork, responds to follow-ups. ~~Can't~~ Doesn't care when I ask silly questions.

I can do something else with my time while the legwork is being done.

Warning?

You have to remember that confabulation exists. I ask it for sources and go check for myself. Because I'm confirming and critiquing (instead of doing the groundwork) it's quicker and easier work.

Also…. OMG if it does maths for you, make sure to double check the numbers. It can quickly go off the rails.

Simple tasks

As mentioned above… this morning I've got a couple of tricky things to figure out… and I wanted to write some tests on a bit of code that had let me down in one of our SDKs.

So, in the background Claude can figure out why the tests weren't working and get them working. Then I check that work, together we correct it.

In reality that probably saved me an hour of work (maybe less but definitely not more).

Could I do that every day? That's heading for most of a working week each month.That's quality memes on Slack time, practically for free!

Warning?

I'm pretty good at context switching, my life forces me to be. If you're not, you should figure out a different way of doing this.

And you're responsible for this work… even though you didn't write it. You still need to engage your brain. The machine isn't thinking. And the more nuance in the task, the more opportunity for it to confidently do something very silly

Things I'm partly sold on

Explaining complex things

The LLM is your over-confident colleague with arcane knowledge. You can ask: "Hey, I'm trying to figure out why my kafka consumer is timing out sometimes. Explain how a nodejs consumer behaves during cooperative rebalance and why it might time out."

And it will confidently share exactly why that is happening. Digesting the docs and the 1000s of blog posts. It will draw diagrams and propose solutions. Amazing learning tool.

I often work with open source tools that do complicated things I don't fully understand. Being able to ask "what does this arcane few lines of code do". To get a quick start on figuring something out is super useful.

Warning?

It will also sometimes confidently explain absolute nonsense. And when you say "but the nodejs consumer doesn't have that method". It will reply "Thanks! You're absolutely right." And then explain something else just as confidently.

Being your army of interns

You can run more than one instance of a tool. And give each of them a different task. In theory that's a multiplier since you can have more than one "intern" doing work for you at the same time.

I've now got two copies of our main repo on disk so that I can happily have two totally separate streams of work.

Warning?

Starting lots of things is not as powerful as finishing lots of things!

Also, personally, I purposefully don't have a job as a tech lead at a company that employs inexperienced folk and then expects the tech lead to make sure things stay on track. I've had that job, it's a valid company strategy, it's not my jam.

I enjoy when I'm making software and I'm not a massive fan of rounds of reviewing PRs with a colleague that I can't simply trust. And you can't simply trust these machines. So, there's a worfklow here that is a multiplier which I haven't quite figured out… but the risk is that I end up squashing the fun bits of my job, and accidentally shipping a bunch of rubbish (as opposed to my current approach of enjoying the process of shipping artisanal, hand-crafted rubbish)

Warning 2?

They're not actually very good software engineers… particularly since most of the data they've ingested about software engineering is "blogs on how to start something from scratch". So, if that's not the task. Then I find it often harder to prompt an LLM to do than to do it myself

Case in point…

While I was typing this post Claude was doing the work to duplicate a data management section of the application. I wouldn't have to think to do this, so giving it to a machine that isn't thinking should be OK.

But in the end I did the job myself…

There was just enough nuance that Claude was making a mess of it.

Maybe I'm not good enough at prompting.

Maybe I'm giving it a job it's not ready for.

But there'a a lot of snake oil to be sold in the gaps there…

For example…

I pasted in the error message after the first set of changes it made. It decided that the problem was TypeScript was out of synch. So, it did some stuff with touch and echo insisting all along that typescript was confused.

So I checked and, actually, it was using packages without installing them. This over-confident thing is amazing and horrifying at the same time.

Reviewing your PRs

Machines don't get bored or distracted (yet). So having a PR reviewer that can look at 78 changes in a rename or move refactor that won't get blind to the one difference where there's a mistake or a typo is pretty powerful. I've tried three reviewer tools. They're all about as good and bad as each other.

Personally, I really hate the summary of the PR they all do. But then I've got colleagues that hate writing PR descriptions I bet the summary is useful for them.

Warning?

It is not thinking, just pretending to. So when you get "nit pick: the blah should be wired to the clink expander" it is fine to just hit "resolve conversation" in GitHub. I think these are a nice pre-filter for human reviewers but they're nowhere near as useful as being able to tag a person you trust and respect.

Things I'm not sold on

Writing tests with an LLM

I don't do TDD any more. Often I write tests after the implementation… shhh don't tell anyone. But for some types of tasks I do like to write a test or two first. Particularly "someone says this is broken and needs fixing, is it?"

Even pointing the LLM at existing tests I find they tend to churn out rubbish tests. I think that's probably because they've ingested the internet and there are so many bad examples of writing tests on the internet.

Whatever the opposite of a warning is?

They don't get bored and have ingested the whole internet. So I find they're really good at "i've started writing parameterised tests, please add more examples to test edgecases in blah processing" or "look at the implementation file X and suggest missing tests or tests that can be removed in this test file".

How do I like to be managed?

Tue, 03 Jun 2025 08:00:00 +0000

An amazing engineer colleague has taken on (booming, god-on-the-mountain voice) extra responsibilities. Unfortunately for them, one of those responsibilities is managing me.

They asked me how I like to be managed. I thought it was a good question, so I pushed it into my background processing queue, got distracted, and never answered them.

Periodically I feel guilty about that, so I thought I'd write it down here. Maybe it will help me decide what my answer is…

I guess I should consider a few different things:

when I've not been managed well
when I've been managed well

When I've not been managed well

The fool

Many years ago, I was working for a large Enterprise omni-clopse style technology services company. I was young and didn't know what I wanted from life.

Well, that's not quite true. I wanted to change the world of long, loud rock music. But I was kidding myself.

I had fallen into a job as an infrastructure engineer because I'm pretty good at solving problems and I like computers.

The person managing me was… well… they were the worst manager I've ever had. I didn't know that at the time. I'd not had many managers before, so I didn't know what to expect.

There came a point where I wanted to be a software engineer. In a 1-2-1 they asked me about my goals, and I shared that. They gave me a long rambling speech about how I wouldn't enjoy that.

I've been a software engineer for a long time now, and I love it.

I take responsibility for my mistakes… listening to them was a mistake, and that's on me. But I am pretty certain I would have been a software engineer years earlier if I hadn't listened to them.

The absent manager

For a short while I was at a consulting company. My manager was on the same team as me. I think… it was never clear.

I don't remember a single 1-2-1 in the time I was there. Particularly, I don't once remember feeling pushed or supported. I didn't think I was doing super well

Again, I could have done something about this… I'm not looking for someone at fault. But on reflection one of the reasons I left that job was a lack of feedback and a feeling I wasn't valued

When I've been managed well

timely feedback

In a 1-2-1 a long time ago, my manager said: "I'm too busy. And I value that when I see an email chain, and I see you've replied, I can ignore it. Because I know it'll be sorted out."

I didn't think of myself that way. It was super clear about what was happening. And how I could continue or level it up.

I'm not in touch with them anymore, but that short feedback changed my approach more than any other moment I'm aware of

And the reverse, a different manager said (paraphrasing) "I need you to decide when to stop working on something." Really clear, timely example of what I was getting wrong, and how I could fix things.

I am… very easily distracted. One person described it as a "curiosity-driven approach to work."

I used to apologise about this and try hard to avoid it. Until a colleague said: (paraphrasing) "the thing is, you're good at it - why don't you just try and get better, instead of fighting yourself."

This has been transformative. I'm more productive, more present as a parent, and less stressed about my behaviour (not the same as thinking I always get it right 🙈)

context, context, context

Another thing I value — the larger or faster the organization the more I miss it.

A more senior colleague often has context that you don't. Your manager is often that person. And sharing that with you is super valuable.

That might be how you're seen ("your long to-do lists don't help people understand what you're working on").

It might be organizational context, for example, once I was worrying about the specifics of a deadline, a senior colleague said: "We have to spend 90% of the marketing budget printing posters by the second week of the financial year. Nobody will care if your deadline moves, but some will really care if you know you'll miss it completely. Because they can't afford to reprint."

Suddenly, I didn't have to plan what week I would hit something. Just how confident I was for a "yes/no" decision. Way easier, and more helpful!

Or, when an exec at omniclopse was a shouty-man, throwing salesforce at every problem. Learning that they'd been hired specifically to implement salesforce completely changed my understanding of their needs. They were trapped doing something they didn't want to do until they could point at implemented salesforce. And I was trapped with them until then…

That made my job so much easier.

experience / the coach

The person managing you has different experience to you.

A previous manager was a purposeful politician. Helping me understand that I had to give a Director level colleague "something to say yes to" instead of showing them why they were wrong (spoiler they were definitely wrong. I know I sometimes am… but not that time). By giving them something to say yes to, we could get past the loggerhead we were stuck at.

Another manager was great at coaching questions. Pushing you to see where you were missing something and to figure out how to address it. Long walks, with tough questions, that sometimes ended with ice-cream 🧑‍🍳👌

Does this help me answer their question?

timely feedback.
- we're all works-in-progress and don't always see what we're getting right or wrong
- in-person feedback is the gold standard, but I prefer feedback sooner. so async is better than missed
similarly "the coach"
- I worry that I'm not great at reflecting on my work
- I also find impostor syndrome a real problem,
- and I'm "senior" enough that people assume I know what I'm doing
- So, I worry that I get less feedback than I otherwise would
- So, I love to hear critical feedback as much as positive
- I'd rather be asked the uncomfortable question than miss the opportunity to improve
context, context, context
- one colleague would refer to the "Chief Reminding Officer"
- it's easy to get lost in the forest even with a map in hand
- your manager often has a very different viewpoint (and worries they're too far from the forest)
- I'd rather be reminded of the context more often than I need