There was one snag: signed commits.

I sign all my commits, and my signing keys live in the Secure Enclave via Secretive. That’s great for security. The key physically cannot leave the machine. It’s less great when git asks the Secure Enclave to sign a commit and the Secure Enclave asks for a Touch ID press from a person who is forty miles away from the keyboard.

This post walks through the setup I landed on. I can be on my iPad or the cheap laptop, remote into the main Mac, and every commit gets signed by a hardware-backed key. Even commits made by a Claude Code session that’s been running since morning. The approval prompt shows up on the device in my hands.

Why Secretive Instead of a Key File?

The traditional approach stores your SSH private key in a file like ~/.ssh/id_ed25519. The problem is that it’s a file. Any process running as you can read it. A malicious npm package can quietly copy it. So can a compromised build script or a sloppy backup. Once it’s copied, it’s gone, and you won’t even know. A passphrase helps less than you’d think because the decrypted key sits in ssh-agent’s memory anyway. Besides, you type that passphrase into enough prompts that you eventually stop looking at them.

Secretive generates keys inside the Secure Enclave, the same hardware chip that guards Touch ID and Apple Pay. The private key never exists on disk or in process memory, and there’s no export button, even for you. When something wants a signature, it has to ask the enclave, and the enclave asks you for Touch ID or Apple Watch approval first. The enclave trusts nobody, which I respect.

That changes the threat model. Malware can’t steal a key it can’t read, so the worst it can do is trigger a Touch ID prompt I wasn’t expecting, which is its own alarm bell. If I lose the laptop, its not a big deal as the key is still sealed inside it. Revoking a key for a laptop I sold only requires that I delete a line from allowed_signers, not a fire drill.

The tradeoff, of course, is that the key can’t leave the machine even when I have a good reason to want it to. Which brings us back to my problem.

The Setup

Each of my Macs has its own Secretive key. Git signs with SSH keys these days (no GPG ceremony required), so the base config is small:

[user]
    localSigningKey = ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys/<hash>.pub
[gpg]
    format = ssh
[gpg "ssh"]
    program = /usr/bin/ssh-keygen
    allowedSignersFile = ~/.dotfiles/git/allowed_signers
[commit]
    gpgsign = true

The allowed_signers file maps my email addresses to every machine’s public key, so any machine can verify commits signed by any other:

haacked@gmail.com ecdsa-sha2-nistp256 AAAA… GitHub-Commit-Signing@secretive.HaackBook-Pro.local
phil.h@posthog.com ecdsa-sha2-nistp256 AAAA… GitHub-Commit-Signing@secretive.HaackBook-Pro.local
haacked@gmail.com ecdsa-sha2-nistp256 AAAA… GitHub-Signing-Key@secretive.Phils-MacBook-Pro.local
…

Each public key is also registered on GitHub as a signing key, so GitHub shows the Verified badge no matter which machine did the signing.

So far, so standard. Sitting at any one of these machines, git commit triggers a Touch ID prompt (or on my MacBook Neo, which lacks Touch ID, a double-click on my Apple Watch) and produces a signed commit. The interesting part is what happens when nobody is sitting at the machine.

The Problem with Being Remote

When I remote into the main Mac, there are two ways in, and both break signing in their own way.

Screen sharing (Jump Desktop): I’m looking at the Mac’s actual desktop, driving its actual shells. When git commits, it asks the Mac’s local Secretive for a signature, and Secretive pops a Touch ID prompt on a laptop sitting alone at a desk in a room I’m not in, its screen long asleep. My iPad can show me the prompt. It can’t press a fingerprint through the glass, no matter how hard I tap it.

SSH: SSH has agent forwarding, which is almost the answer. With ForwardAgent yes, my client device’s SSH agent (Secretive on the cheap MacBook, Blink’s Secure Enclave keys on the iPad) becomes reachable on the main Mac through a socket that sshd creates. Signature requests travel back over the SSH connection to the device in my hands, which is exactly what I want.

But naive agent forwarding has three gaps:

1. The socket dies with the session. sshd puts it at a random path, exports it as SSH_AUTH_SOCK in that one session, and deletes it when the connection drops. Every other shell on the machine has no idea it exists.
2. Long-lived processes never see it. A Claude Code session started this morning inherited whatever SSH_AUTH_SOCK existed this morning. It’s not going to re-read my zshrc because I SSHed in after lunch. Neither is the shell inside the Jump Desktop screen share.
3. Git needs to know which key to ask for. SSH signing requires the specific public key up front. When I’m remote, the right key is the client device’s key, not the Mac’s. A key baked into git config is wrong half the time.

I went looking for a way to remotely approve the Mac’s own Secretive prompts. There isn’t one. Secretive’s approval is deliberately local-only, which is kind of the whole point of it. So instead of trying to weaken the Mac’s key, I stopped using the Mac’s key when I’m not at the Mac and started signing with the key of the device I’m actually touching.

One Symlink, Zero Cached State

The whole system comes down to two decisions:

1. There is exactly one stable agent path on the machine: ~/.ssh/agent.sock, a symlink. Shells, GUI apps, and git all point at the symlink, and the symlink points at whichever real agent socket is currently alive.
2. Git figures out the signing key at the moment of signing, not ahead of time, so there’s no cached key file to go stale.

Everything else is plumbing to keep those two things true. All of it lives in my dotfiles.

The Symlink Healer

A small script, bin/ssh-agent-sync, decides where the symlink points. Handed a live forwarded socket, it points the symlink there. Otherwise, if the symlink is dangling, it heals back to the local Secretive socket:

sock="$HOME/.ssh/agent.sock"
secretive="$HOME/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/socket.ssh"
forwarded="${1:-}"

if [[ -n "$forwarded" && -S "$forwarded" ]]; then
  [[ "$sock" -ef "$forwarded" ]] || ln -sf "$forwarded" "$sock"
elif [[ ! -S "$sock" ]] && [[ -S "$secretive" ]]; then
  ln -sf "$secretive" "$sock"
fi

if [[ -S "$sock" ]] && [[ "$sock" -ef "$secretive" ]]; then
  echo "local"
elif [[ -S "$sock" ]]; then
  echo "forwarded"
else
  echo "none"
fi

It’s idempotent. It only touches the symlink when the symlink is wrong, and it reports which mode it resolved to (local, forwarded, or none) so callers don’t have to figure that out themselves.

The Shell Hook

My zshrc captures the forwarded socket and keeps the symlink synced. The subtle bits are when it captures and how often it syncs:

# Capture the sshd-provided socket once, at startup, before the first
# sync overwrites SSH_AUTH_SOCK with the symlink path.
[[ -n "$SSH_CONNECTION" ]] && _SSH_FWD_SOCK="$SSH_AUTH_SOCK"

_ssh_agent_sync() {
  "$HOME/.dotfiles/bin/ssh-agent-sync" "$_SSH_FWD_SOCK" >/dev/null
  [[ -S "$HOME/.ssh/agent.sock" ]] && export SSH_AUTH_SOCK="$HOME/.ssh/agent.sock"
}
_ssh_agent_sync
autoload -Uz add-zsh-hook
add-zsh-hook precmd _ssh_agent_sync

The forwarded socket path has to be captured before the first sync. After that, SSH_AUTH_SOCK is the symlink, and re-deriving the forwarded socket from it would just compare the symlink against itself.

It also re-syncs on every precmd, not just at shell startup. The symlink is shared machine-wide, and a local shell that was running before my SSH session started will never source zshrc again when that session ends. Without the recheck, that shell would keep pointing at a forwarding socket sshd already tore down. Since the healer is idempotent, idle prompts don’t pay for a redundant ln.

Every shell exports the symlink, never the raw socket. That’s the indirection that makes long-lived sessions work. A Claude Code session started hours ago holds a path that never changes, even though what’s on the other end of it comes and goes.

Resolving the Key at Sign Time

Here’s where localSigningKey pays off. Git has an escape hatch: if user.signingkey is unset, git runs gpg.ssh.defaultKeyCommand to ask which key to use, fresh, on every signature:

[gpg "ssh"]
    defaultKeyCommand = ~/.dotfiles/bin/git-signing-key

bin/git-signing-key re-runs the healer, then answers based on what the symlink currently points to:

mode=$("$bin_dir/ssh-agent-sync") || mode="none"

if [[ "$mode" == "forwarded" ]]; then
  forwarded_key=$(SSH_AUTH_SOCK="$sock" ssh-add -L 2>/dev/null | head -1) || true
  if [[ "$forwarded_key" == ssh-* || "$forwarded_key" == ecdsa-* || "$forwarded_key" == sk-* ]]; then
    printf 'key::%s\n' "$forwarded_key"
    exit 0
  fi
fi

local_signing_key=$(git config --global --includes --get user.localSigningKey 2>/dev/null) || local_signing_key=""
if [[ -n "$local_signing_key" && -f "$local_signing_key" ]]; then
  printf 'key::%s\n' "$(cat "$local_signing_key")"
  exit 0
fi

If a forwarded agent is live, sign with whatever key it offers. That’s the client device’s Secure Enclave key. Otherwise, fall back to this machine’s own Secretive key via user.localSigningKey. Whichever agent is alive when git signs is the one that gets asked.

An earlier version of this setup cached the resolved key in a file that shell hooks kept up to date. That had a hole in it. Anything that signed without a shell prompt having been drawn since the last agent change (a background agent session, a GUI git client) would sign with a stale key or fail. Deleting the cache and resolving at use time made that whole category of bugs go away.

GUI Apps

One LaunchAgent seeds the environment for everything that never sources zshrc:

<key>ProgramArguments</key>
<array>
    <string>/bin/sh</string>
    <string>-c</string>
    <string>"$HOME/.dotfiles/bin/ssh-agent-sync" >/dev/null && /bin/launchctl setenv SSH_AUTH_SOCK "$HOME/.ssh/agent.sock"</string>
</array>
<key>RunAtLoad</key>
<true/>

launchctl setenv makes SSH_AUTH_SOCK visible to GUI apps. And because it’s set to the symlink rather than a raw socket, those apps track agent transitions too, without ever knowing transitions happen.

The SSH Client Side

The last piece is the client config, which is refreshingly boring:

Host phils-macbook-pro macbook
    HostName 100.x.y.z
    ForwardAgent yes

Host *
    IdentityAgent "~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/socket.ssh"

The IP is a Tailscale address, so ssh macbook works from anywhere without exposing sshd to the internet. ForwardAgent yes does the forwarding. IdentityAgent points outbound SSH at Secretive, so authenticating to the Mac is enclave-backed too. On the iPad, Blink Shell does the equivalent with its own Secure Enclave keys.

What It Looks Like in Practice

From the iPad or the cheap MacBook: ssh macbook. Tmux auto-attaches to my persistent session, and from that moment the entire machine signs through the device in my hands. The SSH session, sure. But also the Jump Desktop screen share I have open next to it, and the Claude Code session that’s been grinding away since breakfast. They all hold the same symlink, and the symlink now points at the forwarded agent.

When any of them commits, the approval prompt appears right here. A double-click on my Apple Watch for the MacBook Neo. Face ID via Blink on the iPad. The commit gets signed with this device’s key, which is a different key than the main Mac would use, but allowed_signers and GitHub know all my keys, so every commit verifies the same.

When I close the connection, the next shell prompt on the Mac notices the dead socket and heals the symlink back to local Secretive. I sit down at the desk and Touch ID works like nothing happened. There’s no remote mode to toggle, just a symlink that points at whatever agent is currently real.

How It Bit Me

Not long after I drafted this post, signing started failing on me. Sometimes the approval prompt showed up on the device in my hands like it should. Other times git would sit there waiting on an approval that never came, because the Touch ID prompt was on the Mac’s screen in a room I wasn’t in.

The culprit was me.

At some point I had typed ssh macbook inside a tmux pane that was already on the main Mac. Every tmux pane looks exactly like every other tmux pane, and I thought I was on the other laptop. Reader, I was not. So the Mac ssh’d into itself, forwarded its own Secretive agent back to itself, and the shell hook in that nested session adopted the looped socket as if it were a genuine forwarded agent. From then on, the machine believed it was remote. My Mac was having an out-of-body experience, and my commits were paying for it. Every signature request went out through the “forwarded” socket and arrived right back at the local Secretive, which wanted a Touch ID press at a desk nobody was sitting at. Meanwhile my actual remote session held a perfectly good forwarded agent that nothing was using.

The fix has two parts, both in the dotfiles now. The SSH config disables agent forwarding when the destination is the machine you’re already on. And ssh-agent-sync compares a new forwarded socket’s key list against the local Secretive’s before adopting it. An exact match means it’s a loop, and the script treats it as local.

Caveats

Agent forwarding is a trust decision. A forwarded agent means anyone with root on the host can send signature requests to your client’s agent. Forwarding into a box you don’t control is how people get their keys borrowed. I’m forwarding into my own Mac over my own tailnet, and every request still requires biometric approval on the client, so I sleep fine. I wouldn’t ForwardAgent yes to a shared server.

Pure screen share can’t sign unattended. If there’s no live SSH connection, the symlink points at the Mac’s local Secretive, and that still wants a human at the machine. Usually the fix is one ssh macbook from whatever device I’m holding. For the rare case where even that’s not an option, I commit with --no-gpg-sign and batch re-sign later:

[alias]
    sign-unpushed = "!f() { DEFAULT=$(git default); UPSTREAM=${1-origin/$DEFAULT}; git rebase --exec \"git commit --amend --no-edit -S\" $UPSTREAM; }; f"

git sign-unpushed rebases the unpushed commits and re-signs each one. Back at the desk, it’s a satisfying little drumroll of Touch ID prompts.

Steal It

At no point in any of this does a private key exist as a file. Each device has its own key sealed in its own Secure Enclave, and every signature requires a biometric approval on a device I’m physically touching. If I lose a device, I revoke one key and move on.

And I didn’t give up anything to get here. Claude Code works on the big machine, I supervise from whatever screen is nearby, and commits come out signed and verified. The whole thing is two small scripts, a symlink, and one underappreciated git config setting. The symlink is doing most of the work, which feels right for a technology from 1983.

Everything is in my dotfiles repo: bin/ssh-agent-sync, bin/git-signing-key, the zshrc hook, and the LaunchAgent. That’s what dotfiles are for.

It turns out, we have some great tools now for dealing with tedious chores. In particular, I’ve set up two tools that turned merge conflicts from a dreaded chore into a minor speed bump. Most of the time, they resolve themselves before I even see them. For the ones that don’t, automation handles the tedious parts so I only deal with the genuinely ambiguous cases.

The Problem with Textual Merging

Git’s built-in merge is purely textual. It compares lines of text and looks for overlapping changes. It doesn’t understand your code. It doesn’t know what a function is, or an import statement, or a class definition. It just sees lines.

This means Git reports conflicts that aren’t actually conflicts. Two developers add different imports to the same file, near the same spot. Git sees overlapping line changes and panics:

<<<<<<< HEAD
import { useState } from 'react';
import { useQuery } from '@tanstack/react-query';
=======
import { useState } from 'react';
import { useEffect } from 'react';
>>>>>>> feature/dashboard

A human can see instantly that both changes are independent additions. One added useQuery, the other added useEffect. The correct resolution is to keep all three imports. But Git can’t see that because Git doesn’t understand syntax. It only sees text.

These false conflicts add up. On a large rebase, they can turn a five-minute task into a thirty-minute slog.

Layer 1: Mergiraf

Mergiraf is a structural merge driver for Git. Instead of comparing lines of text, it parses your files using language grammars and merges at the syntax tree level. If two changes touch different parts of the syntax tree, it merges them cleanly. If they genuinely conflict at the structural level, it falls back to standard conflict markers.

That import example above? Mergiraf resolves it automatically. It understands that those are independent additions to an import list and combines them.

Mergiraf supports over 25 languages: Java, Rust, Go, Python, JavaScript, TypeScript, C, C++, C#, Ruby, Elixir, PHP, Dart, Scala, Haskell, OCaml, Lua, Nix, YAML, TOML, HTML, XML, and more. For file types it doesn’t support, it returns a non-zero exit code and Git falls back to its default textual merge. No harm done.

Setup

Three steps.

1. Install mergiraf:

brew install mergiraf

2. Register the merge driver in your ~/.gitconfig:

[merge "mergiraf"]
    name = mergiraf
    driver = mergiraf merge --git %O %A %B -s %S -x %X -y %Y -p %P -l %L

3. Apply it globally in ~/.config/git/attributes:

* merge=mergiraf

The wildcard (*) tells Git to run every file through mergiraf. This might sound aggressive, but it’s fine. If mergiraf doesn’t recognize the file type, it steps aside and Git handles it normally.

Companion Settings

Two additional Git settings complement mergiraf nicely.

diff3 conflict style: By default, Git’s conflict markers only show your version and their version. With diff3, you also see the common ancestor (the “base”). This gives both mergiraf and humans more context to resolve conflicts correctly.

[merge]
    conflictStyle = diff3

Here’s the difference. Standard conflict markers:

<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature

With diff3:

<<<<<<< HEAD
const timeout = 5000;
||||||| base
const timeout = 3000;
=======
const timeout = 10000;
>>>>>>> feature

The base section tells you the original value was 3000. Now you can see that HEAD changed it to 5000 and the feature branch changed it to 10000. Without the base, you’re guessing.

rerere (reuse recorded resolution): Rerere records how you resolve conflicts and automatically replays those resolutions if the same conflict comes up again. This is useful during rebases where you might encounter the same conflict multiple times.

[rerere]
    enabled = true

Layer 2: Automating the Rest

Mergiraf handles the structural conflicts, but some conflicts are genuinely ambiguous. And some aren’t ambiguous at all, they’re just tedious. Lock files, database migrations, stacked PR duplicates. Each of these has a clear resolution strategy, but you still have to do the work manually.

This is drudgery. Drudgery that follows clear rules. Perfect for automation.

I built a Claude Code skill called /resolve-conflicts that handles the entire conflict resolution workflow. Type /resolve-conflicts and it takes over.

How It Works

The skill follows a three-step loop:

1. Detect context. It reads Git’s internal state files to determine whether you’re in a rebase, merge, cherry-pick, or revert, and how far along you are (e.g., step 3 of 12 in a rebase).

2. Categorize and resolve. It runs a categorization script on every conflicted file, sorting them into buckets: lock file, migration, mergiraf-supported, or other. Then it resolves each bucket with the appropriate strategy.

3. Continue. It regenerates any lock files, runs the appropriate continue command (git rebase --continue, git commit --no-edit, etc.), and loops back to step 1 if more conflicts appear.

Resolution Strategies

Each category gets its own treatment:

Lock files: Accept theirs to clear the conflict markers, then regenerate. The content of a lock file is derived from the dependency manifest, so there’s no point resolving individual lines. The skill runs the appropriate package manager (npm install, cargo generate-lockfile, poetry lock --no-update, etc.) to produce a correct lock file from the resolved manifest.

Migrations: Ask the human. Migration files represent sequential schema changes where order matters. Getting this wrong can break your database. The skill flags these and asks you how to proceed.

Mergiraf files: Run mergiraf as a second pass. Even though mergiraf already ran as a merge driver during the git operation, sometimes conflicts remain (partial resolutions, complex restructuring). The skill runs mergiraf solve on the file. If conflict markers remain after that, it falls through to AI analysis.

Everything else: Read the conflict, analyze both sides, and resolve it. This is where the skill earns its keep on the genuinely tricky ones.

Stacked PR Duplicate Detection

If you work with stacked PRs, you’ve probably hit this one. You have a feature branch with sub-PRs stacked on top of each other. You merge a sub-PR into main. Now when you rebase the parent branch, Git produces conflicts where both sides have nearly identical code and the base section is empty.

Here’s what that looks like with diff3:

<<<<<<< HEAD
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}
||||||| base
=======
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}
>>>>>>> feature/add-checkout

Empty base. Both sides identical. This isn’t a real conflict. It’s just Git seeing that code appeared on both sides independently (once from the merged sub-PR, once from the feature branch that originally authored it).

The skill detects this pattern. When the base is empty but HEAD and the incoming side are more than 95% similar (after normalizing whitespace), it auto-resolves by keeping the HEAD version and tells you what it did. For 70-95% similarity, it shows both versions and asks you to confirm. Below 70%, it’s a genuine divergence and presents both options for you to decide.

A Realistic Session

Here’s what it looks like in practice. You’re rebasing and hit conflicts:

> /resolve-conflicts

Conflicts (rebase step 3/12):
- 1 lockfile: package-lock.json
- 2 mergiraf: src/app.ts, src/utils.ts
- 1 other: README.md

Resolving lockfile: package-lock.json... accepted theirs (will regenerate)
Resolving mergiraf: src/app.ts... resolved structurally
Resolving mergiraf: src/utils.ts... 1 conflict remains, analyzing...
  Auto-resolved src/utils.ts hunk at line 42: stacked PR duplicate
  (HEAD and incoming 98% similar with empty base). Kept HEAD version.
Resolving other: README.md... [presents conflict for user review]

Regenerating package-lock.json... done
Continuing rebase (step 4/12)...

If step 4 has conflicts, it resolves those too. All the way through step 12. You just watch it work and only chime in when it needs a human decision.

Setup

The skill lives in my dotfiles repo. If you use my dotfiles, it’s already available via symlink. Otherwise, grab the files and drop them into ~/.claude/skills/resolve-conflicts/.

Putting It Together

The two layers complement each other:

1. During any git merge, rebase, or cherry-pick, mergiraf runs automatically as the merge driver. It silently resolves structural conflicts before you ever see them. You don’t have to do anything.
2. For the conflicts that remain, /resolve-conflicts categorizes them, applies the right strategy for each type, and continues the operation.

The result: most rebases that used to require manual intervention now complete with zero or minimal human input. The conflicts that do need your attention are the genuinely ambiguous ones that deserve it.

Try It

Both tools are open source and available in my dotfiles repo. Mergiraf is available at mergiraf.org and installs in minutes. The resolve-conflicts skill requires Claude Code.

Merge conflicts are an inevitable part of collaborative development. The suffering is optional.

Yet there it was. My smiling face. On that PR.

This was my first year at PostHog, and it felt like a real test of the culture. Would they blame me? Let it quietly color opinions of my work? Fire me over a mistake?

Nah.

My colleagues were supportive and understanding. The question wasn’t “who do we blame?” but “what allowed this to happen and how do we prevent it?” This is a company that looks at failure through the lens of systems and incentives, not individual fault. It embraces the ideas of blameless post-mortems.

If we go with “blame” as the predominant approach, then we’re implicitly accepting that deterrence is how organizations become safer. This is founded in the belief that individuals, not situations, cause errors.

That moment is just one of many reasons why I love working here. This is a company that backs up its principles with action.

A Year of PostHog

A year ago today, I started at PostHog, and it has been even better than I hoped. When I joined, I wrote:

Their company handbook really impressed me. What it communicates to me is that this is a remote-friendly company that values transparency, autonomy, and trust. It’s a company that treats its employees like adults and tries to minimize overhead.

It is easy to be cynical about company handbooks and the values they claim to uphold. Enron famously promoted Integrity, Respect, Communication, and Excellence (RICE) as its values, but we all know how that turned out.

What has stood out to me at PostHog is that the handbook reflects reality. The company thinks deeply about how it wants to operate and is willing to adjust when things drift. At our most recent all-company off-site in Tulum, we even revisited and changed some of our values to better reflect how we actually work.

That kind of self-awareness is rare. It’s one big reason why I love working here. Also, Tulum.

Retirement Job?

When Microsoft acquired GitHub, it gave me a lot of options. I took time off. I started a YC company. That company did not work out, so I took more time off. I was not in a hurry to get back to work, but I did miss the camaraderie of building things with other people. That is what led me to interview at PostHog.

In my interview, one of the founders asked an interesting question. Given that it seemed like I did not need to work, would I be motivated to work hard at PostHog? In other words, was this a “retirement job”?

Of course I said I would work hard. What else could I say?

But here’s what I didn’t say: writing code and building product doesn’t feel like hard work to me, at least not compared to what I did before. As a Director of Engineering, so much of my energy went into bureaucracy, politics, and navigating bad incentives.

That was exhausting.

Writing code is how I unwind.

So in a way, yes, this is a retirement job. Because I love doing it.

Polyglot

I also still have a lot to learn, and this has been a great place to do it.

My team builds the Feature Flags product, which spans the backend service, the frontend UI, and a large collection of SDKs. Over the past year, I have written production code in Python, TypeScript, Rust, Go, Ruby, Elixir, C#, and even PHP.

Yes, PHP. I held out for thirty years. The streak is over.

At one point, I shipped the same ETag caching feature to seven different SDKs in seven different languages in three days.

I am not an expert in all of these languages. But with a solid foundation in programming principles, and a lot of help from LLMs, I have been able to ramp up quickly.

Working across so many languages and paradigms has stretched my thinking and deepened my understanding of how software systems are built.

Team Lead

A while back I wrote Chutes and Ladder career path about how careers do not have to follow a neat, linear ladder. True to that idea, after a year as an individual contributor, I am stepping into a team lead role.

This was not something I actively sought out. I genuinely love being an IC. But, as has often happened in my career, this change grew out of a real need. We are carving out a new Flags Platform team from the Feature Flags team. The good news is that a team lead role at PostHog is not a traditional management role. It’s effectively an IC with a bit more responsibilities for the team such as hiring, mentoring, and planning.

What excites me most about this split is the chance to focus deeply on the platform itself.

I am excited to see what year two brings. I will be spending a lot more time in Rust, pushing our flags platform to be faster and more resilient, and working my butt off to ensure my face stays out of future root cause analysis reports.

But that changed as I began using LLM coding tools to do more work in parallel. Being able to work on multiple branches simultaneously is a game changer.

Without git worktrees, working on multiple branches at the same time in the same repository is a pain. There’s the serial approach where you stash your changes, context switch, and pray you didn’t break anything. Or worse, just commit half-finished work with “WIP” messages (looking at you, past me). Or you can have multiple clones of the same repository, but that’s a pain to manage and can take up a lot of disk space.

Git worktrees solve this. They let you have multiple branches checked out simultaneously in different directories that all share the same git database (aka the .git directory). For me, this means I can work on a feature in one terminal, review a PR in another, have Claude Code work on another feature in another terminal, and have all of them share the same git history.

But here’s the thing: creating worktrees manually is tedious. You need to remember where you put them, what to name them, and clean them up later. Also, by default the git worktree is created in the root of the repository unless you specify a different directory.

I wanted something simpler. I wanted something that would work across any repository. No setup, no configuration files, just sensible defaults.

Enter tree-me

I built tree-me, a minimal wrapper around git’s native worktree commands. It adds organizational convention while letting git handle all the complexity.

Instead of this:

# Create worktree manually
mkdir -p ~/worktrees/my-project
git worktree add ~/worktrees/my-project/fix-bug -b haacked/fix-bug main
cd ~/worktrees/my-project/fix-bug
# Now repeat for every repo...

You do this:

tree-me create haacked/fix-bug
# Creates: ~/dev/worktrees/my-project/haacked/fix-bug
# And automatically cds into it

How it works

tree-me uses git-like subcommands and follows conventions so you don’t have to think:

• Auto-detects repository name from your git remote
• Auto-detects default branch (checks for origin/HEAD, falls back to main)
• Organizes by repo: $WORKTREE_ROOT/<repo-name>/<branch-name>
• Delegates to git for all validation, errors, and edge cases
• PR support: Fetches GitHub PRs using git’s native PR refs (requires gh CLI)
• Auto-CD: Automatically changes to the worktree directory after creation
• Tab completion: Complete commands and branch names in bash/zsh

Commands:

tree-me create <branch> [base]        # Create new branch in worktree
tree-me checkout <branch>             # Checkout existing branch (alias: co)
tree-me pr <number|url>               # Checkout GitHub PR (uses gh CLI)
tree-me list                          # List all worktrees (alias: ls)
tree-me remove <branch>               # Remove a worktree (alias: rm)
tree-me prune                         # Prune stale worktree files
tree-me shellenv                      # Output shell function for auto-cd

Examples:

tree-me create haacked/fix-bug              # Create from main/master
tree-me create haacked/fix-bug develop      # Create from develop
tree-me co existing-feature                 # Checkout existing branch
tree-me pr 123                              # Checkout PR #123
tree-me pr https://github.com/org/repo/pull/456
tree-me ls                                  # Show all worktrees
tree-me rm haacked/fix-bug                  # Clean up (supports tab completion)

Conventions

tree-me is a minimal wrapper around git’s native commands. Works with any repo, any language, any setup. The only convention is where worktrees live and how they’re named.

Want worktrees in a different location? Set WORKTREE_ROOT. Need to branch from develop instead of main? Pass it as an argument: tree-me create my-feature develop. Conventions with escape hatches.

Setup

To enable auto-cd and tab completion, add this to your ~/.bashrc or ~/.zshrc:

source <(tree-me shellenv)

This makes tree-me create, tree-me checkout, and tree-me pr automatically cd into the worktree directory. It also enables tab completion for commands and branch names (try tree-me rm <TAB>).

View the full implementation at github.com/haacked/dotfiles/blob/main/bin/tree-me.

The PR workflow

Here’s where it shines. Someone asks you to review a PR while you’re deep in a feature:

tree-me pr 123                  # Fetches, checks out PR, and cds into it
# You're now in: ~/dev/worktrees/dotfiles/pr-123
# Review the code, test it, leave comments
# When done, switch back
tree-me co haacked/my-feature   # Checks out and cds back to your feature
# Back to your work, no stash needed

When you’re done reviewing:

tree-me rm pr-123               # Tab complete to see available branches

Gone. Clean. No accidentally committing review changes to your feature branch.

Installation

Download tree-me and put it somewhere in your PATH:

# Example: copy to ~/bin or ~/.local/bin
curl -o ~/bin/tree-me https://raw.githubusercontent.com/haacked/dotfiles/main/bin/tree-me
chmod +x ~/bin/tree-me

Then enable auto-cd and tab completion (see Setup section above).

That’s it. No dependencies beyond git, bash, and optionally the gh CLI for PR checkout.

Why I built this

I work on multiple repos daily—PostHog, my blog, various open source projects. I was tired of remembering project-specific worktree scripts and hunting for that worktree I created last week.

The philosophy: Don’t recreate what git does well. Add only the minimal convention needed.

Git already handles worktrees perfectly. I just needed organized paths, sensible defaults, and a consistent interface across all my projects.

Directory structure

Everything is organized predictably based on the repository name and branch name:

~/dev/worktrees/<repo-name>/<branch-name>

For example:

~/dev/worktrees/
├── dotfiles/
│   ├── haacked/vim-improvements/
│   ├── haacked/git-tools/
│   └── main/
├── posthog/
│   ├── haacked/feature-flags/
│   ├── pr-789-contributor/
│   └── main/
└── spelungit/
    └── haacked/performance/

One glance and you know where everything is.

What it doesn’t do

tree-me doesn’t copy environment files, install dependencies, or set up project-specific tools. That’s deliberate. Those concerns belong in your project’s setup scripts, not in a generic git tool.

Want to automate environment setup? Add a script to your repo that runs after checkout. Want to copy .env files? Put it in your project’s onboarding docs. tree-me just handles the git worktree ceremony.

Try it

If you work with multiple branches regularly, give worktrees a try. If you work with multiple repos, give tree-me a try. If you hate it, at least you learned about git worktrees (and that’s probably worth more than the script).

Find tree-me at github.com/haacked/dotfiles/blob/main/bin/tree-me. It’s MIT licensed—copy it, modify it, improve it.

Git’s search is challenging for these sorts of queries. git log --grep="auth" assumes you remember exact words from commit messages. Want to find “commits where we improved error handling in API endpoints”? You’ll need multiple greps with regex gymnastics, and still miss commits that used different terminology. We need a better tool.

Enter Spelungit

I built Spelungit, a semantic search engine for Git commit history. Instead of keyword roulette, you search using natural language through Claude Code’s MCP interface.

Want commits where you refactored authentication? Ask for “authentication flow refactoring.” Looking for race conditions in background processing? Search for “race conditions in job processing.” It understands intent instead of making you guess exact words from three months ago.

How it works

Instead of this:

# How do you even grep for "race condition fixes"?
git log --grep="race\|concurrent\|thread\|lock\|mutex" --all
# Now manually read through 50 commits...

You do this in your AI development tool of choice:

Search git history for "race condition fixes in background jobs"

Queries that work:

• “When did we switch from REST to GraphQL?”
• “Commits where we improved error handling in API endpoints”
• “Show me refactoring of the authentication flow”
• “Security improvements in file upload handling”
• “Where did we fix that memory leak in the worker process?”

It creates embeddings for both commit messages and code changes, which makes semantic search possible. It knows the difference between new features and bug fixes, even when commit messages are vague (looking at you, past me).

Installation

Spelungit uses SQLite and local embeddings to make installation simple. Everything runs on your machine. No need for an API key, a database, or Docker.

One line:

curl -sSL https://raw.githubusercontent.com/haacked/spelungit/main/install-remote.sh | bash

Downloads everything, sets up Python venv, installs dependencies, configures Claude Code. Suspicious of pipe-to-bash? Clone the repo and run ./install.sh.

Using it

Shows up in Claude Code (or your AI tool of choice) as an MCP server. The first time you ask a question in a repository that spelungit responds to, spelungit will index the repository. Once it’s done, it’ll be able to answer questions.For large repos, this can take a few minutes while it analyzes commits and creates embeddings.

Then search naturally:

• “Show me commits about error handling improvements”
• “Find where we refactored the authentication”
• “What changed in the API layer recently?”

Claude calls the appropriate MCP tools (index_repository, search_commits, repository_status, get_database_info) behind the scenes.

Under the hood

Analyzes commit messages and code changes. For each commit:

• Semantic content from messages and diffs
• Code patterns like function names and classes
• File types and directory structure
• Feature vs. bug fix vs. refactoring

Uses Microsoft’s all-MiniLM-L6-v2 (384 dimensions) with local sentence-transformers to create embeddings. Embeddings are stored in SQLite. Searching for git history uses cosine similarity searches.

The sqlite database only stores commit SHAs and embeddings, leaving the full commit message in git. Thousands of commits = few megabytes. Handles Git worktrees if you’re into that masochism.

Why I built this

I work across multiple repositories and constantly need to understand why changes were made. Traditional Git tools are limited. Too much detective work scrolling through commits.

I wanted to ask Git history questions in plain English and get the right commits back. Semantic search of Git history is something I always wished GitHub would add. I got tired of waiting so I built this.

Also, I’ve been experimenting with MCP servers and wanted to build something useful instead of another todo app.

Future ideas for improvement

Configurable models: Local embeddings work pretty well, but OpenAI’s models would be better for teams willing to trade privacy for better accuracy. PostgreSQL support: For massive repos or shared team search. Smarter code understanding: Better refactoring vs. feature detection, architectural changes over time.

Try it

Spelungit is MIT licensed. The project scratched a real itch for me. If it doesn’t work perfectly, that’s what GitHub issues are for.

Find it at https://github.com/haacked/spelungit.

1. Checkout the default branch.
2. Run git up to make sure you’re up to date.
3. Run git bclean to delete all the branches that have been merged into the default branch.

And this worked great for a long time. The way it worked was it would list all the branches that have been merged into the default branch and then delete them. In my case, I didn’t use git branch --merged to list merged branches because I didn’t know about it at the time.

However, my aliases stopped working for me recently after joining PostHog. The main reason is on pretty much all of their repositories, they use Squash and Merge when merging PRs.

When you use git merge --squash or GitHub’s “Squash and merge” feature, Git creates a new commit on the target branch that combines all the changes from the source branch into a single commit. This new commit doesn’t retain any reference to the original commits from the source branch. As a result, Git doesn’t consider the source branch as merged, and commands like git branch --merged won’t show it.

But here’s the thing about Git. There’s almost always a way.

Solution

When you merge a PR on GitHub, it shows you a “Delete branch” button:

This is a great feature. It’s a good way to clean up branches that have been merged into the default branch. In fact, you can configure GitHub to “Automatically delete head branches” when merged:

I highly recommend you do the same. When the remote branch is deleted, Git will track it as “gone”. For example, if you run git branch -vv you’ll see something like this:

> git branch -vv

  haacked/decide-v4      ba39408 [origin/haacked/decide-v4: gone] Fix demo to handle variants
  haacked/fix-sample-app ec15751 [origin/haacked/fix-sample-app] Handle variants
* haacked/local-only     e78d2f6 Do important stuff
  main                   ab885d0 [origin/main] chore: Bump to v1.0.2

Notice that haacked/decide-v4 is marked as gone.

We can use git’s porcelain to list branches and their tracking information in a more easily parseable format.

> git for-each-ref --format='%(refname:short) %(upstream:track)' refs/heads/

haacked/decide-v4 [gone]
haacked/fix-sample-app
haacked/local-only
master

Let’s make this an alias to list these gone branches:

> git config --global alias.gone "!git for-each-ref --format='%(refname:short) %(upstream:track)' refs/heads/ | awk '\$2 == \"[gone]\" { print \$1 }'"

Now we can use the alias to list gone branches:

> git gone

haacked/decide-v4

Next step is to update my old bclean alias to use the new gone alias.

> git config --global alias.bclean "!git gone | xargs -r git branch -D"

Unfortunately, since git doesn’t know it’s been merged, we have to do a force delete. That’s a bit scary, but this won’t touch local branches or any branches that are still tracking a remote branch. With this alias, you can run git bclean to delete all the branches that have been merged into the default branch. Finally, we have the old bdone alias to switch to the default branch, run git up, and then run bclean.

Here’s the complete set of aliases mentioned in this post you can cut and paste into your .gitconfig:

[alias]
    default = "!git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'"
    bclean = "!git gone | xargs -r git branch -D"
    # Switches to specified branch (or the default branch if no branch is specified), runs git up, then runs bclean.
    bdone = "!f() { DEFAULT=$(git default); git checkout ${1-$DEFAULT} && git up && git bclean; }; f"
    gone = "!git for-each-ref --format='%(refname:short) %(upstream:track)' refs/heads/ | awk '$2 == \"[gone]\" { print $1 }'"

Or, if you want to use the git command line, you can use the following:

git config --global alias.default "!git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'"
git config --global alias.gone "!git for-each-ref --format='%(refname:short) %(upstream:track)' refs/heads/ | awk '\$2 == \"[gone]\" { print \$1 }'"
git config --global alias.bclean "!git gone | xargs -r git branch -D"
git config --global alias.bdone "!f() { DEFAULT=\$(git default); git checkout \${1:-\$DEFAULT} && git up && git bclean; }; f"

fatal: ref refs/remotes/origin/HEAD is not a symbolic ref

git remote set-head origin --auto

So now, my old workflow is back. When I merge a PR, I can run git bdone from the branch I merged to clean up the branches. All is right with the world again.

And as always, you can find these aliases and more in my dotfiles repo. See this blog post for more context on how you can include them in your dotfiles.

I joined PostHog at the beginning of the year as a Product Engineer on the Feature Flags team. Feature flags are just one of the many tools PostHog offers to help product engineers build better products.

Much of my job will consist of writing Python and React with TypeScript. But when I started, I noticed they didn’t have a .NET SDK. It turns out, I know a thing or two about .NET!

So if you’ve been wanting to use PostHog in your ASP.NET Core applications, yesterday is your lucky day! The 1.0 version of the PostHog .NET SDK for ASP.NET Core is available on NuGet.

dotnet add package PostHog.AspNetCore

You can find documentation for the library on the PostHog docs site, but I’ll cover some of the basics here. I’ll also cover non-ASP.NET Core usage later in this post.

Configuration

To configure the client SDK, you’ll need:

1. Project API Key - from the PostHog dashboard
2. Personal API Key - for local evaluation (Optional, but recommended)

By default, the PostHog client looks for settings in the PostHog section of the configuration system such as in the appSettings.json file:

{
  "PostHog": {
    "ProjectApiKey": "phc_..."
  }
}

Treat your personal API key as a secret by using a secrets manager to store it. For example, for local development, use the dotnet user-secrets command to store your personal API key:

dotnet user-secrets init
dotnet user-secrets set "PostHog:PersonalApiKey" "phx_..."

In production, you might use Azure Key Vault or a similar service to provide the personal API key.

Register the client

Once you set up configuration, register the client with the dependency injection container.

In your Program.cs file, call the AddPostHog extension method on the WebApplicationBuilder instance. It’ll look something like this:

using PostHog;

var builder = WebApplication.CreateBuilder(args);

builder.AddPostHog();

Calling builder.AddPostHog() adds a singleton implementation of IPostHogClient to the dependency injection container. Inject it into your controllers or pages like so:

public class MyController(IPostHogClient posthog) : Controller
{
}

public class MyPage(IPostHogClient posthog) : PageModel
{
}

Usage

Use the IPostHogClient service to identify users, capture analytics, and evaluate feature flags.

Use the IdentifyAsync method to identify users:

// This stores information about the user in PostHog.
await posthog.IdentifyAsync(
    distinctId,
    user.Email,
    user.UserName,
    // Properties to set on the person. If they're already
    // set, they will be overwritten.
    personPropertiesToSet: new()
    {
        ["phone"] = user.PhoneNumber ?? "unknown",
        ["email_confirmed"] = user.EmailConfirmed,
    },
    // Properties to set once. If they're already set
    // on the person, they won't be overwritten.
    personPropertiesToSetOnce: new()
    {
        ["joined"] = DateTime.UtcNow 
    });

Some things to note about the IdentifyAsync method:

• The distinctId is the identifier for the user. This could be an email, a username, or some other identifier such as the database Id. The important thing is that it’s a consistent and unique identifier for the user. If you use PostHog on the client, use the same distinctId here as you do on the client.
• The personPropertiesToSet and personPropertiesToSetOnce are optional. You can use them to set properties about the user.
• If you choose a distinctId that can change (such as username or email), you can use the AliasAsync method to alias the old distinctId with the new one so that the user can be tracked across different distinctIds.

To capture an event, call the Capture method:

posthog.Capture("some-distinct-id", "my-event");

This will capture an event with the distinct id, the event name, and the current timestamp. You can also include properties:

posthog.Capture(
    "some-distinct-id",
    "user signed up",
    new() { ["plan"] = "pro" });

The Capture method is synchronous and returns immediately. The actual batching and sending of events is done in the background.

Feature flags

To evaluate a feature flag, call the IsFeatureEnabledAsync method:

if (await posthog.IsFeatureEnabledAsync(
    "new_user_feature",
    "some-distinct-id")) {
    // The feature flag is enabled.
}

This will evaluate the feature flag and return true if the feature flag is enabled. If the feature flag is not enabled or not found, it will return false.

Feature Flags can contain filter conditions that might depend on properties of the user. For example, you might have a feature flag that is enabled for users on the pro plan.

If you’ve previously identified the user and are NOT using local evaluation, the feature flag is evaluated on the server against the user properties set on the person via the IdentifyAsync method.

But if you’re using local evaluation, the feature flag is evaluated on the client, so you have to pass in the properties of the user:

await posthog.IsFeatureEnabledAsync(
    featureKey: "person-flag",
    distinctId: "some-distinct-id",
    personProperties: new() { ["plan"] = "pro" });

This will evaluate the feature flag and return true if the feature flag is enabled and the user’s plan is “pro”.

.NET Feature Management

.NET Feature Management is an abstraction over feature flags that is supported by ASP.NET Core. With it enabled, you can use the <feature /> tag helper to conditionally render UI based on the state of a feature flag.

<feature name="my-feature">
    <p>This is a feature flag.</p>
</feature>

You can also use the FeatureGateAttribute in your controllers and pages to conditionally execute code based on the state of a feature flag.

[FeatureGate("my-feature")]
public class MyController : Controller
{
}

If your app already uses .NET Feature Management, you can switch to using PostHog with very little effort.

To use PostHog feature flags with the .NET Feature Management library, implement the IPostHogFeatureFlagContextProvider interface. The simplest way to do that is to inherit from the PostHogFeatureFlagContextProvider class and override the GetDistinctId and GetFeatureFlagOptionsAsync methods. This is required so that .NET Feature Management can evaluate feature flags locally with the correct distinctId and personProperties.

public class MyFeatureFlagContextProvider(
    IHttpContextAccessor httpContextAccessor)
    : PostHogFeatureFlagContextProvider
{
    protected override string? GetDistinctId() =>
       httpContextAccessor.HttpContext?.User.Identity?.Name;
    
    protected override ValueTask<FeatureFlagOptions> GetFeatureFlagOptionsAsync()
    {
        // In a real app, you might get this information from a database or other source for the current user.
        return ValueTask.FromResult(
            new FeatureFlagOptions
            {
                PersonProperties = new Dictionary<string, object?>
                {
                    ["email"] = "some-test@example.com",
                    ["plan"] = "pro"
                },
                OnlyEvaluateLocally = true
            });
    }
}

Then, register your implementation in Program.cs (or Startup.cs):

using PostHog;

var builder = WebApplication.CreateBuilder(args);

builder.AddPostHog(options => {
    options.UseFeatureManagement<MyFeatureFlagContextProvider>();
});

This registers a feature flag provider that uses your implementation of IPostHogFeatureFlagContextProvider to evaluate feature flags against PostHog.

Non-ASP.NET Core usage

The PostHog.AspNetCore package adds ASP.NET Core specific functionality on top of the core PostHog package. But if you’re not using ASP.NET Core, you can use the core PostHog package directly:

dotnet add package PostHog.AspNetCore

And then register it with your dependency injection container:

builder.Services.AddPostHog();

If you’re not using dependency injection, you can still use the registration method:

using PostHog;
var services = new ServiceCollection();
services.AddPostHog();
var serviceProvider = services.BuildServiceProvider();
var posthog = serviceProvider.GetRequiredService<IPostHogClient>();

For a console app (or apps not using dependency injection), you can also use the PostHogClient directly, just make sure it’s a singleton:

using System;
using PostHog;

var posthog = new PostHogClient(
  Environment.GetEnvironmentVariable("PostHog__PersonalApiKey"));

Examples

To see all this in action, the posthog-dotnet GitHub repository has a samples directory with a growing number of example projects. For example, the HogTied.Web project is an ASP.NET Core web app that uses PostHog for analytics and feature flags and shows some advanced configuration.

What’s next?

With this release done, I’ll be focusing my attention on the Feature Flags product. Even so, I’ll continue to maintain the SDK and fix any reported bugs.

If anyone reports bugs, I’ll be sure to fix them. But I won’t be adding any new features for the moment.

Down the road, I’m hoping to add a PostHog.Unity package. I just don’t have a lot of experience with Unity yet. My game development experience mostly consists of getting shot in the face by squeaky voiced kids playing Fortnite. I’m hoping someone will contribute a Unity sample project to the repo which I can use as a starting point.

If you have any feedback, questions, or issues with the PostHog .NET SDK, please reach file an issue at https://github.com/PostHog/posthog-dotnet.

After over a year of being on a personally funded sabbatical, I started a new job at PostHog as a Senior Product Engineer. This week is my orientation where I get to drink from the firehose once again.

What is PostHog?

Apart from being a company that seems to really love cute hedgehogs, PostHog is an open-source product analytics platform. They have a set of tools to help product engineers build better products. Each product can be used as a standalone tool, but they’re designed to level-up when you put them together.

In particular, I’ve started on the Feature Flags team. Yesterday was my first day of onboarding and so far I really like my team.

Today is day two and I’ve already submitted a small fix for my first pull request!

Why PostHog?

When I was looking around at companies, an old buddy from GitHub who worked at PostHog reached out to me and suggested I take a look at this company. He said it reminded him of the good parts of working at GitHub.

Their company handbook really impressed me. What it communicates to me is that this is a remote-friendly company that values transparency, autonomy, and trust. It’s a company that treats its employees like adults and tries to minimize overhead.

Not only that, they’ve embraced a lot of employee-friendly practices. For example, a while back my friend Zach wrote about his distaste for the 90 day exercise window. PostHog provides a 10-year window. Not only that, they offer employes double trigger acceleration!

This is a perk usually only offerered to executives.

I should mention we’re hiring! Please mention me if you apply. If we’ve worked together, let me know so I can provide feedback internally.

I’m excited to be part of a company that’s small, but growing. The company is at a stage similar to the stage GitHub was at when I joined. This is a team with a strong product engineering culture and I’m excited to contribute what I can and learn from them.

The Challenge

The other part that’s exciting for me is that I’ll be working in a stack that I don’t have a huge amount of experience with. The front-end is React with TypeScript and the back-end is Django with Python. I’ve done a bit of work in all these technologies except Django. However, I believe my experience with ASP.NET MVC will help me pick up Django quickly.

Not to mention, I’ve always taken the stance that I’m a software engineer, not just a .NET developer. Don’t get me wrong, I love working in .NET. But at the same time, I think it’s healthy for me to get production experience in other stacks. It’ll be an area of personal growth. Not to mention, they don’t quite have a .NET Client SDK yet so once I get settled in, that’s something I’m interested in getting started on.

The Future

I’ll share more about my experience here as I get settled in. In the meanwhile, wish me luck!

For example, I came across an API that returned a value like this:

{
  "important": true
}

No problem, I defined a class like this to deserialize it to:

public class ImportantResponse
{
    public bool Important { get; set; }
}

And life was good. Until that awful day that the API returned this:

{
  "important": "What is important is subjective to the viewer."
}

Damn! This philosophy lesson broke my client. One workaround is to do this:

public class ImportantResponse
{
    public JsonElement Important { get; set; }
}

It works, but it’s not great. It doesn’t communicate to the consumer that this value can only be a string or a bool. That’s when I remembered an old blog post from my past.

April Fool’s Joke to the Rescue

When I was the Program Manager (PM) for ASP.NET MVC, my colleague and lead developer, Eilon, wrote a blog post entitled “The String or the Cat: A New .NET Framework Library where he introduced the class StringOr<TOther>. This class could represent a dual-state value that’s either a string or another type.

The concepts presented here are based on a thought experiment proposed by scientist Erwin Schrödinger. While an understanding of quantum physics will help to understand the new types and APIs, it is not required.

It turned out his blog post was an April Fool’s joke. But the idea stuck with me. And now, here’s a case where I need a real implementation of it. But I’m going to name mine, StringOrValue<T>.

A modern StringOrValue<T>

One nice thing about implementing this today is we can leverage modern C# features. Here’s the starting implementation:

[JsonConverter(typeof(StringOrValueConverter))]
public readonly struct StringOrValue<T> : IStringOrObject {
    public StringOrValue(string stringValue) {
        StringValue = stringValue;
        IsString = true;
    }

    public StringOrValue(T value) {
        Value = value;
        IsValue = true;
    }

    public T? Value { get; }
    public string? StringValue { get; }

    [MemberNotNullWhen(true, nameof(StringValue))]
    public bool IsString { get; }

    [MemberNotNullWhen(true, nameof(Value))]
    public bool IsValue { get; }
}

/// <summary>
/// Internal interface for <see cref="StringOrValue{T}"/>.
/// </summary>
/// <remarks>
/// This is here to make serialization and deserialization easy.
/// </remarks>
[JsonConverter(typeof(StringOrValueConverter))]
internal interface IStringOrObject
{
    bool IsString { get; }

    bool IsValue { get; }

    string? StringValue { get; }

    object? ObjectValue { get; }
}

We can use the MemberNotNullWhen attribute to tell the compiler that when IsString is true, StringValue is not null. And when IsValue is true, Value is not null. That way, code like this compiles just fine without raising null warnings:

var value = new StringOrValue<string>("Hello");
if (value.IsString) {
    Console.WriteLine(value.StringValue.Length);
}

and

var value = new StringOrValue<SomeType>(42);
if (value.IsValue) {
    Console.WriteLine(value.ToString());
}

It also is decorated with the JsonConverter attribute to tell the JSON serializer to use the StringOrValueConverter class to serialize and deserialize this type. I wanted this type to Just Work™. I didn’t want consumers of this class have to bother with registering a JsonConverterFactory for this type.

This also explains why I introduced the internal IStringOrObject interface. We can’t implement the JsonConverter attribute on a open generic type, so we need a non-generic interface to apply the attribute to. It also makes it easier to write the converter as you’ll see.

/// <summary>
/// Value converter for <see cref="StringOrValue{T}"/>.
/// </summary>
internal class StringOrValueConverter : JsonConverter<IStringOrObject>
{
    public override bool CanConvert(Type typeToConvert)
        => typeToConvert.IsGenericType
           && typeToConvert.GetGenericTypeDefinition() == typeof(StringOrValue<>);

    public override IStringOrObject Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        var targetType = typeToConvert.GetGenericArguments()[0];

        if (reader.TokenType == JsonTokenType.String)
        {
            var stringValue = reader.GetString();
            return stringValue is null
                ? CreateEmptyInstance(targetType)
                : CreateStringInstance(targetType, stringValue);
        }

        var value = JsonSerializer.Deserialize(ref reader, targetType, options);

        return value is null
            ? CreateEmptyInstance(targetType)
            : CreateValueInstance(targetType, value);
    }

    static ConstructorInfo GetEmptyConstructor(Type targetType)
    {
        return typeof(StringOrValue<>)
                   .MakeGenericType(targetType).
                   GetConstructor([])
               ?? throw new InvalidOperationException($"No constructor found for StringOrValue<{targetType.Name}>.");
    }

    static ConstructorInfo GetConstructor(Type targetType, Type argumentType)
    {
        return typeof(StringOrValue<>)
            .MakeGenericType(targetType).
            GetConstructor([argumentType])
            ?? throw new InvalidOperationException($"No constructor found for StringOrValue<{targetType.Name}>.");
    }

    static IStringOrObject CreateEmptyInstance(Type targetType)
    {
        var ctor = GetEmptyConstructor(targetType);
        return (IStringOrObject)ctor.Invoke([]);
    }

    static IStringOrObject CreateStringInstance(Type targetType, string value)
    {
        var ctor = GetConstructor(targetType, typeof(string));
        return (IStringOrObject)ctor.Invoke([value]);
    }

    static IStringOrObject CreateValueInstance(Type targetType, object value)
    {
        var ctor = GetConstructor(targetType, targetType);
        return (IStringOrObject)ctor.Invoke([value]);
    }

    public override void Write(Utf8JsonWriter writer, IStringOrObject value, JsonSerializerOptions options)
    {
        if (value.IsString)
        {
            writer.WriteStringValue(value.StringValue);
        }
        else if (value.IsValue)
        {
            JsonSerializer.Serialize(writer, value.ObjectValue, options);
        }
        else
        {
            writer.WriteNullValue();
        }
    }
}

In the actual implementation of StringOrValue<T>, I implemented IEquatable<T>, IEquatable<StringOrValue<T>> and overrode the implicit operators:

public static implicit operator StringOrValue<T>(string stringValue) => new(stringValue);
public static implicit operator StringOrValue<T>(T value) => new(value);

This allows you to write code like this:

StringOrValue<int> valueAsString = "Hello";
StringOrValue<int> valueAsNumber = 42;

Assert.Equals("Hello", valueAsString);
Assert.Equals(42, valueAsNumber);

So with this implementation in place, I can go back to the original example and write this:

public class ImportantResponse
{
    public StringOrValue<bool> Important { get; set; }
}

And now I can handle both cases:

var response = JsonSerializer.Deserialize<ImportantResponse>(json)
    ?? throw new InvalidOperationException("Deserialization failed.");

if (response.Important.IsValue) {
    if (response.Important.Value) {
        Console.WriteLine("It's important!");
    }
    else {
        Console.WriteLine("It's not important.");
    }
}
else {
    Console.WriteLine(response.Important.StringValue);
}

It’s time to go shopping for a beanie!

Here’s the full implementation for those interested in using this in your own projects!

If you’re lucky, your company supports a tall Individual Contributor (IC) ladder. But often, the next rung swaps your hoodie for a power shirt, suspenders, and management duties.

My first job followed this script: developer to team lead to Senior Manager. I was hustling up that ladder.

But life isn’t linear. Careers are more like Chutes and Ladders (which the Brits know as Snakes and Ladders, but that messes up my metaphor). Lucky breaks shoot you up; surprises send you sliding down. Those chutes? Not failures. Opportunities.

Take my journey. I took a chute from my first job back to an IC role at my second. Climbed back up into management. Took a chute to Microsoft as a Senior Program Manager. Then came another chute: GitHub.

I started as a developer, became a manager, then Director of Engineering. After that, I co-founded a startup, took the CTO title, but spent most of my time writing code.

It looked like the classic ladder climb, but in startups, titles are smoke and mirrors. So it only counted as a step up if we succeeded. Spoiler: we didn’t.

Ladders Are Overrated

Ladders are narrow and rigid. Titles—while shiny—hide what matters: the work. They’re bumper stickers for your career. Nice for signaling, but they don’t tell the whole story.

As Director, I mentored teams and focused on broad initiatives. But over time, I started to miss the tech. The longer I stayed out of writing production code, the more disconnected I felt. As a CTO, I got back to coding and loved it. When the startup failed, I promised myself at least a year off to reflect before jumping into something new.

Growth on the Slide

Over a year later, I’ve been thinking about my next move. It turns out nobody will pay me to be a man of leisure.

Conventional wisdom (and ego) says aim higher: VP of Software Development or CTO at an established company.

The irony of big titles is they mean more power at work, but less power over your time.

For me, my recent life circumstances make time autonomy among my top priorities. Sure, big titles pay well, but maximizing income isn’t my goal.

Here’s what I realized: By my own definition, I’ve succeeded. I’ve been part of great teams, built great products, and helped grow companies. I have nothing left to prove. I don’t need a lofty title or a giant paycheck (but I wouldn’t turn one down either).

So, once again, I’m setting aside my pride and stepping off the ladder. Next year on January 6th I start a new IC role. Details to come, but I’m thrilled to be back in the trenches, building and learning. It’s a place that treats its employees like adults and gives me the autonomy to structure my day as I see fit.

This isn’t about rejecting leadership. It’s about recalibrating. Leadership is broad. It’s guiding organizations or leading by example. I think it’s healthy—even advantageous—to bounce between IC and management roles over the course of a career. Life changes. I might return to management someday. Or not. The point is to stay open to what fits now.

Your Move

If you’re staring at a chute, wondering if stepping off the ladder will hurt you, consider this: maybe it’s not a setback. Maybe it’s a shortcut to what you really want.

Careers aren’t about perfect titles. They’re about collecting experiences, relationships, and skills that shape you. Sometimes, the most important moves don’t look like progress—until you’re somewhere unexpected, doing work that matters.

Spin the dial. Take the slide. Even in Chutes and Ladders, the winner isn’t who climbs highest. It’s who enjoys the game. At least, that’s what I told my friends when they beat me.