A Qualified Defense of Jargon & Other In-Group Signifiers

A Qualified Defense of Jargon & Other In-Group Signifiers

This essay is in part a response to an article I read this morning. I won’t link to the article, in part because I don’t want to diminish it by talking over it, and in part because the story that this article tells is pretty common — plenty of people have complained about exactly the same thing, myself included. The article in question told the story of a self-taught programmer whose unfamiliarity with certain terms and historical figures theoretically irrelevant to her work marked her as an outsider & made her uncomfortable in a professional environment. I sympathize — after all, I too was once a self-taught developer in over my head, and I’ve gone through the process of trying to work in an environment where my unfamiliarity with the shibboleths marked me as an outsider. I also don’t want to imply that her situation is justified — accidents of biology & history like gender, ethnicity, and childhood cultural background can make the bar for fitting into particular groups much higher than it should be. What I’d like to avoid is the shallow idea that we can just reject shibboleths altogether and solve all problems.

Jargon is a clear cut example of when a tool that’s instrumental for competency also acts as a shibboleth. Most fields with complicated forms of technical knowledge also have specialized vocabulary or specialized meanings for particular words; the general consensus surrounding the meaning of a particular word stands in for a vast chunk of shared knowledge that would be complicated to explain in non-specialized language. When someone says “O(n²)”, they are making a claim that, in order to be understood, implies a familiarity with the calculus of derivatives, instruction counting, how loops work, and the idea of worst case versus expected case outcomes. Working with someone whose familiarity with foundational concepts in your field is at the level of an outsider is nearly impossible: you need to act the part of professor more often than you do real work; if someone lacks familiarity with the terminology, your handle for figuring out their knowledge level is no longer usable. Autodidacts are already at a disadvantage here: the set of things they know is not the same as that taught by a degree program, and they can have large conspicuous gaps in their knowledge even when it comes to relevant material. When an autodidact is unfamiliar with a term, it’s hard to tell whether or not that indicates a gap in their competence that needs to be filled, taking up time and effort that could otherwise be applied to the ostensible end goal.

Even when a piece of jargon isn’t of direct relevance, familiarity with jargon is indicative of a shared cultural experience that reflects shared values and habits — some pieces of which can be highly relevant. Using a term like “dot file” when referencing a hidden configuration file indicates familiarity and comfort with the unix environment, which might extend to a familiarity with pipes, standard unix tools, shell scripting, basic unix system administration, the history of the free software and open source movements, unix-style development toolchains, a preference for classic text editors like vi & emacs over graphical IDEs, an understanding of the unix philosophy of small modular programs working together on text streams, a familiarity with and preference for irc over other similar communication systems, a fondness for beards, and the ownership of toys shaped like penguins or tennis shoe wearing demons. Someone who just says “config file” will not open the floodgates of spurious cultural associations. (Likewise with “home directory” versus “user directory” or “my documents”.) All of these associations are fuzzy: not everyone has equal immersion in the cultural ephemera related to some technology. However, there’s a set of expectations associated with use of terminology: kinship with a set of tribes with clear centers and fuzzy boundaries.

Similarly, familiarity with certain historical figures has cultural relevance that extends to philosophy with meaningful applications in work environments. Somebody familiar with Djikstra who only learned about him in school probably only knows about him in the context of graph traversal, but someone familiar with Djikstra’s mythology is likely to be familiar with a couple quotes: “asking if a computer can think is like asking if a submarine can swim” and “premature optimization is the root of all evil”. Even if misattributed & misunderstood, both those quotes have impacts on the way someone develops software that go far beyond familiarity with graph traversal algorithms. Someone who quotes Postel’s Law, similarly, has a particular philosophy that’s easy to identify. All of these philosophies have impact, though the value of this impact depends on the application: Postel’s Law was instrumental in both the widespread adoption of the world wide web and the horrible security shitshow that the world wide web can’t extract itself from.

This is all to say that culture matters and signifiers matter. If you’re working alone, it’s fine to focus only on the precise technical ideas that stand between you and your immediate goal; as soon as you start working with a group, an inability to code switch means your coworkers can’t predict your behavior, communicate with you efficiently about important things, or figure out what you need to know in order to do your job effectively. Hiring an autodidact is a big risk, which is why lots of places don’t bother — it’s not that a degree implies a high level of competence, but instead that a degree is a hedge against a low level of competence that would cost the company a lot of money; hiring an autodidact with big gaps in their understanding of jargon and culture is not merely a risk but an almost-guaranteed cost, even if the person in question has significantly above-average technical skills and work ethic.

All of this is a huge problem, because the tech industry has a number of problems related to a lack of diversity — particularly cultural diversity. We need to shake this industry up with outside ideas, and part of that is bringing in autodidacts who have experiences unlike those systematically manufactured by degree programs or accelerators. We need people who can point at the inconsistencies and stupidities that are passively accepted as normal by the monoculture. But, we need those people to speak the language.

If we don’t throw away shibboleths entirely, what are we to do?

My recommendation is: outsiders, know your enemy. If you’re learning to code on your own, pay attention to the mythology. Read the Jargon File. Read The Devouring Fungus. Read Hackers & Where Wizards Stay Up Late. Make sure that you have enough understanding of the history and culture to pass as a precocious newbie.

As for insiders: be conscious of the way shibboleths are being used. Just because someone doesn’t know the term you used doesn’t mean they are totally unfamiliar with the concept. Make sure you aren’t leaning too heavily on spurious associations: playing Tempest doesn’t really have anything to do with understanding depth-first searches, Stallman’s association with Linux isn’t much more than a series of accidents that don’t meaningfully impact the syntax of awk, and LISP’s vast mythology is mostly the product of it being really popular at MIT fifty years ago rather than some deep truth about lambda calculus. Make sure that, to the extent that you are using shibboleths as a proxy for competence, you are not doing so in a way that unfairly prevents competent outsiders from contributing meaningful work. And, especially, give the benefit of the doubt to anyone who isn’t a cultural fit for reasons beyond their control: assume that women & people who are neither white nor asian are competent, because everyone else in their lives will assume they are incompetent.