Names: Your Name Is a Primary Key

Why "just call me Mike" is a schema migration, not a courtesy.

In your first week abroad, someone will look at your name, wince, and offer you a deal. “Do you have something shorter?” It sounds like kindness. It is a schema migration proposed by someone who will not be paying for it, and most engineers accept it before they understand what they signed.

This is the Foreign Engineer’s Field Guide, translation lane. Jokes covered the payload. Pessimism covered the error channel. This one covers the identifier.

A Primary Key, Not a Display String

Your name is not decoration. It is the primary key of your record: the stable, unique identifier that every other table references. Your degrees point at it. Your publications point at it. Ten years of reputation, every reference call, every “oh, I worked with her, she is excellent” points at it. The person your family calls is stored under it.

Change a primary key and you do not get a friendlier value. You get broken references. A real database can at least cascade the change to every referencing table. Society has no cascade. Nobody updates the citations, the old colleagues, the family. That is why databases treat key changes as a serious operation, and why “just call me Mike” is not a nickname. It is a lossy migration with no rollback script.

The engineers in the room are already objecting: names make terrible keys. Not unique, not stable, and the whole discipline of identity management exists because keying on names breaks systems. Correct, and irrelevant. A negotiated rename that goes everywhere, legal, cascaded, announced, is exactly the real migration this piece endorses later; a first-week “just call me Mike” is not that, because it updates one table and calls it done. You do not get to pick a surrogate key for your reputation. Society keyed on your name without consulting you; every reference call, degree, and old colleague joins on it anyway. That is why an unplanned change is expensive: those references break, and there is no rollback script. None of that is why a properly authored key is off the table. A bad key that everything joins on is not a design debate. It is production.

The Mangling Is a Parser Error, Not Your Bug

Understand what is actually failing when they butcher it. Nothing is wrong with your name. Something is wrong with their parser.

There is a famous engineering checklist called falsehoods programmers believe about names: systems that assume every name is short, ASCII, one-word-first-one-word-last, pronounceable in English. Every one of those assumptions is false, and systems that hold them corrupt real people’s data daily. The colleague who will not attempt your two syllables is running the same buggy parser socially. The form that rejects your diacritics and the manager who renames you at the door are the same defect at different layers.

Their parser, their bug. The problem is that you eat the cost, and the local grid, every room, form, and colleague running the same lazy parser, will let you eat it forever if you volunteer.

What the Migration Actually Costs

So you become Mike. Here is the invoice for the version they wrote for you.

First, referential integrity breaks. The formal record mostly survives on your surname. The informal one does not. The reputation you build here accrues to “Mike,” and “I worked with Mike, he is excellent” does not join to Mikhail when someone searches for you two jobs later. The hallway reputation is the one that gets you hired, and it is now keyed to an alias with no foreign key back to the person who earned everything before.

Second, you pay a runtime tax. You answer to a string that is not your key, and the lookup is not free. Someone calls “Mike” across the office and you respond half a beat late, looking distracted, because that is not the index your brain searches first.

Third, and worst, the flinch compounds. Every introduction where you pre-surrender (”it’s hard, do not worry about it”) teaches the room that your identity is negotiable and their convenience is not. You did not just rename a record. You handed the room write access to it.

Views, Migrations, and Corruption

Steelman the other side first: choosing an alias can be agency, not surrender, when you are the one who authors it, and insisting on full fidelity everywhere, correcting every barista and every badge printer, is its own tax, one that can exhaust you faster than any mispronunciation. That objection is real. Let it land. The engineering answer is still not maximal fidelity everywhere. It is knowing which of three operations is being run on your record.

A display name is a view: a short, stable handle you chose yourself, documented and consistent. There is nothing wrong with offering one. Plenty of languages compress names for daily use; yours probably does too. The view pays the same runtime tax as any alias. The difference is that you priced it and chose it: consciously weighed, not defaulted into under room pressure, even if the choice happened on day one, since timing never mattered anyway; authorship was always the whole distinction. Choose it, and you keep the key. Skip that step, and the room writes it for you.

A real migration is legitimate too. Some people choose a new name deliberately: changed everywhere, legal documents included, never looked back. Complete, consistent, authored by the owner of the record. If that is what you actually want, run it properly and own it.

What “just call me Mike” produces is neither. It is the migration from that first-week offer, run the way bad migrations run: one table updated, no transaction, no cascade, nothing else told. That is not a migration anymore. It is corruption: a second identity created for other people’s convenience, updated nowhere, joined to nothing.

So run it like an engineer. Keep the primary key canonical everywhere it is written: email, Slack, LinkedIn, bylines, the org chart. If you want a spoken alias, pick it yourself, once, and make it derive from the real key, not from the local grid’s laziness. Then ship a pronunciation API: a two-second decode hint (”first part rhymes with X”). Offer it once. Correct twice, without heat. After that, tolerate minor mispronunciation: it is a lossy read at the display layer, like a rounding error in a view, not a write to the key. Correct only the people who matter, and pick your fidelity threshold on purpose instead of defaulting to zero.

And if you manage a team: you run the parser now. Getting a name right is a two-second fix that tells an engineer their record is intact here. Getting it lazily wrong, or renaming people at the door, tells them the schema belongs to you.

The Request

This week, audit your stores. Email display name, Slack, LinkedIn, GitHub, the byline on the last doc you shipped. Is the key canonical, or did the migration already run without you noticing? Decide your policy on purpose: full fidelity, or one deliberate, self-authored alias. Then correct exactly one person who matters, with the decode hint, and watch how cheap the fix actually was.

Then tell me in the comments: what did the local grid do to your name, and what did you let it do? And if you renamed yourself years ago, tell me which operation it was: a migration you ran, or one you suffered. Do you actually know the difference? Own it.

System Library

The Talk: Key & Peele: Substitute Teacher

The canonical sketch: a teacher mangles every plain English name in the room with total confidence, and it is the students who must adapt. The exact power dynamic of name-mangling, run in reverse. Watch who gets to be wrong.

The Think Piece: Falsehoods Programmers Believe About Names by Patrick McKenzie

Forty assumptions systems make about names, every one false. Read it twice: once as an engineer fixing your own forms, once as the person whose name is the edge case the local parser keeps corrupting.

The Concept: Primary Key

The database term this post leans on: the stable unique identifier every other record references, the one value you do not casually rewrite. That is what a name is, named precisely.

System Status

Theory is for brochures. Engineering is for survival. If your reputation is accruing to an alias you never chose, or your team keeps flattening people into whatever is easiest to say, I provide Strategic Debugging and Mentoring. Review the operating parameters at weivco.com.

Elsewhere: I write about building software with AI at The Old Man and the AI, and I build Fractbox, a browser-based 3D fractal engine.