Euan Reid

Delegation Means Letting Go

2026-09-26T00:00:00+00:00

When I delegate a decision, I’ve made it someone else’s call. Within the scope I’ve given them, they get to choose. That includes choosing things I wouldn’t.

That can be hard when I know the technology well. I can probably spot a cheaper approach or a problem they haven’t considered – and I’m accountable for the result. But being accountable for a project doesn’t mean owning every decision. When I delegate, I’m saying “you own this piece, and are accountable to me for it”.

As a director, I need to make the whole team more effective. That means taking a broader view than I get from working through each engineering problem in detail. If I keep making the decisions I’ve supposedly delegated, I’m undermining the people I’ve delegated to – both by not empowering them to decide and by making myself a bottleneck. I’ve also left myself with less time to do my actual job.

Another Thing to Maintain

Suppose a manual reporting process needs replaced and we have a deadline of around six weeks. I delegate this to a senior engineer. We already have a reporting service, so I’d prefer to extend it. They decide to implement a small, separate tool instead – the existing service belongs to another team, the changes we would need aren’t on that team’s schedule, and the engineer thinks waiting for the other team would miss our deadline.

I see their rationale, but I don’t particularly want another service to maintain. Somebody will have to deal with its upgrades and failures long after this deadline has passed. I think the other team can deliver for us in time.

But I didn’t make using the shared service a requirement, because it wasn’t. The decision they’ve made was within the scope I delegated. So it’s their call.

What I Need My Time For

A senior engineer is the right person to work through the reporting design in detail. As a director, I need to consider why this report takes priority over the other things we’ve been asked to deliver.

Time and money are not unlimited. Suppose we have more work to do than we have time and budget for. I need to be spending my time with my fellow leaders deciding what things we actually do. I can fill my week with useful technical conversations while those problems sit unresolved, but that just eats up the time we’re already short of.

Once Work Has Started

Once the engineer chooses the separate tool, I need to support them in delivering it. If another team questions the choice, I should make clear that it was theirs to make. Referring every challenge back to me for a fresh decision would undo the authority I gave them. Using “it was their decision” to disclaim responsibility for the result would be cowardly. I chose who to give the work to and how much room they had to do it.

We should agree early on how much involvement I will have. Someone doing this kind of work for the first time may want to work through estimates together; an experienced engineer might only need to flag a change to the delivery date.

Suppose the connection to the source data takes longer than expected. We need to look at the remaining work and see whether the deadline is still realistic. Reopening the topic of using the shared service won’t get the connection finished.

I would intervene if the deadline was at risk or we discovered the design couldn’t meet an unknown requirement. Usually I’d ask the engineer to work out what to change, but some problems might require my involvement to resolve. I should be able to explain which ones and why.

I have work to deliver too. In this example, the teams need an answer about their competing commitments. If they’re still waiting when the reporting tool ships, I’ve not done my job.

After We Ship

Suppose the separate tool works, but takes more maintenance than we’d prefer, and we later learn that the shared service could definitely have delivered in time. That doesn’t mean the call was wrong. They made the best call they could based on the information available to them at the time.

I have to be comfortable with good work going out that I would have done differently. I can offer advice and intervene when something moves outwith the scope we agreed, but within it the decision belongs to the person I gave it to. My disagreement doesn’t entitle me to take it back.

That is part of accepting a director’s job. There is more work than I can do myself, and some of it needs the authority and perspective of my role. I need other people to make the engineering decisions so I can get on with that work. I can’t take on the wider responsibility and keep their decisions too.

Tomato and Boursin Tart

2026-09-22T00:00:00+00:00

I first made some version of this when I was a teenager. It came from one of the many cookbooks around the house, but I’ve long forgotten which.

The original was very simple: pre-made puff pastry, Boursin, thick slices of tomato, olive oil, and dried herbs. I’ve changed bits of it over the years, but not much.

The biggest change is that I make the pastry now as well, specifically John Kirkwood’s flaky pastry. Flaky pastry works particularly well here: crisp, buttery, and sturdy enough to sit under the cheese and tomatoes. If I don’t want to make it, reverting to puff pastry is the obvious move. Blocks and ready-rolled sheets work equally well; the sheet only saves the rolling.

Serves 4-6 as a light meal, 8 as a starter, or more if you cut it into canapés.

Ingredients

For the Pastry

255 g plain flour
185 g unsalted butter
4 g fine salt
90 ml ice-cold water

For the Tart

150 g Boursin Garlic & Fine Herbs
3 large ripe tomatoes
Extra-virgin olive oil
Dried thyme, mixed herbs, or herbes de Provence
Sea salt
Freshly ground black pepper
1 egg, beaten

Make the Pastry

Put the butter in the freezer for about 15 minutes. It wants to be very cold, but still soft enough to grate.

Mix the flour and salt in a large bowl. Put a box grater in the bowl and grate the butter straight into the flour, dipping the butter in the flour occasionally to stop it sticking. Toss the grated butter through the flour with your fingers, without rubbing it in.

Put the bowl in the fridge or freezer for 10 minutes.

Add the ice-cold water and bring the dough together quickly. Don’t knead it any more than needed to form a rough dough. Wrap it and put it back in the fridge for at least 15 minutes.

Make the Tart

Heat the oven to 220°C, or 200°C fan, with a heavy baking tray inside.

Roll the pastry on a lightly floured surface into a rectangle roughly 30 × 40 cm. Put it on baking parchment.

Score a border about 2 cm from the edge, without cutting all the way through. Prick the pastry inside the border a few times with a fork. Put it in the fridge while you prepare the tomatoes.

Cut the tomatoes into fairly thick slices, around 6-8 mm. If they are particularly wet, give the cut surfaces a quick blot with kitchen paper. They should still be juicy.

Take the pastry from the fridge and spread the Boursin over the middle, stopping at the scored border.

Lay the tomato slices over the cheese. A little overlap is fine. Season well with the herbs, salt, and pepper before drizzling olive oil generously over everything inside the border.

Brush the exposed pastry border with beaten egg.

Slide the tart, still on its parchment, onto the hot baking tray. Bake for about 25 minutes, or until the pastry is well risen and properly golden. Give it another few minutes if the base still looks pale.

Leave it alone to cool for five minutes before cutting it. This is best served warm, not piping hot.

A Few Notes

The olive oil goes on before baking. As well as tasting nice, it helps stop the exposed tomato from drying too much in the oven.

I prefer large slices of tomato here rather than small tomatoes or a finely arranged layer. The tomato should still feel like tomato when you eat it.

Part of what I love about this tart is that it allows its main ingredients – the butter in the pastry, the Boursin, and the tomatoes – to show off. You could add balsamic vinegar, caramelised onions, or another cheese, but I don’t think those extras actually improve it. Like with steak, good ingredients don’t need or want anything else.

Civilised Futurism

2026-09-19T00:00:00+00:00

I like the future.

I like better technology, better medicine, better infrastructure, greater freedom, easier access to knowledge, and the steady removal of needless inconvenience. Modern life blesses us with extraordinary things previous generations couldn’t even begin to imagine. I have no desire to recreate the past nor patience for hardship preserved just because of tradition.

But I also dislike the assumption that progress requires us to discard everything that came before it.

Modernisation is too often treated as a process of subtraction. Formality becomes stuffiness. Ceremony becomes inefficiency. Craftsmanship becomes unnecessary expense. Manners become affectation. Old institutions are presumed obsolete because they are old; new things are presumed superior because they are new.

I think there is a better way to approach the future: keep what remains useful, beautiful, or humane; discard what no longer deserves to survive; and build new things with enough care and character that they might themselves be worth preserving.

I call that Civilised Futurism.

Progress Without Amnesia

Traditions are not valuable merely because they are old. Some encode assumptions we are better without. Some solve problems that no longer exist. Some survive through inertia alone.

But traditions are also accumulated solutions.

Manners make interaction easier. Ceremony marks occasions as significant. Dress communicates context. Institutions carry knowledge and expectations across generations. Craftsmanship gives ordinary things permanence and pleasure.

The useful question is not whether something is old or new. It is whether it still serves a worthwhile purpose. Where it does, deliberately preserve it. Where the purpose remains but the form has become outdated, thoughtfully adapt it. Where neither remains useful, let it go.

Modern Systems, Human Experience

Technology should improve life without having to dominate it.

A genuinely advanced house need not look like a computer. A good restaurant should not feel like a logistics platform. A useful institution does not need to advertise every system keeping it running. The machinery can become more sophisticated while the experience becomes calmer, simpler, and more human.

That principle applies well beyond technology. Efficiency is valuable, but not every part of life exists to be optimised. The point of sharing dinner is to enjoy time with others – it shouldn’t be fast. Ceremonies, be they formal occasions like weddings and funerals or informal ones like birthdays, contain deliberate rituals because significance is not measured in throughput.

Progress should create more room for civilisation, not less.

Modernity with Manners

Manners are sometimes appropriated to enforce hierarchy or arbitrary rules, but that’s not their purpose. Their purpose is to make consideration habitual – a set of conventions for making life easier for other people. The particular conventions can and should change. The underlying principle should not.

The same is true of many things we inherit. We can keep the useful principle without preserving every historical expression of it.

Civilised Futurism is neither nostalgia nor techno-utopianism. It’s a mindset that rejects both “we’ve always done it this way” as justification and “this is old” as criticism. It’s the belief that we can enthusiastically build a more advanced future without accepting that advancement requires us to become less civilised. Keep the manners, ceremony, craftsmanship, institutional memory, and sense of continuity that still enrich human life. Discard the injustices, inefficiencies, and empty conventions that do not. Build new things with enough care and character that they too may someday become traditions. Insist that progress can and must retain beauty, warmth, responsibility, and character.

Civilised Futurism is the belief that a better future shouldn’t just work better, it should be worth living in.

Tooling Matters

2026-09-15T00:00:00+00:00

Engineering teams spend too much time maintaining things that aren’t functionality. Linters, formatters, package-manager glue, hooks, CI wrappers, editor setup, and version management – all of it needs attention, and the interactions between them need more. Some of that work is necessary, but most of it isn’t.

A package script wraps a shell script because “consistency”. CI and editor plugins acquire their own copies of a tool. Someone fixes an editor warning by adding a duplicate configuration file. Eventually, a change passes locally and fails in CI, and an engineer spends the afternoon working out which version of which command actually decides whether the code is acceptable.

I treat tooling as a systems problem. A repository’s tools have components, boundaries, responsibilities, interfaces, failure modes, and an operational cost. We tend to choose them individually then leave their interactions to whoever next gets stuck. I’d rather design that system up front and ensure I can explain it.

Who Decides?

For starters, I take a leaf from RACI’s book: a tool is Responsible for enforcing a standard; the engineer is Accountable for the code they commit. If Ruff owns Python formatting, it decides what correctly formatted Python looks like in that repository. Another formatter doesn’t also get a vote. I’m still accountable for what I deliver, including changes a tool makes on my behalf. Passing a check doesn’t transfer that judgement to the executable.

That gives me one canonical owner per concern. Two formatters rewriting the same files are an obvious problem. Two linters enforcing the same rule, two task runners defining the same workflow, or an editor silently overriding the repository’s configuration are versions of the same mistake. I regard that overlap as a design smell. Every exception adds something the next engineer has to understand before they can trust the result.

Ownership also needs a scope. A tool may support ten languages while owning only one job in my repository. I can use Oxfmt for CSS formatting and Biome for CSS linting without enabling Biome’s formatter. A wrapper can call the owner; it shouldn’t carry an independent copy of the owner’s rules.

I’m certain I’ll replace several of these tools over time. Most of them replaced others, after all. When I do, I want the replacement to take over a defined responsibility without making everyone learn a new way to work in the repository. Put simply: which job does it do, and why should it do it?

The Repository Has an Interface

mise is my default approach for acquiring and versioning tools, setting up environments, and orchestrating tasks in a repository. Where practical, I start with mise use X which installs the tool and records the version requirement in the repository. I want setup to be something easy to do on a fresh checkout, with the same flow available to a developer and to CI.

I give Git hooks to prek, configured through prek.toml. Hooks invoke the appropriate checks using the repository’s chosen tools and configuration. Those checks must also work when run directly; committing shouldn’t be the only way to find out whether a change is ready.

In every repository, I want a small common set of commands:

mise run fmt
mise run fix
mise run check
mise run test
mise run build
mise run validate
mise run ci

fmt applies formatting and fix applies configured automated repairs. check reports static problems without changing files. test and build do what their names suggest, validate composes the local readiness checks, and ci is the entrypoint for an automated pipeline. Each repository should document what those last two involve. A desktop app and a website don’t use identical pipelines, or even need all seven commands.

The value is being able to move between repositories without relearning how to work. A Python task can call uv; a Rust task can call Cargo. If a web workspace already has a task graph, mise can delegate to it. Recreating that graph in mise would give me two places to maintain the same dependencies. Consistency matters most when moving across projects. The internals can vary more.

Humans, editors, CI, and coding agents all benefit from that interface. An agent should be able to discover how to validate a change without reconstructing the workflow from package scripts and pipeline YAML. The engineer reviewing its work should be able to run the same command.

I also commit explicit editor settings and useful extension recommendations. The selected formatter and its configuration should agree with the command line. A contributor’s personal editor setup shouldn’t be a hidden prerequisite for producing an acceptable commit.

Go Tall, Not Wide

Research by Ruder, Rutter, and others finds prose is most readable at 50-75 characters. Code isn’t prose, but the physical constraints of eyeballs scanning text don’t disappear. Many developers argue for 100 or 120 characters rather than the classic 80 of punch cards and terminals, saying wide monitors obviate that limit, but I’m a firm believer in the value of that brevity – closer to that optimal range, and far better for split editors and side-by-side diffs.

Putting separate arguments or entries on separate lines also gives a small change a small diff. That’s useful when reviewing an engineer’s work or an agent’s patch: I want to see what changed without scanning a rewritten line for the one altered value. Eighty columns is a target, and I leave the exact layout to the formatter. Manual line-wrapping disputes waste time.

Fast Enough to Matter

I prefer fast, portable tools. Portable because developers should be able to collaborate regardless of their OS. Fast because it changes how people work.

If a check finishes in a fraction of a second, all the context is still in my mind and I can keep working. If it takes a few minutes, I’m probably refilling my water or checking Slack, and some of that context is lost. If it takes longer, I’ll batch up changes, go do something else, find out about errors later, and have to reload all the working context to my brain.

Speed isn’t the most important thing, though. Correctness is. A faster linter that doesn’t handle newer syntax in a language or a test runner that doesn’t handle mocking correctly leaves work for someone else to do. When an ecosystem has authoritative tooling, that’s generally the safest bet.

The Tools I Use

For Python, I’m a firm believer in the Astral stack. uv handles packages and environments, Ruff handles formatting and linting, and ty handles type checking. I use pytest for tests.

For JavaScript and TypeScript, I favour Vite+ and its vp interface. It brings together tools including Oxfmt and Oxlint; its vp check combines formatting and linting with type checking when enabled. Integration is useful when it removes configuration and version coordination I’d otherwise have to maintain myself.

An integrated tool still needs boundaries. Vite+ can manage runtimes and hooks too. In my setup, prek keeps the hooks. For a runtime, I choose either mise or the ecosystem manager as the authority and have the other use that decision. Installing both and letting them independently select versions would defeat the point. The same applies to uv’s ability to manage Python versions.

Rust already has Cargo for builds and dependencies, with rustfmt for formatting and Clippy for linting. I use nextest for test execution and cargo-deny for dependency policy checks. The repository tasks can expose these tools without trying to hide Cargo’s model from the engineers using it.

The supporting files deserve owners too. My current choices are rumdl for Markdown formatting and linting, lychee for links, Tombi for TOML, and sqruff for SQL formatting and linting. For CSS, Oxfmt formats and Biome lints. These assignments also mean excluding those files from overlapping tools, even when a newly installed tool offers to check everything by default.

Buf is my choice for Protobuf. Like Vite+, it pulls together formatting and linting in a single tool, but it also handles some Protobuf-specific concerns: breaking-change detection and code generation.

Who Cares?

The point of good tooling is to let you not care. I don’t agree with every decision rustfmt makes about Rust or Oxfmt makes about TypeScript, but I don’t need to. Unless the choice they make is actively causing a problem, arguing with a formatter is a bad use of time. The responsibility is delegated to them the same way I delegate responsibility to engineers on my team – genuinely, not provisionally. Delegation only works if you actually let go.

By choosing good tools – fast, correct tools – and giving them clear responsibilities, we free up our time to focus on things that really matter. Engineering time is expensive – spend it wisely.

Watch Bells

2019-11-11T00:00:00+00:00

Short version: rings ship’s bells on your computer according to the traditional watch system. Download it from WatchBells.com or browse the source code.

Timekeeping is a finicky business. Or it was. The rise of the internet and network connected clocks with it – be they smartphone or desktop – rendered keeping a watch accurate a thing of the past. Watches themselves made reasonably accurate time portable. But watch has more than one meaning.

A ship at sea is continually operating. Emergencies, by their nature, can arise at any time, and a ship whose crew are not ready to deal with situations at a moment’s notice is likely soon a ship in distress. On ships large enough and voyages long enough to warrant it, the crew responsible for the essential functions of operation are split into two groups – the Port and Starboard divisions – and alternate those duties, one division resting while the other “keeps watch”.

The length and timing of watches vary, particularly on smaller boats, but there are a few common patterns, the most well known and assumed-default of which being the one formed by the British Navy in the Age of Sail. This pattern breaks the day into 5 four-hour segments and 2 two-hour segments:

First Watch (8pm-midnight)
Middle Watch (midnight-4am)
Morning Watch (4am-8am)
Forenoon Watch (8am-midday)
Afternoon Watch (midday-4pm)
First Dog Watch (4pm-6pm)
Last Dog Watch (6pm-8pm)

By creating an odd number of watches, the dog watches result in each division’s watch hours changing from day to day. They also, by being shorter and arranged around dinner time, make it easier to feed the entire crew a main meal with the least amount of effort.

But back to timekeeping. For much of said Age of Sail there was no portable way to keep time (the marine chronometer being invented in 1761, and the Age of Sail commonly held to be 1571-1862), and ships – useful ships, anyway – tend to move around. However, solar noon can be readily observed and confirmed with a sextant, giving a reference point. Portable hourglasses, unlike chronometers, have been available since ancient times. By combining the two, ships were able to keep track of time accurately enough for day-to-day practical purposes – and to convey this to the crew, the ship’s bell would be rung every half hour.

Of course, a single toll every half hour is only so useful when people might be asleep for some number of them. Instead of ringing one for every half hour since last noon (which would get cumbersome very quickly), bells instead count through the half hours of a watch. Eight bells (or four, for the first dog watch) signals the end of a watch, and for the next to take their posts.

There’s one last thing to know, however, about the number of bells rung. The last dog watch rings one through three bells again, rather than five through seven. This is not, as might be assumed, because the watch is split and the latter half is counting from their start. Instead, it is due to the Nore mutiny of 1797 – five bells of the dog watch was the mutineers signal to commence so it was decided to never again ring it, leading to the one-two-three-four-one-two-three-eight pattern.

History lesson complete, the project itself – ship’s bells for the desktop. Using the computer clock, this program strikes bells in accordance with the traditional watch system. It can be muted, unmuted, or closed by right clicking on the tray icon. The source code is available on GitHub.

Blackberry-Sloe Sour

2018-11-26T00:00:00+00:00

A twist on a classic, this berry-forward drink has a pleasantly sticky sweetness but remains surprisingly refreshing.…

Typhoon

2018-11-25T00:00:00+00:00

Illegal to serve in many bars around the globe due to its formidable alcohol content, the Typhoon is “like a Dark and Stormy but far more dangerous” – and one of the most delicious things I’ve ever drunk.…

Challenge Rating

2018-11-17T00:00:00+00:00

Originally devised for Dungeons & Dragons 5e, this is a quick way to tune an NPC to the party facing it. It sets armour class, hit points, attack bonus, and damage without relying on the game’s built-in Challenge Rating. It transfers readily to other d20 games, and often to other systems.…