I've worked on computer systems in many different environments: cloud-native serverless functions, self-managed virtual servers, embedded devices, pushing code for on-prem bare-metal racks that I'm not allowed to look at, much less touch. My experience across all these projects has falsified a lot of opinions, but there's one thing I believed when I first started coding and still believe now, perhaps more than ever:

You need to be able to run the damn code.

Whether you're starting a new feature, testing your implementation, or trying to root-cause some gnarly bug, you need to be able to run the damn code.

Whether you're shotgunning printlns, attaching a debugger, or grinding out bugs with fuzzing, you need to be able to run the damn code.

Whether you're a senior operating at the highest levels of architecture, a junior hanging on by your fingernails, or somewhere in the middle trying to level up, you need to be able to run the damn code.

Whatever your scaling challenges, cost constraints, compliance requirements, ideological loyalties to this or that technology the thing you should never give up, no matter what the content marketing or the case studies or the highly paid consultants say is the ability to run the damn code.

Not “we have a functional core that we run in a serverless shell.” Not “we have a staging environment that developers can access.” Not “you can spin up an emulator for this data service that mostly works except for this long list of caveats.” You need to be able to run the code on your own hardware with full access, zero marginal cost, and total visibility into the process.

Anything less will become a productivity destroying, team blocking, project killing obstacle.

This means:

• Writing code that can run in an environment you can emulate: prefer containers to cloud functions unless you have a very good reason
• Use software that can be obtained without approval: either use an open source database or pony up for as many licenses as you have developers
• Write your code to be run: it can be a compose file that emulates production or a local Kubernetes environment, but it can't be a pile of shell scripts and implicit state (unless you have someone who's extremely good at shell scripts)
• Write down all the state: Keep your infrastructure definitions in version control and run them. A lot. Do devops as “developers can operate the system”, not “we have someone whose job is YAML and AWS certifications”

And of course having a coding agent makes this so much more true. Having a system you can inspect yourself is necessary. Having a system that an fast-working, dogged, and reasonably capable LLM-driven tool can interact with and iterate on without worrying about costs or permissions or dropping a database that you needed, actually—that's glorious.

This is an interesting piece of work! A small team built a bunch of software in a short time by leveraging a whole lot of LLM assistance both for building their software and for validating it.

The main things that are new to me in this story are:

• Building digital twins of third-party services like Google Docs that you can test against without rate limits.
• Keeping validation scenarios away from the processes doing the building so that they can be “independently verified” by another agent (kind of like a holdout set in machine learning).

I think there are some interesting things in this writeup (though I'd love to see more details about how they build their digital twins), but I have some fundamental concerns as well.

Primarily, even if you keep your validation scenarios hidden, if they're being done by an LLM they're inherently probabilistic and could be hiding nasty surprises, especially security problems caused by weird adversarial inputs. Even though Claude can write pretty good code, is very fast, and sometimes catches things that I miss, I'm still not comfortable putting my name on software without a closely reviewed and deterministic validation step.

It also sounds like there are some easily avoidable code quality. I think bringing taste and good practices to a repo is an important part of your work as a senior engineer, and something that can pay dividends as agents follow the patterns that you've laid down.

Advent of Code is back again and I'm joining in the fun! This year, I'll try solving it with Unison, a statically typed functional language with some very neat ideas about content-addressable source code and distributed computing. It has a proprietary cloud backend, but you can also run it on your own machines, and it recently had its 1.0 release.

What follows are my very first ignorant baby steps coding in Unison.

Pure Functional Programming

I have some experience with other pure functional programming languages. There will, of course, be some differences, but I'm going to assume that I can pick it up as I work through the puzzles. That's what AoC is all about!

If you're not familiar with this style of programming, I recommend Elm or Clojure as starting places. They're quite different (Elm is a little closer to Unison), but both very illuminating, and more approachable if you're coming from something like Python or JavaScript.

The Unison Codebase Manager

When I've worked on Advent of Code in the past I've used languages like Chapel, Rust, or Gleam where you write code in files, you edit code in files, and you run code from files.

Unison... doesn't work like that.

You do write your code in text files, but rather than living there you load it into your content-addressed, append-only codebase with a tool called the Unison Codebase Manager (or ucm).

It feels a bit like using a REPL: you write your code, ucm watches for changes and does type checking, runs tests, etc. When you're satisfied with the code you're working on you run an update command at the ucm prompt and your functions are imported.

I followed the tour of the Unison workflow to get a feel for how it works. I wouldn't say it's comfortable yet, but I'm ready to get started which is all we need!

Reading Puzzle Input

Rather than using the Advent of Code API I like to get my puzzle inputs manually, read them from a file, and then paste the output to check. I'm a bear of little brain, and sometimes I need to get hands on with debugging my code!

To approach AoC this way I need to know how to:

• Read input from a file
• Parse that input into a data structure
• Print output to the terminal

This is slightly complicated by the way Unison handles “effects”, which includes things like input and output. Full treatment is beyond the scope of this writeup, but the relevant functions are documented in base.IO.

Printing a file is easy enough: we can use printLine anywhere in our main function. Reading a file involves constructing the path, opening the file, and reading it as text.

Putting these parts together looks something like:

main : '{IO, Exception} ()
main =
    use IO *
    do
        inputPath = FilePath "input/foo.txt"
        inputHandle = open inputPath Read
        input = getAllText inputHandle
        printLine input

Parsing is trickier.

There are tools in the base language for doing parsing, but they're quite simplistic. In particular, they don't handle parsing recursive structures, which is something that past AoC puzzles have required. On the other hand, sometimes puzzles start with tidy nested structures but then switch to considering the input in a more ad-hoc fashion.

For now, I'll try using the built-in parsing tools, but I'll figure out how to bring in a more sophisticated parsing library if I need it.

Sharing Solutions

Another lovely feature of AoC is reading solutions from other developers. Seriously: BurntSushi's 2018 solutions in Rust taught me more about working in that language than hours of noodling on code did.

Unison programmers seem to share code on Unison Share instead of GitHub. There's even an Advent of Code template pinned to the front page!

I followed the instructions in Unison share code hosting to get a feel for this. I'm not sure if my code will be valuable to anyone, but I'll publish it here anyways!

snaste (noun, obsolete):

The wick of a snuffed candle

What I love about this word is how it conjures up feelings that could only have existed in the past.

I might read about changing technology, how in the past light-after-sunset was an expensive luxury and a messy, sooty, stinking affair. I might imagine the advent of clean-burning oil or electric light, or examine graphs of economic indicators and see how they track the adoption of new modes of lighting.

But none of that could make me look at a snuffed out candle and appreciate it as something with parts that I’d care about enough to call by name. It wouldn’t occur to me to differentiate a wick from a snaste, but somebody did, which means they were thinking about candles a whole dang lot. I can imagine, vividly, the feeling of picking up a taper and finding the wick broken, and exclaiming, “a pox on thee Jeremy, thou hast marred my snaste and now my taper is all jacked up.”

The past is always more complicated and more remote than you think. How lucky to glimpse it, even fleetingly.

I adore ripgrep. It's fast, it's convenient, and I've never wanted a feature and found it missing.

But no software is perfect, and today ripgrep was the program causing problems.

echo '!/.github/' >> .rgignore

By default, ripgrep doesn't search everything. It checks your .gitignore for example, which is wonderful when you don't want to be searching all of node_modules. It also ignores hidden files and that's what bit me today.

See GitHub Actions are stored under .github/workflows/, so when I removed a particular file and rg'd through my whole codebase making sure it wasn't used anywhere I missed that it was used in some GitHub Actions.

Easily fixed, but how to make sure I don't get bit again?

We can search hidden files (but ignore .git/) with

rg --hidden --glob=!.git/*

but that's a bit of a pain to type for a tool I use many times daily.

It turns out ripgrep does have a configuration file that you can activate by setting an environment variable (RIPGREP_CONFIG_PATH).

After a bit of fussing with fish to get the variable set properly, I ended up with this in my shell config:

set -gx RIPGREP_CONFIG_PATH $HOME/.config/ripgreprc

and this in my ripgreprc:

--hidden
--glob=!.git/*

And now I'm on to bigger and better (or at least different) problems.

Greg Wilson was soliciting strategies for lazy-loading datasets in Python modules. There are, of course, many ways to do this, but I didn't see this one being discussed.

Since Python 3.7 (released in 2017) you can define a module-level __getattr__ function that gets used for name resolution (see PEP 562). You can use this to call a data-loading function the first time each module-level property is accessed. This implementation uses only functions, dicts, and the one magic “dunder” function, which might be more approachable than programming with classes (depending on your audience).

A sketch of an implementation:

# Cache loaded datasets
_dataset_cache = {}

# Dictionary mapping dataset names to loader functions
_dataset_loaders = {
  # maps names to argument-less functions that load datasets
}


def __getattr__(name):
    """PEP 562 module-level __getattr__ function for lazy loading"""
    # Check if we should load a dataset for this attribute
    if name in _dataset_loaders:
        # If not already cached, load and cache it
        if name not in _dataset_cache:
            _dataset_cache[name] = _dataset_loaders[name]()
        return _dataset_cache[name]

    # If not a dataset, raise AttributeError
    raise AttributeError(f"Module has no attribute '{name}'")

For example, this module has attributes foo and bar which are only calculated when they're first referenced:

# foo.py

# Cache loaded datasets
_dataset_cache = {}


def load_data(name):
    if name == "foo":
        print("loading foo")
        return 1
    elif name == "bar":
        print("loading bar")
        return 2
    else:
        # This should be unreachable, but just in case...
        raise AttributeError(f"Module has no attribute '{name}'")


# Dictionary mapping dataset names to loader functions
_dataset_loaders = {
    "foo": lambda: load_data("foo"),
    "bar": lambda: load_data("bar"),
}


def __getattr__(name):
    """PEP 562 module-level __getattr__ function for lazy loading"""
    # Check if we should load a dataset for this attribute
    if name in _dataset_loaders:
        # If not already cached, load and cache it
        if name not in _dataset_cache:
            _dataset_cache[name] = _dataset_loaders[name]()
        return _dataset_cache[name]

    # If not a dataset, raise AttributeError
    raise AttributeError(f"Module has no attribute '{name}'")

In use, this looks like:

>>> import foo
>>> foo.foo
loading foo
1
>>> foo.foo
1
>>> # NOTE: didn't load foo a second time
>>> foo.bar
loading bar
2
>>> foo.quuz
Traceback (most recent call last):
  File "<python-input-4>", line 1, in <module>
    foo.quuz
  File "/Users/nknight/tmp/foo.py", line 34, in __getattr__
    raise AttributeError(f"Module has no attribute '{name}'")
AttributeError: Module has no attribute 'quuz'

After yet another fight with the syntax for text fragments in URLs (which I've written about before) I had Claude whip up a little app for constructing and testing them.

It's published here.

It’s April Cools! It’s like April Fools, except instead of cringe comedy you make genuine content that’s different from what you usually do. This is my very first April Cools post. 🥶

I attend (and marginally help organize) a local in-person monthly tabletop role-play game meetup. It's consistently the extracurricular highlight of my month. Whether you've been playing for years, are just getting into the hobby, or (like me) have had to dramatically cut back the time you spend at the table because you're a parent, it's a great way to scratch the TTRPG itch without the considerable labour and time commitment of a long-term campaign.

Running games at a public meet up on a monthly basis is very different from running a home game. This article talks about some of the challenges you might have and gives some advice on how you might successfully run a meetup of your very own.

What you Need

1. Players: Before you can do anything you need folks to play with. Maybe you can get started by dragging some friends along, but you should think about how you're going to get the word out, especially if you're trying to include people who aren't already in the hobby.

   Do you or some of your friends have network you can tap? Can you try to grow by word of mouth? Do you want to advertise at local game stores if those exist? You don't need to grow exponentially or anything, but you should think about how to keep your project sustainable and that's hard to do if nobody's attending.

2. Venue: Next you need somewhere to play. This could be a local game store or pub or café, but these all come with costs either directly to your players (as they buy pints and fries) or to you (as you pay rental fees). If you're lucky perhaps one of your players has a space that could host the meetup. Otherwise, venues like churches or community centres might have space you can use for free or for cheap, especially if you emphasize the community building aspect of your project.

3. Games: You might be happy to play D&D on a one-off basis for a few hours a month, but I certainly don't. When I'm looking for a good meetup game I try to find something that is:

   • quick and light, so you're spending your time playing instead of learning rules,
   • contained so that you can have a satisfying experience in one session of play, and
   • different, because I like variety in my gaming life, and because it makes for a more welcoming meetup if there are lots of different options for folks to choose from.

The Agenda (or at least the one we use)

Once you've got your players, your venue, and your games, what do you actually do at games night? Here's the agenda we use.

1. Arrival: Meet at the appointed time, welcome folks in, do a bit of idle chit-chat, and eventually gather into a big circle.
2. Intros: The facilitators introduce themselves, tell folks about the venue (e.g. where the bathrooms are). Then we go around and have folks give their names and pronouns. Then anyone who has brought a game they'd like to run gives quick pitch describing its premise, tone, play time and player count.
3. Make groups: If we have enough players we divide into smaller groups based on interest. We usually do a quick straw poll to see which games have critical mass and then sort of Vornoi ourselves into groups by putting those games in different corners and having folks position themselves in space according to their relative interest.
4. Play! Most games go for 2-3 hours with a short break. Your mileage may, of course, vary.
5. Debrief: About twenty minutes before we need to close down the venue we re-convene and share something that we appreciated about our game that night.

Then we clean up and close down the venue and wait eagerly to do it again next month.

Games to Play Occasionally and with Strangers

Here are some games that I can personally recommend in a meetup setting:

• For the Queen by Alex Roberts

  You are accompanying a powerful and mysterious queen on a perilous journey to end a generations-long war. She has chosen you as her retinue because she knows you love her.

  For the Queen is a card-based story-building game that you and up to five other players can begin playing in minutes.

  Play For the Queen to tell the story of an awesome/awful Queen and kingdom and her complicated, unequal relationships.

• The Quiet Year by Avery Alder

  The Quiet Year is a map game. You define the struggles of a community living after the collapse of civilization, and attempt to build something good within their quiet year. Every decision and every action is set against a backdrop of dwindling time and rising concern.

  Play the The Quiet Year to tell a zoomed-out story about a community building in the midst of adversity.

• Fiasco by Bully Pulpit Games

  Fiasco is an award-winning, GM-less game for 3-5 players, designed to be played in a few hours with no preparation. During a game you engineer and play out stupid, disastrous situations, usually at the intersection of greed, fear, and lust. It’s like making your own Coen brothers movie, in about the same amount of time it’d take to watch one.

  Play Fiasco to tell a story about people with big ambitions and poor impulse control.

• Galactic 2e and its expansion Going Rogue 2e

  A game of relationships, rebellion, and war among the stars.

  Play Galactic or Going Rogue to tell a Star Wars story with no dice and no game master.

• Blood Feud by Blackfisk Publishing

  Blood Feud is a game about toxic masculinity: certain common attitudes and behaviours among men, that cause great harm to them and to others around them. This is a game about people being nasty to each other and about figuring out why.

  It’s also a game about vikings of pre-christian Scandinavia; about honour and blood feuds, courage and brutality, corruption and consequences. Above all it is a game about what it means to be a man in such a world—and what consequences that has on the communities they live in.

  Play Blood Feud for a tragic story about men who can't help but hurt each other.

• A Perfect Rock

  Your home planet was destroyed.

  You are aboard the last Generation Ship with the sole survivors of your people. You must find a perfect rock: a new planet to call home.

  Play A Perfect Rock for a sci-fi story about exploration, especially if you have a cool rock collection.

Laurie Voss hypothesizes that rather than driving all software developers out of a job, the rise of generative LLMs and “vibe coding” will result in more overall software development jobs, but that they will look different than the ones that currently exist.

The argument goes roughly:

• LLMs are a new layer of abstraction for writing programs
• New layers of abstraction create new kinds of programmers who don't think as much about layers lower on the stack
• There's lots of unmet demand for software development
• Developers who can “vibe code” to meet this need will be numerous, productive, and decently paid (though perhaps not well compensated as developers in 2025).

He also argues that overall demand for software development will go up as it gets cheaper, so salaries for current developers won't really be impacted.

While I have a couple of quibbles, I like this a lot! I think “AI is a new level of abstraction” is a much more useful take than “all code will be written by AI” or “AI is useless and will go away”. The idea of a software engineer who doesn't really know how to code is very strange, but I can sort of see how it would work with the right tools. You would need a bunch of knowledge about protocols, databases, architecture, etc. that previously would have been inaccessible to someone who doesn't code, but that's changed now.

I'm not sure I buy the “salaries won't go down” component. We've witnessed fifty years of capital rapaciously sucking up every grain of surplus profit it can, so if there's a way that LLMs could be used to undermine software developers' bargaining power re: the cost of their labour I bet someone will find it, or at least try hard enough that it will be a bad time, at least in the short term.

With all the AI hype flying around leaders who (for example)

• replace their staff with AI agents
• create a class of “vibe coders” whose salaries are anchored lower
• buy AI licenses for their favourite half of the engineering team and lay off the other half

will be lionized as bold and forward thinking, at least until the negative consequences of these actions start to crop up. I think they will crop up, because more code means more tech debt, and with fewer people building theories you're going to hit that wall sooner or later, but the owning class and their lackeys can remain irrational way longer than it takes to erode your salary.

I remember a time when there were whole libraries dedicated to clipboard management.

Turns out in browsers released after ~2020 you can do it with one line:

navigator.clipboard.writeText(text).then(console.log).catch(console.error);

Some caveats:

• this only works in a secure context (which mostly means either “a site served over HTTPS” or localhost).
• the user needs to have interacted with the page before you can actually call the method.
• this was only added to certain browsers in 2020, so it's new enough that it might cause problems if your constituents have older devices or don't update often.

Usually when I do this I'm implementing something like a “copy to clipboard” button:

<span id='copy-target'>This text is going into a clipboard</span>
<button onclick='copyToClipboard("copy-target")'>Copy</button>
<script>
    const copyToClipboard = (target) => {
        const element = document.getElementById(target);
        const value = element?.innerText
        if (value) {
            navigator.clipboard.writeText(value).then(console.log).catch(console.error);
        }
    }
</script>