Just TWO Words Will Make You A Better Software Engineer

in this video we're going to look at two words that are going to revolutionize your communication with other software engineers and team members this is a concept that's actually used a lot in improv and I just want to offer a full disclaimer I am not good at improv at all but I thought it was really interesting that it's a carryover from that to illustrate this let's actually walk through a really common scenario that we all go through with software developers pushing up code to be reviewed by our peers now if you're very Junior you might not have encountered this yet but for people with more experience this is actually unfortunately a pretty common thing that pops up okay so the scenarios that you've been asked to work on a feature and you've been developing the code for it running it on your own and it's actually working so if you have a service you've tested out the service and it's doing what you expect or if it's a user interface application you've checked it out and you've gone through the workflows and it's all working exactly as you'd expect and you push it up for review and your teammates go to look at it and then the comments start rolling in and you start seeing the names and it's the one person on your team or maybe it's someone else on a different team doesn't matter but you start aren't seeing the comments coming in going nope this doesn't work change it change this change that like get rid of this and everything on there is completely dismissive of the things you put up and you're sitting there reading these comments like okay but I'm running it and it works and it's doing the thing how could it possibly be so bad that everything I put up is being totally dismissed and I'm being told everything's wrong all right so we're gonna come back to this one but I want to give you another example to walk through and we're going to look at both of these and flip it around with just two words to improve all of it okay so in this situation let's imagine you're on an engineering team and your task is that you guys have to figure out a way to improve the performance of your service so within your team you're going around the group and kind of asking who's got ideas so you put your hand up and you say well I think we should address the database queries because I've been taking some measurements and I think they're going slower than we'd expect I think there's too much latency we might want to look at addressing the round trip time so maybe we can put a Cash in place or figure out some way to be doing fewer on trips so that we can be faster and you're feeling pretty good about yourself because you've finally been able to speak up and kind of share some insights and some Focus areas that you think are important and right away someone goes no but I think we should actually try to focus on the hot path that I've measured and it's actually related to this Loop that's running and we should address that because this is actually the most important part and that person is the senior engineer on the team and of course because they're more senior people are looking to them for guidance and they've totally shut you down and now you're kind of feeling like I don't want to speak up anymore because that felt pretty bad so I've exaggerated these situations a little bit but these types of things do come up where you're on code reviews and things are being dismissed or shut down or even in idea sharing sessions where you're finally able to speak up you kind of feel like man why did I bother doing that because I'm left feeling like really bad about me sharing my own ideas now like I said I'm going to transform just two words in these scenarios we're going to go through them again see if you can pick up on it and then from there we're going to dive into why this works so much better okay so your code review goes up in the first example right you're all excited because you finally got the feature working the comments start rolling in you start seeing the names for who's sending it you start holding your breath because you're nervous about what's about to happen but you start reading the comments and you read I see what you're trying to do in this particular situation I like that you tried to address this algorithm this way and I think that if you were to change this up a little bit I do think that you'd be able to get the performance gains that I was concerned about so that might help or it might be a matter of hey I see what you're trying to do with this feature here and how you were implementing in this spot and I think that if we were to try moving it over to here it actually might be more scalable so we won't run into some challenges that I'm foreseeing in the current design in this case it actually doesn't feel so bad because you're hearing hey look this person actually sees what I'm trying to do they acknowledge it's probably working but they're sharing with you something to improve it and giving you some reasoning behind that so a subtle change if you haven't picked it up we're going to analyze it a little bit deeper but let's go to the second example walk through that now with the same change right so it's about trying to find an area to improve the performance in your service and like I said you're kind of feeling nervous about speaking up but you put your hand up and you say well I think we should address the database queries and the round trip stuff that I was talking about before and then the senior engineer speaks up and says yes and I think after we look at that we should also consider this hot path that came up in my analysis because I noticed that that was adding a lot of execution time that we weren't expecting all right so that second might have been a little bit more obvious but let's actually pick this apart and see what changed all right so let's cue up the drum roll and the answer is two words just like I said you're changing no but to yes and how simple is that right the entire idea here is that when you're saying no but or even leaving out the button just saying no and dismissing things that you're actually completely shutting down people's ideas and your intention might not be to do that if you're the one saying this or if you're hearing this that's probably not someone's intention to say hey everything you were just saying zero value shut it all down that's likely not the case but what they're probably trying to do is saying this other thing I think is more important more valuable or more correct the problem with that though is that when you completely dismiss someone's ideas and this goes back to communication and why I think communication is such a fundamental skill to have as a software engineer that when you shut down people's ideas like that they are less likely to keep speaking up and sharing ideas and sure some people have thick skin They Don't Really Care they're going to move on from it but I do think that the more Junior you are the more likely it is that you're going to be like oh man that didn't feel good and start to get trained out of speaking up more and that's exactly what we don't want for more Junior Engineers we actually want to be working in the exact opposite direction so that more Junior Engineers start gaining more confidence and you as a software engineer with more experience you actually want to be trying to level up the people around you this is going to help you progress and become more senior as a software engineer and yeah there are definitely software Engineers that be become more senior without doing this and the reality is they're not a lot of fun to work with because they keep shutting down your ideas they're not very collaborative and having people like that within a team can be detrimental because it feels like everything grinds to a halt because the more senior person is speaking up and they shut down all the ideas of the team even if that's not their intention when we change the framing to say yes and what we're actually doing is acknowledging that someone had a good idea this is more positive reinforcement even though it's a tiny little thing it's going to help people feel like it was comfortable to be able to speak up it was a safe place and even if you offer criticism after that or disagree with it right you might say yes and I think this other thing is better right so you can still have a difference in opinion you might still say like I think this is more important but you're acknowledging that someone had good input when you do this within a team especially when brainstorming you actually can get so much more momentum because instead of proposing ideas shutting them down going back to square one you can actually propose ideas and other ideas and keep building on top of them taking the pieces that seem to align and keep making progress that way but when you say no but and then you completely replace it with something else the person who offered up the idea or even the other people observing that conversation say it's on a design document or something right if they're reading through this and they're reading the comments on the document or your feedback and they see no but and this other thing they might have the impression that you're saying that thing should be completely omitted it's not valuable right there's not enough context when you say no but and then you're just dropping off the one thing that you're dismissing and to be completely honest I didn't have any idea this had to do with improv until I went to go make this video I wanted to see if other software Engineers were talking about this kind of thing and when I started searching for one of the first hits was actually that this is an improv tool and here's the article I came across so I'm not going to read through the whole thing but I just wanted to point it out to you because I thought it was super neat that that was the case so what I noticed here was they were saying they give an example right so you end up getting this example here so person a is saying wow it's so hot today and then their improv partner says what are you talking about it's freezing so partner B is stopping the scene from moving forward right so an improv the whole idea is that you're kind of playing off of the other person or the other people in the group so someone will say something and because there's no script the whole point is you need to keep the momentum going so as soon as you have someone that's completely dismissing an idea it puts a break in place where you're like oh crap like I have to think of something new some new trajectory to be able to jump in so in this example the wording they didn't actually like literally say no but right because they say what are you talking about it's freezing there's no but in there but what they're doing is actually putting an end to the train of thought from the first person and just saying something else and actually what this person goes on to say is but like what if the suggestion that that one scene partner made actually makes the first partner uncomfortable right and I want you to think about this back to the software engineering perspective so if you're the person shutting down other people's ideas you're not realizing it you're just saying no but this other thing the person that you just shut down completely they might be left in a state where they're like okay like I thought there was some Merit to what I was saying but now it's just been completely dismissed it's a really bad feeling so it's a very interesting parallel and then the rest of this article actually just talks about some like improv games that you can try doing and you're actually practicing replacing situations where you're saying no but with yes and and that way you can literally play around with like the phrasing and actually making it feel like it's more productive okay but I don't want to just leave it at improv I thought that was a really cool example because it's totally separate from software engineering but it still is exactly the same type of idea going on because it's all about communication and I'm going to pull up another article and this one's actually from LinkedIn here so full disclaimer I actually don't know who this individual is they're a CEO at some company so that's interesting um but I thought it was really cool that in this article that this person wrote they were actually saying that they they tried this exercise where they went around a room and they got people to explicitly say no but and then go and like generate a new idea so one person would go and say something and the next person would say no but and then continue on with something else and they repeated the exact same thing but instead of no but you said yes and and the result of that was really cool because people were saying that yes and actually felt a lot more creative they can move faster and get more momentum and then no but actually made it really hard for people to come up with ideas and move forward so again not necessarily A group of software engine years here but it's a perfect parallel example to how this communication style can really have an effect on either stopping things on their tracks or making momentum for generating ideas alright so that's exactly how two words can revolutionize your communication as a software engineer and if you were thinking about this in the sense of no but and you were reading the title and you were looking at the thumbnail and you were feeling like nope like that's not what was going to revolutionize someone's software engineering communication you might be a no butter so you might have said no but what would revolutionize someone's communication skills or level them up as a software engineer is actually doing more code reviews or building more projects right you're dismissing the idea and having something else in its place if you were a yes Ander you could say something like sure two words could revolutionize someone's abilities as a software engineer and I think something else that would really help is building more projects on the side is participating in more code reviews so you're adding additional things onto it so just a little example tying it back to this video so I hope you found that useful I want to keep reinforcing with people that watch my content that yes all the programming skills super useful we can keep building on the technical skills right so we can be looking at different architectural patterns best practices things like that all tying back to actual engineering coding and software development but the communication part and other human skills I feel like are often neglected and so much of the time when we focus on the Tactical Parts these Advanced really quickly and the other parts are kind of left in the dust I do think that if you want to become more senior and a more effective software engineer you really need to focus on these things and right not but but yes and you need to focus on your technical skills in addition so I hope you found this useful thanks so much for watching and we'll see you next time foreign