I'm A Junior Developer - How Do I Improve My Soft Skills?

• 500 views
vlogvloggervloggingmercedesmercedes AMGMercedes AMG GTAMG GTbig techsoftware engineeringsoftware engineercar vlogvlogssoftware developmentsoftware engineersmicrosoftprogrammingtips for developerscareer in techfaangwork vlogdevleaderdev leadernick cosentinoengineering managerleadershipmsftsoftware developercode commutecodecommutecommuteredditreddit storiesreddit storyask redditaskredditaskreddit storiesredditorlinkedin

From the ExperiencedDevs subreddit, this developer wanted perspectives on improving soft skills as a junior software engineer.

📄 Auto-Generated Transcript ▾

Transcript is auto-generated and may contain errors.

Hey folks, we're going to go to the experience dev subreddit. I'm just sitting in traffic here, so let's do another video. This one is from a developer who is asking about being junior and uh trying to focus on improving their soft skills and any advice to go along with that. Uh and I think this is great, right? I think that we often don't get enough uh people talking about how to to focus on this kind of stuff. I realize that everyone especially in software engineering is you know very focused on how to get better technically right there's uh a lot moving very fast especially with AI now but even before AI was a huge focus it was like well what's what's the best programming language what's the best tech stack how do I get projects for my my resume it's always like technical technical technical how do I prove that I am able technically And so don't get me wrong, you know, technical competence is still very important as a software engineer.

Makes sense. Um, but like I said, I don't think a lot of people are doing um I don't know, like getting their focus on on soft skills and things like that. So, it's great to see someone kind of asking like, hey, how do I do this? And so, uh, I thought it was kind of interesting because they they say in their in their comment like, you know, I'm they're a junior developer, but they're like, you know, I'm trying to get better at leading projects and stuff like that. I'm sitting here going like, great for you. Like, if you're a junior developer, leading projects plural, like this is a thing that you're doing. I think that is awesome. Um I I don't think it's that common that uh juniors are are doing that kind of thing, but I think it's great if you find such opportunities.

Um I wanted to talk about this in a way that's maybe a little bit more general guidance that I think to for me is like a helpful framing for how to approach this kind of stuff. And that way in your situation you can kind of massage this to fit. When I think about soft skills, I think uh primarily about communication and uh how to try doing that more effectively. And when I think about communication and where I see that often going wrong is assuming too much about what you are saying and how that's going to be interpreted and then the inverse direction, right? like assuming too much about what someone else is saying and what their intentions are. Because of that, I think that this kind of stuff has like absolutely nothing to do with software engineering specifically. Like this is just generally applicable for for life.

Uh but there I I don't know like as a software engineer and someone who's been in this space I don't know if I'm just biased to thinking that this is like a lot more of a you know common issue in software engineering but uh it to me it seems that way. It seems like we often have a lot more challenges surrounding communication. So um where to start on this? I I think that, you know, one of the most important things to consider is that when we're talking about communication, we're we're relaying information between audiences, right? Like you have some thoughts, you are communicating them. You want people to sort of understand and uh the meaning behind what you're saying, right? You want them to receive the information the way that you intended. Like that's the goal, right? And um we need to understand that like how we intend information to be communicated does not guarantee that that uh the impact of such communication is received the same way.

And that might sound obvious or maybe that doesn't make sense. I don't know. But um the point is that once you know once the information leaves your mouth or you've typed it and pressed enter once that's happened how the other person or people interpret or receive that is no longer directly in your control like you've already sent the information. Right? I realize this might sound kind of weird but I'm I'm just trying to get you to think about what's actually happening. And so unfortunately like once that's happened and it's not in your control for how they interpret it, what I think is important is observing how people interpret it, right? And so if you are someone who's more senior, right, you you might not realize this, but sometimes when you're conveying things, there's a lot of additional impact that your your message might have on more junior people without you realizing it, right?

So like you may be telling them things. This bus is trying to get in front of me. This is insane. No zipper merge behind me, buddy. Oh, this is the worst. I'm stuck behind this damn bus. Um, God. So, yeah, if you're more senior, you you might be conveying thoughts, right? You have an intention behind them, but you're not realizing that there's like an additional impact that is received. And it could just be your tone. It could be something that you're not intending. But it's important to observe how people receive the information that you're conveying because this gives you an opportunity to then adjust as needed. Right? Because if your intention was one thing and you're observing that that's not potentially not how it's received, then it makes sense to adjust. And I would say we get better at doing this by understanding our audiences better.

Right? So understanding that every person you're talking to is is a different person. They're they're going to be unique in their own ways. Right? Uh you might see a lot of differences even talking amongst more junior developers. You might notice some general patterns between junior versus more senior or people of different cultures. Like that's a big thing to consider, right? people have uh you know different communication styles and patterns uh that that come from from different backgrounds and that's not to say that like just because you are from a background you must be communicating some way but there's some generalizations that if you I don't know like spend more time communicating with a more diverse set of people you'll pick up on some of these things so that you can try paying attention to them sooner the other thing is across roles right? Um, understanding that maybe someone who has less of a technical focus in their role, you may need to communicate things differently.

So, regardless of who you're talking to, the intent of what you're trying to relay might be identical, but you need to adjust for your audience. Right? To give you a very concrete example, say you're trying to explain a bug that's in the codebase. Okay? So um your intent with your communication is so that the person on the other end understands what is happening with the bug. If you are let's just say you're a more senior developer and you're talking to another senior developer who works in the codebase with you might be able to get into a lot of technical detail surrounding that. Right? they're familiar with the code, you know, um they have a deeper level of understanding maybe compared to someone more junior. Um so you can go deeper and explain things and be more thorough. Uh maybe there's another senior developer who doesn't work in that part of the codebase at all.

They're on a different team. They're not even familiar. You might still be able to talk about some technical depth, but there might be some nuances, some hyperspecific things in the code where like you need to omit that because it's just going to be confusing and irrelevant to them. If you take a junior on your team, right, um you might say like, okay, maybe they have less technical depth than their understanding. I need to uplevel this, but still talk about parts of the code. So, it's kind of teaching them and getting them acquainted. Maybe you're I hate making it sound like I pick on product managers like to be less technical, but a product manager, engineering manager, if they're not actively working in the code, they might understand the domain that you're talking about, but the specific, you know, classes and files in the code, maybe less so.

So, you would omit that kind of stuff and still try to navigate your explanation of the bug without hyperfocusing on that. So in all those situations like you're conveying the same intent or attempting to but you need to adjust your communication and this gets a lot more complicated when you have an audience that's a mix of you know different roles. So my point for for thinking about this kind of stuff is that you know if you are someone who's more junior trying to think about how do I get better at communicating um or in this case they were saying soft skills I'm focusing on communication specifically I would I would really recommend like how do you how do you start taking a step back and like and understanding that like if you want your communication to be effective you need to be thinking about the people receiving it, right?

It's not it's not just, oh, I said it and or sorry or I typed it and pressed enter. Now it's the onus is on the other person like they need to just understand it. Like that's not that's not effective, right? That's that's actually assuming that you have perfect communication and surprise, you don't like no one does. uh it is uh something that kind of goes both ways and on that note let's talk about the other direction right so um while you are trying to improve your soft skills and improve your communication you are trying to you know understand how other people are interpreting what you're saying or what you're typing trying to make sure that you're doing a good job explaining things in ways that different audiences will understand great stuff you're working on that what about the other way All right. So, now you got the, you know, the the old old guy on the team looks like me, right?

Got white in his beard, doesn't have hair, and um you get a, you know, a bunch of comments on your code review, and you're like, "Holy this guy is old and crusty and mean and, you know, doesn't want me to merge code. Like, he's always complaining about stuff like can't seem to do anything right." um these might be things that you interpret from how they're communicating and so maybe there's someone who hasn't put a lot of thought unfortunately into like how their audience receives things. Um what I would recommend to you is like please please do try assuming that people are acting with best intentions because uh I would say it's not impossible that people are malicious with their intent but uh at least from my working experience if you're working on teams with other people odds are you're all trying to move in the same direction.

You're all trying to get better. You're all trying to deliver value to customers. odds are they're not intending to be malicious. And so when you start to feel this way, right, when you start feeling like, man, that Nick guy is such a pain in the butt, like I don't want to add him onto my reviews cuz he's going to have some stupid comments and it's going to make me feel stupid and I can't do anything right and this guy sucks. Um before going down that path too far, uh try reminding yourself right like people are acting with best intentions. And I think that if you can try catching yourself when you're getting comments like this, maybe it's on a design document, maybe it's messages in chat, um code reviews, emails, try remembering like catch yourself going when you're thinking like someone's being an to you or they're mean or they're upset with you, whatever.

Try remembering, hey, what if what if this person is genuinely acting with best intentions? What if um you know I try reading this in a voice that isn't like I hate you or I'm mad at you? What if? Right? Like try doing that. Try that exercise. And um I encourage you to like keep this in mind. I say this because um unfortunately like I don't know enough about psychology on this kind of stuff. Uh so I don't want to make it sound like I'm pretending to know. But um I I think a lot of the time what happens is that when this goes unchecked, we start like more generally assigning this kind of uh intention or this kind of voice, this narrative to others. Right. So, the example I was giving where it's like, "Oh, every time I put Nick on these PRs, he's just old and crusty and mean and it sucks." Um, like a lot of that is actually invented, right?

It's not necessarily grounded in in reality, but it's it's a narrative that you've created. And I'm not saying like you should feel bad for doing this or you're wrong or whatever. I'm just saying a lot of the time we invent this kind of thing. And like if you don't believe me, I like challenge you to think about someone that you work with where you're like, "Ah, they kind of they're the old crusty person or they're always a pain in the butt." I challenge you like go go talk to them about these topics, right? like have an honest conversation with them about like the comments you get on your PR and and like you're feeling like you can you can steer this however you want, but like hey like it seems like you know when I'm reading your comments it seems like you're upset with me or it seems like uh I can't seem to do anything right or whatever.

Like tell them how it makes you feel and have a conversation with them. I bet you I would bet you right. I don't know statistically speaking, but I bet you more often than not, uh, people don't realize that they're having that effect. They don't intend to have that effect. They're just trying to do what they think is right, what they think is helpful. I think there's there's absolutely situations where people are in a bad mood and they're they might be taking it out on you and not realizing it. But I I think it's very rare that people are actually doing this kind of stuff um with ill intent. So if you are someone that's more junior and you're trying to get better at communication, I encourage you to try keeping this in mind so that you don't start building resentment and you you don't start building like this artificial interpretation of like what's happening when you're interacting with others.

If you do start doing this, right, you start going down this path where you're like making assumptions about people's communication, it's not like you're screwed now. I would just recommend that if you notice you're doing it. This is going to sound really difficult and I promise you it's much easier than than it sounds. Have a conversation with them. You are a human. They are a human. just have a conversation with them. I know that sounds scary because I get it. Like I don't like the idea of having to have a conversation like that cuz it sounds confrontational. But in my experience and from the people that I've worked with and either coached, mentored or managed, having a conversation like this almost always results in a much stronger relationship after because there's some amount of like vulnerability, transparency, alignment. People are like, "Wow." Like, you know, it took courage for like they get it.

Like people understand it takes courage for you to talk about something like that, right? Like it it ends up creating a stronger working relationship and then you get alignment on it. They go, "Okay, like I didn't realize that when I do this, it's having this effect." Right? I I know it sounds kind of scary, sounds like more work, easier to just avoid, but I promise you um it will make a a really big difference. So that would be my recommendation to this person for their soft skill improvements is one, think about your audience when you're communicating and that way you can adjust your communication for that target audience so that they can receive your information more effectively. And then the inverse trying to understand better um that people communicating with you are more often than not operating with best intentions and that if you're struggling to really see that um try having a conversation with them.

So hope that helps. I think there's you know lots of things to focus on for soft skills especially around communication and I hope those two highlevel things uh help. So if you got questions about software engineering or career development, you can leave them below in the comments and otherwise you can go to code.com. You can submit questions anonymously that way and I will make a video response for you and others to watch and hopefully it can help other people as well. So thanks for watching and I will see you in the next one. Take care.

Frequently Asked Questions

These Q&A summaries are AI-generated from the video transcript and may not reflect my exact wording. Watch the video for the full context.

How should I start improving my communication as a junior developer?
I would start by thinking about the audience and how they will receive what I say or type, and I can't assume my intent will be understood. I observe how people interpret it and adjust as needed, because once information leaves my mouth or I press enter, the impact isn't under my control. I want to tailor my messages so the other person can receive them effectively.
How should I approach feedback in code reviews to avoid misinterpretations?
I try to remind myself that people are acting with best intentions, and I assume they’re trying to help rather than attack. When feedback feels harsh or unclear, I consider having an honest conversation with them to understand the intent and how it makes me feel. I’ve found that these conversations can build stronger working relationships and alignment.
How do I tailor explanations about a bug for different audiences on the team?
I adjust my bug explanations based on the audience: with a senior developer who works in the codebase I can go deeper, while with a senior on a different team I omit hyperspecific details. I also tailor explanations for juniors by up-leveling the explanation but still covering relevant parts, and for product managers or engineering managers I focus on the domain rather than the exact classes and files.