LaurieIn honor of my talk at Indy.Code() this week I want to talk about vocabulary and communication. I was having a great conversation the other day about the phenomenon of "cookie licking".
@MrTurnerj Haha ya, I didn't realize other people didn't use that term until recently. But I think it works really well! Cookie licking - when you prevent anyone else from getting something off the plate when you could never consume all of them yourself! 🍪11:53 AM - 10 Apr 2019
This concept can be applied in any number of ways. From the way an application is built to the transparency of the developer doing the work. However, I think the majority of cookie licking instances are done by accident. A lot of the time, it's just that no one else is able to understand what a specific engineer is doing. So they become the only person able to do that work by default.
Oh How Quickly We Forget!
Anyone remember what it was like to start in this industry? I got lucky, I went to school for (some) of it. So I knew what an IDE was, I knew the right terms for data structures, etc. But my first day on the job was still a different world!
This list could go on and on. In so many different directions. But there was such a breadth and depth of vocabulary that existed in real life coding environments! And half the time people would talk about them and I'd be lost.
This has only grown. Just think of all the cloud service provider tools...
Vocab as Gatekeeping
The problem with this never-ending revolving door of tools and names and vocabulary is that it makes it hard for those outside our industry to understand what we're talking about.
Unfortunately, there was a time where this was done on purpose. As a result, learning tech lingo is like learning another language, even beyond the code itself. So once you know how to translate between that lingo and layman's terms you've created pretty good job security for yourself.
Instead of ranting about all the reasons we shouldn't promote this exclusive vocbaulary, I'm here to try and help! I want to focus on just a few areas you and your company can cut down on the vocabulary necessary to do your job. This will help with onboarding, it'll help with handover, and it will ultimately decrease the bottlenecks around systems.
Acronyms
I have a million amusing stories about acronyms. But the reality is that we already know this is a horrible way to communicate, yet we do it anyway! If you're writing you NEED to define acronyms the first time you use them.
If you're speaking? I'd love an example of a universally known acronym that is shortened enough from the actual term to justify its use. I'm sure there or one or two. But I'm still telling you to define it the first time you use it! And for the most part, there isn't a good enough reason to speak an acronym in place of the term it represents.
Product Names
We are TERRIBLE at naming things. Which is kind of ironic given how much we harp on computer science students to use informative variable and function names. None the less, someone somewhere decided that product names were made for marketing and not for understanding.
Well, in this field we have a LOT of those. If you're building a tool for internal use only, please don't use a "fun" name. It doesn't help anyone.
If you're building something for mass consumption? I expect the very first line on your landing page to be an explainer for what it is and what it does. And not some marketing mumbo jumbo. I'm looking at you Puppet!
Don't Know What You Don't Know
The reality is that communication in engineering is so hard and "gatekeepy" in part because we work on a lot of concepts people don't encounter in everyday life. And we need names for those things!
There is no silver bullet for this problem. But the good news is that regardless of where you are in your career, we're all actively learning. Tech moves too fast for any of us to stay in one place for too long. This is actually a major benefit!
How do you learn best? What methods of communication are most effective and the least confusing? You know the answers to these questions.
...maybe try and remember that when you're the domain expert? Being cognizant of the potential for misunderstanding is likely to slow you down and focus you enough to be more easily understood. And even better, this mindset and positioning of yourself as a fellow learner makes you approachable, prompting those around you to ask questions.
After all, we're all learning from each other!
leffel 🌵🌺@devilherdue
my strongest skill as a software eng is my willingness to interrupt an entire meeting to announce “I have no fucking idea what those words mean, please explain”
there are *always* other folks who pipe up about being confused once someone else admits it first21:16 PM - 05 Apr 2019
I used to tell students “if you are confused, ask a question. I guarantee you someone else is just as confused but scared to ask because they don’t want to look foolish”
This goes beyond the classroom. If you don’t understand what someone’s saying in a meeting, ask questions.22:03 PM - 08 Apr 2019
