DEV Community

loading...
Cover image for How To: Explain Coding Projects To A Team Of Non-Coders

How To: Explain Coding Projects To A Team Of Non-Coders

CodeCast
A New Form of Developer Media
Updated on ・4 min read

We've all been a part of (or have overheard) a conversation where you have no idea what someone is talking about. Perhaps you've tried to read a medical report given to you or your pet, and even though it was in English, it felt entirely foreign to you. This can be the case with the programming world as well. Trying to communicate with non-coders about specific coding aspects can leave them feeling lost.

Coding is incredibly jargon-heavy. Not only that, but the jargon can often differ in meaning depending on the language. While there are aspects to any coding projects that nearly anyone can understand, a lot of it requires you to understand the jargon. Trying to communicate with non-developers about your project requires you to find ways to explain it without using confusing jargon.

The goal of this blog is to give you tips and advice on how to effectively explain your projects to non-coding members of your team so that everyone is on the same page about what is going on in the workplace.

Explain the End Goal

Unless your project is incredibly developer-specific, try to explain the project in broad and general terms first like you would explain it to a potential user. While you’ll likely have to get into the specifics later, a general understanding of the end goal is vital for someone who is not familiar with code. It will help them be able to picture the smaller details and comprehend the more complex components by relating them to an overall picture.

If the end product is still slightly unclear, begin by explaining some features of what you’re currently working on, or explaining your overall vision for the product. Find some way to relay it to the other person that makes them as excited for the project as you are.

Use Analogies

One of the most effective ways to have people understand something is to compare it to something they might already be familiar with. While I'll go into relating it to a similar product later, don't get stuck on that if something similar doesn't exist or is too complicated. I’ll give an example of what I mean.

Say perhaps you’re trying to explain your role in the backend of a project to someone who doesn’t know anything about code. You want to convey to someone that your role in the project is building out a significant portion of the server. While this is simple to understand as a developer, we want to explain it in a way that has nothing to do with the project.

Firstly, knowing your audience is a great start. Explaining something to a tech-savvy person versus someone who hates technology will be very different. While most people who are familiar with tech will understand what a server is, someone who isn’t might be completely lost if you assume it’s an understood word.

Once you have a grasp on what your audience’s knowledge base is, you can decide what analogy will best fit. But with coding, one of the tried and true examples when explaining general client-server architecture is to use the restaurant analogy. So if you want to convey your role in the company and the project as working on the backend, it could be helpful to portray it as you being the “kitchen”. There is a great article that dives deeper into using this analogy for those that may be interested.

Regardless of your chosen method, choose an analogy that is simple and understandable.

Keep It Simple

One of the best things to remember when trying to explain a project or concept to someone less familiar with the topic is to remove anything that they don’t need to know. Don’t bog them down with information about the language and framework if they don’t need to know any aspect of it to understand it. Generally speaking, when having to explain a project to a non-coder, you're trying to explain what the project can currently do, or what it is going to be able to do. The more unnecessary information you provide someone with, the more likely they are to get confused.

It’s very easy to get excited and passionate about something you’re working on. Being able to convey that to other people on your team is important, but it’s important to not overwhelm them with any information they don’t need.

Show Them Inspiration

Very often, coding projects and software ideas come from a developer or team of people wanting more from a currently available software. Sometimes they wish a software had more features or a better sense of community, so they set out to make their own software that borrows some concepts and functionality while expanding on it with their own ideas.

This is best explained via social media. Essentially, the core of all social media is exactly the same, yet we have so many different applications available to us. You’ll also notice that when a company adds on a new feature, other applications scramble to stay relevant by implementing the same feature on their own.

This is not specific to social media and is the case with most software and applications. Unless you have an incredibly unique and niche product or service, there is probably already something similar on the market. Relate the product you’re going to be building to something else someone would have come in contact with, or can easily look up to see it working in action. Then explain how the software or application that you are building differs from it, and what features you will be adding.

All in all, the best way to describe something that is outside of someone’s knowledge base is to keep it simple and be able to relate it to things they understand already. Whether you do this through analogy or comparison, knowing how to communicate your ideas to non-coders is an essential skill as a developer.

Originally published at codecast.io by Amy Oulton

Discussion (0)