Docker on houdeshell.dev

Software that I

Mon, 01 Jun 2026 00:00:00 +0000

I bounce between Mac, Windows, and Linux daily. Honestly, the tools matter more than the OS at this point. Great software is great software, and I’ve been lucky enough to build a career on top of things other people built well.

This is the stuff I actually reach for. Not a “best of” list, not sponsored, not comprehensive. Just software that makes me better at what I do. Or at least makes the work more fun.

Software Development #

IDE

JetBrains Rider #

Cross-platform .NET IDE. Fast, smart, and doesn’t need Visual Studio’s weight to get the job done.

IDE

Visual Studio #

The OG. Heavy, but when you need the full .NET debugging experience, nothing else comes close.

editor

VS Code #

Extension ecosystem is unmatched. Somehow Electron done right.

editor

Neovim #

Vim reborn. Lua config, LSP native, and a plugin ecosystem that won’t quit. :wq is a lifestyle.

version control

Git #

The version control system that won. Love it or hate it, you can’t ship without it.

version control

lazygit #

Terminal UI for git that makes interactive rebases feel like cheating.

JSON

jq #

sed for JSON. Once you learn the syntax, you’ll pipe everything through it.

database

JetBrains DataGrip #

SQL IDE that actually understands your schema. Autocomplete that works across joins.

database

DBeaver #

Universal database tool that actually works. Connect to anything, query everything.

database

SSMS #

Microsoft SQL Management Studio. If you’re in SQL Server land, you already know.

database

PostgreSQL #

The database that keeps getting better. Extensions, JSON support, and rock-solid reliability.

containers

Docker #

“Works on my machine” became “works on every machine.” Changed how we ship software.

AI #

agent

Claude Code #

AI pair programmer in your terminal. It’s writing this page right now.

agent

VS Code Agents #

Native agent mode inside the editor. Let the assistant plan, edit files, and run commands without leaving VS Code or babysitting a separate CLI.

agent

Codex #

OpenAI’s open-source coding agent. Terminal-native, sandboxed by default, and you can swap the model behind it whenever.

platform

Azure AI Foundry #

Microsoft’s AI app stack. Build agents, point them at your data, ship them on Azure. The enterprise wrapper for everything you’d otherwise glue together yourself.

Infrastructure #

orchestration

Kubernetes #

Container orchestration that makes you mass produce YAML for a living.

orchestration

K3s #

All of Kubernetes in a single binary. Perfect for homelab, edge, and production deployments.

IaC

Terraform / OpenTofu #

Infrastructure as code. OpenTofu if you prefer the open-source fork without the license drama.

networking

Tailscale #

WireGuard-based mesh VPN that just works. Connect everything without opening a single port.

observability

Grafana #

Dashboards for everything. Pairs with Prometheus, Loki, and Tempo for the whole observability stack.

Kubernetes

k9s #

Terminal UI for Kubernetes. Makes cluster management feel like a video game. Way faster than raw kubectl.

Kubernetes

Lens #

The Kubernetes IDE. When you want to point and click your way through a cluster without shame.

it's complicated

Cloudflare #

You love them. You hate them. Your DNS is already there. Their edge network is everywhere, their pricing is unbeatable, and their product sprawl is terrifying. Stockholm syndrome as a service.

Shell & Terminal #

shell

Bash #

The shell that’s been there since before you were born. Simple, portable, everywhere.

shell

Zsh #

Bash’s cooler sibling. Tab completion, globbing, and plugin support that actually makes the terminal enjoyable.

prompt

Starship #

Cross-shell prompt written in Rust. Fast, pretty, and infinitely configurable.

multiplexer

tmux #

Terminal multiplexer. SSH into a box, detach, come back tomorrow. Your session is still there.

coreutils

eza #

Modern replacement for ls. Colors, git status, and tree view out of the box. Written in Rust, obviously.

Utilities / Apps #

macOS

AltTab #

Why does macOS think a minimized window is an inactive window and not let you switch to it? This fixes that.

About

Sat, 11 Apr 2026 00:00:00 +0000

// bit herder. pointer wrecker. yaml apologist.

I’m a bit herder, a pointer wrecker, and HTTP is my best friend. 0xA3 & 0x7C are also my friends, but not 0x08.

I spend my days somewhere between writing code and making sure other people can write better code. I love distributed systems, low-level embedded devices, and anything that has a content-type. I also have an unhealthy relationship with YAML, but that’s a Kubernetes problem.

The day job #

During the day, I lead engineering and operations at EnergyCAP, a SaaS platform that helps organizations track utility spend, energy consumption, and sustainability goals across massive building portfolios. We’re talking $100B+ in utility bill spend tracked across 350,000+ sites. Government, education, healthcare, commercial real estate. If it has a meter, we probably manage it.

I started here as a developer in 2009 and have been building ever since: through senior roles, into leadership, and eventually into the VP seat where I get to shape both the tech and the teams behind it. Some days that means architecture decisions. Most days it means removing blockers so smart people can do their best work. And yes, sometimes it’s just meetings about meetings.

My philosophy is simple: technology should serve people. Build teams where people feel safe to be wrong, give them the tools to be great, and get out of the way.

Things I geek out about #

Distributed systems, container orchestration, database performance tuning, developer tooling, process dumps, leadership that doesn’t suck, making engineers’ lives better, and the eternal quest for a perfect terminal setup.

I also talk at things #

I like getting on stage and nerding out about the things I’ve learned the hard way. My talks tend to fall into a few buckets, and yes, I have strong opinions about all of them.

AI & the developer experience #

The AI wave hit and I leaned in. I’ve talked about using LLMs as debugging partners, building RAG pipelines that actually know your business context, and the ethical lines we should be drawing as we hand more work to machines.

My Rubber Duck is a Large Language Model
Unleashing the Power of the AI Wizards: Retrieval-Augmented Generation Spells

Kubernetes & cloud native #

I was late to the Kubernetes party, and I’ll tell you all about it. From lightweight K3s workshops to navigating the 900+ services in the CNCF landscape, to making the case that cloud-native principles work even when you’re not in the cloud.

Kubernetes Chronicles: Late to the Party, Big on Adventure!
K3s: Half the Size, Twice as Awesome (workshop)
Orchestrating Machine Learning Workloads with Kubernetes
Exploring the Cloud Native Landscape
Cloud Native is Only for the Cloud, Right?
Nomad: Orchestration Doesn't Start with a K

Performance & databases #

I’ve spent an unreasonable amount of time staring at query plans. These talks cover squeezing performance out of SQL Server, using DMVs like cheat codes, and that one time we took a 10-hour process down to 10 minutes.

ReArchitecting Data: 10 Hours to 10 Minutes
Mastering SQL Server Performance Optimization (workshop)
SQL Server DMVs That Give Me Superpowers
Achieving Continuous High Performance with Query Store
Practical High Performance: C# Edition
Intrinsics in .NET: Start Somewhere

Production war stories & leadership #

Production breaks. Systems fail. The interesting part is what you do next. I also talk about the human side: what I’ve learned (and gotten wrong) leading engineering teams.

Bug Squashing with Process Dumps
Recovery by Design: A Postmortem Adventure
Joining the Cloud: Our Journey
TIL as a CTO

The wildcard #

Sometimes you just want to build something fun with your hands.

Paper Circuits: Origami for a New Generation

Let’s talk #

I drink a bit too much coffee while rambling on about technology. If you’re willing to have a conversation, I’m ready to buy you a cup.

email: chris@houdeshell.dev
github: choudeshell
linkedin: choudeshell
bluesky: @choudeshell.bsky.social

Now

Mon, 01 Jun 2026 00:00:00 +0000

Focus #

AI at /\$DAYJOB/. Production agents on real customer data. Compliance edges, evals, on-call playbooks.
Upgrading Azure infrastructure. Modernizing the stack we run customer workloads on.

Thinking #

AI. Where it pays off and where it just adds latency.
Team. Shape, growth, what each person’s pulling toward.
The price of the cloud. Watching cluster spend while AI workloads scale up unpredictably.

Reading #

TODO — drop in current books, longreads, or RSS finds here. The shelf changes monthly.

Running Ubuntu on Apple's Container

Fri, 12 Jun 2026 14:00:00 -0400

After getting Apple’s container running, the thing I actually wanted was a normal Ubuntu box to poke around in. That took one more step than I expected: systemd.

A container runs whatever its CMD is as PID 1. The stock ubuntu:26.04 image doesn’t ship an init, so you boot into a bare shell and not much else. If you want services, units, and a machine that behaves like a real Ubuntu install, systemd has to be the thing running as init. So you build your own image.

Here’s the Dockerfile. Most of it is the well-worn systemd-in-a-container cleanup: install systemd, then delete the units that make no sense inside a container so it doesn’t sit there trying to start hardware that isn’t there.

dockerfileFROM ubuntu:26.04

ENV container container

RUN apt update -y && apt upgrade -y && apt install -y systemd init
RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == \
systemd-tmpfiles-setup.service ] || rm -f $i; done); \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;

VOLUME [ "/sys/fs/cgroup" ]
CMD ["/usr/sbin/init"]

Build it, create a machine from it, and run:

❯ container build -t local/devel -f devel.dockerfile
[+] Building 356.1s (7/7) FINISHED
 => [resolver] fetching image docker.io/library/ubuntu:26.04
 => [internal] load build definition from Dockerfile
 => [linux/arm64 1/3] RUN apt update -y && apt upgrade -y && apt install -y systemd init
 => [linux/arm64 2/3] RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do ... )
 => exporting to oci image format
local/devel:latest

❯ container machine create --name devel --set-default local/devel
devel

❯ container machine run
chris.houdeshell@devel:/Users/chris.houdeshell$

That last line is the Ubuntu shell. You’re in.

What the flags are doing, quickly:

container build -t local/devel -f devel.dockerfile: -t tags the image as local/devel; -f points at the Dockerfile by name, since I didn’t name it Dockerfile.
container machine create --name devel --set-default local/devel: builds a VM named devel from that image. --set-default makes it the machine everything else targets, so I don’t have to spell out the name on every command.
container machine run: boots the default machine and drops me into its shell.

One thing worth knowing: that build ran just shy of six minutes. The tool is young and the build path isn’t quick yet, so don’t assume it hung.

Apple's Container Tool

Fri, 12 Jun 2026 10:00:00 -0400

Apple has a CLI for running Linux containers on macOS now. It’s called container, and the part I care about is that it doesn’t need Docker Desktop.

The design choice that makes it interesting: there’s no single shared Linux VM that every container piles into. Each container gets its own lightweight VM. So you get real isolation for free, boots are quick, and it all sits on top of Apple’s Containerization Swift package. Images are plain OCI, so the registries and the pull/build/push workflow you already know carry over. The requirements are stricter than I’d like, though: Apple silicon, macOS 26 or newer.

You install it from a signed package on the releases page, then start the background service. The service is where I tripped.

Run anything before it’s up and you get this:

❯ container machine create --name dev --set-default fedora:latest
Error: interrupted: "XPC connection error: Connection invalid"
Ensure container system service has been started with `container system start`.

❯ container system start
Launching container-apiserver...
Testing access to container-apiserver...
Verifying machine API server is running...
No default kernel configured.
Install the recommended default kernel from [https://github.com/kata-containers/kata-containers/releases/download/3.28.0/kata-static-3.28.0-arm64.tar.zst]? [Y/n]: y
Installing kernel...

XPC connection error: Connection invalid is not a bug. The system service just isn’t running. Start it with container system start, say yes to the default kernel, and you’re good.

Docker Desktop on a Mac has always felt like more machinery than I needed. This is lighter. Give it a spin.

A Single Border and a Better Radius

Wed, 10 Jun 2026 10:00:00 -0400

I read the release notes. I just opened a Finder window and it feels better, and it took me a second to figure out why.

It’s two things. There’s now a single vertical border between the sidebar and the content pane, so the two regions actually feel like two regions instead of one dark expanse where the divider was only implied by a shift in shade. And the inner corners got a slightly larger, more consistent radius that lines up with the outer window. That’s it. No new feature, nothing to learn.

The smallest possible line in the right place does more than any amount of gradient or shadow. One border to say “this is a boundary,” one radius to make the corners agree with each other, and the window stops feeling vague.

Good detail work is invisible until you go back to the old version and feel how much you weren’t seeing.

You're the Typist

Wed, 27 May 2026 10:00:00 -0400

There’s a question I ask engineers when they hand me an AI generated PR: “walk me through what this does.”

If they can, the PR is usually fine. If they can’t, the PR is almost always broken. Not visibly broken. Not the kind of broken that fails a test. The kind of broken that ships, sits in production for six months, and then takes down a service at 2am because nobody knew the cache invalidation only ran on the leader.

AI doesn’t fix that. AI makes it worse.

AI is a multiplier. It multiplies whatever you bring to it. If you understand the problem, AI gets you to a working solution faster than any tool we’ve ever had. If you don’t, it gets you to something that looks like a working solution faster than any tool we’ve ever had. Those are very different things, and the difference doesn’t show up until later.

The engineers I see thriving with AI right now read every line. They push back when the model takes a shortcut they don’t like. They ask “why” three times. They notice when the generated code uses a pattern they’ve never seen, and they stop to learn it before they accept it. AI doubles their throughput because they were already good. It also doubles their learning rate, because every prompt is a chance to see how an experienced engineer (which is what the model is impersonating) would have approached the same problem.

The engineers I see drowning treat the model like an oracle. They accept the diff. They run the tests. The tests pass, so they ship. They have no mental model of what they just merged. Six months in, they’ve shipped a hundred PRs and learned nothing. The codebase has grown faster than their understanding of it, and the gap is widening.

Here’s the test I’d give anyone using AI heavily. Pick a PR from last week. Open it without the model. Explain every block out loud. Why this data structure? Why this error path? What happens if this call times out? What does this loop do on the empty case? If you can’t answer those questions about your own merged code, AI isn’t helping you. It’s helping the model, and you’re the typist.

This isn’t just an engineering problem. Engineering managers and product managers fall into the same trap, one rung up. If you used AI to write a JIRA ticket and you can’t explain it five minutes later, your problem is different than you think. The ticket isn’t the artifact. The thinking behind the ticket is. If the model did the thinking and you hit save, you’ve handed your team a task that nobody on your side actually owns. The first time an engineer pushes back with a real question, the whole thing falls apart, and the engineer figures out fast that there’s no one home behind the requirements.

Use AI. Lean into it. Just don’t outsource the part of the job that was ever actually yours.

KQL Reads Like a Sentence

Sat, 23 May 2026 10:00:00 -0400

Watch a smart, curious person try to learn SQL. They get through SELECT * FROM x WHERE y and they’re fine. Then they hit JOIN, or GROUP BY, or a correlated subquery, and the floor opens up. Most never come back.

KQL is the opposite. It reads left to right, the way the human brain wants to think about data.

kustoPageViews
| where TimeGenerated > ago(7d)
| where ClientCountryOrRegion == "United States"
| summarize count() by bin(TimeGenerated, 1d), Page
| top 10 by count_

Read it out loud. “Take page views, where time is in the last seven days, where the country is the US, summarize by day and page, give me the top ten.” That sentence is the query. Nothing is hidden, nothing is out of order.

The verbs are English. where. summarize. project. extend. take. top. There’s no CROSS APPLY lurking three chapters in.

You can do useful work on day one without ever learning a join. That matters more than engineers remember. Every join is a cliff for a non-engineer, and SQL puts that cliff in front of trivial questions. KQL puts the cliff somewhere on chapter five.

Add to that:

Sane defaults — take 100 to peek, results are always tabular
Time-series operators baked in — ago, bin, series_decompose
Autocomplete that actually understands your schema
A query pane that gives you instant feedback the moment you stop typing

KQL isn’t the right tool for everything. I’d never reach for it to build a transactional system. But for letting smart, curious people answer their own questions about their own data, I haven’t seen anything better.

Take all that with a grain of salt — I wrote a KQL-to-SQL parser and generator, so I’m clearly not sure what any of this means.

Inverse AI Consulting

Fri, 15 May 2026 15:00:00 -0400

Mitchell Hashimoto wrote a post on X that I haven’t stopped thinking about.

It’s frightening, because the psychosis folks operate under an almost absolute “MTTR is all you need” mentality: “its fine to ship bugs because the agents will fix them so quickly and at a scale humans can’t do!” We learned in infrastructure that MTTR is great but you can’t yeet resilient systems entirely.

I love AI. I lean into it harder than most people I work with and know. Engineering is genuinely better because of AI. Daily and categorically.

Purely AI written systems will scale to a point of complexity no human can ever understand. For a while it looks fine. Defects close, bug reports trend down, dashboards stay green. Then the defect close rate tapers. Token burn per defect climbs. Eventually, AI changes cause on average more defects than they close, and the whole system becomes unstable. The decay.

AI amplifies good thinking. AI amplifies good engineering. AI also amplifies bad thinking and bad engineering.

When that happens, I expect a new type of consulting to emerge. Call it Inverse AI. An involution. The same specialists who get called for an active breach, or when production data is gone and the backups failed. People who walk into a doomed AI generated codebase, distill out the core design principles nobody bothered to write down, and rebuild from scratch with good thinking and good engineering – using AI.

This time with with humans in the seat where it counts.

The decay isn’t a reason to be against AI. It’s a reason to be honest about what comes next.

How I Run 1:1s

Tue, 05 May 2026 09:00:00 -0400

I’ve been running 1:1s for years and I still get them wrong. The version of “wrong” has changed. Early on, my 1:1s were status meetings with the lights off. Manager asks what you’re working on. Engineer recites their pile. Manager says “anything blocking you?”. Engineer says no, even when they mean yes. Forty-five minutes evaporate.

That isn’t a 1:1. It’s a standup with a longer time slot.

I figured out it was wrong because of one engineer. Smart, quiet, on a team I’d inherited. We’d had eight or nine “great” 1:1s in a row. He left to go work somewhere else and on his way out told me, in different words, that he didn’t think I knew anything about him. He was right. I knew what he was working on, what his blockers were, what he’d shipped that quarter. I didn’t know what he wanted out of his career, what he was sick of, what his last manager had broken in him that I was busy perpetuating. Everything I knew about him was project-shaped.

That cost me an engineer, and it cost me about three months of figuring out how to run these meetings differently.

The frame #

This is your meeting. You set the agenda. If you want to talk through a tricky design problem, talk it through. If you want to vent about a teammate, vent. If you want to plan the next two years of your career, plan. If you want to talk about your kid’s soccer team, fine. I have a notes doc I never make you open.

I do bring things. Three or four every week. Coaching I want to give, feedback I owe, context you’d want, a decision I want your read on. Mine goes after yours. If we run out of time and I never got to my list, that’s okay. My list keeps. Yours might not.

One question that does most of the work #

I used to have a list. Three questions, same every week, the kind of thing that lands in a leadership newsletter. They worked, mostly. They also made me predictable, which made the answers predictable.

Now I mostly ask one thing and let it breathe:

“What’s draining you right now?”

The honest answer is rarely the project. It’s a person, a process, or something they don’t want to admit they’re avoiding. Half the time the first answer is “nothing, I’m good,” and then five minutes later something real comes out because the question planted a seed. Naming the drain doesn’t fix it. It just lets us start.

If they bring me energy instead, fine. I roll with it. The point of the question is to give them permission to say something they probably haven’t said out loud yet.

What I stopped doing #

I’d love to write you a clean bullet list of antipatterns. The truth is messier, and most of them are mistakes I made before I learned to stop.

I used to ask for a status update at the top of every 1:1. I told myself I was “checking in.” I was filling silence. Now if I’m asking what they shipped, it’s because I genuinely don’t know, which means I’m not paying attention to the team. JIRA exists. Standups exist. The 1:1 isn’t where that goes.

I used to ambush. The “by the way, we’re concerned about your output” drop, slipped into a 1:1 because I didn’t have the spine to schedule it as its own meeting. Every time I did it, I blew up trust for a quarter. Performance feedback gets its own slot, its own framing, its own heads-up. Not a sneak attack between “how was your weekend” and “what’s on your mind?”.

I used to solve for them. They’d bring me a problem and I’d hand them the answer thirty seconds later because it felt helpful and made me feel useful. It made them dependent. “What would you do?” is the better question, even when I already know what I’d do. Especially then.

Cadence #

Weekly, 30 minutes, on the calendar. Not “ad-hoc when we both have time.” Ad-hoc never happens. Ad-hoc is what people say when they don’t actually want the meeting.

I cancel mine more than I’d like. Sprint demo collides, customer call drops in, an outage at 2am. I always reschedule. I never delete. The person sees that a 1:1 with me is a slot that survives the rest of the calendar. That matters more than they’ll ever tell me.

Skip one, fine. Skip two in a row, that’s a signal you’re sending whether you mean to or not. Skip three and you’ve made the problem for yourself.

The unsexy part #

Nobody puts this on a leadership thread because it doesn’t tweet well. The actual work of 1:1s is being there, in this meeting, every week, for years. Not the clever question. Not the great coaching moment that lives rent-free in their head five years later, though those happen and you’ll remember them. The week-after-week of showing up, paying attention, and remembering the things they told you last month so you can ask about them this month.

Most of it is just that. Show up. Pay attention. Remember.

The engineer who left taught me one more thing on his way out, without meaning to. He’d told me about his daughter’s blights in passing about six weeks earlier, and I never asked about it again. Not because I didn’t care. Because I forgot, and he noticed.

I write things down now.