Do you avoid micro-culture jargon and insider terms?

Code that relies on nicknames, abbreviations, or internal jokes can create unnecessary obstacles for new team members or future collaborators. Terms that only make sense to the “in-group” (like a specific project team or company department) can be hard to interpret, causing frustration and slowing down onboarding.

Instead, favor widely understandable names or domain-specific terms that reflect a shared understanding of the business or domain.

Imagine you’re working on a temperature regulation system and need functions to identify areas where the temperature has exceeded an upper or lower threshold. You write an enum to represent the state of an area that’s too hot or too cold:

enum ThresholdBreachState
{
  Hoth,
  Mustafar
}

Now, this is actually pretty awesome, and if I saw this in your code, I’d probably buy you a beer. But realistically, this is too niche a description, and the mental leap required to connect the dots is burdensome.

A more universally understandable version would be:

enum ThresholdBreachState
{
  MaxExceeded,
  MinExceeded
}

Let’s say you have two developers on your team who are unusually tall and short, colloquially referred to as Big John and Little Dave. You’re working on code to compress and decompress messages entering and leaving a queue and name the methods BigJohnify and LittleDavify. Although the prefixes may hint at the methods’ functions, this requires a specific knowledge of the team dynamic and could easily lead to confusion.

public byte[] BigJohnify(Stream input)
{
    //
}

public byte[] LittleDavify(Stream input)
{
    //
}

For instance, if nicknames are used ironically (think of “Little John” from Robin Hood), it’s possible that LittleDavify actually decompresses messages while BigJohnify compresses them. Did you spot the word "respectively" at the end of the first sentence? Anyone “in the know” might understand this, but it demands unique insider knowledge and risks being both unprofessional and confusing.

A far better method name pair would be CompressMessage and DecompressMessage. They are clear and concise to anyone reading the code, without the need for insider knowledge or the cognitive load of applying it.

public byte[] Compress(Stream input)
{
    //
}

public byte[] Decompress(Stream input)
{
    //
}