My cousin and I had a brief conversation on Twitter the other day (although really, what other kind of conversation can you have in 140 characters or less?) about engineering terms that are considered jargon even when they’re convenient for describing less-technical situations. One term in particular, actually, but I’ll come back to that; it’s an interesting case. The conversation got me thinking about other places where tech-y terms have seeped into my day-to-day vernacular.

Bug resolution jokes aren’t uncommon among people who find them or fix them for a living. When someone logs a software bug and the developer or designer chooses not to fix it, there are a couple possible reasons. Maybe they can’t reproduce the bug (“Not Repro”). Maybe it’s not a bug in their own software, but rather a deficiency in the underlying operating system (“External”). Maybe it really is a bug, but fixing it wouldn’t be cost-effective or would destabilize the rest of the product too much (“Won’t Fix”). Or maybe what the tester thinks is a bug is what the designer thinks is how it’s supposed to work (“By Design”).  While they’re primarily used in technical contexts, they transfer to real life without too much trouble. Someone describes a complex problem that is less likely to happen than a lightning strike on a sunny day, and we’ll respond “Yeah… Won’t Fix, buddy,” with a chuckle.

One that’s become pretty common outside the technical field is “bandwidth.”  In the context of electronic communications, one meaning is the amount of data that can be passed along a communications channel in a specific period of time. Your internet provider may advertise that they offer a high-bandwidth connection, for example. Among my co-workers, I’ve also heard it used referring to their personal ability to take on tasks: “Let’s give that one to Mikey, he’s got the bandwidth right now.”

The term my cousin and I were discussing was “Namespace collision.” It’s not an intuitive name to someone who doesn’t write software code on a regular basis, and yet it describes a situation that just about everybody’s been in at some point. In a nutshell, a namespace is a context in which a particular word or phrase has a specific meaning that might be different outside that context. A namespace collision, then, is when that term is used and it’s initially ambiguous which meaning you’re referring to. This sort of thing happens all the time in real life, as illustrated by a conversation my husband and I had the other day:

Husband: “…and Mike brought waffles and the toaster to HQ on Sunday morning.”
Me, thinking: <Mike? Mike J.? What toaster? Why would he have–OHHH, does he mean Mike H. instead of Mike J.? Mike H. has a toaster that we’ve talked about recently, well, not really HIS toaster, which is why we’ve talked about it…>

In programming, occasionally you’ll have two functions with the same name, say “getSpeed.” If the compiler can’t figure out whether you mean the one that goes with the radar detector software or the one from the auto aerodynamics software, it will give you an error. Every programming language provides a way to designate which one you mean. In conversation, we resort to qualifiers like initials, or possessives, or rambling descriptions like “My co-worker Steve, you know, the one who flies model planes? Who has an office two doors down from me? Yeah, the blond one, that one.”

Everyone’s been there, but we (by which I mean my cousin and I, not the more general we-the-people; another unclear reference) couldn’t think of a general non-technical term that rolled off the tongue as easily as “namespace collision” does for us. “Ambiguity” gets close, but is itself ambiguous: does it mean simply an unclear qualification, or does it refer to a situation where there is no clear answer?

I think “no clear answer” is exactly what we’ve got here.

But in truth, sometimes it’s fun to have inside jokes making light of the challenges we get paid to deal with. I’m certain that engineers aren’t the only ones who make those kind of references. They’re just the ones that I’m likely to catch when they’re thrown.