Nearly fifteen years ago, I left my home to serve a two-year Mormon mission in Minnesota and Wisconsin. But one does not simply walk into the “mission field”. They must first spend three weeks at the LDS Missionary Training Center in Provo, Utah, which is probably best known for its unlimited supply of Marshmallow Mateys.
In the sixteen-hour-a-day crash course of the “MTC”, one major recurring theme was on using language that is familiar to the listener, rather than Mormon terms and colloquialisms.
In fact, it’s quite easy to spot members of the LDS church that have had this training, as they tend to use terms such as “congregation” (in the LDS church, this is referred to as a “ward”), “lay minister” (“Bishop” in Mormon parlance), or “church responsibility” (known as a “calling”).
There are scores, if not hundreds, of such “insider” terms woven into Mormon culture. Imagine my disappointment after joining the church at age 11, upon discovering that not only was there to be no steak at steak conference, but also that stake conference was a two-hour-long marathon of back-to-back sermons.
The LDS church knows what many of its members do not: that the language you use has the power to invite people to participate or to shut them out.
There’s no “PTC”
Programming has a much larger, much more deeply embedded intrinsic language, except there’s no Programmer Training Center where ambassadors from the world of programming are taught this essential principle. Perhaps there should be.
One of my regrets is that at a prior company I never got to hold a training session I’d planned for our development team, where our accountants would come talk to them in tax code, to convey a sense of what developers often sound like to their coworkers.
It’s not that insider language is bad. It’s quite necessary. The fact that police communicate urgent information via short, numeric codes actually saves lives. For the rest of us, our jargon provides invaluable shortcuts when discussing complex concepts within a group that has a shared background and a similar level of understanding. Developers, in their efficiency, cram oodles of meaning into words and phrases that sound like total nonsense to non-technical folks.
But even knowing this, I often catch myself spouting jargon and terminology that draws blank stares from less-technical people around me.
Terms that shut out non-programmers
It’s hard to keep in mind that you’ve accumulated your vocabulary over years, or even decades, and that people around you may not share that same type or level of experience.
But even more difficult is the mindset change that requires modifying, defining, or even skipping terminology to accommodate people that don’t share your technical background. Here are some terms that triggered a sense of being “locked out” of programming conversations or intimidated me as a new programmer:
- Algorithm: That word’s pretty big for its britches, considering it just means “a solution” or “a way to get to a solution”.
- Abstraction: It’s a great term for programmers, but “stepping up/back a level” may suffice for non-technical folks.
- Interface: Another fancy way to say “the way two things talk”
- Parse/parsing: Another great term that is tough to unpack. The closest I can define is “to digest”.
- Boolean: It’s just true/false, except when it means something completely different.
- Design patterns: I don’t know how the Gang of Four did it, but they somehow created a naming strategy that is 100% guaranteed to make a non-programmer’s eyes glaze over.*
- Parts of your technology stack: Unless for some reason you need to explain a technology, its purpose, and its benefits and drawbacks, it’s not helpful to let non-programmers know you’re going to create a Git topic branch to migrate your denormalized serialized data to a REST-based document database while preserving your Solr indexes.
Those are just a few of many, many terms that can sound odd or intimidating to people. Even terms like “array”, “hash”, or “object”, which to programmers is like “flour”, “sugar”, or “eggs”, are an alien language to 99.9% of people.
Now, if you’re a developer, you may look at that list of terms that intimidated me and wonder why I didn’t just “get over myself”. I can assure you that most people, when confronted with unfamiliar language, are silently wishing for you to speak at their level (or worse, misinterpreting you or tuning you out entirely).
The danger zone: misunderstood terms
I could devote a whole, hilarious post to programmer jargon that non-programmers think they undersand (and before I was a programmer, I was sooo that guy). The danger here is that instead of tuning out, people may get a completely incorrect picture (think “steak conference”).
- API: For a thing that basically means “how you talk to my software”, this is frequently misunderstood.
- AJAX: I used to think this meant any interactivity on web pages. In all likelihood, so does your CEO.
- Object-oriented: I literally once told someone I was pretty sure it meant programming directly with graphical objects, you know, like buttons and stuff.
- Technical debt: This is too often used as “parts of the code I don’t like” rather than “remnants of the best way we knew how to solve problems at the time”. So nontechnical decision-makers often discount the entire concept.
- Refactoring: To you, it may mean “We’re paying down some of this high-interest debt.” To a stakeholder it means “I won’t get anything that I want while the developers play in a sandbox.”
- Scalable: To me, this means “able to handle occasional traffic spikes” while a stakeholder thinks it means “racks and racks of stock-photo-style servers, ready and waiting for our inevitable million users.”
In my opinion, these terms are fine, with the only trick being to make sure you toss in your definition to check that you have a shared understanding.
My favorite programming metaphors
There are some programmer colloquialisms that I will never apologize for. And in fact, each time I explain them to non-programmers, they’re grateful for having them in their lexical toolbelt. They’re also great because each tells a specific story:
- Yak shaving
- Cargo culting
- Bike shedding
If you’re not familiar with all of them (or even if you are), Matt Nielsen has written a terrific, laugh-out-loud funny post defining all three.
A path forward
Developers can’t even agree on the definition of terms among themselves, so what hope have we for a shared understanding with our non-technical cohorts? Well, like all language, it matters less what the terms mean and more what the shared understanding is of the people who are communicating.
Half of the solution can be handled by good process, and half is deeply personal.
Solution part 1: Shared definitions
Extreme Programming (guitar solo squeeedleedeedleedeee!) predates my career by a wide margin. But I love the concept of the “Metaphor” principle, which is similar to the “ubiquitous language” principle in domain-driven design, which advocates for a shared set of metaphors and language between the stakeholders (the problem definers) and the developers (the problem solvers).
I also think that non-developers and new developers are more than willing to meet somewhere in the middle. Stakeholders are quite happy to pick up technical terms when they’re core parts of the business or when they save time.
In my experience, the best results come from starting to reach out and show an interest in a business domain’s language, then slowly walking folks toward the technical implementations, bit by bit.
Solution part 2: Conversational empathy
The other half is in developing a specific kind of empathy: learning to have a running thought that wonders, “How are the things that I’m saying coming across to this person?” In doing so, you are forced to think from the perspective of the other person, to imagine what they hope to get from the conversation, and to think about what you’re saying that might trip them up.
But I really do believe that by adding one extra layer of thought during conversations, and periodically sitting down with stakeholders to nail down business-domain terminology, a developer can become as effective a force for good as anyone in the organization.
*I want to come up with design patterns with awesome names. The Sandwich pattern. The Exploder pattern. The Hug pattern. Who’s with me?