Grahm Larkham
Here to help 😊
About
I'm an embedded software engineer at Johnson & Johnson MedTech, where I work on the Automated Impella Controller, the console that drives the Impella CP, RP and 5.5 heart pumps.
Most of my day is C and C++ on QNX, and the split is roughly 50% documentation, 30% debugging, and 20% designing new features. The documentation share tends to surprise people, but on a regulated medical device it is most of the job. If it isn't documented, it didn't happen.
Outside of work I mostly tinker, and it has grown well past what I originally intended. The small things are unchanged: a mod when something in a game bothers me, a Python script to scratch one specific itch. But the home server I started has become the largest thing I have built, and I am partway through teaching myself Godot and shaders properly.
Not all of it is software. I make things with my hands too, including a jester costume for the Renaissance Faire. A lot of this is still me learning as I go.
Contents
Experience
Education
Selected coursework
Computer Science: Algorithms and Data Structures, Computer Systems,
Programming Languages, Compilers, Object Oriented Design, Database Design, Discrete
Structures, Introduction to Computer Science Research.
Networks and Distributed Systems (CS 3700).
Mathematics: Linear Algebra, Calculus I.
Other: Genetics and Molecular Biology, Organic Chemistry I and II.
Skills
Vintage Story modding
A handful of small mods for Vintage Story, written because something in the game was bothering me. They are deliberately unambitious: each one fixes a single irritation and does nothing else.
Download counts below are read from the mod database, so they are current rather than whatever they said on the day I wrote this.
Source for all
of these is in vintage-story-mods on
GitHub.
Learning shaders
I have been teaching myself Godot, and shaders in particular. Everything you can see in these screenshots is shader work rather than texture work, which is the part I am pleased with.
There are three shaders. The water surface has its own, which drives the waves. The robot has its own. Both are ordinary Godot shaders, written in gdshader.
The third is the interesting one. A large core shader governs how almost everything else appears, including the transition from above to below the water and the caustics underneath it. It navigates a sparse octree and implements a ray marching traversal over that structure, which is how it stays fast enough to be worth doing at all.
That shader is written in Slang rather than gdshader. Slang itself transpiles it to GLSL, and a small Python script of mine then rewrites that GLSL into gdshader, which is a modest job since the two syntaxes are similar. The reason for going the long way round is testing.
Slang will also compile the same shader to C++ and run it on the CPU, which means I can step through the traversal, inspect the octree, and unit test the whole thing, instead of inferring what went wrong from the picture on screen. I would not want to debug a sparse octree traversal any other way.
The terrain itself is procedurally generated and streamed in chunks, loading and unloading around the player as you move. I wrote that part in C++ after the GDScript version proved too slow to keep up.
The grey cubes are a buoyancy test. They float, and rise and fall with the swell of the waves rather than sitting at a fixed height.
Writing the traversal in Slang also meant I ran into a genuine miscompilation in it. Reading an array element with an index, then changing that index on the next line, made the compiler reorder the read to after the change and return the wrong element. It showed up in my octree traversal stack, of all places. I reported it with a minimal reproduction and it was confirmed and triaged: slang issue #13273.
Renaissance Faire costume
A jester costume for the New York Renaissance Faire, made from scratch. Not software, but the most satisfying thing I have built with my hands.
My friend Ashley and I learned together while her mum, Lisa, taught us. We started at the basics and worked up: threading and running a sewing machine, how to rip a seam without ruining the fabric, how to use bopkins to thread elastic, and how to read costume patterns, which are written in a dialect of their own. The trousers came from a pattern and taught me why that dialect exists.
Some of it we simply winged, and those parts are the ones I am fondest of: the hat, the collar, and the cross-shoulder bag.
Theseus
The machine this page is served from. It started as a way to stop paying for cloud storage, and has turned into the largest thing I have built: a server that holds my photos, films, music, files and code, and runs a language model on the side.
It is named Theseus because the original plan was to replace bits of it over time until nothing original remained.
Hardware
Storage, and how it grows
The bulk storage is a btrfs pool called tank, running in RAID1. It
began as two 12TB drives, which gave about 11TB of usable, fully mirrored
space.
In September 2026 I added a second pair of 12TB drives and the pool grew to 22TB. That operation is the reason I chose btrfs. RAID1 in btrfs mirrors at the block level rather than tying one disk to another, so drives can be added while the pool stays online: no restoring 11TB from a backup, no downtime, and redundancy maintained the whole way through. With this much media, the alternative was going to be painful.
A few things I learned along the way. Copy-on-write is switched off on the large
video files individually, since rewriting whole multi-gigabyte files on every
read is pure overhead. The filesystem mounts with noatime, so
reading a frame does not trigger a timestamp write. And a scrub runs once a
month, reading back every block and checking it against its checksum, which is
how bit rot gets caught before it reaches a film you actually wanted to watch.
What runs on it
Several dozen containers, most of them behind Docker Compose. The ones worth naming:
Immich
Nextcloud
Jellyfin
jfa-go
Minecraft
Open WebUI
GitLab
GameVault
SnappyMail
Beszel
Uptime Kuma
Dockge
All of it is reached through a Cloudflare Tunnel with identity checks in front, so nothing is exposed directly.
How one person manages all of this
A fair question, and the honest answer is that I do not manage it alone. Theseus runs nearly fifty services and I could not keep up with them by myself. A great deal of the work is done with AI assistance, and the way that is organised is the actual engineering.
Every application or feature on the server has its own dedicated AI chat. When something needs doing I go back to that same chat, which by then holds the full development history of that one thing. It starts with complete context and does not need re-briefing.
Everything is version controlled, so I can review any change at the command line and see exactly what was touched and why. The amount of accumulated context is what makes the assistants genuinely capable, to the point that I can ask for a new service to be deployed and have it stood up and wired in without me intervening. That is a deliberate strategy rather than something I stumbled into.
The roster, roughly in order of seniority:
There are around twenty more beyond this list. Being able to hand a distinct, well-scoped piece of infrastructure to a distinct assistant, with its own history and its own accountability, is what makes a server this size tractable.
Pets
