I was invited to speak at this year’s AI Engineer Europe conference on the topic of how to do AI-native engineering in big tech companies with a cool demo planned. Sadly, my extremely peculiar employer refused me permission to speak. So you’re reading this instead of watching a talk. If you’re trying to do meaningful, novel AI work inside a big company (not just Big Tech, with capital letters), it’s difficult because you’re being squeezed from two sides simultaneously. I’ve seen teams respond in a way that makes things worse. Here’s what I think actually works.

Sheffield has always been the doe-eyed ingenue compared to the oi-oi-oi brashness of Manchester and whatever it is that Leeds is. Many are attracted by the climbing and the trees. Fewer are attracted by the local tech industry. I’ve worked remotely since moving to Sheffield four years ago, so I’ve never had much reason to care about the local scene. That changed when I was nearly made redundant and suddenly found myself asking: what software companies are actually based in Sheffield? Turns out the answer wasn’t easy to find. There’s no single page listing the IT and tech companies here, what they do, or what kind of developer jobs they offer. So I made this one.

2026 note: this is an old build log, not current advice. I am leaving it up because it still captures the useful bits of trying to run Kubernetes cheaply on Hetzner Cloud, but I would reach for a managed cluster now unless I had a very specific reason not to. This post is a guide to setting up a bare-metal Kubernetes cluster on Hetzner Cloud. Why? Well, previously I had a couple of applications running on a Google Cloud virtual server. They were running on FreeBSD because my original plan had been to use it as an opportunity to learn a bit about FreeBSD. This failed because I’d forgotten that the end goal of setting up a server is to interact with it as little as possible. Once things were working I didn’t really want to dick around with it and so my main FreeBSD-specific experiences were limited to fiddling about getting things to build properly. Because I didn’t interact with the server very often I kept forgetting how to do things and had to rely on past me having thought to write copious notes. Doing per-application backups was a bit fiddly and generally I didn’t have good visibility on what was going on. Since I wanted to play with Kubernetes anyway I thought it would be a good opportunity to improve my deployments, backup strategy and general plumbing.

I wrote a Game Boy emulator in Go called Goboy. This was not because the world was desperately crying out for another Game Boy emulator. It was because emulators are a lovely excuse to learn how real machines work without immediately drowning in modern hardware complexity. The posts below are a build log rather than a pristine tutorial. That means there are wrong turns, mildly embarrassing bugs and a lot of “I thought this would be simple and then it was not simple”. I think that makes them more useful. Most emulator write-ups show the final clean architecture. Real emulator development is more like discovering that one bit in one register was supposed to be read-only and that your entire mental model has been quietly wrong for three days.

This is part of the Writing a Game Boy emulator in Go series. One of my aims with Goboy was always to deploy a web-based version using Webassembly. It actually turned out be remarkably straightforward (see here). The first step is to build for the Webassembly architecture. Following the instructions in the Go repo, the build incantation was simple: GO111MODULE=on GOOS=js GOARCH=wasm go build -o builds/wasm/goboy.wasm cmd/goboy/main.go That ran in the browser using the helper JavaScript specified in the Go repo. Ebiten, the game runner library I’m using, supports Webassembly and so things were painless.

This is part of the Writing a Game Boy emulator in Go series. Goboy is nearly completion – well, as complete as a Gameboy emulator can ever be. My wife was volunteering in Phnom Penh for a few weeks and I had intended to use the time to implement the audio unit. As things turned out I ended up spending a few weeks chasing down various bugs. There is still some errant flickering sprites that I haven’t had time to debug yet and the audio remains unimplemented. Those two aside, though, Goboy is in much better shape.

This is part of the Writing a Game Boy emulator in Go series. Goboy has reached a major milestone – a working display! Recently, my development process has been a bit unorthodox. My wife and I are spending this year travelling and so I only have bits of time between the many, many temple visits to program and blog. The display is the most complex single component of the Gameboy and, in my opinion, implementing it is pretty much an all or nothing job. You can’t really built it piece by piece as you can with the instruction set. Each time I worked on the display it took me a little while to rebuild my mental model of how the display works and all of its (sometimes obtuse) details. I had started work on the display while we had a solid block of time in one country. I was also working remotely at this time so progress had been pretty slow and I was worried I wouldn’t finish it before we started moving again. The thought of having to tackle this pile of half-finished, broken code on a series of night buses did not appeal.

This is part of the Writing a Game Boy emulator in Go series. Finally the opcodes are implemented. I took the approach of getting all of the opcodes implemented and unit-tested before moving on to other components. In retrospect I wouldn’t recommend this approach because you go through a long period with nothing really to show for it. On the other hand, once the opcodes were done all I had to do was implement basic ROM loading and all of the blargg test ROMs would pass straight away, right?

This is part of the Writing a Game Boy emulator in Go series. The first tranch of instructions to implement are the various load and store operations. These are interesting to start off with because they obviously require some kind of memory model. The instructions themselves are quite variable. Some include immediate values, entailing variable-length instructions, some do complex addressing and so on. I spent quite a bit of time implementing these and refactoring what I had because I wanted to establish a solid pattern. Implementing the memory instructions was probably a bit more involved than, say, the arithmetic ones but I thought that if I could get the memory instructions right the others would follow easily.

This is part of the Writing a Game Boy emulator in Go series. This is the first in a series of posts documenting my progress writing a Gameboy emulator in Go (imaginatively called Goboy). Sometimes it’s nice to write something that’s not a web app. My plan is more to track my progress and highlight interesting bits rather than create an in-depth guide to writing an emulator so these may be a bit scrappy and intermittent. I’m trying to take a fairly agile, one-instruction-at-a-time approach so there will probably be plenty of missteps and backtracking.