Dev Tales is part of a Heart Internet blog series showing that web developers are humans too. Any resemblance to any duck themed imagery, fictional or non-fictional, is pure coincidence. Honest guv. If you missed Part 1, you can find it here: How I became a developer.

In the world of development and technology things can get incredibly complex. Indeed from the casual onlookers perspective it could almost be regarded as mystical. Although a lot of advanced technology has made its way into the consumer market, a lot of the users of said technologies are completely oblivious to how they work. I recently introduced my friend to Dropbox so that he could better organise his life and he promptly described the whole thing as “witchcraft and sorcery”.

As developers, we frequently forget just how intricate and complicated the things that we deal with on a daily basis can be to the layman, myself included, and we also forget that we do not exist in isolation from the rest of the non-technical world. Even within Heart Internet, where our entire business is about technology, being able to explain technical concepts in a non-technical manner is a skill that is difficult to master.

I recently found myself in a situation not unfamiliar to developers everywhere. It was release day for the latest feature of our signature product and everything was ready to go. Hours before we were due to go live, we found that we needed to implement just a bit more functionality that had been missed originally. The problem was the feature was designed one way, and the change would require another approach – I needed to change the output of a particular function from a customisation that was abstracted far away using a variable I only had hold of in a niche scope. To get this feature implemented would require days of refactoring.

So I approached the Project Manager to tell her of my woes. The problem was if I explained my problem in the way that one developer would to another, I would lose her somewhere between the words ‘refactor’ and ‘nested callback’. So I took a different approach; I boiled down the problem to the core issues and explained it as simply as possible.

Me: “To change this, I need to know the value of x.”

PM nods

Me: “But I only know what x is when it’s over here”

PM: “Makes sense… so why don’t you….”

She then gave me an abstract version of exactly what I wanted to do anyway, and after talking about it she realised that it wasn’t going to be ready in time for release and planned accordingly.

The moral of the story is to simplify technical concepts as much as possible, and let them direct the conversation as they understand it to gauge how much they are understanding. The key to this approach is understanding and patience – even in my current role there are countless times when a senior developer will be explaining a concept and my eyes will glaze over, leaving me more clueless than I was before.

Without a doubt the most useful tool in a techie’s arsenal is the analogy. By taking a technical concept and placing it in an environment that is familiar to the listener, you can rapidly increase the chances of the person you are talking to understanding what you are on about.

A non-technical friend of mine once overheard me talking about APIs. Out of curiosity he asked me what an API was as he had heard the term used in the past. Of course he could have looked this sort of thing up, but generally the explanations are written for the tech-minded. An example from Wikipedia:

“In computer programming, an application programming interface (API) specifies a software component in terms of its operations, their inputs and outputs and underlining types. Its main purpose is to define a set of functionalities that are independent of their respective implementation, allowing both definition and implementation to vary without compromising each other.”

Helpful.

So instead, I created an analogy on the spot.

“An API is sort of like a shop-assistant. The shop doesn’t want you to be able to just go in to the warehouse and start looking through their stock in case you damage something. So they have a set of assistants out front with a pre-programmed set of things you can ask them. For example, I could say to the ‘Shop API’ – ‘I would like to know what red t-shirts you have in stock’, and he would shortly come back with a list. You don’t need to know how he got to that answer, but you know he is right”

Sure this trivialises a lot of points and smooths over the nuances of an API but that is information he didn’t need to know at the time. The analogy that I drew up gave enough information to give him a fundamental knowledge of what an API does – you make a request and you get information back. Of course the analogy breaks down if you start to pick at it, but it served me well at the time.

The absolute worst thing that you can do when talking to a non-techie is to bombard them with jargon. Technologically skilled people use jargon as a means to speed up communication, but when used with someone non-technical you risk alienating them and coming across as condescending. Using jargon just mystifies the mystery and all you end up doing is making yourself look like a know-it-all. Use simplified concepts and familiar language to get your point across in a much more efficient manner.

Giving people an idea of how technology works is never a bad thing, you may inspire someone to become the next Internet guru of a particular technology. Even at minimal impact, you’ll have another person to talk with about your passion for technology. I have been surprised how many people are curious about how the magic world of technology works, even if they don’t want to program it themselves.

It is very easy to be patronising, but even if the idea that someone hasn’t heard of an API appalls you, always try to be the friendly neighbourhood coder who enlightens them without belittling them!