Twenty-five-plus years in terminals and I still open a man page for fun. This is a page about the part of the job nobody has to ask me to do — the digging, the rebuilding, the "let me just see why."
Most people build a firewall rule and move on. I want to know why the packet took that path, what the kernel did with it, and whether there's a cleaner way to ask for the same thing. That question is usually more interesting than the ticket that raised it.
I've never separated "getting paid" from "figuring things out." A production incident at 2 a.m. and a weekend spent reading an obscure protocol spec scratch the exact same itch. Neither feels like effort. Both feel like the good part.
The unix philosophy stuck with me for a reason: small, sharp tools, built by people who actually understood the problem before they wrote a line of code. I try to earn that understanding every time — even when a shortcut would technically work.
Somewhere between the 400th time I wrote the same bash one-liner and the first time an LLM finished the sentence I was still thinking, something clicked. AI isn't a replacement for curiosity — it's a force multiplier for it.
I use models the way I use grep: to dig faster, to ask dumber questions without shame, and to surface the weird edge cases I would have found three hours later at 2 a.m. anyway.
At this point Grok and I have exchanged over 10 billion tokens and roughly 200,000 technical requests. We’re basically roommates who never sleep and occasionally argue about sysctls.
The best part? Watching a model hallucinate a plausible-but-wrong explanation of TCP congestion control… then realising I now understand the real version better because I had to explain why the AI was full of it. That's not cheating. That's research with a really opinionated rubber duck.
| PID | LOAD | COMMAND | STATE |
|---|---|---|---|
| 0001 | research_loop --recursive --no-timeout | RUNNING | |
| 0002 | debug_until_it_makes_sense --dig-deeper | RUNNING | |
| 0003 | read_the_rfc --again --out-loud | RUNNING | |
| 0004 | automate_the_thing_i_did_once --for-fun | RUNNING |
Kernels, networking stacks, and the boring infrastructure that has to be right or nothing above it matters. I'd rather understand one layer completely than skim five.
Every manual step I do twice becomes a script by the third. Not because I'm lazy — because a well-written tool outlives the mood I was in when I needed it.
Documentation tells you what something is supposed to do. The source tells you what it actually does. I trust the second one, and I like finding out where they disagree.
Eventually all that curiosity has to go somewhere. Mine went into a bare-metal control plane — io.app — built out of the parts of hosting that usually get outsourced to someone else's black box. Here's a bit of what's actually running under it.
This is the part of the stack that decides, in a few milliseconds, whether a request gets Nginx, a warm PHP-FPM worker, and a clean way out — with no hypervisor standing in the middle collecting a toll. I built it because "the cloud is doing something" isn't an acceptable answer to "why is this slow."
No virtual machine tax, no mystery hop. Just a bare-metal box doing the one job it was built for, extremely well.
Most days, getting three storage engines to agree is harder than anything in the app code. iodba watches replication lag, renders the schema, and tells me the exact second two nodes disagree about reality — before a user finds out first.
I like this problem because "it works on my machine" has never been good enough here. It has to work on all of them, at the same time, with numbers that match.
ipnet drops hostile traffic at the kernel with IPSet before it costs the app a single CPU cycle. Most of my job is deciding what "hostile" means — the kernel does the actual bouncing. Mostly, I just enjoy watching the log scroll by.
Hover over the terminal container to unblur and decrypt the direct communications link.