Why the Best Programmers Are Linguists (Without Knowing It). What Do the Variable 'temp' and the Nickname 'Specs' Have in Common?

Artem Lakomov, a philologist from Moscow State University, applies classical linguistics to programming. He argues that naming conventions in code follow the same patterns as nicknames in human communities — a theory developed by Russian linguist A.V. Superanskaya.

Four Onomastic Models in Code

1. Naming "From Appearance" (The Diagnostic Name)

Terms like godObject and spaghettiCode are diagnostic names reflecting observable properties rather than function. Similar to schoolyard nicknames like "Fatty" or "Four Eyes," they describe physical or structural characteristics. Generic names like utils, manager, and handler indicate the author struggled to name something meaningfully. These are the equivalent of calling someone "Hey, you" — the name communicates almost nothing about the entity's true purpose.

When you see temp in code, you're looking at a diagnostic name that describes a transient quality rather than a meaningful function — much like calling someone "Specs" because they wear glasses. Both names describe an external attribute while hiding the essence of the thing being named.

2. Naming "From Things" (Metaphorical Power)

DataPipeline and Firewall demonstrate effective metaphor-based naming. These borrow familiar physical-world concepts to clarify digital abstractions. A pipeline carries data like water; a firewall blocks threats like a literal wall blocks fire. Strong engineers excel at finding intuitive, precise metaphors that communicate purpose instantly without requiring the reader to inspect the implementation.

The metaphorical model is the most powerful naming tool in a programmer's arsenal. When done well, it creates an immediate bridge between the unfamiliar (an abstract software concept) and the familiar (a physical-world object). When done poorly — like calling a module Octopus because it has many dependencies — it confuses more than it clarifies.

3. Naming "From Precedent" (Cultural Codes)

Heisenbug (referencing Heisenberg's uncertainty principle — a bug that changes behavior when observed), Yoda Conditions (inverted syntax like if (42 == x)), zombie processes, and daemon exemplify culturally coded identifiers. These names compress information densely and serve as markers of group membership — insiders understand the reference immediately; newcomers learn the culture by decoding them.

This model is the most "tribal" — it separates those who belong from those who don't. The name daemon comes from Maxwell's demon in thermodynamics, yet today most programmers use it without knowing the origin. The cultural code has been absorbed into the community's collective vocabulary, losing its original context but retaining its function.

4. Naming "From Narrative" (Scarred Code)

Names like legacyAuthFix, hotfixForTicketJIRA123, and tempWorkaroundForIE6 tell historical stories. These narratives warn future maintainers: "Here was a battle; complex decisions were made; proceed carefully." They preserve project memory, functioning as scar tissue in the codebase — evidence of past trauma that serves a protective function.

Every TODO and FIXME is a micro-narrative, a message in a bottle from a past developer to a future one. The best narrative names answer not just "what happened?" but "why was this decision made?" — giving future developers enough context to know whether the workaround is still necessary.

Three Practical Principles

1. Recognize Your Role as Name-Giver

Each identifier is an act of nomination creating meaning for your community, not just yourself. You are not labeling a variable — you are establishing a term that dozens or hundreds of people will encounter, interpret, and rely upon. This is the same responsibility a cartographer bears when naming a new geographic feature.

2. Think of the Reader, Not the Writer

Names exist for collective understanding. Ask yourself: "Will my colleague understand this without my explanation six months from now?" If the answer is no, the name has failed its primary purpose. Writing code is a solitary act; reading code is a communal one. The ratio of reading to writing code is estimated at 10:1 — optimize for the majority use case.

3. Embrace Semantic Completeness

Superior names fully answer "What is this?" and predict "How does it behave?" Compare archive_inactive_users_and_notify() (complete) versus proc_users() (opaque). The first name tells you exactly what the function does; the second forces you to open the implementation and read every line.

Example Comparison Table

Left-column names force code inspection; right-column names self-document.

Core Insight

"Programs are written for people," echoed from Donald Knuth's principles. IT's costliest problems arise from communication failures, not algorithmic errors. A poorly named function costs far more than an inefficient algorithm — the algorithm can be profiled and optimized, but a misleading name silently propagates misunderstanding across an entire team. Precise, meaningful names form the foundation of this communication, and the best programmers — whether they know it or not — are practicing the same art that philologists have studied for centuries.