RAMÓN: [Laughs]. Have you ever been in a meeting like this? Like jargon is being thrown all over the place, and you don't quite understand everything being said, and you feel a little lost but also nervous, you don't want to interrupt the flow, and you're afraid to ask. A lot of us have been there, and not all of us have been there, and what we want to do is address that, talk about the good and the downsides of using jargon at work, the cultural inclusivity that comes with that, but before I do any of that, Suze already did a little bit, but ...
TARYN: I would love to introduce you to my co-speaker and co-worker, Ramón. Based in Austria, originally from Chile, he's a developer-advocate at Suborbital, DevRel consultant, educator, so many other things, and general all-round amazing human.
RAMÓN: And it is MY esteemed joy to present an even better human! This is Taryn. They're a Developer Advocate and engineer at Suborbital, working with me, lucky me and all of us at the team. They're a community advocate, tech career mentor, and overall just a joy to be around and a good friend.
TARYN: Thanks, Ramón. Now, definition. Dog-fooding. Noun. The practice of using one's own products or services. Use it in a sentence "The Rust programming language is compiled using Rust. That is dog-fooding, right? "
RAMÓN: Before we get to the good and down sides, when you're using jargon and language overall, that jargon kind of goes all the way down. What we've done today is we've introduced — we want to introduce you to different types of jargon we've categorised like this.
TARYN: First up, we have tech jargon. This type of jargon can include things like "solid", "dry", terms that were created as software processes or development. They come from the tech development and communicate software development ideas.
RAMÓN: There is also business jargon, and this one was an interesting one for me when I started working out as a contractor, because I spent myself spent a lot of time freelancing here in Vienna, but then when I worked to doing more international contracting and permanent roles, I found myself working with North American companies in particular that use a lot of words, jargon that didn't sound like things I would have expected, like dog-fooding, sunsetting, bike-shedding. This is jargon that describes workplace methodologies or processes.
TARYN: Right. Next up, we have uncommon daily, but common in tech. This relates to English words that are used uncommonly in daily language. When learning English first or as a supplementary language, these words tend not to show up in conversation but appear frequently in tech.
RAMÓN: Next let's talk about acronyms! Who doesn't love acronyms, especially, when you don't know what they mean, and you're nodding along, right? Here is a fun fact: did you know the first use of OMG, or "oh, my gosh" — seems to be traced back to World War One, so 1917, in a telegram sent to Winston Churchill? These have been around for a while. We might think of them as necessary for the early days of the internet, but we've been using them for a while, in particular for synchronous time-sensitive communication to share ideas, especially when character limits were present. While these are useful, they can also be misleading, confusing, or depending on context could mean different things. More on that later.
TARYN: You might not think of emojis as jargon but they can convey a lot of meaning, and can be wildly different depending on the context. We will be covering the positives and negatives of using jargon at work, offer tips, goals and insights.
RAMÓN: Definition: rubber-ducking. Phrase. A method of debugging code by articulating a problem in spoken or written natural language. Used in a sentence: can I help you fix the bug you encountered by rubber-ducking with you?
TARYN: Is all jargon bad? Jargon definitely has its uses. Being included is not the same as feeling like you belong. Using common language with your team or workplace can make you feel like you're a part of something. Making Slack or Discord emojis as a team or company can create a common language. It can also achieve this using acronyms, internal terms or just general jargon. So we have on this slide here having a common exclusive language, but we just talked about being inclusive at work, so that doesn't make sense. But how having a common understanding with your team can create a sense of camaraderie, and it is not just for you. As written by Kathy Sierra, there is this wonderful quote: "Learning the technical jargon of a domain enables rich deeply rewarding service, and, yes, feels like a superpower". This extends to people too and who doesn't want to feel empowered in their work place?
RAMÓN: Here's the thing: can be helpful to have jargon. If wielded improperly, jargon can cause confusion over understanding and this ambiguity can lead to harm which we would like to cover next. When it comes to ambiguity, this can range from simple misunderstandings to harmful even ableist messages being sent. Let's start with the simple smile emoji. You might look at it and think how is that ambiguous? Hear me out. In some contexts, and depending on the person, the simple smile sort of a "don't worry about it" simple smile, can either be a friendly gesture, or can be ambiguous and be interpreted and passive-aggressive. Same goes for the fire emoji. Fire emoji can be a symbol of something being amazing, or something being on fire and we need to fix it.
TARYN: You know, Ramón, in pull requests, I've seen this emoji used a lot, and sometimes absolutely, it's used to represent something that is really good, this is on fire, this is great, or we need to get rid this code. It can be very confusing.
RAMÓN: Totally. Thanks, Taryn. But when it comes to greater harm caused, when symbols or jargon like the okay hand emoji which recently became adopted by hate groups to symbolise white supremacy as a dog whistle or a hidden symbol in public, this can create conflict when interpretations of the past, for example, in scuba diving, the okay hand can mean "I'm doing fine", usually scuba diving with partners when you're a beginner like me, and this means, "We're doing okay." In other cultures, like in a lot of Buddha statues in Thailand will use these as well. I'm not saying you're going to be texting while scuba diving, but you know what I mean!
TARYN: We talked about ambiguity and the harm it can cause. What about the awkward humorous things that can happen? When I first started as a little developer, I used to see "LGTM" a lot on pull requests, and I always thought this meant, "Let's get this moving", based on a pull request about to be merged, almost done, ready to go, and I also heard of someone who felt said, "Let's get this money" for pretty much the same reason, they get the product, the product makes them money. The most common usage of this term, however, is "Looks good to me". While this isn't a harm. Mistake, it means we're not speaking the same language.
RAMÓN: It can also come from the what the turn of phrase means. For example, ASAP — as soon as possible. Any fellow native Spanish speakers in the house will know that the term "right away" in Spanish can mean a wide variety of things. That interpretation of how soon is can be wildly different. Depending on the workplace and the culture, what happens if, say, a supervisor will tell you, "I need this done ASAP", are they saying, "I need you to stay extra time and make sure the day does not end until you get this done?" Hopefully, it means, "This just goes at the top of the priority list." This lack of clarity can create disjointed expectations.
TARYN: Absolutely. In the tech world, where a lot of very large companies came out of North America it can be easy to forget we're a global increasingly remote group of people operating outside of that area. As someone who didn't grow up in North America but did grow up in an English-speaking country with English as my first language, I struggle with North American publish like bi-weekly which can mean twice a week or fortnightly, which is once every two weeks.
RAMÓN: Same here, honestly. I'm originally from Chile, grew up in Austria, didn't have that much experience working with North American companies. Once I did, and I learned of all of these terms, I'm still thrown off by the term "John Hancock" which up until I learned what this term meant I thought was a character from American history, and the video, I knew them from the video game Day of the Tentacle, but it turns out it means "signature". We've got this jargon that came out of American business developments, particularly 19th and twentieth century, whose origins by now are kind of muddy, but are nevertheless cemented in business use. For example, dog-fooding. It's not actually confirmed where it comes from. There are different stories.
TARYN: Absolutely. So let's talk about adding context to context. So businesses have their own acronyms and companies internally create these over time. They become part of the work culture. If you have a lot of these, it might be worthwhile considering whether you need a glossary or documentation for these terms. It can also be useful to have a style guide which is used for both consistency, internally, and externally. Acronyms and internal terms can mean different things from company to company but also from industry to industry. Context is very important. Especially for acronyms. For example, when I worked on the railway as a signal engineer, we had our own alphabet, the signalling alphabet. The letter H stands for yellow, D is green, or clear. And these are used in electrical diagrams. They are used by signal engineers on the railway, but they're different from electrical diagrams used by electricians, which I also was! At one point! Both use symbols to represent concepts that can be different, fending on the context. If someone new was to join my team or industry, would they be able to look this up on their search engine of choice, find the information they're looking for, and understand what terms they're trying to convey? A good general thought is: can I Google this?
RAMÓN: I'm always amazed by these things, and, of course, the variety of experiences you have, Taryn. But something you said there. Somebody new joining a team. I think this is critical to what we are trying to say as well. This experience of feeling included and being given the space to learn and also try and understand the language of a work culture as you come in. Onboarding is a critical time to take a step back and examine what that language is like. And so, by doing so, expand and improve that company or work culture. Because here's the thing: no two onboarding sessions are alike. I mean, not only is the onboardee also different, I would say should be, but the onboarder, the person doing the onboarding, can be different as well, and having different perspectives can mould what that looks like. Making sure to talk about what language looks like during onboarding the our opinion is critical. If language is being used that is lacking context or ambiguous, or, worse, harmful, it is critical that we give that space, we give these people space to be able to talk about this.
TARYN: Not only does language evolve but our understanding and acceptance of that language moves forward too. Just because it was accepted in the past doesn't mean it's acceptable now.
RAMÓN: Absolutely. What do we do when we see a term needs updating? We've seen this a couple of times. There's been historically friction and pushback especially from folks of privileged backgrounds seeing times like "master branch" changed to "main branch", and what was done in order to make this considerably smoother is folks who had at least some authority in this, like, say, GitHub, and the GIT project made the default branch "main" in later updates to their systems, playing a huge role in rolling this out. As Taryn said, language evolves.
TARYN: One source of education for terms that are harmful is the self-defined app that looks you're encouraged to contribute to. There is an open collective and GitHub sponsors for this project.
RAMÓN: It also offers alternative terms which I find really helpful.
TARYN: Absolutely. Definition: bikeshedding, noun. The futile expenditure of time and energy in discussion of marginal technical issues. Used in a sentence: how many people do you think bikeshedded on the creation of that definition?
RAMÓN: [Laughs]. All right, folks. We've talked about the positives and negatives of using specific jargon in the workplace. Week kick off a conversation about how to thoughtfully and inclusively communicate. Number one.
TARYN: Opting for clarity. As tempting for software developers in software development to use abstractions or metaphors to communicate ideas, instead, let's try to embrace verbosity and be clear what we are trying to convey. I said "verbosity". Is that super clear? That means to give more information than we think might be needed.
RAMÓN: I love this, but, Taryn, just to clarify, are we saying that folks should write giant walls of texts and loads of paragraphs in order to convey ideas?
TARYN: We are saying try to share your ideas in a succinct way but be aware that prior experience influences our perspective, and not everyone is on the same page. And sometimes not even in the same book. Our second takeaway is state your intent. Intent is difficult to convey, especially via text. Intention is subjective, and as Kim said, impact over intention. The reception of a message or comment varies wildly depending on the situation. The person that sends the mention, the interpretation by the recipient, and the relationship between those people. Don't worry about it sent by a friend can be different to the same message sent by a co-worker. This is why companies have team-bonding events to help build relationships to make it easier to interpret a person's intent.
RAMÓN: I've got to say, the full stop in that sentence is throwing my anxiety for a loop!
TARYN: Absolutely. Punctuation can be anxiety-inducing for people. There are techniques for stating your intent with a little more clarity. As an example, in the autistic community, a lot of folks use forward slash s to convey sarcasm or write the word to avoid confusion.
RAMÓN: Next, let's talk about lending your privilege. Especially when starting out as I said towards the beginning of this talk, I found myself in a lot of situations where I was scared to ask about terms and I didn't want to interrupt the flow of meetings, and one thing I learned early on, which I've started doing now, is that folks who even though they might understand and have that clarity, will still ask for clarification, just to make 100% sure that everyone is on the same page. And I found this super empowering, because it even gives me as the asker, even though I have most of the clarity, it gives me even more clarity. For example, a couple of weeks ago, I was participating in a little mini conference about content creation, and one of the speakers mentioned "SEO", right? I asked, even though I knew, I still asked, "Hey, what does SEO mean?" They told me about what it means, search engine optimisation, how it is useful, and it lent more clarity, and other people said thank goodness you asked because I didn't want to interrupt.
TARYN: Thanks so much for doing that. It is so helpful to have somebody ask a question like that, even when you know the answer. Previously, I've been on a team, and the name of the team was an acronym, and I didn't know what it stood for. I was very embarrassed that I was on a team with a name I didn't even know.
RAMÓN: Gosh. Sorry to hear that. Did you end up finding out what it stood for?
TARYN: I ended up asking publicly days later and found out that I wasn't the only one. Lots of people didn't know what the name of our team was.
RAMÓN: I bet, folks, this has happened to lots of you before where you find out that later on not everybody was on that same page, nor having that clarity. If you can, do take an extra step to be able to ask those questions. The same goes for acronyms, as what an acronym stands for, or when you are writing them out, make those explicitly written or verbal. Next, we will talk about language feedback. As we said a couple of times already, having a work culture that encourages feedback, especially on language, helps us thrive. So here's an idea. Why not have dedicated language feedback sessions? For example, there's a book Docs for Developers — link coming up — where they suggest having audits of documentation. So if possible why not have language audits?
TARYN: Have you ever worked anywhere where they've done language audits like this?
RAMÓN: Not formally, no, but we have had discussions about evolving our internal and external language. You know how we mentioned about having a style guide earlier, this is something that we've gone back on the off and re-examined.
TARYN: Embrace change. Woo hear tech folks having a growth mindset, becoming less resistant and more adaptive to change. Language is no different. Whether in the workplace or your everyday lives. Historically, there's been words, terms, phrases, used in our languages and products that are harmful. As of 1 October 2020, all new GitHub repositories were created with a default branch name of "main" rather than "master", and as a community moving forward with language is very important.
RAMÓN: Finally, and this one is something that I'm very keen on, it is about listening. I find a lot of the time kind of an unsung hero of core skills is the ability to listen, and not just to listen, but to listen strategically. When we are working with our feedback, with other people, when we're working with other people, we are going to get feedback. And it is important to separate ourselves from that feedback. Try to listen to that feedback. Try to leave your ego at the door and process it accordingly. When you've caused harm, it's not about you, it's about the person being harmed. Remember, most of the time this isn't about you, but the language that was used. This is of course depending on folks having the space to voice that feedback. Remember, we use words, and we need to be conscious of the evolution of their meaning and context within our lives, ours, and other cultures. Definition: "bus factor", phrase. A measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus". Sentence: the glue code between the Android apps is only maintained by Geraldine giving it quite a high bus factor.
TARYN: This is where you come in, Dear Listeners. It's time to put your newly found knowledge into practice. First up, start by keeping a list of jargon you encounter. Observe the language used around you, be curious, try to think about when you joined a new work place, a new group of people, and see if you can recall anything that is confusing to you. Travelling or speaking to people from different backgrounds to yourself can make you realise some of the interesting things you might say that don't make sense to someone who don't make — they don't make any sense to someone who doesn't have the same experiences as you.
RAMÓN: Absolutely. To that point, how important it is to pay attention to the language that we use. I said before: a good healthy work culture should evolve and at the same time invite bad feedback. It is a good idea to be conscious not just of yourself and immediate team but a future potential team that might join you, take your place, and of course the audience that is exposed to that language. So take a moment and look out for your own phrasing of things. Pay attention to idioms, turns of phrase, or jargon, that are being used, how you came across these in the first place. You probably have been there before. You looked at language that you used five or ten years ago, and you've winced. You've been like, I should not have said that or put it that way. This is what we are talking about.
TARYN: Keep questioning things. Ask questions, and question things. If there is a possibility something said by yourself or the group you're in could be misunderstood, it is always useful to call it out and explain. And when language use is updated, question it. Why are we still using something that is harmful or doesn't make sense? Embrace change.
RAMÓN: Well said. Okay, folks, you've heard us, but you don't just have to take our word for it. We would like to offer the perspectives of many others who have worked in this or adjacent areas. Books! A couple of books here for you. Culture Map by Erin Meyer, Badass, and Docs for developer s. We also have a talk to you. Really, really great talk by Tatiana Mac called Building Inclusive Social Design Systems. The link is here at the bottom of this slide, and they also may be self- de fined app, really, really good resource.
TARYN: Here are more resource s to help start your learning journey. You can find the link to our slides here too. Yak-shaving. A seemingly endless series of small tasks that have to be completed before the next step in a project before it can move forward. An exceptionally long sentence! So I want to write a blog. In order to write my blog, I need somewhere to put it. I need to build my personal website. I need to build my personal website I need to ... wait, I'm totally yak-shaving at this point.
RAMÓN: We don't want to yak-shave any further! I will say TYVM ... thank you very much!
TARYN: Hold on, Ramón, we gave a talk about this. What is this?
TARYN: You're right. My bad. "Thank you so much, friends". You can find Taryn on Twitter.
TARYN: And Mastodon. You can find all of Ramón's contacts on his website. We would love to hear your questions and wish you a wonderful You Got This.