Speaking Technically: Characters and Personification
In bad science-fiction, characters often have a very serious conversation which is almost entirely composed of made-up words that mean nothing outside of the context of the show. “If we realign the plasma-matrix with the phase-conjugate diffraction array, we might- we just might- stop the alpha-wave generator from destroying the planet.” Even the most committed fan has a difficult time keeping their eyes from rolling back and the snores from coming on.
This phenomenon is what I call the technobabble effect, the most powerful soporific in three galaxies.
Well used, technobabble can lend flavor to a setting, and spur our imaginations. Where would Star Trek be without words like “phaser” and “warp drive”? Technobabble becomes a problem when the story stops being about the people, and instead becomes about the buttons they’re pushing.
As a technical speaker, this poses a problem: our stories aren’t about people. When I explain how Oracle’s cost-based-optimizer executes a SQL statement, it’s difficult or impossible to do the concept justice without delving into technobabble. There are no people here, just execution plans, database-statistics, cache-hits, optimizer hints, query block and predicate pushing. I can reflect on how this jargon impacts real people- end users and developers- but that won’t help illustrate the complex engine at work.
It gets even worse when describing our own software or architectures. Not only do we have the technical domain, now we add our unique business domain. I recently developed a domain-specific-language to allow users to build complex expressions for manipulating color data represented in the CIELAB, CIELCH, and CIELUV color spaces. When bringing new developers onto the project, I needed to walk them through the parser and dynamic code generation of the DSL, and give them a crash course on color space transformations.
This problem isn’t unique to IT. Explaining how the world works is a problem that dates back to prehistory, and our ancestors solved the problem elegantly with a technique knows as personification. For as long as human beings have been telling stories, we’ve been treating non-human things as if they were human.
Human beings are social creatures. Our brains are are finely tuned to watch other people, to respond to their emotions, to model and predict their behavior. Good storytelling uses this. If we give the audience memorable and well expressed characters, they’ll respond. We’ll get their interest, they’ll retain information better, and they’ll enjoy the experience.
By simply talking about software and infrastructure in human terms, our jargon ceases to be technobabble and becomes a character trait. We can discuss what our software thinks, what it wants. We can build a personality around the technical facts to communicate memorably and clearly. This is how we get others to understand and to care about technical subjects.
I had an index on a table, but for some reason, Oracle’s cost-based optimizer refused to use it. Now, the CBO is more than a little bit coy. It’s perfectly happy to tell me what it decides to use for an execution plan, but it’s far less open with how it reaches that conclusion. It’s like when your parents shouted at you, “If you don’t know why I’m angry, I’m certainly not going to tell you!” “If you don’t know why I’m not using that index, I’m certainly not going to tell you.” We do know that the CBO relies on the statistics, so the CBO is looking at the stats on this table and index- the distribution of values, the cardinality, etc.- and deciding that using the index is too expensive. And it might be right! Or, maybe our statistics are bad. This gives us a good place to start looking for ways to tune this query.
I didn’t explain every word- but I didn’t need to. I made the Oracle CBO behave like a character with a personality. The technical facts are accurate, and I’ve avoided oversimplifying or misleading the audience. Instead, I’ve mixed the technical details with personal language, with metaphor. I even gave the CBO a little bit of dialogue!
We shouldn’t treat human beings like objects. If we want to be understood, we shouldn’t treat our objects as objects, either. Give them a sense of self. Find their personality, let them act, let them talk. There are millions of little things you can do to make personification work for you. The most important thing is just to make that shift in perspective: treat your IT assets and software modules as if they were your best friends (or enemies).
Storytelling enhances every aspect of your job: debugging, requirements gathering, interviewing, learning new tools and platforms, knowledge transfer, and more! If you’d like to transform the way you communicate, sign up for my upcoming workshop with master storyteller Kevin Allison.
October 19th
1–4PM
Rehearsal Studios at CUBE PGH, 5877 Commerce St, Pittsburgh PA 15206
With less than two weeks left, seats are filling up fast. Get yours now!
Sign up today.
Other “Speaking Technically” articles: Failing Upwards, Driving Change, Detail Oriented
