Throughout my software engineering career, I’ve struggled with and against jargon. Intellectually, I understand jargon as a set of specialized terms meant to facilitate smooth and precise communication, particularly in a professional context. It binds groups together: it’s the secret handshake, the side-long wink, the showing that yes, you’re in the club too, you belong. Experientially? I know the ways jargon can keep you out as you feel along, grasping for knowledge in the dark.

Let’s take recent example. I attempted to randomize an error message displayed in an interface. Randomizing the error message would shake things up a bit, make things feel fresh (this particular error message displays a lot). We decided that every, say, sixth time, a fancier, longer error message would show up. Unsure of how to solve this problem, I asked some colleagues how I could make sure that every sixth time, this message would display. Terms were quickly thrown my way: determinism, hashing, random number generator. Immediately, I’m out of my depth. Immediately. Fingers flying, I furiously searched:

> what is deterministic?
> what does non deterministic mean?
> can a nondeterministic random generator be stateless?

I tried to ask what I hoped were insightful questions based on approximately 45 seconds of reading (I know, I know), but confronting jargon is like that: not knowing what you’re saying, what you’re asking. I feel myself getting agitated —I’m not sure how to solve my problem, but I don’t want to bother my workmates with my questions. I’m my father’s daughter, after all: proud, and unfailingly stubborn. The conversation dries up. I’m not asking the questions right. It’s undeniably clear I don’t understand, and I burn with shame.

I came to programming late; self-taught after completing a liberal arts degree, and ruling out law school. I’d always been interested in computer science, but there was no structured way for me to learn it: there wasn’t a single computer science course offered in any of my compulsory education. In my second year of college (and finding myself still curious about computer science), I enrolled in CS101 — the most entry-level computer science course offered at my university.

On the first day of class, the professor walked wordlessly into the classroom and began writing on the chalkboard. He transcribed, almost verbatim, out of an O’Reilly Java programming language book we’d been required to buy. Instantly bewildered, I was deeply, thoroughly out of my element — in a way I flash back to sometimes, while staring at for-loops in my code editor.

The course had a lab component, and students were meant to complete ten programming assignments. We met weekly, in a computer lab with rows of bulbous CRT monitors sitting atop tables made of particle board and a water-stained ceiling. Draw a face, the instructions to the first lab read. The eyes should be able to follow your cursor around the screen. At this point, I lacked an understanding of programming fundamentals. Thinking about it now, I realize I never stood a chance. I asked the teaching assistant a series of frantic questions: What is a variable? What do those squiggly brackets mean? Why do I need to write the word “public” first?

Back then, I was the sort overachieving teen that things came easily to: I rarely struggled in school, especially over what I intuited were basic concepts. I hadn’t felt this kind of frustration before, the kind of deep-seated frustration that I’d eventually become intimately acquainted with in my future professional life, the kind of frustration software engineering forces you to face. After my slew of questions, the teaching assistant looked at me pityingly, and advised me to drop the class. I didn’t know then that I wouldn’t learn how to program in this class, a class designed for those who already knew how. It would be ten years before I tried again.

Even now, I find it hard to ask questions. Questions, after all, are the best way to defeat the feeling of exclusion jargon inspires. Questions are the way you ask to be let in. Still, I have to swallow my pride, and sometimes choke back hot tears when I ask about indexes, about why a specific algorithm is faster than another, or about known figures in computer science.

Once, I asked a colleague, Who’s Edsger Dijkstra? Out of nowhere (thanks, open office plans!), a second colleague screeched, almost comically: Yoooooou don’t know whoooo Dijkstra is? How? “I’m self-taught,” I replied, flustered. “I didn’t study computer science in school.” I hoped my voice had a bit of steel in it.

I’m quickly told about image processing algorithms, and how this second colleague used it in a video game he played once, he prattled on, proud of his knowledge. My mouth tightened, my heart dropped. I still don’t fit here, I thought. Finally, interminably, the conversation concluded, and we went back to work. Later in the day, the colleague who I originally asked about Dijkstra sent me a chat.

I’m sorry about that, he wrote.

Why? I asked. You weren’t the one who made me feel bad.

It takes too long for me to fully understand his apology.

Dijkstra once said, “Computer Science is no more about computers than astronomy is about telescopes.” Too right, too right.

Struggling with jargon has made me less selfish about what I do know, less inclined to feign incredulity when someone trusts me enough not to know something. I give away my knowledge, openhandedly. I try to speak plainly. I keep a running tally of the words I don’t know, the jargon that comes up in casual conversation at work.

I’m ashamed by this list, but it keeps me honest, grounded. I never want to make anyone feel like I did, when I didn’t know something. I try to be generous, but it feels self-redemptive, like stepping into the past and helping my younger self, somehow.

This essay could not have come together without the help and guidance of the following people: Alexa Guerra, Ibu Madha, Kyle Kingsbury, Sarah Dunning Park, and Charlie Park. Thank you: y’all are the real MVPs.