Posts

A colleague looked at my pf.conf last month and said, “That’s it? I thought it’d be longer.”

I took it as a compliment. She didn’t.

She was expecting something impressive. Hundreds of lines of rules, maybe some complex queueing disciplines, an IDS integration, traffic graphs rendered in real time. What she got was about sixty lines of pf rules, two third-party packages, and a box that’s been quietly routing packets for months without anyone noticing it exists.

It’s 3am and your ISP has quietly dropped your WAN connection. Not a hard link-down, nothing that dramatic. The cable modem still has sync, the LEDs are green, DHCP is up. But somewhere between your house and the wider internet, a route has gone stale or a BRAS has crashed or someone at the telco has pushed a config change and not tested it properly. Your firewall has a default route pointing into a void, your DNS queries are timing out, and you’re fast asleep with no idea any of this is happening.

The first time I watched a senior engineer tear apart a junior’s pull request, I didn’t say anything. The feedback was technically correct. Every comment pointed to a real issue, a naming convention, an edge case, a slightly inefficient pattern. Nothing was wrong with the review itself.

Everything was wrong with how it landed.

The junior didn’t submit another PR for three days. When they did, it was half the size it should have been, over-engineered in the places where the senior had left comments and under-thought everywhere else. They’d learned a lesson, but not the one we wanted them to learn. They’d learned that code review was a test you could fail.

Last July, my firewall rebooted itself at 2pm on a Tuesday. No warning, no panic log, just a clean reboot. I was in a call, so I didn’t even notice until my VPN dropped and I found myself staring at a spinning reconnect icon.

Turned out the CPU had hit 92 degrees. In a fanless box. In a house in Larnaca. In July. The ACPI firmware did exactly what it should do and yanked the power. But 92 degrees means the silicon had been cooking for a while before the hardware killed it, and I hadn’t set up a single layer of monitoring to catch it on the way up.

I was sitting in a cafe in Larnaca last year, waiting for a coffee and idly poking around in packet captures from my home network. I’d just installed a new ISP connection, and I wanted to see what the default DNS behaviour looked like before I started messing with it.

Every single query. In plain text. To my ISP’s resolver.

Every website I visited. Every API endpoint my code called during development. Every smart bulb that phoned home. Every NTP sync, every certificate revocation check, every background update from every device in my house. All of it, neatly logged by my ISP, correlated with my account, timestamped to the millisecond.

Eight days. I’d had the new firewall running for eight days when I pulled up pfctl -s info and stared at the numbers: 61 million packets passed, 325 thousand blocked. Zero percent CPU. The APU3D2 was barely awake. Just sitting there, quietly dropping a quarter of a million packets that had no business being on my network, using roughly the same computational effort as breathing.

I’ve been writing pf rules on and off for about fifteen years, and the thing that still gets me is the syntax. If you’ve ever written iptables rules, you know the feeling of wrestling a language that was designed by committee and refined by people who actively enjoy suffering. pf isn’t like that. pf reads like prose. Not elegant prose, maybe, but clear, declarative, opinionated prose. You read a pf.conf and you can see what the firewall is doing. You don’t need to trace chains and jump targets and figure out which table is evaluated in which order. It’s just… there.

Last month I was reading through the privacy policy of my ISP here in Cyprus. Not for fun, obviously. Nobody reads those for fun. I was looking for something specific about data retention, and halfway down page eleven I found a sentence that made me put my coffee down.

It said, more or less: we may use DNS query data to improve our services and share aggregated data with third parties.

I bought some lightbulbs. Nice ones. Wiz colour-changing LEDs that can do 16 million colours, warm whites, cool whites, animated scenes, the lot. I screwed them in, downloaded the app, and watched my phone send a request to an AWS server, probably in Frankfurt, so that the server could send a command back to my house, through my router, to a lightbulb that was three metres away from me.

To turn on a light. In my own house. Via Germany.

I’ve been leading engineering teams for over eleven years. In that time, I’ve never lost an engineer I didn’t want to lose.

I’m not saying that to brag. I’m saying it because it surprises people, and when they ask how, I never have a satisfying answer. There’s no framework. There’s no retention programme. There’s no career ladder with carefully defined levels and competency matrices. There’s just a way of working that, apparently, makes people want to stick around.

Last month I stood in front of my engineering team and told them that the cross-platform build we’d spent weeks perfecting, the one that output our Qt application for Windows, macOS Intel, macOS ARM, Linux x86-64, and Linux ARM64 from a single CI pipeline, was being reduced to Linux x86-64 only.

They looked at me like I’d lost my mind. And honestly, from a pure engineering perspective, I had. We’d done the hard work. The CI was beautiful. The whole team could demo from their own machines. Product could show it on their MacBooks. The CEO could run it on his Windows laptop. It was one of those rare engineering achievements where everything just worked.