editione1.0.1
Updated August 7, 2023It’s a popular stereotype that programmers are often introverted, reclusive, and lacking in the social skills department. Even though this doesn’t accurately reflect the industry as a whole, it’s been perpetuated in anecdotal stories of old-school hackers in the early days of Microsoft, Apple, Facebook, and many more tech giants. There’s a common theme in Hollywood movies in which the genius coder hacks into the mainframe from his dark basement, surrounded by empty pizza boxes and energy drinks. But while the act of programming has always been between a human and a machine, the software products used by people throughout the world are a result of collaboration and communication between many different people. Shipping software at scale is a team effort, and it takes good communication skills to deliver quality products.
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.
Although the act of programming is mostly an individual one, working on a team with other technical and nontechnical people will be one of the hardest things you do in your career. Human nature is incredibly complex and unpredictable at times, and as programmers, we’re required to interact with many people throughout the software development process in order to perform our jobs.
It may be uncomfortable at times, especially for junior programmers because you’re learning how to write code at an advanced level while simultaneously learning how to interact with other programmers and business stakeholders. There will be times when you’ll struggle to communicate your ideas clearly, and it’ll be frustrating. And there will be times where you’ll be intimidated because you can’t get your thoughts out while all eyes are on you. We deal with abstract thinking quite often in our industry, and it’s sometimes hard to convey those ideas to others in a way that helps them understand your exact point of view. Being able to convey technical ideas clearly and concisely takes good communication skills, and being able to communicate clearly is a skill that can be learned over time, but it requires practice.
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 become second nature.
To be successful in modern-day software development, programmers need to be well-rounded individuals who can communicate cross-functionally with other teams. 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 of the integration.
Good ideas themselves are no longer enough to build great software products. You need the ability to communicate your ideas so that they are properly received by your audience and the entire team has bought into your ideas. And finally, as we’ll see in a bit, good communication is not just about talking, but also about listening to others.
Most senior developers understand that their communication skills are what sets them apart from their peers, and their skills will position them as a trusted source of knowledge within their organization. Good leaders are often the best communicators, and programmers need good communication skills if they aspire to lead projects and teams.
If you want to be recognized for your work, influence the direction of your team and your products, or earn a promotion, you need to learn how to interact well with other people and build meaningful relationships along the way. Great communication skills are a differentiator among programmers and will help you stand out amidst your peers of similar experience. What many programmers fail to understand is that the best communicators have a special skill that surpasses pure technical knowledge.
As I mentioned earlier, 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 are powerful, and you can hurt people deeply with just words alone. All it takes is a few select words to ruin professional and personal relationships that you’ve worked for years to build. It may sound a bit silly that “be good to others” is advice that will help you in your career, but when smart people with lots of passion work closely with one another, it’s easy to forget. Difficult decisions get made every day, at both the business and technical levels, and sometimes people come out on the losing end of those decisions. Sometimes your ideas won’t be chosen, or someday you may need to make decisions that affect people’s careers.
Words have consequences, and it’s important to choose the right words and do your best not to hurt someone’s feelings. Words can create harm to other people, and they can create conflict with your coworkers.
One of the most important things to remember is to be aware of your emotional state when communicating with others. You may be pulled into an incident that wasn’t your fault, or you may be participating in a heated discussion about the best design for a new system architecture. Regardless of what it is, you should always act and speak with empathy and professionalism. 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.
It’s not just about staying calm under pressure, either. It’s also about the tone you use in your conversations and that you use with other people, regardless of their seniority or job function. All of these variables affect how you should convey your thoughts if you want to get your point across and position yourself so people will take your ideas seriously. It starts with yourself, and that may be hard for some people to grasp. The sooner in your career that you focus on building rapport with your coworkers, clients, and customers, the easier it will be to gain support for your ideas. And it starts with awareness of who you’re talking to and how you’re talking to them.
Understanding the audience you’re communicating with is an important principle to keep in mind for effective communication. Knowing who you’re speaking with and their level of understanding about a topic will often dictate how the conversation will play out. 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. Sometimes it can be difficult to explain technical topics to nontechnical people, but at some point, you’ll find yourself coming up with analogies to explain a complex technical concept to someone who isn’t as technical as you are.
We deal with a lot of abstraction in our day-to-day jobs and deal with things like entities, instances, classes, interfaces, modules, and so many other concepts that are hard to articulate and explain to other people—sometimes even other programmers. Even though these concepts may make sense in your own head, finding the right words to verbalize your thoughts is sometimes difficult.
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.
In some situations, it may be beneficial to teach your coworkers simple programming concepts if you know you’ll be working closely on a project in the future. Teaching them concepts such as an API or the difference between frontend and backend systems can go a long way in helping them understand requirements or limitations for a project. Additionally, they may end up teaching you about marketing, operations, customer success, or other topics related to the team they work on. The more knowledge you have about different organizations within your business, the better decisions you’ll be able to make when designing systems and user interfaces and solving problems for your customers.
While you may be interacting with people from different areas of expertise, you may also be interacting with people of varying seniority and experience, so it’s important to keep your audience in mind so you communicate at the appropriate level for your audience.
Another way to gauge the audience’s communication needs is to ask them directly. Sometimes directors, vice presidents, or executives may not care about the details of how you implemented your solution, but sometimes they actually are interested in how it works under the hood. The best way to determine how detailed to get is to straight up ask them how detailed you should get when explaining something. Most likely all they care about is that the problem was solved or the bug was fixed, but sometimes they might want to know the nitty-gritty details about it.
Additionally, they may be more interested in knowing when something will be done or if something is even possible to do and less interested in how it’s done. The role of upper management is to set the vision, put together a timeline, and prioritize resources to bring the vision to life. Oftentimes, they may not care what design patterns or frameworks you’re using, but they do care about how long a project will take so that they can fit it in with the other priorities on the roadmap.
The bottom line is that programmers with good communication skills are the ones with the ability to communicate complex ideas in clear and concise ways to both technical and nontechnical audiences. In doing so, they can build rapport with their team members, including individual contributors, managers, directors, VPs, and executives. When your team members know they can trust you to convey important information to various audiences, you will be seen as a valuable asset to the company, which could lead to more responsibility and a higher salary.
Once you’ve determined who your audience is and how you should approach the conversation, the next thing to be aware of is the channel you’re using to communicate. Whether the conversation takes place in person or through a written form of communication such as chat or email will determine how you approach the conversation.
The first channel we’ll dive into is written communication. 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.
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. Constructive comments from senior developers are one of the best tools to help you become a better programmer because you’re receiving direct feedback on how you can improve your code and your logic. Whether it’s more concise syntax, bringing clarity to your logic, ensuring maintainability, improving performance, or handling edge cases you didn’t think about, the act of having someone else peer review your work will improve your technical skills.
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. The wrong words or the wrong tone can do more harm than you may realize, so it’s important to be cautious of this when reviewing and commenting on another’s code. It’s always best to stick to constructive feedback, and you should never personally attack the programmer for coding a solution a certain way, even if it’s wrong.
There are numerous ways to solve programming problems, and the best solution may not always be apparent to the person assigned to the task. While it may seem easy to disagree with someone’s code because you believe there’s a better way to solve the problem, criticizing their thought process or their implementation is the wrong way to go about it.
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 your 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. It’s possible the programmer was lazy when writing their algorithm, but it’s also possible they may not even be aware their code is inefficient. The commenter comes off as abrasive, and the programmer who wrote the code may take their criticism personally, which could lead to indecisiveness and self-consciousness the next time they submit their code for review.
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. That doesn’t necessarily mean they’re a bad programmer by any means, so don’t make them feel like they are.
Another aspect of this comment is that it avoids using the word “you” and replaces it with “we” and “us.” By doing so, you’re signaling to the programmer that they are part of a team and that you’re all in this together.
Senior engineers tend to focus more on the success of the team as a whole, rather than just themselves, and it’s the small details like this that go a long way if you want to show that you’re a team player. Try not to single out programmers when offering feedback on their code. You’re all on the same team, and it’s everyone’s responsibility to deliver the highest quality code possible. It’s always better to stress the importance of the team and acknowledge that the code is owned by everyone and not a single person. In doing so, you’ll build confidence in your teammates and they’ll take your feedback seriously.
Now let’s look at the next way in which you’ll communicate with others through writing, which is in your project management system.
How to Deliver Constructive Feedback in Difficult Situations (productivityhub.org)
How to Review Code as a Junior Developer (medium.com/pinterest-engineering)
There’s a good chance your team is using some kind of bug tracking or project management system. These tools help teams plan, organize, and track new features, tech debt, and bugs as tickets make their way through the development process and into production. Ticketing systems can get complicated very quickly with multiple people moving tickets around, creating subtasks, setting deadlines, and marking certain tickets as high priority.
Many programmers seem to despise these tools because they are heavy on process and always seem to get in the way. There are complex workflows, planning meetings, and coming up with arbitrary estimations for tickets—all of which sometimes feels unnecessary. While it may seem like these tasks take time away from actually writing the code they’re meant to track, these tools are important for project managers to stay organized and even more important for the management team to track progress on larger projects and to plan out longer-term goals that align with the company’s strategy.
Given the complexity of these tools, it’s important to make sure you’re communicating clearly on your tickets as you move them through the pipeline. When you create a new ticket, provide as much detail as possible. Don’t assume that other developers on your team will understand where to find the bug, how to reproduce it, or why a certain part of the code should be considered technical debt and needs to be cleaned up.
Software engineers can be lazy now and then; we’ve all been there before. There’s nothing worse than pulling in a ticket to work on and finding almost no information to go on. There may be a title and a one-sentence description. How do you know how to reproduce the issue if it’s a bug? How do you know if it’s a high-priority feature request from an important customer? How do you know if it’s tech debt that’s not really an issue but the developer who filed it felt like the code was just a bit messy? It’s sometimes impossible to know these things when there’s no information to work off of, and as a developer, it’s frustrating when you are assigned these kinds of tickets.
don’tHere’s an example of a bad ticket:
Type: bug
Title: User audit logs export is broken
Description: (blank)
Acceptance criteria: (blank)
Priority: low
There’s almost no information on this ticket! There’s no context to work off of when it comes time to plan the next development cycle, except that a bug exists. It’s not even clear if the bug still exists because there’s no instructions on how to reproduce it.
Furthermore, it’s possible this particular report is complex, with multiple export settings, and the bug only exists for a specific configuration setting. If you pick up the ticket and try to reproduce this bug, the report’s export functionality might work fine for you because you don’t have the application in the same state as the person who reported the issue.
There’s also no indication of any acceptance criteria, which is a set of predetermined requirements that must be met in order for the product owner to mark the ticket as complete. In other words, how will we know the bug is actually fixed? It’s important to lay out this information up front, before the development work begins, so there is a clear finish line to know when you’re done. Doing this helps reduce scope creep and keeps the developer focused on solving the original problem instead of making additional unrelated changes in the process.
So, how would you improve this ticket so the issue is clearly communicated?
doLet’s take a look at an improved example.
Type: bug
Title: User audit logs export is broken when selecting CSV format
Description: We are seeing a 500 status code from the server when trying to export the user audit log in the admin portal when selecting the CSV format. XLS format seems to work fine. The following stack trace is getting thrown on the server:
[stack trace snippet]
Steps to reproduce: (1) Log in to the admin portal and go to the Users > Audit log section; (2) Click the export button and select the CSV format; (3) Click download.
Acceptance criteria: I should receive a 200 status code from the server and be able to download the file successfully in the CSV format.
Priority: medium
You can already see that there’s much more information in this ticket that will help prioritize this work during planning sessions and will help the developer reproduce the bug when they pick up the ticket. The ticket provides a stack trace to help the developer pinpoint exactly where the error is thrown on the server, as well as steps to reproduce the bug. Notice how the description states that the bug happens when exporting in CSV format, which is also helpful. Without that, someone may try to reproduce the bug and be able to successfully download the report in Excel format.
Lastly, the acceptance criteria are clearly defined so the project manager knows exactly what requirements need to be met in order to mark the story as complete. This helps the developer focus on fixing the actual bug rather than optimizing the code or cleaning up a part of the codebase unrelated to the actual bug itself.
You’ll be creating lots of tickets throughout your programming career, so it’s important to build good habits now. While they may seem trivial to you at first, these small details make a big difference. Junior developers tend to overlook this aspect of software development because they’re focused on writing code. Sure, writing code is important, but keeping information organized in the issue tracking system is another piece to the puzzle when it comes to documenting, planning, and delivering software.
When writing tickets, it’s helpful to think of it as if you’re communicating with someone in the future. Whether you’re communicating with yourself or someone else, your goal should be for whoever picks up the ticket tomorrow, next week, or next year to have all the information they need to work on the task. If they pull up your ticket a month from now and there’s no information except for a title, there’s a good chance they’ll just close the ticket and move on to something else because they don’t know enough context to pull it into the next development cycle.
Which brings us to the next point—closing tickets. While your version control system acts as a historical record of changes made to your codebase, your project tracking system acts as a historical record of all implemented features, bug fixes, and technical debt that has been paid down over the years. It acts as a paper trail for the work your team has accomplished and also offers insights on how efficient your team was in delivering the work.
Leaving notes and details about each ticket (and updating any relevant documentation) as the work happens allows project managers and new engineers to look back and get important context for why some action was taken on a ticket. A new engineer may find a reference to a ticket number in a git commit or a comment in the codebase that they can pull up and get additional context around why a specific piece of code was written.
It’s important to add comments and give good reasons when closing tickets, because other people may find that information useful in the future. Sometimes multiple developers will report separate tickets for the same bug, or there may be tickets that overlap in scope. Other times the change may be so low in priority that it’s closed to reduce the clutter during a ticket grooming session. Other times the ticket may not be relevant anymore because the bug has already been fixed or priorities have changed. Regardless of why the ticket is no longer a priority, it’s always a good practice to add a comment giving a reason for why you’re closing the ticket and choosing not to work on it.
Here are a few examples:
“Closing this ticket because it is a duplicate of BUG-394.”
“Closing this because the issue is no longer reproducible. It looks like it may have been fixed as part of the refactoring done in ENG-1138.”
“Closing this since it will no longer be needed once we migrate to the new ordersservice.”
The worst thing you can do is to close a ticket without any context because whoever pulls up that ticket in the future will have no idea why this work was never done. It takes less than a minute to add a one-sentence comment about why you’re closing a ticket, so try to document why you’re doing something when making changes.
And lastly, not everyone will be able to monitor the comments and activity for each individual ticket, so it’s helpful to tag the relevant people when adding your comments. It’s easier to keep track of ticket activities when you get email or chat notifications when things happen, rather than having to continuously monitor each ticket for new comments or movements in their status.
Following these few tips while working in your project management system may not seem like much, but your manager will appreciate good communication skills, even in asynchronous channels. In general, the more information you can provide, the better, especially when it comes to updating others on the progress of specific tasks in your tracking system. As you work your way towards a senior role, building good habits when working in your project tracking system will let everyone benefit from the knowledge and information you share.
Chat systems have been around for decades and have been adopted by companies of all sizes, from startups to public companies. They’ve even become valuable tools for open-source projects with the rise of Slack, Microsoft Teams, Discord, and many others. While you’re probably already experienced with chat communications, here are a few things to keep in mind when using them a professional setting. It may be simple and obvious advice, but it goes a long way when exchanging information with others.
Asynchronous
Similar to tickets in your project tracking system, communicating over chat systems is asynchronous in nature. Although chat is much more real time, you may or may not get a response right away. Conversations can happen quickly in group chats, or they can happen over the span of hours or days. If you need an immediate response, consider other channels of communication. If you’re in the office, talking to someone in person is the quickest way to get the answers you need. If you’re working remote, try to get them on a video call or at the very least, a voice call. Recognizing which conversations are best held over chat and which ones are better off in a different channel will help avoid miscommunication and will get you the information you need in a timely manner.
Acknowledge requests
One habit that is good to get into is to simply acknowledge when someone asks you to take a look at something. You may need to ask someone to take a look at your pull request or to review a design document, and it’s sometimes frustrating if you need an answer right away but your request just sits there without any response.
When someone asks you to review something, give a quick response like “Taking a look”, “Looking now”, or “Will take a look in 15 minutes after this call” to let them know that you saw their request when you will look at their document. When someone reaches out to have you look at something, it’s usually urgent enough to warrant asking for a review. This small habit lets the other party know that you’re working on it so they aren’t met with complete silence on their end.
Choose the proper channel
Different channels are meant for conversations around different topics. Your company may have a few different channels like #general, #marketing, #engineering, #industry-news, or a #random channel. The larger the company, the larger the audience in each channel, which is why it’s important to respect the channel topic when posting or holding a conversation with someone. It’s insensitive to hold personal conversations with others in public channels. If possible, try to move those kinds of conversations to a direct message channel with the person you’re talking to.
On the other hand, sometimes it’s best to hold certain conversations in public rather than in a direct message. If it’s an urgent conversation or a discussion about a topic that multiple people should be aware of, then it would be helpful to discuss in a public channel, because it allows others to follow the conversation along with any decisions that are made.
By now, we’re all comfortable communicating over email, so I won’t get too deep into details here. Similar to communicating over chat, try to determine if email is the right channel for the kind of information you’re trying to communicate. 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. Sometimes a 15-minute video call is more efficient and effective than multiple emails back and forth with other people.
Urgency is also another thing to consider and may dictate which communication channel is best. Sometimes it’s best to pick up the phone or hop on a video call to discuss something time-sensitive. Alternatively, if the conversation isn’t time-sensitive, email could be a good asynchronous option.
Regardless, email is still widely used throughout the world, and there are certain conversations where it’s the best option, such as communicating with people outside of your organization. Unfortunately, email conversations tend to be slow, and important points can be easily misinterpreted. Let’s look at a couple of things you can do to improve your communication over email.
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
Better subject lines are clear, to the point, and worth the extra few seconds it takes to think of something specific. They go a long way in helping make sure your emails are read and not skipped over by someone skimming an inbox.
Some people get hundreds of emails a day, which leads to email fatigue. When things are moving quickly in the office or when there’s a time crunch to meet a deadline, not everyone will have the time to read every email they get. People frequently scan emails to look for relevant information, and a good way to guarantee your email doesn’t get read is to send a big wall of text to your recipients.
Keep emails short. The shorter the better. And try to get your point across in the first or second sentence. This helps people that are in a rush and gets them the relevant information they need. Not everyone will read to the end of your emails, so if you’re asking someone a question in the third paragraph, don’t assume they will see it and respond with an answer.
Additionally, a good way to make your emails easier to scan and make your most important information stand out is to use text formatting for your important points.
Use bullet points or numbered lists to make it easy to convey different options or lists.
Use bold fonts to stress importance. The bold lettering will usually be the first thing someone reads, so use it sparingly and only for the most important one or two points you’re trying to make.
If you have to write a long explanation, break it up into multiple paragraphs. There’s nothing worse than a huge wall of text, and multiple paragraphs makes it easier to read.
Consider underlining or using font colors to highlight the most important information. If you do this, do it consistently within a single email. Keep in mind that certain colors can be hard to read if they don’t contrast well with the background. And using colors to highlight some text can draw attention away from other parts of the text which may be overlooked.
Use red to highlight disclaimers or risks that are critical for people to know. You can even preface the sentence with “Disclaimer:” or “Important:” in boldface or red to add more impact.
If you’re responding to an email and answering someone’s questions, highlight your answers in a different color like blue. This makes it easier to differentiate between the original author’s questions and your answers.
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.
Whatever you do, do not send the email immediately after you finish writing. There’s no undo once you hit send, so taking a few minutes to proofread your email could save you from embarrassment in the future.
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.
Even if you’re using tools to help catch errors, you should still proofread your own writing. Reread your email, and then reread it again. Try to combine or remove sentences completely in order to shorten the email to just the necessary information. Only after you’ve proofread your email multiple times should you hit send.
Now that we’ve covered some things you can do to improve your written communication, let’s look at verbal communication.
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. Improving your public speaking skills has many benefits and will help you be more effective at your job.
Let’s take a look at some things you can do to improve your speaking skills, whether you’re talking to one person, a small group of people, or a large audience.
Speaking publicly doesn’t come naturally to most people. No one wants to embarrass themselves in front of an audience, yet that’s the most common fear among people who have to get up and speak in front of others.
It takes a lot of practice and preparation to build confidence in your public speaking skills, but even the best public speakers still get hit with anxiety and need to manage their nerves. In fact, some even argue that nerves can be a good thing because the adrenaline rush makes you more alert and helps you focus on what you need to communicate. Regardless of how you deal with the anxiety of speaking in front of people, learning to manage your nerves is a valuable skill to build. You may never be able to get rid of your nerves, so learning to manage them will help you communicate more effectively.
If you get up in front of others to give a talk without any kind of preparation, you’ve failed to set yourself up for success. Finding time to prepare for the talk 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.
Research your topic. You want to make sure you have a thorough understanding of what you’ll be speaking about. To teach others about a topic or idea, it’s crucial to have a solid understanding of it yourself. If you don’t understand something well, you’ll have a hard time teaching others about it.
If you’re putting together a presentation with slides, add notes to each slide. These are usually talking points you want to touch on for that slide. Add bullet points and use short sentences or phrases so it’s easy to scan during your presentation.
If possible, ask someone else to proofread your slides, especially if you will be speaking to people outside of your immediate team. Spelling mistakes, grammatical errors, and inconsistencies in your talking points can distract listeners from the message you’re trying to get across, so it’s good to catch these things early with a second pair of eyes, similar to how you have your coworkers proofread your pull requests when making code changes.
Practice running through your slides at least once before giving your talk. Find an empty conference room in the office or do it at home in front of a mirror. Talking out loud helps you find parts of your presentation that may sound awkward or don’t make sense. It’ll help you identify which points you’re having trouble explaining so you can refine your notes and improve your delivery.
Sometimes, you’ll only have a limited amount of time to give your talk. It could be five minutes or fifteen minutes, but you want to make sure you respect the time of others who may be speaking after you. If you practice beforehand, make sure to time yourself so you have an idea of your talk’s length. This will help you know if you need to shorten it and cut things out of your presentation, or if you’re under time and can dive deeper into one or two key slides.
Staying on topic sounds easy, but it can be difficult when you’re in the middle of a speech or presentation. It can be intimidating standing in front of a group of people who are staring back at you, and you’ll feel like you need to say something interesting to keep their attention. Try not to ramble on and talk about things that are not closely related to your topic. Try to get your point across as succinctly as possible, which is why practicing beforehand is crucial to refining your message.
More words do not necessarily mean more information, so don’t assume that the more you talk the more your audience will learn. In fact, rambling on will often dilute your message and make it harder for your audience to understand the points you’re trying to make. Most people will tune out after a certain point or once they reach a certain information threshold, so it’s usually better to keep it as short and sweet as possible.
Always try to leave a minute or two at the end to answer any questions people may have. Depending on the complexity of the topic and how familiar people are with it, you may have quite a few questions from the audience. It’s usually a good idea to anticipate what questions people may have, but it’s impossible to think of every question you may be asked.
Also keep in mind that you may not have the answer to all the questions people will ask, and that’s okay! It’s not a bad thing to admit that you don’t know the answer, but let them know that you’ll follow up and try to get them an answer later on after the presentation. Then, make sure you actually do follow up and try to answer their question as best you can.
So, now that we’ve gone over specific things to keep in mind when communicating both in writing and verbally, let’s look at some more general things that will help you become a better communicator.
10 Tips for Improving Your Public Speaking Skills (harvard.edu)
Important Public Speaking Skills for Workplace Success (thebalancemoney.com)
Most people assume that communicating is all about how you write and speak to other people, but that’s only half the story. Communication also requires you to listen to other people’s thoughts, ideas, and concerns, and that’s equally as important for collaborating and working well with others.
Just as it can be frustrating when you feel like you’re not being heard, your teammates, coworkers, clients, and customers will also feel frustration if you don’t listen to what they have to say. Building rapport with others requires mutual respect between all parties, and everyone’s thoughts should be taken into consideration with equal weight. Other people’s opinions matter just as much as yours do, so make sure to listen to what they have to say.
So, what can you do to become a better listener?
One of the easiest things you can do is to practice reflective listening. The whole idea of reflective listening is quite simple. First, listen to the speaker and try to understand their ideas, then try to paraphrase the idea 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. This goes a long way in building mutual trust with the speaker.
It helps to point out any misunderstandings, because they will be apparent in your summary that you repeat back. It will also help the speaker formulate and clarify their ideas.
It will help you embrace the speaker’s perspective without forcing you to necessarily agree with it. It helps open up your own opinions to new ideas without having to commit to them.
It’s especially helpful when discussing business processes and procedures from other organizations within the company. For example, if you’re working on a project to integrate two systems, it will be easier if you have a holistic view of how they work. Ask the speaker to explain the processes you’re tasked with automating, and repeat it back to them to make sure you understand it correctly.
It will help you clarify assumptions during the requirements gathering phase when planning new features and projects.
Reflective listening is a technique you can put to use today that will automatically improve your communication skills, and chances are you may already be doing it to some extent. As always though, be careful of using this technique too much or going too far with it, as it can come across fake or forced.
Reflective Listening (wikipedia.org)
How To Practice Reflective Listening (With Tips And Examples) (indeed.com)
Not all meetings are created equal. While your daily stand-up meeting may not seem too important, you will be in other meetings where crucial decisions are made. Depending on the topic of the meeting, it may be worth your time to prepare so you have an idea of what you want to communicate before you need to. That may involve scanning your project management board to remember what you worked on yesterday, reading through the codebase to refresh your memory about how a particular component works, or reviewing documentation for potential third-party services.
You may be called upon in the meeting to give your opinion or your input on how a particular part of the system works and how easily it can be extended. If it’s not fresh in your mind, it may be hard to give a complete answer during the meeting when everyone is relying on your input. By preparing ahead of time, you will be able to give an answer confidently so that important decisions can be made.
It’s also good to go into meetings with a list of predetermined questions you’d like to have answered. Don’t assume that everyone is on the same page about how easy or hard some change will be, or how the change should be made. Oftentimes, other people haven’t considered a solution you may be asking about, so asking the question can be helpful to others as well as yourself.
Finally, it’s good to keep a notebook and write down your thoughts and questions before starting the meeting. Conversations happen quickly in meetings, and if you try to keep it all in your head, you may not remember everything you wanted to bring up. Writing down notes also helps organize your thoughts, and you can cross things off your list as they are discussed.
These may be simple ideas, but as they become second nature, these habits will help you communicate your thoughts more clearly throughout the course of your career.
Did you ever play that game called “Telephone” growing up? It’s a game where kids stand in a circle and one player whispers a sentence to the person next to them. The second player then repeats the message to the third player, and so on. When the message reaches the end, the last player announces the sentence that was whispered to them and compares it to the original sentence from the first player. Almost always, the two sentences are completely different due to each player interpreting and repeating the message with slight differences to the next person. With each iteration the message becomes less like the original.
The same thing can happen in professional settings as well, even if it’s unintended. If possible, try not to rely on someone else to pass your message along to the intended recipient, because it may not be communicated exactly as you intended it to be. Sometimes though, you may not have an option, such as if you need to convey important information up the management chain to the executive team. In general, the more people your message passes through, the higher the chance it will be misinterpreted by the receiver.
If possible, send a chat message, an email, or speak to the recipient directly rather than communicating through a chain of people. If you must pass along information through others, try to follow up with the recipient and confirm they got your message. It may seem trivial, but it’s yet another habit you can build now that could save you from headaches in the future when collaborating across teams and organizations.
Good communication is about being able to convey your ideas in ways that are properly received by your audience. It’s simply not enough to assume that just because you said something people will understand your ideas. You may not always be able to get your point across, which can be frustrating as a programmer when it comes to conveying technical ideas to your teammates.
Additionally, just because you tell someone something doesn’t mean it’s no longer your responsibility. 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. Senior engineers tend to learn this skill as they work to develop their teammates and improve the codebase. They don’t just assume that everyone will understand what needs to be done or how something should be done, and they know that just raising concerns about something doesn’t mean it will get done. If you want something to get done, you’ll need to learn how to inspire action.
If you stick with programming long enough, you’ll eventually be a part of some emotional discussions. As programmers, we take pride in our craft, and it can be easy for individuals to get attached to certain solutions or architectural designs. You’ll deal with conflicting views at some point in your career, and emotions may run high.
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. 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.
In rare cases, passionate developers may get into tense arguments over which solution is the better approach. It’s possible that each approach has its strengths, weaknesses, and trade-offs, and that both developers are correct. No solution is perfect, and that’s okay.
If you find yourself in a heated discussion and you sense that emotions are running high, the best thing you can do is to keep the conversation as civil as possible. Take the higher road if possible, which sometimes means making compromises. It may even be best to table the conversation and walk away to let everyone cool off. You can always pick up the conversation again at a later time once people have the opportunity to reflect and think things over some more.
Always remember that it may take months or years of hard work to build up trust between your coworkers, but you can lose that trust in an instant if you lose your temper during a heated discussion. You won’t always be able to convince people that your ideas are the best, even if you feel like they are, and that’s okay. A good quality of a senior developer is that they realize that no solution is perfect and they sometimes have to make decisions on suboptimal solutions.
Pick your battles, because you don’t want to lose the trust of your teammates over the name of a variable or which design pattern to use to solve a problem. Being a senior developer means making compromises, and sometimes it’s best to just go with the flow every now and then.
While it may be difficult to realize when you’re just starting out, poor communication skills often contribute to programmers plateauing in their career. As a programmer in a senior position, you will lead technical projects and mentor younger developers. To continue on the trajectory to staff and principal engineering roles, you’ll need to learn how to build support for your ideas and work cross-functionally with nontechnical 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.
Complex software systems cannot be built by one person alone. Modern-day software solutions require multiple people, both technical and nontechnical, to collaborate and deliver products that meet evolving customer needs. Successful teams consist of a broad set of people with diverse backgrounds and skill sets, and the ability to connect, collaborate, and solve real problems with different people is a rare skill that is often overlooked by programmers.
Once you reach a certain technical level, everyone will have the necessary skills to solve the problems at hand in some way, but not everyone will have the communication skills to convey their ideas and gather feedback when they need to. 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.
As programmers, we spend a lot of time in front of a computer. It’s not uncommon to go a full day staring at pixels on a screen as you click and type away. There’s a lot of pressure from employers to work long hours to reach the quarterly and annual goals set out by the management team, and it always feels like there’s too much work and not enough resources. The deadlines are tight, but we have to ship this quarter!
There are competing interests between employees and employers that may be hard to understand early in your career. When you’re young, you’re just happy to have a job and a good salary. But as you grow more experienced and progress through the different stages of life, your priorities may change.
Your employer, whether you like it or not, is motivated to run a streamlined and efficient business. Unfortunately, your employer’s goals probably don’t align with your long-term goals. Your company is incentivized to squeeze every ounce of productivity out of you while paying you as little as possible. Businesses operate on margins that they are naturally incentivized to increase by keeping costs low.