Translating Dolphin Speak
by Jeff Jia, Principal Engineer
It happens to us all at some point. You start excitedly explaining something to a colleague. You have just reached some sort of groundbreaking epiphany, or hit some immovable roadblock in your work.
You need to share this unprecedented illumination!
You need someone to help you break through this frustrating barrier!
But as you fervently and passionately explain your predicament, or your genius, you can see a light go out behind your colleague’s eyes. Why can’t they lend empathy or aid to your frustration or see the obvious beacon of your genius?
This happens all too often in the technical world when we attempt to use the insular, and to be honest rather poorly constructed, language of tech to communicate with the outside world. When attempting to communicate the importance of particular ramifications of a decision to a project manager, a UX designer, or a business analysts, we become stymied by the pitfall of what a former colleague of mine dubbed “Dolphin Speak.” People can tell what you are saying has intelligence behind it, but have no idea what ideas you are trying to convey. Intelligent people make intelligent sounds at each other constantly, but no communication is happening.
I have in my time been privileged to work with many talented entrepreneurs, designers, product managers and the like who could not write a single line of code. This does not make them any less intelligent, less capable, or less crucial to a project’s success. The communication gulf between the tech literate and illiterate is a problem prevalent in our industry. We are an assortment roles and disciplines divided by a common language.
Think of this in your every day life. Have you ever attempted to discuss sports with someone who has interest, but no experience? What about attempting to explain 80’s X-men continuity to someone who may have seen one of the movies? It simply isn’t productive to dive in an attempt to explain what is blocking vs charging, or what the Phoenix Force is to someone who has no foundation.
In our line of work we do not necessarily have the time, nor the inclination, to lay all of the necessary bricks to support a colleagues comprehensive understanding of computer science. How does one begin to bridge this communication gap?
Firstly, one simply needs to acknowledge that the people you are addressing to are intelligent and receptive human beings. I know this sounds needlessly banal, but we live in a world where the inscrutable, troublesome tech-person stereotype is prevalent to the point of cliché. Keep in mind that any designer, project manager, or really anyone you encounter, will have some degree of arcane domain knowledge locked away in their minds that would sound just as alien to you. A few seconds to remind ourselves the fact that a team is usually composed of competent people who want to do their jobs to the best of their ability can definitely help.
Secondly, it helps to step away from technical shorthand when discussing a problem. Looks like you’re about to miss an estimate because the database structure behind what should be a simple relationship is instead a byzantine nightmare of complex polymorphic relations? A project manager isn’t necessarily going to care about the eccentricities in the way one untangles polymorphic rails model relationships, and the difficulties inherent introduction a new one. However, if you instead explain that the foundation upon which you are building your shiny new feature is needlessly complex, and that time is needed to either simplify it, or to comprehend it in order to ensure a solid base for the new feature, that should convey the nature of your difficulty, and hopefully facilitate that all important spark of collaboration that may help you navigate through this particular morass.
In this particular area, analogy is a powerful tool. I know everybody loves to feel bilked by their high school SAT instructors, but the translation of technical domains is an honest to goodness real world use for all of those analogy skills that have been locked up in the back recesses of your mind since you were 18. If one reads “Design Patterns,” one will find it rife with analogy and simile. Observer, Dispatcher, Factory, all words in the common vernacular of software engineers, have their given names because of their similarities to concepts that are part of the broad human understanding. Specific problems and solutions you face in code should not be much harder to adapt to common experiences and nouns. For example, one of my favorite ways to describe the model/view/controller split of an average application is by comparing it to the setup of an old Nintendo. The model is the game console, which is where the information is stored, the view is the television by which the user can one can see the adventures of Mario, and the controller is the literal controller with which the user interacts with the game. The controller sends messages to the console, which in turn updates the image on the screen.
I should also mention, and some eagle eye readers may have spotted it in the paragraphs above, an awareness of with whom one is communicating should also ground what information one chooses to use. If working with a product/project manager, usually the important point of contention is time. If one is explaining a situation to design or UX, attempting to frame the issues in user impact is usually the most fruitful route. Different roles have different concerns over differing aspects of a project. Only by acknowledging the breadth of these concerns can proper collaboration happen. This practice also helps to trim the problems down to their most essential pieces. Not able to implement a particular type of input because of a strange bug in the Swing package of Java 1.8? Instead of focusing on how their implementation of listener will not register clicks on a three-button mouse, explain simply the difficultly of implementing said design. This will give the people with the vested interest in the design the information needed to make a value call, and help both sides cut to the hear of what is truly important. You may find out that it is acceptable to implement something much simpler. Or perhaps you will find out in fact that this particular eccentricity of behavior is critical to user experience, at which point it would be time to start looking at 3rd party UI tools, or even building something up from the AWT layer.
Lastly, be sure to lay that foundation your co-workers are lacking. I will continue to reiterate the fact that the people around us are generally well meaning and intelligent. While no one will have the technical vocabulary afforded to those of use have been building our ivory tower for years, it is possible for us to help lay some groundwork in order to elevate everyone’s understanding. With time and patience, it is possible to establish infrastructure to aid in the expedience of future issues. Every success in communication helps to add to this foundation. If the non-sports fans can understand what a blocking foul is, then one can explain the difference to charging, and then slowly build to the added twist of the restricted-zone (I make no claims that you will ever be able to explain the continuity of the Phoenix Force).
If you can successfully communicate the gordian knot like nature of a particular portion of the architecture to a project manager, then when new features that rest upon that code said project manager will have more understanding for the reasons behind longer estimates, or be more receptive to stories that devote time to unravelling that architecture.
I will leave you with this, what maybe the most obnoxious of my points that I have espoused, but none of this is possible without the acknowledgement of the competence of nontechnical people. Nowadays, it is nearly impossible to build software as a single person. Gone are the days where a lone developer can crank out a full formed piece of software in a matter of months. The crux of our industry lies in collaboration and teamwork. A little empathy and respect will go a long way in facilitating that collaboration and teamwork. I hope this article will help foster that collaboration in some small way, so that we can start communicating and stop simply making intelligent noise.
Stay tuned to this blog for more specific posts in this vein. I will be taking a deeper dive into such topics a refactoring, and gradations of testing and how to communicate these intensely developer focused topics to a non-developer audience.
