How To Communicate With Software Engineers So That They Understand You
Two helpful frameworks to Win Friends And Influence Coders
Software engineers, like lawyers or doctors, have their own way of talking about what they do for a living, the problems they face and their potential solutions. Unlike lawyers or doctors, however, engineers of software are a fairly recent phenomenon of human labor, one that has a relatively short history.
It’s hence not surprising that software engineering hasn’t really bled into the cultural aspects of our world. We have TV shows like Suits, House, even George Clooney was Dr Doug Ross on Emergency Room back in the 1990s, but shows that revolve around the work of software are only in the realm of comedy, like The IT Crowd or Silicon Valley.
There is a communication breakdown between engineers and the rest of society, despite the fact that software is not inherently more difficult than medicine or law. That’s because software engineering sits on top of communication frameworks that are completely alien to those who do other things for a living.
To make matters worse, communication skills are a rare trait among programmers: so much so, it is considered a key feature of those who are the most successful. You’re better served by assuming that the burden on making things clear between you and your engineer team is on you; some powerful dynamics are in play so that the software industry selects for people who prefer the consistency of the computer to the messiness of human affairs.
Luckily, there are two modes of communication, low hanging fruits of ways to bridge this gap, that are effective for non-engineers who want to discuss meaningfully about the interplay between their jobs and how engineers are helping them via software. These are The Spreadsheet Analogy and the Given-When-Then framework.
The Spreadsheet Analogy
The Excel spreadsheet is by far the most widely used piece of software in the entire planet. More fiction has been written on it than on Microsoft Word. What passes as tabular data and some few basic functions to connect the cells that contain that data is indeed the most successful end-user programming language.
So my first piece of advice to non-engineers, when they’re coming to me with a problem for which they believe software can be used to solve, is: “can you express what you need on a spreadsheet?”. I don’t require them to build a prototype on Excel, but at least have some idea of roughly how they would use such a prototype, what cells would be inputs, and what outputs would they expect from it.
Being a programming language, spreadsheets benefit from the expertise of engineers, but it’s so popular that most non-engineers have had sufficient exposure to it. I’m surprised that this method of communication is not used more often.
Given-When-Then
A second approach, which overlaps with but is independent of the first, has to do with testing. Spreadsheets, by construct, allow you to see intermediate steps as you code along, so that at every point in time you have a clear picture of whether the flow of information from the initial input to the desired outputs is correct.
Software engineering, unlike simple coding, combines the process of writing software with the techniques and practices that ensure reliability (anticipating when things go wrong), scalability (admitting a growing user base) and maintainability (facilitating the addition or change of features).
These three fundamental ideas permeate the use of software tests, which is a scaffolding around the working software whose goal is to guarantee that the specification of the working software is satisfied. Tests consist of small pieces of code that run parts of the software product, each one checking that certain inputs produce certain outputs consistently.
Testing never runs as part of the “real” software product, but engineers are dependent on it to check the gazillion situations that the product is going to be used for, to avoid having to manually check for every single scenario upon making even the smallest change.
Engineers think about software in terms of testing, and the single most useful paradigm to talk to engineers about their work is to frame the conversation around a potential test.
What kind of conversation is that? One that has the following structure:
Given a certain set of inputs…
When someone uses the product on a particular way…
Then some result must happen.
This “specification by example” provides a shared language between engineers and non-engineers to speak clearly, in mutual respect to each other’s part, about making the product successful.
Software’s Ailing Mythology
It’s been more than six decades since the computer was first put to work on a commercial setting. It is a superstition that code is seeing as difficult: it’s just information, flowing from one side to another, not differently from modes of communication that involve humans talking to humans.
I hope that these two frameworks help you communicate with engineers better and understand what they do. They’re probably looking forward to telling you all about it.