I’m new to LinkedIn.

I’ve spent most of my career hidden inside private employers, writing code and architecting systems that were emphatically closed source—software destined never to see daylight beyond the corporate catacombs into which I birthed it.

I was always a prolific coder, but almost entirely in private.

From time to time, an employer explicitly approved releasing something to the community: an old prototype, an abandoned branch, or a stripped-down version that no longer resembled the system we eventually shipped. It gave me something I could share without exposing the proprietary work that remained behind the walls.

But those releases were exceptions. Work, family, and life consumed the available hours. I would occasionally start an open-source project, make some progress, and then watch it slowly fossilize while the software I was paid to write continued growing behind locked doors.

Then two things changed.

Freedom and Leverage

First, I started my own consultancy instead of working inside someone else’s company.

That gave me freedom. I can decide which problems are worth solving, which software should be public, and which licenses I release it under. I no longer need a committee to decide whether a useful piece of code may escape into the world.

Second, AI arrived.

That gave me leverage.

AI has made me roughly 50 times more productive. I was already considered unusually productive before AI, but every implementation, experiment, test harness, benchmark, and documentation change still had to pass through one pair of hands.

A great deal of software development consists of translating a decision into reality: writing boilerplate, tracing unfamiliar code, finding the exact file under /proc, remembering which system call exposes the information you need, constructing test data, wiring up a benchmark, or discovering that one library’s idea of a timeout is not quite the same as yours.

The thinking may take two minutes. Expressing it through a keyboard can take two days.

AI changes that ratio.

I still decide what should exist. I choose the architecture, data structures, trade-offs, and benchmarks. I inspect the implementation and own whether the result is correct. But I no longer have to personally turn every bolt.

The first change gave me permission to publish.

The second gave me the time.

So Now I’m Cranking Out Artifacts

Goblin Core is a Redis-compatible database with better performance in many areas and a markedly better memory-consumption story.

Goblin Store is a Memcached-compatible object store designed for large-object workloads, again with better performance and lower memory consumption than its incumbents in the cases I care about.

Those are not the only two. I have roughly a dozen projects moving forward: databases, caches, SIMD implementations, networking experiments, compiler work, and other strange creatures crawling out of the laboratory.

They are not prompt-generated demos with a README claiming victory over computer science.

They are artifacts.

They have tests. They have benchmarks. They run on real hardware. They are compared against serious incumbents using workloads I construct carefully—and, according to people who have watched me disappear into benchmark design for days at a time, perhaps obsessively.

That is the fun part.

Unfortunately, writing good software is not enough.

Nobody Downloads Software They Don’t Know Exists

Public software that nobody discovers is much less useful than private software actively serving the employer that built it.

You have to explain what it does.

You have to demonstrate why anyone should care.

You have to earn enough trust that someone will download it, run it, and perhaps entrust a tiny corner of their infrastructure to something written by a stranger in Vermont with too many old servers.

In other words, you have to market it.

Marketing is a new skill for me.

My instinct is to publish a graph showing that one implementation used 36% less memory, cut P99 latency in half, or moved an embarrassing number of bytes through a machine old enough to vote.

Surely everyone will immediately understand why this is wonderful.

Apparently not.

People care about benchmarks, but they care about the humans behind the benchmarks too. They want to know why the project exists, what problem annoyed me enough to build it, what went wrong, what surprised me, and what I learned while crawling through the wreckage.

A benchmark tells people what happened.

A story tells them why they should remember it.

Learning LinkedIn

I’m starting that education here on LinkedIn.

My projects are young, and the audience here is comparatively gentle about that—certainly gentler than Reddit or Lobsters, where a missing semicolon in the third paragraph may result in a tribunal.

LinkedIn is strange, but useful. It rewards technical work, provided the technical work arrives wrapped in something recognizably human.

That has required a small adjustment.

As much as I want to talk about my latest benchmark, new feature, memory allocator, compiler experiment, or obscure argument with the Linux kernel, I cannot publish an uninterrupted stream of charts and expect people to care.

For every benchmark win, I need two posts about the human side of software development.

The frustration.

The history.

The odd machines involved.

The reason I chose one trade-off over another.

The small joke that kept me entertained while a benchmark ran for six hours.

The discovery that something I believed for twenty years was subtly wrong.

These are not really lesser posts. Often, they are the pieces people respond to most strongly. They make the technical work legible to someone who was not sitting beside me while I built it.

But my engineer brain still regards them as the vegetables standing between me and dessert.

Or, perhaps more accurately:

Two poops and a lollipop.

The lollipop is the benchmark post I desperately want to publish.

The two poops are the human stories I must produce first so anyone will still be listening when I finally unveil a chart showing that I moved an extra 14 million operations per second by rearranging twelve bytes.

Apparently, this is marketing.

The goblin is learning.