I wasn’t sure whether I should write this article now, or leave it for later. Why? Because this summarises the entire concept of Human Side of Code (HuSOC). Am I giving up the golden egg too soon? Maybe. However, I ultimately decided that writing this now, putting the foundation of HuSOC out there, can only help HuSOC grow. It provides the basis for all subsequent articles, and an anchor to which I can always return if in doubt.
So, let’s jump in.
I’m a pretty decent developer (bold start I know, but bear with me), certainly not the best but perhaps above average. I taught myself to program at 9 years old by reading a book on Delphi (1.)
After Delphi, I picked up BASIC, VBScript, C#, and JavaScript. All mostly dependent on whatever project piqued my interest at that time. I started, along with my best friend, a game development “company” at 13 with the lofty ambition to build an MMORPG. This, of course, failed. Despite building up a team of 8 or maybe 10 at its peak, we were only 13 and knew close to fuck-all about running a team/managing a business. But! The code side of it was pretty decent. Since then I’ve worked as a full time developer, a database administrator, moved over to the commercial side as a Business Analyst and now, almost 20 years after I first picked up “Delphi in a nutshell” (2.) I’m a Head of Development at the 3rd largest automotive dealership group in the UK.
Why am I telling you all this? Because it has almost nothing to do with why I have had the career path I’ve had. My ability to write code is not why I’ve been promoted.
My ability to communicate and explain those lines of code. That’s why.
My ultimate goal with HuSOC is to help software engineers improve, and get promoted. But not through teaching you the latest developer trends. Through helping you improve your communication skills, and build relationships. I truly believe that’s the secret to unlocking career growth.
Side note, if you’re not that interested in career progression then instead I posit this focus on communication will make your existing job easier. Less stressful. More enjoyable. And that’s a valid focus as well!
Right, so, that’s a lot of preamble without any true substance. Let’s dive into the title of this article. What do I mean when I say “you’re the expert, not them”? Well, mainly, I’m referring to how you handle and respond to questions. Questions which you might deem as dumb, or silly, or a waste of time. In my experience these questions are usually coming from outside your department. Let’s say from the legal team, or the marketing team. Someone who isn’t a software engineer. And therein lies the secret. Stop expecting them to know all your technical lingo. Stop expecting them to know the intricacies of development or ins and outs of your specific tech stack.
“But I’ve already explained that to them! Multiple times!” I can just hear you screaming. Because I used to scream the exact same thing.
Here’s a little perspective shift for you. If you’ve explained it multiple times, and they’re still not getting it, maybe the way you’re explaining it isn’t the right way.
One more time for those in the back!
If you’ve explained it multiple times, and they’re still not getting it, maybe the way you’re explaining it isn’t the right way.
For the most part, the people you’re working with aren’t dumb. They’re just not developers. They’re not experts in your field, you are. They’re probably experts in their field, and each one of them will need a different, unique, bespoke and personal approach to explaining an idea.
Taking my above example, the way you’d explain a concept to a lawyer will need to be different to how you explain it to a marketer. Because their thought processes, knowledge bases, and experiences are all different. Learning to adapt your communication style to different people’s needs will be the number one biggest shift in your professional relationships and overall job satisfaction.
So what are some actionable tips you can take away from this article? How can you start adopting this mindset shift?
Create space for questions
Often people are too nervous to ask you to clarify something. Maybe that’s just how they are, but we also need to be honest and ask ourselves “is this the environment I’ve created?”. Instead of waiting for questions, or assuming people understand, finish every explanation with “Does that all make sense? Are there any points you’d like me to go over?” or perhaps even the direct “let me know if you want anything explained in a different way.”
By creating the space for people to ask questions, and showing them they’re not just going to hear the same spiel again, you might be surprised by the positive reactions.
Also the narrowing of options, “was there any specific parts of that you want me to cover in more detail?” is a good approach. It allows people to ask for clarity, without feeling like they come across as stupid for not understanding anything at all.
Challenge yourself
Make a game out of it. The next time you find yourself having to explain something, try to do it by not including any buzz words, three letter acronyms, or specific names.
A variable is now a bucket. An array is a group of things. A function is a bit of reusable code. A database is a library. An API is the postal service for software.
I don’t know how effective any of those analogies would be, but it might prompt new questions. And it will force you to rethink how much basal knowledge you’re expecting your listener to have.
The classic “explain it to a 5 year old” is an oversimplification of this idea. But there are many ways to have fun with your explanations, the above is just one idea!
Book some one-to-one time
People don’t like to look dumb. This usually comes across in meetings as “yup, totally understand!” or just blanket silence. So instead, jump on a 10 minute call with someone after the call.
“Hey so-and-so, I’m trying to work on my communication skills and wondered how you found my explanation of complex-idea-here. Was there anything you think I could’ve explained differently to make your life easier?”
This takes the focus off them not understanding, and instead onto you and how you can improve. Over time you’ll build up a large library (or is it a database?) of this feedback and notes. Common threads. Individual requirements. Difficult topics. And all of that helps to turn you into a better communicator.
In conclusion…
If you’ve explained it multiple times, and they’re still not getting it, maybe the way you’re explaining it isn’t the right way.
Remember that people aren’t stupid, they’re just not experts in your field.
As an aside, albeit an important aside, the above applies not only to other departments, but also to junior developers!
Treat people as people, with respect and integrity, focus on your communication style. You’ll be surprised how quickly your job satisfaction increases, frustration decreases, and maybe, just maybe, the promotions will start to come.
Footnotes:
- While writing this article I took a look at Delphi again, fully expecting it to be dead and forgotten… but no! It’s most recent release was April 2024 (I’m writing this in August 2024) and honestly I might spend a weekend building something in it!
- "Delphi in a nutshell: a desktop quick reference” by Ray Lischner, published in 2000