The IT industry swapped out master/slave and blacklist/whitelist, but words like orphan barely came up. A Korean developer's take on why inclusive terminology lands unevenly across cultures -- and what it means when AI is trained on the legacy.
I was running a DB migration with Claude when the word orphan showed up in the logs.
Orphan. That's what they call a child record left behind when its parent record has been deleted. The foreign key points at something that no longer exists, so referential integrity is broken. Technically, it's a precise metaphor. Abandoned data. A row with no link back to anything. But that word -- I couldn't help feeling it didn't quite sit right in Korean.
orphan shows upTurns out orphan is a term used in a lot more contexts than I'd realized.
git checkout --orphan)What they all share is the metaphor of "something left alone, with no guardian." In English, that metaphor lands pretty naturally. Literary references -- Dickens's Oliver Twist, Harry Potter -- frame the orphan as "the sympathetic protagonist."
But once you bring it into Korean, the story shifts. The Korean equivalent of slavery historically was the "nobi" system, with a social hierarchy of "cheonmin" (lowborn) underneath it. So when you translate slave into Korean as "노예" (noye), the first image that comes up is American South plantations -- which is a layer removed from Korea's own historical wounds. Translation rounds off the sharp edge of the word.
"고아" (goa -- orphan) is a different story. After the Korean War, there were massive numbers of war orphans, and the aftereffects still show up today -- international adoptions, orphanages, the weight of family-centered culture. The Korean word "고아" still reads heavy. If English orphan is a literary object of sympathy, Korean "고아" is a much more concrete word, one that stands on recent history. Same metaphor, but the felt weight is completely different depending on which society's history it's sitting on.
After BLM in 2020, the IT industry did a big terminology cleanup.
| Old term | Replacement |
|---|---|
master / slave | primary / replica |
master branch | main branch (GitHub changed the default in 2020) |
blacklist / whitelist | blocklist / allowlist |
black hat / white hat | malicious hacker / approved hacker |
Major projects like MySQL, Redis, Django, and Kubernetes rolled the changes out one after another. The Linux kernel adopted an inclusive terminology guide in 2020, and IETF also swapped out master/slave and blacklist/whitelist in RFC documents. But in that same wave, words like orphan, widow, zombie, and kill barely came up in the discussion.
What the industry reacted to most sensitively were mostly metaphors tied to slavery and racism. master/slave was direct, and blacklist/whitelist drew strong pushback for reinforcing the "black = bad, white = good" color association.
Words like orphan and widow, on the other hand:
dangling, unreferenced) that aren't as intuitive as the originalSo the discussion happened, but it never quite went mainstream.
sanity check is similar. The opposite of sanity is insanity, and there's been pushback against using mental illness as a negative reference. Google's and the Linux Foundation's style guides recommend validation check or consistency check instead. But in actual code and docs, sanity check is still used widely -- because the alternatives don't quite capture its specific nuance ("a quick once-over to see if things make sense").
Side note: I first learned the word
sanitythrough Sanity.io, the headless CMS, and I was oblivious to the psychiatric context for a long time. A case where a brand overwrites the original nuance. Stripe, Slack, Discord, and Notion are similar.
Here's a category-by-category rundown of terms that show up consistently across inclusive language guides from Google, the Linux Foundation, IBM, Microsoft, and others.
| Avoid | Use instead |
|---|---|
master / slave | primary / replica, leader / follower |
blacklist / whitelist | blocklist / allowlist, denylist / allowlist |
black hat / white hat | malicious hacker / approved hacker |
black box / white box | closed / open, opaque / transparent |
master branch | main branch |
grandfathered | legacy |
| Avoid | Use instead |
|---|---|
sanity check | validation check, consistency check |
crazy, insane | unpredictable, unexpected |
dummy (data) | placeholder, sample |
crippled | disabled, impaired |
blind to | unaware of, overlook |
dumb (terminal) | basic, simple |
| Avoid | Use instead |
|---|---|
manpower / man hours | workforce, person-hours |
chairman / foreman | chairperson, chair |
guys (referring to people) | folks, team, everyone |
| Avoid | Use instead |
|---|---|
hang / hung | stall, unresponsive |
kill (process) | stop, end, terminate |
hit (the endpoint) | call, access |
abort | cancel, stop |
| Avoid | Use instead |
|---|---|
powwow | meeting, discussion |
tribal knowledge | institutional knowledge |
spirit animal | favorite, mascot |
guru, ninja, rockstar (hiring) | skilled, experienced |
native feature | core feature, built-in feature |
Looking over this list, the thought that keeps coming back is -- terminology changes ultimately happen through the sensibilities of English speakers.
Code is written in English to begin with, so variable names, function names, error messages, and official docs all get built around English. Which means the questions about which terms to use naturally start from the discomfort native English speakers feel. That's also why most of the items in that list are rooted in English-speaking historical contexts -- Jim Crow, slavery, Indigenous Americans, the Roma, American psychiatric terminology. A word like abort, which English speakers handle carefully because of its abortion association, gets tossed around casually in Korean -- and that nuance evaporates the moment it's translated to "중단" (halt).
The other direction -- words that feel much closer in Korean, like orphan, widow, slurs aimed at disabled people, or expressions that discriminate by region or background -- don't have any place to land in English code or documentation. Since the medium of code itself is written in English, there's no real channel for that difference in felt weight to come through. That's why slave got renamed, and orphan is still orphan.
Some projects do use dangling, unreferenced, or stale in place of orphan -- expressions like dangling reference or unreferenced row. Consciously reaching for these in tools or docs made by Korean developers is one small option. Of course, going into 2025, as US big tech has been scaling back DEI initiatives, the inclusive language guides themselves have been drifting backward. Google pulled DEI language off its responsible AI page; Meta dropped its fact-checkers. Where this current heads next is uncertain.
The thing is, the thought that stayed with me longer while writing this was somewhere else. If seeing orphan made me feel "this lands heavy in Korean," the flip side is the awareness that among the words I use without a second thought, there's probably one that lands the same way for somebody else. Just as American developers were the first to feel uncomfortable with slave, and just as I, as a Korean, felt that friction with orphan -- going through the list of alternatives, most of those words triggered absolutely nothing in me. Not because I'm insensitive, but because I haven't lived the history that makes those words sharp. So I must have walked right past someone else's discomfort without noticing.
These days, there's barely a moment when I write code without AI help. Claude Code, Codex, Gemini -- they all train on enormous bodies of past code and suggest the most plausible next token. And most of that training data is code from before the terminology shift happened. Decades of open source piled up on GitHub, tutorials, Stack Overflow answers, tech blogs. The overwhelming majority of it is code from the era when master/slave and blacklist/whitelist were the "right answer."
So when I casually tell the AI to "set up DB replication," the statistically most common pattern -- master and slave as variable names -- pops right back out. The developer hits accept without thinking, the code ends up in some other repo, and it becomes training data for the next generation of AI. Even after there's formal consensus to change a term, the old term keeps coming back to life inside this loop.
That's a little scary. AI is a tool that reproduces the average of the past, which in a sense means it also works as a force anchoring norms to the past. When I'm typing it out myself, at least there's a moment to catch it and think "ah, this should be primary now." When I'm just accepting AI's autocomplete, that moment never happens. No awareness either. So as a developer using AI, I think there's a reason to pause one extra time. The variable name, the function name, the error message the AI just suggested -- from what moment in the past is this coming? Don't just take it; doubt it at least once.
The point isn't to memorize "which word is right and which is wrong" and use them like correct answers on a test. It's closer to a sense -- pausing once in a while to think about how the word I'm using might read outside my own culture, and which era's norms that word comes from.
Feeling that bit of friction with English terms as a Korean developer, recognizing that the English terms I use might land sharp for someone in a different culture, noticing that the words AI suggests might just be a rerun of the past -- all three end up pointing in the same direction.
There's no guarantee that what's fine for me is fine for someone else, and no guarantee that what's common is what's correct. We're already building on top of each other's work. The single word I choose to change ends up changing the default the next person receives.
Written by
PM & builder. Director of Sapienta.