RM
Management · 10 min read

The Language Your Team Carries

Your codebase inherits language that nobody decided on. A practical lens for engineering managers on what those defaults say, and how to change them.

#management#inclusion#culture

I used to think D&I work happened in two places: the all-staff meeting and HR. Training programs. Hiring dashboards. That’s where the effort went, and I assumed it was enough.

Working at my current company changed that. They have internal guidelines on inclusive language: category breakdowns, historical context, and concrete alternatives. What struck me was how much of it was already being practiced around me, and how little of it I’d thought about before.

I started going back through code I’d shipped.

master branches. slave replicas. A blacklist in the networking config. man-hours in the project estimation template. A recurring calendar invite labeled “All-Hands.”

Nobody made a decision to put those words there. They were the defaults: inherited from the tool, copied from the documentation, used without thinking. Inherited defaults are worth examining precisely because nobody chose them.

What it looks like when a manager catches it

Our manager brought it up in a team meeting. We’d been using “SA” as shorthand for Security Audit in tickets and documentation. She pointed out that it could be read as “Sexual Assault,” and that for any team member who’s experienced that, seeing those two letters in a project plan or a Slack message could surface it unexpectedly. Her ask was simple: write out “Security Audit.” Don’t use the acronym.

She said it the way you’d flag a typo. No policy document. No follow-up thread. Just: here’s something we hadn’t considered, here’s the fix, let’s move on.

That’s the posture this kind of work requires. She wasn’t policing language. She was intercepting something that looked like nothing. A two-letter abbreviation. Before it became the thing someone had to absorb quietly and decide not to mention.

Why it matters beyond the terminology

Dr. Suzanne Wertheim, linguist and author of The Inclusive Language Field Guide, frames this as a core principle: inclusive language doesn’t lightly reference painful history or experiences.

The mental health example is the most direct one. When someone says “that deploy was insane” or “I’m so OCD about code reviews,” they likely mean no harm. Casual use still trivializes the real experience of people managing those conditions.

The same logic runs across all four categories below. Using slave in a database architecture diagram doesn’t mean anyone endorses anything.

But it uses that word casually, in a space where some of the people around you carry its history. It makes some people feel like guests in a room that wasn’t built for them.

The four categories

These terms cluster into four groups, each with a different root.

Socially-charged terms carry historical or social roots that assign moral weight to a group. Several of the most common ones in engineering look like neutral technical vocabulary. The histories behind them aren’t obvious, and that’s part of why they persist.

Gendered terms assume the gender of your users and developers. The default engineer in most technical writing is implicitly male, and that assumption accumulates across every doc, every API reference, every calendar invite. The specific replacements are in the table. The root to address is the assumption.

Ableist terms come from casual references to physical, cognitive, or psychiatric conditions. Wertheim’s principle applies here most directly: casual usage trivializes the real experience of people who live with those conditions. Malice isn’t required. The harm accumulates through normalization.

Technical terms have their own list, co-authored by Mallory Knodel and Niels ten Oever in an IETF Internet-Draft. These carry less social history than the others. The primary argument for changing them is precision: the alternatives say more clearly what the thing actually does.

Here’s how the most common substitutions break down:

Socially-charged

Language with historical or social roots that assign moral weight to a group, or assume one classification as dominant over another.

Avoid Use instead
master (branch, key, server)
main, primary

GitHub switched the default to main in October 2020; GitLab followed in 2021. Most new repos already use it.

slave
replica, secondary, standby
master / slave
primary / replica, leader / follower, orchestrator / worker
blacklist
denylist, blocklist

Black = bad, white = good is a moral coding that predates computing by centuries. The alternatives are also more precise about what the list actually does.

whitelist
allowlist
brown bag (session)
lunch and learn

References the brown paper bag test, a colorism-based gatekeeping practice used in some Black American social organizations. Skin tone was judged against a brown paper bag to determine inclusion. The phrase carries that specific history.

grandfathered
legacy status, historical

Traces back to 'grandfather clauses' in post-Civil War US legislation designed to disenfranchise Black voters. SCOTUS struck them down in 1915. The phrase survived in everyday usage while the history faded.

Gender & Orientation

Language that assumes the gender of your users, developers, or colleagues, or uses sexual orientation as casual shorthand. The default engineer, in most technical writing, is implicitly male.

Avoid Use instead
manhours / man-hours
person hours, engineer hours, staff hours
manmonth / man-month (MM)
person month

MM is a standard estimation unit in Japanese project management. Person month (PM) works as a direct replacement.

manpower
workforce, labor
guys (addressing a group)
folks, people, everyone

Feels casual and inclusive to people who grew up using it that way. Lands differently for women, non-binary, and gender-nonconforming people in the room.

he / him (generic user in docs)
they / them
'that's so gay' (as a pejorative)
don't use

Using 'gay' as a synonym for bad communicates that being gay is less desirable. Regardless of intent.

Ableist

Language rooted in assumptions about physical, cognitive, or psychiatric ability. Includes terms that casually reference disability or mental health conditions.

Avoid Use instead
all-hands (meeting)
all-staff

Derives from the nautical 'all hands on deck.' Someone attending an 'All-Hands' who lives with limb difference reads that label in their calendar every week.

stand-up (meeting)
sync, check-in, catch-up

The meeting format doesn't require standing. The name assumes it.

dummy value
placeholder value, sample value
sanity check
confidence check, quick check
crazy / insane (informal)
unexpected, surprising, puzzling

Mental health terms used casually trivialize the real experience of people managing those conditions.

Technical / IETF

Terms from security, networking, and process writing that the IETF has flagged for replacement. Cleaner, more precise alternatives exist.

Avoid Use instead
man-in-the-middle (attack)
on-path attack, interception attack
kill (a process)
end, halt, stop, terminate
dark pattern
deception pattern

Harry Brignull, who coined 'dark patterns' in 2010, renamed his own site to deceptive.design and published a book under that title in 2023.

Most of these alternatives are already the default at the organizations your tooling runs on. The industry has moved this way. You’re updating to match an industry consensus.

Language isn’t static

You can’t maintain a fixed list and call it done. A term that felt neutral in 2008 carries different weight now, and the people joining your team today bring different contexts than the people who wrote the original code. Dr. Wertheim frames the practice as developing an ongoing sensitivity to what language asks of the people who encounter it.

That’s why having this conversation with your team matters more than quietly swapping terms in PRs. Name the principle once: we try not to let our defaults reference histories that aren’t ours to use casually. Then the work becomes something your team owns, not something you manage alone.

What the manager actually does

The manager’s job is narrower than policing language in every meeting. If you call out every instance of “guys” in real time, you’ve lost the room before the point lands.

The job is to set the default.

New branch? Call it main. New config file? Write allowlist and denylist. When you’re reviewing a PR and see master/slave in a new file, leave a comment: “let’s use primary/replica here instead.”

If it’s already in old code, don’t make renaming the entire codebase a project. That creates friction around something that doesn’t need it. Make the better word the default going forward. The ratio shifts over time.

A few practical entry points

  • Leave it in code review

    When you see an opportunity, leave a comment with the alternative. Done once, it's a visible signal about how this team makes decisions. Done consistently, it becomes the default.

  • Frame it as a codebase health item in a retro

    "Are there terms in our code or docs we should update?" is an engineering question, not a political one. It belongs next to 'do we need to clean up the README?'

  • Update the templates

    PR templates, ADR templates, Jira estimation fields. If man-hours is in your planning sheet, change it. The next person inherits your choice without having to think about it.

  • Name your own learning curve

    I still catch myself saying 'guys.' Saying that out loud, not performatively but honestly, gives the people around you permission to work on theirs too.

On the resistance

You’ll hear “it’s just a technical term.” You’ll hear “it’s too much work.”

The first treats language as a fixed, context-free system. Words carry history. When the whole industry has already found workable alternatives, defending the old term because it’s “just technical” doesn’t hold up as well as it sounds.

The second is almost always overstated. Renaming a branch from master to main is a git branch -m and a push, once you’ve checked your CI configuration. Updating blacklist to denylist in a config file is a search-and-replace. The technical barrier is low. The resistance is usually social.

That’s the manager’s terrain. You clear the social path. You make it a non-event instead of a debate.

There’s a third thing you’ll sometimes hear, quieter than the other two: “I didn’t know.” That one deserves a different response.

The history behind some of these terms is genuinely buried. The goal is to raise the floor.

The work that stays

An all-staff meeting about inclusion is easy to give. Changing slave to primary in your architecture doc is an afternoon of work. But that afternoon is concrete and permanent in a way a presentation isn’t. It goes into version control. It doesn’t fade.

The manager’s SA example stuck with me because of how small it was. Two letters in a project plan. No policy document, no follow-up thread.

Just: here’s something we hadn’t considered, here’s the fix, let’s move on. That’s what raising the floor looks like. A choice, made once, that the next person inherits without having to think about it.

I learned most of this at work. I’m writing it down because it’s worth carrying forward.

Further learning