Communication Is More Important Than Your Coding Skills
TL;DR
Communication is More Important Than Your Coding Skills
A few short months ago when I started writing on Medium I vowed never to write a post with a clickbait title. So, there you have it. The title is the thesis to this whole post. Feel no obligation to continue reading (reading only the title is a common practice anyways, right?).
Communication and Coding
There’s a famous quote attributed to Phil Karlton:
There are only two hard things in Computer Science: cache invalidation and naming things.
That quote is certainly true while purely discussing the topic of computer science. If we expand to include areas that use computer science though, it’s clear that communication takes the cake as the hardest part.
It Doesn’t Matter How Well You Code, If You Can’t Communicate
It’s true. Sure you need to be competent, but most developers already are, and have been for a long time. Communication is the skill that takes a junior, or medior, and makes them a senior. Or take a senior and makes them an even more effective senior. Communication is the skill that takes a good team member and makes them invaluable.
With that said let’s walk through many, if not all, aspects of being a developer and see why communication is important.
Pull Requests/Code Reviews
I hope you’re already doing code reviews for all new pull requests wherever it is that you work! If you’re not this is also something that can help take your skills to the next level. The opportunity to talk through your code with someone else and hear their perspective is extremely valuable and can help you learn a ton.
But at the end of the day, code reviews are only as valuable as you make them. You need to be able to clearly explain your thought processes and decisions to enable the reviewer to truly grasp the whole picture. Some coding choices might seem strange at first to a reviewer who lacks full context of the problem being solved. They will rely on your communication to decide whether or not you’ve found the best possible solution to a problem.
Design Reviews
At many companies, large projects will often start with a design review. This is a meeting with stakeholders (or just interested people) where engineering architecture and design are discussed to find possible faults, or potential improvements.
However much like the code reviews the efficacy depends on your ability to articulate your thoughts. If you have the most brilliant architecture for a new product or tool in your head, its development can be hindered by your ability to convey it properly to your colleagues. Why would your VP of Engineering choose to invest time into a project that you yourself cannot explain. In theory it should be much easier to make a deck for a new project, then to actually execute it. Being able effectively convey potential designs and project plans will help you develop better projects, and will demonstrate that you can be trusted with interesting and tough assignments.
Writing Documentation
Let’s be honest, writing documentation probably isn’t your favorite aspect of development. Yeah, me either. On the flip side, how amazing is it when you find an awesome tool (package, API, SDK, etc.) and it has awesome documentation along with it? An okay tool with great docs is always more useful than an extraordinary tool with no docs. Useful tools are only useful if you know how to use them.
With that in mind, you can boost the effectiveness of your own work simply by documenting it. That’s a pretty amazing thing, don’t you think? If you write decent code that does its job, and you can document it so that other people can easily use your code, it magically becomes 10x better code! Writing good documentation can be your X-factor.
Writing Comments
I’m sure you’ve heard that your code should be clear enough that it doesn’t require comments to be understood. Your variable names should be perfect. Line length should be no more than 79 (nice, round number) characters. Functions and/or methods should be no more than 10 lines long. Right.
If you’ve worked on a large software project you also know that it’s not always possible to adhere to this. You wish it were, but it’s just not. Sometimes a well-placed and succinct comment can really make all the difference.
Kevlin Henney is a really great developer and speaker with many interesting (and hilarious) talks on YouTube. In one of his talks he said something along the lines of “If someone can’t write clear code, what makes you think they can write clear comments”. It’s a funny thought (and was delivered perfectly and got a big laugh from the audience), but I don’t really believe it to be true. Development skills are separate from communication (in this case written) skills. I’d argue the reason that comments are frowned upon is because most of them aren’t effective, not that they can’t be effective. If you stumble upon a difficult piece of code that takes you a while to figure out, and can leave behind a short, sweet, and helpful comment, you should go for it! The person behind you will praise your name.
Managing Expectations
Have you ever gotten an impossible ask? A feature request that would require more computing power than exists on the planet? A UI design that looks more like a Picasso than the Material component library your whole product is built on?
As developers it’s our jobs to make the magic happen. It’s not always clear to the folks giving you the work (be they product managers, executives, or whomever) what’s possible to do and what isn’t. It’s their job to ask, and it’s your job to answer.
Let’s say your VP of Product comes to you with an impossible new feature or offering. If you can’t explain to them clearly, in less-than technical terms, why something can’t be done, it switches from a technical problem to a you problem.
If you can explain in layman’s terms the technical limitations, they’ll understand that not everything they can dream up is doable. Plus you’ll be surprised at the ingenuity that arises when you get close to those limitations. You might just be able to dream up something better than your VP originally had planned.
Managing Timelines
Presumably every task you have has a deadline. Presumably a lot of those tasks aren’t done by that deadline. It happens to everyone. Especially in the world of estimates == deadlines, which is this world.
Managers know not everything will be done on time. It’s not (always) a problem if something is late, but it is always a problem if something’s late without warning. Delays should be communicated early and often. Emails, slacks, task management tools, ticketing systems, whatever you use. The more you communicate your status the happier your higher-ups will be with your work. That’s not to say everything should be done late. But if something’s going to be late, which is inevitable, let it be known sooner than later.
Job Interviews
It’s obvious that communication is important in job interviews. You have to answer qualitative questions about yourself, your past experience, etc. The HR portion of the interview as they say. However, what if I told you that communication is equally as important in the technical portion, including the dreaded whiteboard interviews.
That’s right! Even if you come up with the smartest solution an interviewer has ever seen, it won’t matter if you can’t clearly explain your thought process. This video from Google about how to answer Google interview questions demonstrates this perfectly. You need to have a good answer in an interview, of course, but it needs to be accompanied by an even better explanation.
The reason for this is companies are hiring you to be part of a team. They want to see that you can communicate effectively so that your PRs, DRs, documentation, everything we’ve touched on before, will be valuable to the entire team.
Going Forth and Prospering
It would be so simple if all we had to do as developers was code. It’s clear that communication is just as important as our coding skills. Luckily communication is also important for just about everything, and because of that there is an abundance of resources out there to help you improve.
Two great books I’ve read on the subject, that you might find helpful are:
How to Win Friends and Influence People — by Dale Carnegie
The Pyramid Principle — Barbara Minto
How to Have Impossible Conversations: A Very Practical Guide — by James Lindsay and Peter Boghossian
Just being aware of how you’re communicating and the role it plays in your day-to-day work is an important first step. If you have any useful tips or tricks, or great resources please share them in the comments!
P.S.
Some clickbait titles I would have considered were:
- This One Skill Will Make You a 10x Dev
- The Secret No One Tells You About Excelling as a Developer
- Transcend Your Peers and Achieve Engineering Nirvana… With This Skill
That last one might have been a stretch.
