Ignoring This CRITICAL Software Engineering Skill Is Holding You Back

I'm here to talk about a different skill that I think is even more important than some of the technical skills that we focus on for software engineering. Before I talk about the skill for today, I'd like to hear from you in the comments what you think the top three skills are for software engineers. The skill that I want to focus on today is actually communication. And I want to talk about why communication is so important for software engineers. The first thing I want to talk about with respect to communication is actually considering your audience. The reason considering your audience is so important is because communication is all about relaying information to someone else and receiving information. So just because you have information that you want to provide to someone else does not mean that it's going to be translated into a way that they will receive it effectively. So when you start to think about your audience, this is an opportunity for you to think about how you want to translate important information into something that will be effective for the receiving party to receive. If you think about other programmers and software engineers on your team, if you take for example jumping into some code, you can probably speak to them about particular lines of code, different parts of the codebase, how different algorithms perform. You might even be able to talk about a recent bug that came up in the different part of the codebase that that was affecting. But that's all because you and the other software engineers might be able to share that same context because you and the other people on your team work in that same codebase. If you switch up the audience a little bit and still consider software engineers, but perhaps a different team and you're talking to someone on a different team about this same context, you might already have to switch some of your communication style because you're speaking to other software engineers. They might also understand some of these areas of code. They might understand the programming concepts, but because they're on a different team, they might not have actually worked in your code base. So even though you're talking about a particular bug, maybe how it was fixed, you may have to consider actually changing some of your messaging so that the person on the other team can actually understand the implications of this bug in a way that might relate to something that they've been working on. If you start using all the technical jargon specifically to your team, they might have no idea what you're talking about. So that's a simple example of going from software engineer to software engineer but crossing team boundaries. But what happens when you think about people in different roles? Now, this is also really critical for software engineers because in real software engineering environments, you're not just going to be working alone. You're not just going to be working with other software engineers, but you're likely going to be working with product managers, project managers. You might even have opportunities where you're interacting with clients. In most software engineering organizations, you might have your direct manager. You might actually have interactions with their manager and other leadership roles as well. As you're considering sharing information about particular context to these other roles that might not be as intimate with the code base as other software engineers, this is where you need to be able to practice what I call zooming out from the code and being able to abstract and generalize the different things that you want to be able to communicate. So for example, if you were talking to your manager or perhaps you're talking to someone else in a leadership position above your manager. If we go back to the bug example from earlier, it probably does not make sense to be talking to these individuals about specific lines of code in the codebase, it doesn't probably make any sense to be talking about particular classes. However, for these roles, it might make a lot of sense to be talking about the impact of that bug. You could be including things like how much developer effort it took to actually resolve that bug or even things like expressing the confidence level in the bug fix. When you're giving consideration to communicating with different audiences, you'll want to be thinking about number one, the types of information that they're interested in, and number two, how you can translate the information that you have into a way that they can understand it and be applicable. The next really important part about communication that I want to focus on is actually asynchronous versus synchronous communication. This is a huge factor considering how much of us as software engineers are currently working remotely. Often with remote work comes people working in different time zones. Now, if you have a really small team and perhaps everyone's located in the same time zone or across a couple of time zones, this might not actually be a big issue for you. But when we talk about synchronous versus asynchronous communication, what types of things are we factoring in here? Well, synchronous communication might look like getting on a video call to discuss and debate things. It might look like an information sharing session. You might be presenting findings in a PowerPoint or perhaps even demoing a feature that's been delivered. Now, these are common examples of synchronous communication where you would want to have everyone invited into something and on a call or in person at the same time. Now, the benefits that you get with synchronous communication are that people are able to get and give feedback in a way that's very responsive. Now, with respect to synchronous communication, one of the big benefits is that there's a very small delay between being able to give information and get responses for that information. But some of the drawbacks might include actually being able to get everyone coordinated at the same time depending on the size of the audience that needs to be involved. And something else that you're going to want to consider is that when you have a lot of people involved in some form of synchronous communication, not everyone can effectively participate in that communication at the same time. So what you may notice is that on really large meetings, not all of the participants are active. And in fact, you might even find yourself that when you're on some really large meetings, you might be zoning out and you're not actually getting a lot of value out of that meeting. So this is an opportunity where we can be thinking about asynchronous communication to supplement the synchronous communication that we have. Asynchronous communication can be really handy for software engineers especially that are working remotely or across distributed teams. And this is because when we have things that come up that we would like to provide information for or we have questions where we would like to get information, we can actually reach out provide said information or reach out and ask for said information. And even if the receiving end of that communication is busy, maybe in a meeting, perhaps they're offline because they're not at work or they're sleeping. As soon as they're available and they have the time, they can actually go look up the information for you or they can take the information that you provided and take some action on that. If you had to strictly rely on synchronous communication for some of this stuff, you'd actually have a very large time delay where you would have to end up waiting to coordinate for a time where you're both available. And of course, this is compounded when you have more people involved. However, some of the challenges that we do experience with asynchronous communication is that when we need to clarify things that can really throw a wrench into how effective the asynchronous communication feels. When we think about some of the drawbacks about asynchronous communication, in my opinion, a lot of this comes back to the fact that we're talking usually about communication methods that are written. And that brings us to written communication. As software engineers, so much of what we do is written communication. I mean, even what we're doing on a day-to-day basis by writing code is technically written communication. Now, there's a really common spot that as software engineers, we are using written communication, not only just for code, but for conveying thoughts about code. and that's going to be pull requests and code reviews. So stay right till the end because if you want to improve your communication skills in code reviews, you're going to want to watch this video. But let's look at some of the list of things that we're doing day-to-day that are also written communication. This will include things like emails, instant messaging, or even things like design documents and updating statuses on work items in whatever system that you're using to track your work. As software engineers, we are constantly relying on written communication. Written communication is super powerful because a lot of the systems that we are writing into have some type of mechanism for us to have history and for us to be able to look up information that has been written. So think about that for a second. If you can go search your email or search all of your chat history or even through your codebase, you can go find all of the things that you're interested in because they've been written down and indexed in a way that you can go pull it up as you need. But written communication does come with drawbacks. Now, I'd like to go through a little exercise with you. I want you to think about a time that you were reading a message that you received from someone and you weren't totally sure how to interpret their emotions. This might have been a situation where when you were reading the message, you might have thought that perhaps the person was angry, they were upset, frustrated, or perhaps even disappointed. And I want you to think about that message and why you were confused about the state of this person's emotion. I suspect that one of the reasons this is really challenging is that because in written communication, there's not a lot of opportunity for us to be expressing things like emotion and there's no opportunity for things like body language to be conveyed. So, for example, if you're watching this video and not just listening to it, if I were to furrow my eyebrows and really start making an angry face as I start to talk to you, you would interpret that I'm actually angry. Now, if I simply change my expression and I'm smiling and talking about the exact same thing, I'm still using the same style of words and language to convey the thoughts that I want to tell you. Now, in written communication, you don't have access to things like my facial expressions. You don't have access to things like my tone of voice either. Now, I've seen repeatedly situations between software engineers where there were misunderstandings because of things like this. It seems like such a very simple thing on the surface, but being able to improve in your written communication skills, both in how you deliver information and how you try to interpret information can make a huge difference. So to summarize, communication is a huge part of being a software engineer and has many different facets. The first thing we talked about is how you want to consider your audience and how you need to change how you're providing information to that audience. The second thing that we talked about with respect to communication was asynchronous versus synchronous communication and some of the pros and cons that you get out of each of those. The third that we talked about is written communication and how that ties into being such a critical part of being a software engineer. So, thanks for watching. Please give the video a thumbs up, subscribe to the channel, and as promised, here's a link to that video about improving your communication in code reviews.