Being a good communicator is a core part of being a successful and productive software engineer. Soft skills and technical skills may seem like opposite ends of the talent spectrum, but when combined, they’re often what set you apart from other programmers and increase the impact of your work. The practice of programming may feel like an individual activity, but the process of building software involves collaborating with other people. While reading, writing, and debugging code will challenge you, you must work effectively with colleagues and partners—and a lot of that work centers around communication skills.
This guide will give you the tools you need to hone your communication abilities and boost your career.
important These tips will be of particular interest to individual contributors, but engineering managers and senior engineers may still find some of the material useful for mentoring or sharing with their team members or direct reports.
We’ve all seen the movies—the genius, loner coder hacks into the mainframe from his dark basement, surrounded by empty pizza boxes and energy drinks. It’s a persistent myth that programmers are inherently introverted, reclusive, and content to be lone wolves whose only company is their computer. But while the act of programming has always been between a human and a machine, the software products used by millions throughout the world are a result of collaboration and communication between many different people.
Over the years, we’ve gotten better at building software. We’ve learned from our mistakes; invented new algorithms, software patterns, user interfaces, and development methodologies; and built languages and tools that have increased the speed and quality with which we can produce software. As the industry changes, so has the role of programmers. It’s no longer enough to be technically competent—communication skills are just as important as technical ability and will continue to play a critical role in software production for years to come.
Technical knowledge is relatively easy to acquire nowadays, especially with the internet as a distribution channel and the number of books, videos, and other resources we have at our disposal. The ability to communicate and connect with people on a personal level is much harder and may even require introspection and difficult changes to your own personality in order to improve your skills.
Unlike a new programming language or design pattern, good communication skills are not something you read about once and understand right away. These skills require years of work and putting them into practice in your day-to-day conversations before they’re second nature.
But that’s why we’re here! Improving your communication skills may not be as easy as a one-click download, but the more you know, the easier it will become.
Think of a workplace like a beehive. Everyone’s serving the same goal—to develop the best product possible—and each group has a different job.
In your role, you might be asked to collaborate with Marketing, Sales, Customer Success, and other teams within the company to produce better software for both internal and external users. Some developers are even tasked with communicating directly with customers and clients. Occasionally, you may need to work with programmers at other companies or on other teams to build an integration between your system and theirs. The other programmers may have their own priorities (and their own technical limitations) for their part in the integration.
That’s a lot of different groups to coordinate between! But without proper communication, efficiency can break down and good ideas can be left on the table. Communication is the key to trust, collaboration, productivity, and ultimately, achievement—both personal and collective.
This skill can be learned over time, and anyone, including you, can master it. So, what can you do right now to improve your communication skills? Let’s take a look at a few ideas.
Words have consequences, and it’s important to choose the right words and do your best not to hurt someone’s feelings. Keeping your composure when tensions are high is not something many people will notice, but losing your cool under pressure is certainly something that everyone will notice. Choosing your words wisely, especially when you’re in the middle of navigating challenges, can make a big difference.
Understanding the audience you’re communicating with is an important principle to keep in mind for effective communication. Are you communicating with your boss, another programmer, a nontechnical coworker in another department, or an external client?
Depending on how technical your audience is, you may need to change how you explain certain topics. You might be able to discuss the details about API schemas, HTTP status codes, and how CORS requests should be handled between your backend and frontend applications with your fellow programmers, but a customer success representative or a marketing manager may have no idea what those topics mean.
The most important thing to keep in mind in these conversations is to respect your audience, especially if they aren’t able to follow along when talking about technical concepts. The last thing you want to do is to be condescending because they don’t understand a complex technical topic that seems like second nature to you.
Try your best to avoid using slang, acronyms, or technical jargon. Instead, try to use metaphors or draw comparisons to common concepts that almost any audience would understand. Trying to connect a technical concept to common everyday objects or ideas that your audience may be able to relate to can even be fun and challenging.
Once you’ve determined who your audience is and how you should approach the conversation, the next thing to be aware of is written communication best practices, which are the backbone of even the most technologically advanced workplaces.
As a programmer, you’ll be reading and commenting on a lot of code reviews throughout your career, and how you communicate your thoughts and ideas in writing can determine how well those ideas are received by your coworkers. Even if you don’t think of yourself as a good writer—that’s ok! There are a lot of easy, straightforward ways to approach it to get your message across clearly.
Code reviews are often one of the poorest areas of communication between programmers, which is unfortunate because it’s also one of the most important.
Unfortunately, code reviews can often be intimidating experiences for developers because it’s easy to feel like the reviewer is criticizing the programmer and not their code. To build healthy relationships with your coworkers, it’s imperative that you stick to constructive criticism during code reviews. It doesn’t help anyone if you comment that the code is wrong or that it’s inefficient. Instead, explain why their solution is suboptimal and, more importantly, offer advice on how they can improve their code.
Let’s look at examples of two different types of comments you may see during code reviews, and why one is better than the other.
don’tFirst, a bad example: “This will cause a performance issue. Needs to be fixed.”
This comment doesn’t help the programmer at all because it doesn’t explain why the code will cause a performance issue, and it doesn’t offer a solution for how to fix the issue.
doNow, let’s look at a constructive example: “This is a critical part of the program and can cause bottlenecks if we’re not careful. Should we consider optimizing this? Maybe try caching the value from the previous iteration, which could save us quite a few database queries.”
First, it’s less aggressive if you approach the comment as a question, rather than a statement. That way, you’re asking the programmer if they had considered your concerns, and it gives them an easy way to admit they hadn’t thought about that aspect when coding their solution, without trying to embarrass them.
Next, the comment offers a suggestion for how the programmer can improve their solution. Perhaps they were so caught up in getting to a working solution that they completely missed the opportunity to improve the efficiency of their algorithm.
important Using the word “you” and replacing it with “we” and “us” is a great trick—it signals to the recipient that they are part of a team and that you’re all in this together.
By now, we’re all comfortable communicating over email—it’s usually the default mode of communication in the workplace. But before sending an email, consider other communication channels and determine if it’s better to ping someone over chat or hop on a video call instead. Sometimes a 15-minute video call is more efficient and effective than multiple emails back and forth with other people.
When email is the right channel to use, let’s look at a couple of things you can do to improve your communication.
Use the subject line to get your point across. Lots of people scan subject lines when they’re busy or in a hurry, so try to make yours specific and to the point so that someone scanning their inbox will know they need to open your email.
don’tHere are some bad examples of subject lines that are vague and do not convey any useful information.
Subject: sync
Subject: follow up
Subject: (no subject)
Always try to be as specific as possible, while keeping the subject line concise. A good subject line should hook the recipient in and stand out among the clutter of an inbox.
doHere are some examples of good subject lines:
Subject: Compliance presentation sync
Subject: Third-party integration follow-up
Subject: Production incident postmortem
Some people get hundreds of emails a day, which can lead to a very clogged inbox. .
To optimize and honor everyone’s time, it’s best practice to keep emails short. This doesn’t mean that all manners and word choice go out the window (see above about words mattering!), but if possible, try to get your point across in the first or second sentence. You can also use formatting to help underscore your important points—think bullet points for readability, bold fonts to stress importance, and underlining or font colors to add emphasis.
In group emails, if you need to direct a question to a specific person or direct specific people to handle action items, it’s helpful to use @ tags. It’s usually a good idea to combine these with bold formatting to make sure your requests are seen.
@dave do you still have that infrastructure diagram from last quarter?
@allison can you coordinate with marketing on a release date?
When someone sees you’ve tagged their name, you’re more likely to drive action or get a response from them, but as always, use them sparingly otherwise they lose their effectiveness.
Work can feel like it’s a mile a minute, but whenever possible, do not send the email immediately after you finish writing. Sending emails with grammatical errors can actually hurt how people perceive you and how much they trust your opinions, so it’s crucial to catch any mistakes before hitting send. There are tools, such as Grammarly, that can highlight grammar mistakes in real time and help you catch simple mistakes and clarify your writing. Reread your email, and then reread it again.
Speaking in front of a group of people can be very uncomfortable, especially for programmers. In fact, public speaking is one of the most common and stress-inducing fears there is, regardless of which profession you’re in. Almost all people experience anxiety before they have to speak to an audience, so you’re not alone if your nerves get the best of you.
While you may never need to speak in front of your entire company, you may find yourself in one-on-one conversations, team meetings, or larger all-hands meetings where you’re asked to speak on a certain topic. Finding time to prepare will make a huge difference in your confidence, and you’ll have more time to figure out how to explain your topic clearly and concisely.
Communication isn’t only about sharing your own information, it also requires you to listen to other people’s thoughts, ideas, and concerns.
One of the easiest things you can do is to practice reflective listening, the idea of listening to who’s speaking to you and echoing their ideas back to them. You don’t have to repeat what they said word for word, but try your best to summarize their ideas in order to confirm that you understood them correctly.
While it may feel silly at first, there are a few benefits to reflective listening:
It shows the speaker that you’re listening.
It helps to point out any misunderstandings.
It will help you embrace the speaker’s perspective without forcing you to necessarily agree with it.
It will help you clarify your assumptions—and theirs.
Asking questions is a natural instinct in humans—children full of endless questions, but there’s one that is simple, yet so powerful at the same time: why? Asking “why” is such a profound step in the learning process and deeply indicative of curiosity for understanding.
As a software engineer, it helps to be curious about your craft. Just like a child asks questions to understand something about the world around them, you should ask questions about the codebases, systems, and team processes you work with on a daily basis.
exampleA curious software engineer might ask:
Why is our data processing pipeline a series of asynchronous jobs instead of one big calculation?
Why did we choose NodeJS over Ruby or Python for our backend?
Why do we spend so much time grooming our ticket backlog when we could be building?
How does our fraud detection system differentiate a legitimate purchase from a fraudulent one?
Why did we decide to use the builder pattern here instead of calling the constructors directly?
Asking these kinds of questions not only helps you learn and understand how the systems around you operate, it also gives you context behind some of the decisions that were made in the past, even before you joined your team, which will help you understand why your team might do things a certain way.
You’ll learn a lot just by asking questions, but keep in mind that it is, in fact, possible to ask too many questions. It’s important to find the right balance of figuring something out on your own versus asking someone to explain something to you.
Here are a few examples:
don’t“Why isn’t my code working?” This is one of the worst things you can ask your coworkers. You’re asking them to help do your work for you.
doAsk this instead: “I’m having trouble getting my solution to work the way I want it to. I’ve tried X, Y, and Z, but I’m still not able to get it right. I could use a second pair of eyes on it to make sure I’m not missing something obvious. Do you mind helping me out?”
don’t“Where do I start with this task?” This is another one that will probably upset some of your teammates. It shows that you haven’t put in any effort to research the task on your own.
doAsk this instead: “I’ve read the ticket and searched the codebase for where to begin, but I’m unsure if I’m understanding it correctly. Is [insert file name] the correct place in the codebase where this change needs to be made? If not, would you mind showing me where I should be focusing?”
Good communication isn’t just about asking questions or conveying ideas—it’s about putting those ideas into action. As programmers, we’re prone to the bystander effect when it comes to the maintenance and operations of our systems. Individuals are less likely to take responsibility for something when there are other people present, because they assume someone else will step up to the plate and take care of what needs to be done.
don’tYou: “It looks like the build server is about to run out of disk space, which will block deployments and prevent tests from running on pull requests.”
Later that day, the build server runs out of disk space.
You: “I thought someone was going to fix this since I announced it during stand-up?”
Your teammate: “I thought you were going to fix it since you announced it during stand-up.”
doYou: “It looks like the build server is about to run out of disk space, which will block deployments and prevent tests from running on pull requests. Does anyone know how to clean up the old builds so we can prevent this from happening?”
Your teammate: “Yes, I cleaned up the old builds last time this happened. Come find me after stand-up and we can take care of it together.”
You: “Thanks, I can document the steps as you walk me through them so anyone will be able to do it next time.”
A better approach is to not only communicate what the problem is, but also communicate what actions should be taken, and if possible, come to an agreement on who will take responsibility.
The best communicators are successful because they have the ability to inspire actions that lead to certain outcomes that benefit themselves and those around them.
Here are some key ways good communication can spark day-to-day success and add an upward spin to your long-term career trajectory.
Adapt to Challenges
Challenges are bound to happen in any workplace, and when there’s a bug in the code or a product just won’t work like it should, working together is the cornerstone to overcoming obstacles and moving forward. And how do you build the trust necessary to adapt to challenges quickly? Communication.
Let them know what you’re facing, what you’ve noticed, and how you think you can contribute. You may not be able to fix the situation or connect the dots yourself, but you might offer a clue that can help you identify a problem’s root cause so you can all collaborate to solve the problem.
Manage Conflicts
As engineers, we take pride in our craft, and it can be easy for individuals to get attached to certain solutions or architectural designs. It’s okay to disagree with your teammates, but how you handle yourself will speak volumes about your character and how your teammates view you.
Communication is core to being able to navigate these tricky situations with tact and empathy. In fact, healthy debates are a sign of a high-functioning team, but the discussions must be respectful. While it’s good to debate the pros and cons of different designs and algorithms, it can be bad if things turn from a civil conversation to a full-blown argument. If you can take the lead in these situations with tact and diplomacy, you can set yourself apart and set your team up for success.
Continuous Learning
Software engineers are curious creatures. We strive for continuous improvement and are constantly looking to refine our understanding about how the world works around us. Asking questions is a fundamental aspect of our jobs, and asking good questions is equally an art and a science.
Over time, with better communication skills, you’ll hone your ability to ask better and better questions. Sometimes you’ll get the answers you were looking for, sometimes you’ll get unexpected answers that change your perceptions, and sometimes you’ll get insufficient answers that will require additional questions. If there’s one thing for certain though, it’s that good communication and continuing to ask why can help you learn and grow as a software engineer.
Find New Ways Forward
There will be times when you’ll hit a dead end with your code. Either you’re getting an error or your code just isn’t doing what you think it should be doing. It’s tempting to drop everything and ask a coworker for help, but knowing what to ask is often the hardest part. You should be asking for advice, not a solution.
The more effort you put into asking the question, the less time your coworker will need to get up to speed with the problem. You’ll help your coworker understand the problem quicker, which means they’ll be able to help you quicker.
Understand Your Manager
Your professional relationship with your manager is one of the most significant factors affecting your career growth. You are ultimately responsible for your own career, but your manager has more influence over your career trajectory than anyone else in your company, so it’s critical that the two of you work well together.
One of the best ways to do that is by understanding their communication style. How do they prefer to communicate? How often do they expect updates from you? What time of day are they usually available? Do they prefer if you provide them with objective analysis for each option, or do they prefer to hear your personal judgment when making difficult decisions?
Although these aren’t things you need to think about often, when you understand your manager’s preferred way to work, you’re less likely to make costly errors due to miscommunication.
Learn More. Do Better.
Failure is only the opportunity more intelligently to begin again.Henry Ford*
After you’ve completed a project—particularly a trick one—bring people together to discuss and document it. Good communication can help make this a constructive, collaborative process that focuses not on placing blame, but on finding forward progress together.
Good questions to communicate include:
What was the timeline of events leading up to and during the incident?
What was the ultimate root cause?
What was the impact on the customers and the organization?
What actions were taken to mitigate the failures and get the system back to a stable condition?
What steps, if any, should be taken to prevent the same thing from happening again?
Level Up Your Career
You’re here because you want to learn how communication can help you become a better software engineer—a team player who collaborates well with others, who communicates effectively, and who knows how to manage risk while delivering value to customers. These skills become increasingly important as you climb the career ladder.
While many programmers may have the technical ability to reach a higher career plane, not all possess the soft skills necessary to have the greatest impact on a team. Simply put, these soft skills are what separate good programmers from great ones in the later stages of their careers.
As an individual contributor, you’ll need to learn how to build support for your ideas and work cross-functionally with people across your company. And if you choose to go down the managerial path, good communication skills are even more critical, as you’ll be managing projects and people constantly.
The bottom line is that the higher up you advance in your career, the more you will stand out if you are an excellent communicator. The best programmers communicate with empathy and listen to what others have to say, and those who communicate the best will be the first to advance when it comes time for a promotion.