All Software Engineers SUCK At Written Communication

it took this developer 5 years to realize the significance of this particular skill but hopefully in just a few minutes you can learn why it's so important and make a difference for the future hi my name is Nick centino and I'm a principal software engineering manager at Microsoft in this video we're going to jump over to Reddit and read through a post where the individual was talking about the importance of written language skills now to be fair it's not that it took him 5 years to realize the significance of this skill it's that it took him 5 years to realize that most companies just seem to undervalue the importance of this particular skill we're going to have a read through of the post I'm going to give my perspective on why I think written communication so important and then we're going to analyze some of the comments if that sounds interesting just a reminder to subscribe to the channel and check out that pin comment for my courses on dome train with that said let's jump over to Reddit and read through this post okay so this post is titled after 5 years of working in Tech I've surmised that almost every company severely underestimates the importance of English writing skills some of the tickets I see are so badly written and communicated that it's left me thinking that as an industry we underestimate how important it is for staff to be able to write clearly and succinctly the amount of time we waste seeking clarification when it comes to tickets must be huge it makes sense when you think about it we put people through all sorts of Assessments during the interview competency interviews coding assessments take-home challenges and yet we don't seem to care whether a new hire can write well what makes it even worse is that this skill has become even more important with the rise of working from home and with many of us communicating over slack teams Etc I think this is a very interesting take right um if you watch my other content I talk all the time about why I think Communication in general is extremely important uh a lot of the time I'll have people reaching out to me you know aspiring software Engineers Juniors they're asking what they should be focused on and it's always questions about technology like what's the best language what's the best TCH stack um which projects should I be building you know how do I demonstrate on my resume that I have all these technical skills and while that is important to be able to have the technical skills it almost feels like people forget just how important some of these soft skills or people skills are so in particular uh in this video we're going to be talking about a written language um so yes I think Communication in general is critical so even when we're talking about that you're having meetings with people or you're having conversations in general your spoken communication being able to say things clearly get to the point on topics make sure that you're thinking about your target audience as you're communicating so that people understand what you're trying to convey that's all important but it really really applies to written language as well and if you think about it as software developers what are we writing all of the time right it's code we write tons of code and if our code you hear this a lot right our code needs to be clear it needs to be readable we spend so much more time reading code than writing code and that means that if we're not writing clearly even in our code it's going to be very difficult to even you know understand your own code in the future but we're working in teams you need to be able to convey ideas and meaning through your code to other people on the team it could be next week it could be a month from now it could be years from now but people need to be able to understand your code but it's not just code right I think that's the obvious one we always are coding so it's a really obvious one when it comes to written communication but what about poll requests and code reviews right the comments that we're leaving for individuals we're going to see as we go through some of the the comments in here there's going to be talk about uh work items or tickets that you might have in jira Azure devops Trello whatever else you're using the idea there is like when people are like you know creating a ticket or something it's like you know fix the bug and it's like well where's the information on this right how is this valuable and it makes it really difficult for other people or even yourself to pick up on this work later in general we end up I agree with this person we end up wasting so much time when we're not clearly commun unting and I think there's a lot of examples in terms of written communication that we could do such a better job and honestly it does not take that much more effort I think we just have to have a little bit more awareness of the fact that we are communicating and we need to be clear when we're doing it so the couple of examples that come to mind before we start scrolling through some of these comments and reading through them I've already talked about code I think when you're doing code reviews and poll requests the comments that you're leaving for other people you want to make sure that you're not just saying like bad code fix this like we don't do this this doesn't work like try to explain why Right add the context into there make it easier for the other person to understand I think that's incredibly important I think one like I said that comes up in here is going to be work items so if you need to be able to document something like we do need to add this feature we do need to fix this bug uh Tech Deb in particular for software Engineers a lot of the times what will happen is if you're trying to propose that Tech dead is getting prioritized and scheduled in terms of the other work that's being done you need to make sure that people understand what that Tech de is if you just say like clean up this class or clean up this part of the code like why what's so bad about it what does clean up mean what impact is that having like documenting this information is incredibly important because we've all seen it right especially with tech Deb you bring it up someone says yep that makes sense but it's not a priority right now maybe it's never a priority but if it is is going to get brought up later you want to make sure that if it is a priority it can get the attention but what's going to happen if someone opens this ticket and says what was the priority on this again is it time to schedule it and it doesn't make any sense not going to be a good time it's probably just getting kicked back into the backlog or even deleted or closed off so making sure that you are clear in these is going to go a long way and I realize that for some people that just feels like extra work but truly what's more work spending a little bit more more time trying to write this stuff clearly or having more conversations going back and forth potentially multiple times and spending even more time than just spending a little bit more time upfront writing clearly commit messages are another one I think there's a lot of guidelines online for following like uh templated or consistent styles for your commit messages this might not seem as important to some people if you're not actively going through and uh looking at history uh depending on how you're working or your team structures like this might seem less valuable but I've been in situations where we need to see what's been changed looking through a code change and kind of looking through what the commit messages are and seeing what someone was trying to do versus what code was actually changed can be very helpful in making sure that we understand especially if we have to revert something out I would highly recommend putting a little bit of extra effort into that I say that knowing that in my own personal projects my a lot of my commits are like curse words that I finally fix something or something like that so I get it but I think if I were working in teams and larger organizations committing code I would want to make sure that I'm being pretty clear about what's happening next we can think about messages that we're sending so like I think in this original post here slack teams whatever you're using for communicating with your colleagues you got to remember right they're not all going to be software Engineers they're not all going to be working in the exact same space as you even if they are software Engineers so you need to think about what you're trying to say to your target audience so writing messages asking for help on something for example you can save a lot of time by being more clear about the scenario that's going on so that you don't have this back and forth trying to get someone to prod you for information on things in fact you might even find that in those scenarios you add enough context and someone says look we should probably just get on a call for this because it's going to be a little bit more involved written communication and messages things like email as well you want to make sure that you're providing enough context and explaining things again for your target audience I don't think I can say this enough because I still see it all the time from all different levels of software Engineers uh even other roles as well right you want to think about who your target audience is if you start explaining things in a way that probably only you or someone very technical in your domain is going going to understand like what are the odds that you should be expecting that other people can you know meet you at that level is everyone that technical does everyone understand that domain that effectively if they do then that's a great way to communicate right you're meeting people at their expected level of understanding but if you're talking to a different team that doesn't understand these things or perhaps different roles that maybe don't have as much technical background in your domain you're going to want to find other ways that they can understand this stuff so there's a lot of different ways that we can focus on having a better clearer communication but you need to actively be thinking about these things so that you can practice doing a better job so let's go read through some of the comments and see what some other people had to say so right at the top here as someone who writes 90% of our Internal Documentation I agree 100% right so this person's realizing it too um I think so I took a bunch of Online technical writing classes and I would highly recommend them so interesting right if this is something where you're like maybe I am struggling with this uh maybe I don't uh have enough I feel like I have enough opportunity to practice it you could go look for a class or something like that to go practice this kind of thing and that way you can get some different perspective on different ways to go writing things I've personally never taken a technical writing class or anything like that but uh I feel like in my experience at least I've had to deal with many different types of stakeholders so might not be something that I would value as much but certainly if this is something that you having challenges with that might be a great opportunity um there's a link here for the Google one that's like Tech writing so developers.google.com te writing overview I haven't checked this out but the link looks pretty fresh uh lots and lots of up votes on that so uh might be something to go consider this person goes on to say I agree but I'll add that part of the problem is that getting good requirements is a bunch of work in and of itself so often people find it easier to be vague or to use offis skating language and make the developer do all that it's somewhat reinforced by the fact that often you'll have senior plus level devs who will write their own tickets for certain things like Tech de and since they understand the issue the ticket describes almost nothing just a vague reference so the vague or half-done tickets become normalized yeah so this is kind of what I was hinting at near the beginning right so if you're going to be writing tickets especially for things like Tech de if you're writing it only for you to be able to reference like that might not even be good enough for you a month from now you might lose all of that context because you're off doing other things so writing tickets you want to think about other people understanding this information and at a minimum that's you in months from now if you months from now aren't even going to understand it how can you imagine that other people are going to as well right so think about the individuals that you're working with so your colleagues who might be trying to prioritize this kind of stuff other teammates and make sure that you're trying to write for them as well if you think that they're not going to understand it probably want to go put some more effort into that this person goes on to say it's a pet peeve of theirs especially since older tickets inevitably get canceled because even the writer forgot what they were tangentially insinuating right so it's just like there's a brief amount of text and it's like yeah people aren't even going to remember that months from now let's keep going here move on from some of the ticket stuff we'll scroll a little lower uh so providing a link to the class we already kind of mentioned that uh so people are saying okay this one's interesting so the problem Reddit doesn't want to say or admit to is at the cost of a large majority of the workforce being on Visa or offshor um so shocking if you hire people not born in a country that natively speaks English the documentation of communication barriers might happen so this is interesting right like if you have global companies that are bringing people on from different areas of the world um this is an interesting take right um certainly I've worked with individuals where they're even worried about their own communication so never mind like I know if you're hearing this or reading what this person said and you want to jump on and say like hey like that's not fair of them to say I have worked with multiple Engineers that are concerned about how they communicate right never mind someone else coming to them and saying you're not communicating clearly these individuals are worried about it whether that is their spoken language or their written language so I have seen this in my own experience come up from individuals from different countries so I think that this is a real thing now that doesn't mean that these people cannot get better at writing I think everyone can right they can get better at communication but I think it's an interesting point here that if we're bringing people on from different countries if we go back to the idea that what the op was saying if it's not something we're interviewing for right if the if that's not a focus like should we be surprised I think the answer is no we shouldn't be surprised but that also means that maybe it's not a matter of like okay we Gat people um because they're their written language isn't good enough it might be something where we acknowledge it and we say look we acknowledge this that means we're going to have to spend extra time helping these people skill up in this because it is important and the same thing applies in my opinion to programming languages because I've seen this work really well people it's not like these individuals maybe in their own language their native language maybe they're great at being able to articulate all this information very clearly so it's not the the technical writing that's a problem for them maybe it's just that English is a challenge for them but the same thing with the programming language I've had people brought onto my teams at Microsoft the overwhelming majority of people that have been hired onto the teams that I've worked with at micros sort of like after or right before I started I think uh I might be wrong statistically on this one for sure maybe two people that have been brought onto my teams have known C before so that means every other person has come on and not actively worked in C like they might know what it is but they haven't programmed in it so we spend time and they learn C right it's going to be challenging in the beginning but we spend time to make sure that's better so could be the same type of thing for written language I of course do not have stats on this so I can't say that this is fact or not but I think that it's interesting something else I want to say is also some of it is cultural differences as well what is expected to be communicated in one culture could be seen as unnecessary in another culture this is the cost of all this this is an interesting take too I've actually had employees from Mexico uh especially from uh like uh verbal communication they have told me that they uh they have this awareness at least these individuals that were talking to me about it this awareness that how we communicate in different cultures they have said that there's some cultures that they've interacted with um go out of their way to try and uh soften things before delivering uh some type of key message right so they'll they'll do a bit more of a preamble to try and like feel things out kind of make sure that everything's okay in the conversation and then get into delivering their message and they've acknowledged again that they've been working with other cultures where that's completely not the case where it's much more direct much more succinct and there's situations and they were telling me about these where it's almost awkward because they're doing a lot more softening and they talk to someone who's like why the heck are you like they can tell they're like why are you doing this and then they get this really direct response and they're like okay okay so I think this is a really interesting point on the cultural differences in my opinion it's not a right or wrong thing I think it's about awareness of it so if we have awareness that there are different cultures involved people have different ways that they expect to communicate this is all really important we have to think about our audience when we're having verbal communication or written communication so I think that's an interesting take for sure this person says at least 80% of programmers I've worked with don't even try to shape their code into any sort of consistent narrative I wouldn't expect anything different from their emails or their documentation as long as incoherent programs can still make money we're going to have to live with this interesting I I feel like I kind of agree with this because it's like if it works people are going to keep going right but I'm not saying that I agree with that we should just be okay with it I think that they're probably right with this but I do think that and I don't think this person's uh not saying this but I think that we should uh put more emphasis on trying to make this better right it is an efficiency thing if we can have more clear communication uh this person says this is something I'm feeling more and more the code should be functional but it also but it's also a communication with the next developer who has to read it so I said this earlier when I was giving my perspective on this stuff right so you need to think about the intended audience thank you and how they're going to perceive understand the code and we said the same thing about uh writing work items and stuff like that right you need to think about your audience when you're writing stuff down or you're saying things if you're just thinking like this makes sense to me only are you talking to yourself because if you're not talking to yourself you probably need to be adjusting how you communicate with your target audience if you know because you've worked with your target audience a lot that they are very much like you and they seem to happen to understand all the same things very well you might be able to get away with it but think about your target audience even something as simple as please put the test cases inputs for your test next to the actual test method is something I can't believe I have to tell people over and over it'll run the same but if you just dump everything into a file willy-nilly it's a nightmare to read so interesting right so they're talking about some coding standards different ways uh it might be a stylistic type of thing but they're saying like hey look like if you collocate things it makes it easier to understand so um that could be a personal preference there might be reasons uh that people want to do it a different way but the point is like if people aren't thinking about how this stuff gets interpreted it's a missed opportun for doing it more effectively and finally we're going to jump down to this one this person says this is why I'm glad to have a history degree interesting early in my career it dawned on me that the first functional version of a deliverable be it a utility script that's just for now until we can write a much much better version or adding a feature to a product it's just a first draft it Al it also helped me to not take critical code review comments personally I've talked about this before right where um we want to be able to separate oursel from the feedback but I think there's also an opportunity for the reviewer to just not be a butthole when they're leaving feedback like you can also do a little bit more work leaving comments you can make things explained uh well you can make sure that you're uh trying to write things in a way that don't feel like they're an attack like I think communication works both ways but yes on you know to this person's point uh having some of that uh that background is giving them that ability to not take it personally which I think is awesome so meaning a judgment on my value value not an attack on me right so uh great point it's possible to take that mindset too far which is where communication about expectations is vital but I find the refinement process including proper documentation is a lot less frustrating when it's treated like any other writing process so a reason I wanted to read this comment out too is because they said this is why I'm glad to have a history degree I do try to on my channel and other social media platforms talk about the fact that people with different backgrounds so not just going sort of the air quotes traditional software engineering route of like I was born with a keyboard in hand I've been programming in 17 languages for the last 40 years like and then went to University you know like people that did not do that and they happen to take maybe an alternative path there are plenty of awesome skills and experiences that can really contribute into software development it's different perspectives it's different experiences and this person's case I think it's a great point that they're saying their history degree actually helped them with this part in particular with all of that said I hope you have some additional perspective on why written communication is so valuable in software development and that means that as you go forward hopefully you can help shape the areas and the companies that you're working in to try and make communication whether it's spoken or written improved right we want to make this better for the future going forward so thanks so much for watching and I'll see you next time