Note: While writing this post, I looked back at a post I wrote entitled Understanding ETL to ELT by Going to Costco. That post does exactly what I say we should not do in this post. It takes a process and explains it using a metaphor that cannot hope to fully encompass what I try to say. I do think that metaphors can be somewhat useful when attempting to give a high-level overview of a subject, but I think I did it rather poorly in that post. As always, I want to make sure I check myself when writing anything that has the word “should” in it. As I look back at the aforementioned post, I don’t think it is very useful, and I hope to improve in my writing so that I follow a mindset more in-line with what I write below.
I spend a lot of time explaining Crossplane, Kubernetes, and distributed systems to people from all walks of life. I often find myself using metaphors to describe how a system works: “Kubernetes is like an overbearing boss, delegating tasks to different workers and then checking in to make sure they are carrying out the work as expected”. I also see many others, especially in the more niche fields of software, following this same pattern. However, over time I have found this to be the wrong approach. Jumping to the use of metaphors immediately makes assumptions about your audience’s ability to comprehend and your ability to explain, and it can “omit free knowledge”. Allow me to explain…
Do You Really Know Your Audience? Link to heading
I have heard about 1,000,000 conference talks that begin with: “Raise your hand if you are using X in production”. While this is an efficient method of gauging a room, it turns a spectrum of experience into a binary evaluation. In doing so, you are assuming that a group is more interested in walking out of your talk feeling confident than they are in obtaining new knowledge. When I listen to a technical talk, I love walking out with a long list of terms and having no idea what they mean. When this happens, the speaker has not only given me the knowledge that is contained in their talk, but also a large set of trailheads to embark on new learning adventures in every direction.
If you are concerned that lack of base knowledge will hinder your audience from gaining something from your talk, reconsider the track and description. Furthermore, conferences almost universally post talks on YouTube, and blog posts can always be revisited. If a portion of the audience is unfamiliar with your topic and you do not start from the basics, you should provide resources and directions for listeners to get up to speed after hearing your talk. When you do this, you do not have to dilute your material with metaphors that abstract, but you are empowering your audience to understand exactly what you are talking about.
Are You Competent to Speak? Link to heading
Yes. Yes you are competent to speak. Whether you are at a conference, writing a blog post, or being asked a question face-to-face, you are in that position because someone chose to listen to you or found you worthwhile to ask. If there are parts of a topic that you do not understand, feel free to say so! I would argue that it is much better to leave a few “this happens and I don’t know why” holes in a story than it is to abstract the entire process away. We should care more about giving our audience great content than we care about convincing them that we are intelligent. Imparting knowledge is a privilege. If you know something that is worth sharing it is highly likely that someone else took the opportunity to explain it well to you. You should strive to pass that gift along to your audience.
When adopting this mindset, I find myself both less nervous about speaking and more focused in preparation. If I truly care about the consumer of my talk or post coming to understand the material more fully, then I will take time to make it accessible without taking the shortcut of making it abstract. I also start to feel confident about sharing more often because I don’t have to make sure that I am an expert on a topic before I present the aspects I do understand. What I contribute can be just a piece to a larger puzzle that likely involves others who are much more knowledgeable than myself.
Did You Maximize your time? Link to heading
If you are using a metaphor to communicate an idea to your audience, a large part of your message is already known. The entire purpose of a metaphor is to use a process that is already well understood. If you start with a metaphor, you are either putting a cap on the amount of learning that can happen during an engagement, or wasting time talking about something in abstract terms that you will define precisely later on. For instance, if I start off by saying that “X is like a plumber…”, I have taken whatever X does and reduced (or expanded) it to what a plumber does, which by definition cannot be exactly like what a plumber does, or it would be a plumber itself. If I realize this and then go on to say all the ways that X is different than a plumber, then using the plumber analogy was futile and I could have spent that time simply explaining what X really is.
If I do not go on to explain how X is different than a plumber, then I cannot expound upon any aspect of X that is different than a plumber. Deeper concepts have become off limits because I have started our conversation by making X into whatever the audience associates with a plumber. I have lost vital control over perception because I have brought in thoughts and biases that have nothing to do with X. Now, context is clearly very important here. If you give a talk at a distributed systems conference and say “X is like a plumber”, it is very likely that your audience is able to discern that X is not a human and does not work on physical pipes in a water supply system. However, your audience might have different perceptions of what a plumber does, causing your metaphor to lead them to a conceptual model that you may not have intended. If you had simply told them exactly what X is, you would have much more control over what they believe to be true about X.
Conclusions Link to heading
Let me be clear: metaphors are not always a bad approach. Sometimes they are a useful abstraction when you have limited time or the audience doesn’t want to know exactly how something works. I don’t believe you should never use metaphors. However, I do believe that they are grossly overused in software. I encourage you to check yourself next time you come up with a brilliant metaphor and see if it is actually doing yourself or your audience a disservice. I would appreciate all of you holding me accountable in this area as well.
As always, please feel free to reach out with questions or comments on Twitter by tagging me or directly messaging me at @hasheddan!