The best code I write makes itself disappear

The best code I write, nobody thanks me for

We spend enormous effort on how a product feels to use. We spend almost none on how the code feels to work in. That second thing has a name, developer experience, and it is invisible to everyone except the people living in the codebase. This is about why it still matters, and why the work that fixes it almost never gets noticed.

My best work this year has no screenshot.

No demo. No line in a release note. No little round of emoji in a channel. If I tried to show it to you, you would squint and say "okay, and?"

That is the strange thing about it. The code I am proudest of is the code nobody can see I wrote.

We obsess over UX. We ignore DX.#

UX is how the product feels to the person using it. We pour energy into that. We argue about spacing, loading states, the wording on a button.

DX is how the code feels to the person working in it. The next developer who opens the file. Often that next developer is you, three months from now, having forgotten everything.

Both are real experiences. We treat only one of them as real.

Good DX is mostly about saving the next person's time. Nobody should have to learn how the machine works just to flip a switch. If a developer has to stop and dig through the codebase to figure out how the app even toggles a feature, that time is gone, and it gets spent again by the next person, and the next.

And bad DX has a very clear smell. To change one thing, you have to change it in ten places.

The afternoon it actually mattered#

Here is what that smell costs you.

We hide unfinished features behind switches. To check a switch, you read its name and test its value, and getting that exactly right takes a small bit of care.

One day I had to touch one of those switches. I went looking, and found the same check copy pasted by hand across a dozen files. Change one, miss the others, and the feature is half on and half off. In fact a bug exactly like that had already shipped, a feature showing up for people when it was meant to be hidden, because one of those copies was subtly wrong.

That is the worst kind of bug. Nothing throws. Everything runs. It just quietly does the wrong thing until a real person sees it.

So I did the unglamorous fix. I wrote the check once, the correct way, and gave it a name:

function useFeatureFlag(name) {
  // the one correct way to read a switch, written once
  return isFlagOn(name);
}

Now there is one place to get it right, and everywhere else just asks. Ten chances to get it wrong became one place that is correct. More than that, nobody who comes after me has to learn how flags work under the hood. They call one thing and get back to the job they actually opened the file to do.

Then the even more boring half. The switch names were typed by hand too, where a single typo silently turns a feature off. So I put the names in one list you pick from instead of retype. Misspell it now and your editor underlines it before you save. The bug that used to reach production became a red squiggle on your screen.

None of this changed a single pixel. That is the point.

Why DX is the work nobody rewards#

Let me be honest about the catch, because nobody tells you this part early.

DX work does not feed you.

Ship a feature and you get a hit. Someone reacts, you feel seen, it shows up when people list what got done. Spend a day making a flag changeable in one place instead of ten, and you get nothing back you can point to. The person you saved six months from now will never know. They will just not hit the bug, and move on.

So you keep choosing between the work that gets noticed and the work that makes the codebase liveable, and only one of them claps for you.

Early on I chased the loud stuff, because loud is what gets seen, and when you are new you badly want to be seen. It took me a long time to trust that good DX is worth building even when nobody can tell you built it.

What it pays back instead#

It does pay back. Just not in applause.

You stop fighting the same fire twice. The code stops surprising you. People start copying your patterns instead of correcting your code. One day you notice your little helper is everywhere and nobody remembers it was ever missing.

And quietly, you become the person teammates trust with the messy parts. That trust outlasts any single demo. It just arrives slowly, and without a notification.

If you are early and want to stand out#

Here is the move that took me too long to learn. Treat the next developer like a user, and the code they touch like a product.

• Find the fiddly thing everyone re-types and hide it behind one good name.

• Make "change it in ten places" into "change it in one."

• Make the mistake turn red in the editor instead of quiet in production.

None of it will get you a demo. All of it is DX, and DX is what makes a codebase, and an engineer, worth keeping.

Do the work nobody thanks you for. It is usually the work that mattered most.