Engineering Culture — Use Precise Language

Language and culture are intimately related. Human communication is arguably one of the most complex negotiations in the known Universe ^{(citation needed)}.

A principal factor in assessing an organization’s engineering culture is reviewing how engineering resources communicate, both verbally and in writing.

Regardless of engineering field, any technical discipline that interfaces with humanity (very close to my personal definition of engineering) finds itself communicating ideas, operations, limitations, concerns, and recommendations with other engineers, scientists, technicians, and customers.

Technical, nuanced topics require technical, nuanced language that is unambiguous, detailed, and precise. The phrase precise language is the shorthand for unambiguous, detailed, and specific.

In most disciplines, imprecise language wastes time, money, and contributes to frustration. However, in disciplines responsible for human safety, imprecise language can lead to far worse consequences. Engineering culture, safety culture, and supporting language develops (better or worse) over time.

To someone not used to communicating with precision, up the ante a bit: consider the next written communication (email, technical documentation, log entry) responsible for the safety of a loved one. If ambiguity or inaccuracy are found, regardless of topic, harm will befall a loved one. A morbid experiment indeed, but history has fruitfully demonstrated ambiguity or imprecision harming somebody’s loved ones. How would your written words change? How would the messaging change to promote precision and avoid ambiguity?

How many times have you encountered the following in a technical work log?

“Restarted the system.”

Which system? Include a proper noun. At what time? Reference it in 24-hour format (UTC or not based on organizational standard). Did it restart normally? How long did it take? “Unremarkable” is a valid description, but still recommended to include objective measurements like duration or diagnostic outputs as available.

“Restarted SPIRE-3f8kz at 0628Z. Warning message FZ-128 was present on console, but Whiznut LED was solid until power down. Unremarkable startup sequence took approximately 7 minutes.”

How about this profundity?

“Troubleshooted issue.”

Anti-useful as a detail-devoid description, wasting 21 bytes (42 bytes in UTF-16) in a database somewhere.

Or perhaps you have listened to a blowhard gas on for a good minute launching a double-digit quantity of pronouns into the local ether without regard for aligning antecedents leading to am I the idiot? questions… “Did the quick brown fox land on his own mother…? The dog’s mother…? Or the skulk of maternal vixens…?”

Precise Language Matters

In contrast, has your wetware lexer ever tokenized the vocabular formulations of an individual who writes, speaks, and generally communicates with precision and detail?

1. “An application layer PDU sits in a TCP segment in an IP datagram in an Ethernet frame.”

Sounds a bit silly in a single sentence, but not when working toward resolution, on a whiteboard, or in an interview. (UDP PDU’s are also datagrams!)

2. “We will need two branch circuits to implement redundant A/B power in the cabinet. Each branch circuit should be fed from a separate sub-panel delivering nominal 240VAC 30A terminated on NEMA L6-30R. Two rack mount PDU’s (A/B) with NEMA L6-30P’s will be mated to the branch circuit receptacles and each PDU provides 6 IEC-C19 and 16 IEC-C13 connectors. For single PSU devices in the cabinet, a multi-branch automatic transfer switch will be provided with 8 IEC-C13 connectors.”

The electrician will love you. The requirements deity will love you. Some added difficulty here using the PDU initialism in a new context (another point of engineering culture — context matters, future post for sure) — not your mama’s protocol data unit but your daddy’s power distribution unit.

3. “Move that ACE up two lines in the ACL.”

Access Control Entry != Access Control List. Impress (or be) a network engineer worthy of the title by using the correct one in conversation.

4. “Allocate 4 vCPU, 32 GiB vRAM, and 32 GB primary vDisk.

• 32 GiB is 32 * 230 bytes
• 32 GB is 32 * 109 bytes

Which one is more bytes? Not a trick question.

How about another way. Would you rather have 10 Ki$ (kibiDollars) or 10 K$ (kiloDollars)? Knowing the difference is important should you find yourself on Computer Science Cash Cab.

It’s also important to be able to explain why a 1 TB disk drive (as printed on the sticker) shows up as 0.91 TiB in the operating system (hint: disk manufacturers use base-10 prefixes while OS’s use base-2 prefixes). Usable loss due to filesystem format is negligible in most filesystems.

The disparity widens as we march through the SI prefixes Ki, Mi, Gi, Ti, Pi, Ei. 1 EB shows up as 0.87 EiB, for example.

5. “In the HKCU hive, under the key ‘foo’ create a DWORD value ‘bar’ with value data 0xdeadbeef (3725928559).”

A Windows sysadmin should know the difference between a key and a value, particularly when automating registry operations with PowerShell.

Do Both

“I learned very early the difference between knowing the name of something and knowing something.”
— Richard Feynman

In the context of Dr. Feynman, I assert:

• Knowing only the name of something is posing.
• Knowing only something will lead to confusion.
• Good engineering culture knows and practices both.

Note 1: Richard Feynman is easy to idolize, and deserves the attention of every impressionable mind. The reference here is tongue-in-cheek and frankly an excuse to reference one of the finest minds of the 20th century.

Note 2: Richard Feynman also goes on separately, many years later saying “The real problem in speech is not precise language. The problem is clear language…” criticizing overly-pedantic language in an educational context to which I completely agree. Know your audience. Speak to people in language they understand, especially in an educational context. I’d also argue an engineer that doesn’t yet insist on or grok precise language a) has important mistakes to make or b) is not in the right field.

Value

Using precise language has engineering value — understanding correctly leads to being correct which leads to doing correct — critically important and predicated on precise language.

Using precise language has business value — less mistakes, less wasted time, less wasted money, improved reputation.

Using precise language has cultural value — in many ways a right-of-passage for budding engineers to learn terminology, gain context, and how to precisely speak and write. For the juniors and seniors alike, correcting each other for everyone’s gain (without malice) is a point of pride and regularly a teaching moment.

Using precise language has safety value — for those in disciplines with human safety factors.

Cautionary Tale: Continental Express Flight 2574

Continue reading a cautionary tale of how imprecise language, along with its well-known accomplice latent safety culture, killed 14 people on September 11th, 1991.