Strong Opinions as a Senior Developer: Good or Bad?

Strong Opinions as a Senior Developer: Good or Bad?

• 313 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 to know if it's good to have very strong opinions as an experienced developer.

📄 Auto-Generated Transcript

Transcript is auto-generated and may contain errors.

Hey folks, we are going to the experienced dev subreddit and this developer wanted to know if being super opinionated is good or bad and you immediately might have some thoughts on this but I think they're I think their framing is is helpful. So they they go on to say that you know earlier in their career they felt that you know having being being very flexible on things was uh sort of convenient but as they've uh gone on in their career and they become more experienced. remember like from the experienced dev subreddit if you're not familiar with it, the intention is supposed to be that um the people that start the threads are by some definition experienced developers and they have a dedicated weekly thread for more junior people asking pardon me more junior people asking uh questions to the experienced uh developer group. So the people that post these are supposed to be you know people with uh some experience in the industry.

So, they've gone on to say that as they're more senior in their career and as the time progresses, they're finding that um they they feel like they've seen enough patterns and things like that where they they really want to start being uh a lot more opinionated um about how things are done so that they can avoid problems that, you know, teams have encountered in the past and stuff like that. And uh you know, I think when I read this, it like it it makes a lot of sense to me on the surface, right? It's like I have these years of experience. I've I've kind of walked the walk. I've been there, done that, and like uh not that you've seen every problem, of course, but you've seen a bunch of problems. You've had to to live through some of the pain. And that is some of the best learning that we can do, right?

is to to experience these things and go, man, like next time like I think we should really do things a different way. Um, and so I get it right. It it to me it does on the surface make a ton of sense where as you're more experienced in your career, you want to start like helping people not make the same types of mistakes. Like uh can you help other individuals learn that? Can you help your team? can you help other teams and potentially your whole organization learn from, you know, problems that you've literally lived through in the past? And so, like I said, I think on the surface it makes a lot of sense. The um I think there's there's some nuance though, right? And the question is like, you know, is it is it good to have really strong opinions? And, you know, I to this I would say sure.

I think everyone should have opinions. I think that's a really good thing that people have opinions, but it's what you do with that opinion that I think changes the framing of of this question a lot and how I would want to answer that for people because if you leave it on the surface of like is it good to have strong opinions? I would say hell yeah. Have your strong opinions. I think it's really good that if you've lived through things, you have a strong opinion about it, and you can say, uh, especially with clarity based on signals that look like this, data that looks like that, um, I have an opinion, and here's like, you know, x number of examples where I can sort of back this up where this would have been helpful or it was helpful because we we employed this. I think that's super great and I think there's lots to learn from that.

However, um the counter to this is what you do with it, right? So once you get into a mode where your strong opinion becomes the roadblock, I do think that's where uh it becomes a problem. And I think that there are people uh unfortunately like lots of people that have a difficult time balancing this And I will sit here and say that, you know, I've been an engineering manager for for 13 years now. And I don't I'm not going to sit here and say to you like here's the solution for this because I don't know um the solution for this. Um but to explain sort of the impact or the side effect from from like my lived experience is that when you have people with really strong opinions I think that can be really helpful for communicating with the team so there's awareness so people

can have better design so they can factor in this kind of information right it's like you can you can share your learnings with the team and I think that that is tremendous but the the problem. The problem or the challenge I guess is that this kind of behavior where your opinion becomes the roadblock is such such attacks on a team that it can literally grind things to a halt. And the unfortunate part is that uh I guess a couple things like one is that sometimes or I would say most of the time if not all the time people are just trying to help right people aren't saying from my experience not trying to say here's my opinion and you better listen to it or else because I hate all of you and you got to listen to me. It's like no I'm just trying to help us do you know what I believe is the right thing based on my experience.

So that's you know that it sucks because you're you are trying to help. And the second part is that a lot of the time people don't realize just how much of a negative impact it has when they are sort of uh completely roadblocking these types of things. And when I've talked about this before, um there's sort of like a an archetype of a developer or like a persona and they're not the same, but I find that this other persona happens to do this a lot. And it's the intelligent Okay? And I'm not saying that anyone who has a strong opinion that roadblocks things by definition is an intelligent but I would often say the inverse that like most intelligent often do this roadblocking kind of thing where they have a strong opinion and that's the only thing that's going to happen. So it's it's kind of like usually one comes with the other but not necessarily the other way around.

So, I'm not I don't want to focus on, you know, the intelligent archetype. I want to talk about this idea of like what it means to have a strong opinion. And the phrase you've may have heard is something along the lines of like strong opinions loosely held. And the concept there being like yes, it is good to have strong opinions. It's good to use your experience and knowledge and data points and all of this to help bring information, visibility to a team, group of people to make better decisions. But at the end of the day, it's not something that you dictate because what ends up happening when you do this kind of thing, especially across uh multiple groups of people, is that you end up halting the progress because now you are the gatekeeper across X number of projects and you slow things down so

much that things cannot get done because at the end of the day what ends up happening sorry is that you're essentially enforcing that you are uh like you are the developer without doing the coding work on all of these projects. It has to be done my way. Implement it this way or else it it won't make, you know, I won't sign off on it. And it's not good. It's uh I can, you know, speak from my manager experience that when I talk to people on I got to get out of this lane. Why are my windows all fogged up? Give me one sec, folks. I just realized my whole window is fogged up out of nowhere. That's so annoying. My window is so fogged that I didn't see that I hadn't merged over one more lane. Man, that's okay. So yeah, my my experience as an engineering manager over the years talking with individuals on my team when I ask them about things like engagement, right?

Um obviously we talk about the type of work they're doing, uh the areas of career growth, things like that, but I also try to to ask about the opposite, right? Like what are things that are that are disengaging for you? like how can I help in these areas to make sure that as much as possible ideally that you know you come to work and you're excited about the work you're doing and across the board over the years literally across the board I would say the most common thing I see aside from things like um you know I want to be able to common things are like I want to be able to work on interesting projects or projects that are aligned with my career growth aside from that the most common thing that comes up is that mis conversation around like I just want to

be able to do good work without uh and usually they don't say individuals they try not to but usually don't say like certain individuals but they'll say I want to do good work but it seems like I can't because I'm always like basically blocked on someone or someone is uh has some kind of behavior where it's like I just can't get anything done because they need to have the final say and that person is not actively engaged in the work that's happening. So they end up feeling like I can't get anything done because of this, right? It's like they're kind of in lock step waiting for someone to to say yes. And again, from my experience over time, it's usually it's usually not like one person on the team is saying, "Hey, I have this challenge and uh it's, you know, it's only with one

person here." It's usually a theme that comes up where it's like you'll have one or two individuals that kind of have this behavior on the team, but they don't realize and they actually do believe that they're trying to be helpful. And I legitimately believe that they are trying to be helpful. Um, you know, if you were to talk to these individuals, their goal is that they're just trying to do the right thing for the team. And uh and it's really challenging because if you can imagine a conversation like this, how how do you have a conversation with someone who is putting a lot of time and effort into helping? How do you tell them by the way the way that you're helping people is actually uh like I'm going to use a stronger word. The way that you're trying to help people is actually harming them.

harm is a pretty strong word, but like hindering them, right? You'd pro like if you were the receiver of that, you'd probably be like, "Whoa, whoa, whoa, whoa, whoa, whoa, whoa, whoa. What do you mean? Like, I've been, you know, I've been putting a lot of effort into doing this thing that's supposed to be good, but they don't realize that it is problematic." And so as I'm saying all this, some of you might be going, "Okay, well maybe I've seen this or maybe you're hearing it going,"Well, isn't there like an easy solution to this? Like why why don't people just tell them? Like why don't people just say when you're doing this? It's actually a you're being a pain in the ass." And great question. Um we should be doing more of this, but I I think that the way that this happens is like it's over time.

Uh there's often say a seniority or power dynamic, a perceived one at least, right? Usually usually this kind of thing comes up when you have more senior people who have the experience who are trying to help and they have a strong opinion and it's not loosely held. It's a strong opinion that's enforced. And then you have more junior people usually I'm generalizing here, right? you have more junior people that are they have less confidence in the area. They want to be able to trust what the more senior person is saying. There is this power dynamic or perceived one where they're like the more senior person says this therefore that must be what I have to do. And so if you're thinking, why doesn't someone just say something to them? I think it's because of things like this where um they're like, well, I guess this is just how it has to be and I guess I just have to listen and I guess it just is a slow kind of sucky process.

And then usually for me at least in my career how I hear about this is you know through one-on-one conversations or um I'll hear it kind of like observe it even in like uh weekly sync meetings or standups where it's like yeah like still waiting for this person's feedback or you know did what this person said and like uh you know got to go back to the drawing board once again because like now there's sometimes it's like almost like scope creep. Like I did the thing I thought and they were supposed to be in agreement, but like now they have more opinions about this. And at this point, it's kind of like you're just it feels like you're just doing the work that this person probably should just be doing if they have such a strong opinion. And it's it's just a crappy dynamic for people, right?

So again, I do think, you know, an improvement to all of this is, yeah, like we should be communicating this kind of stuff more often. We should be saying to people more often, hey, when you're doing this kind of thing, um, I I know that you're trying to be helpful or I believe that you're trying to be helpful and genuinely and like and here's sort of the impact that it's having. Now, some of you may have talked to people like this and had conversations with people like this, or some of you might even be people that are like this or were like this in the past, right? It's it's not like a rare thing. It's it's a pretty common thing that happens. And I think that when I've talked to people like this, some of the issue comes back to trust. Some of it comes back to trust.

And it's it's hard to have convers like to make a video like this and like talk about this without um you know my my goal is to never say like here's the only things are the only ways this happens. It's not the case. But um I often think a lot of it comes back to trust. And it's like if you don't do it this way because I've seen these things happen. I don't trust that you know how to navigate this or I don't trust that you fully understand this because if you did fully understand it you would have done it the way that I'm saying cuz this is this is the way right this is how you prevent this or this is how you uh enable this which were you know we're going to need this or whatever it is I don't trust you that you understand this fully I don't trust that you can handle this I think that's part of it.

Um I think the other thing that comes up too like I think trust is a big part. I think that in some cases I've seen where like a pretty typical or like stereotypical I guess like a example of like programmers I'm using the word programmers specifically being detached from like um like business value is that uh you get individuals who are focused on like what code looks like specifically and Maybe this is just becoming more and more of a thing of the past with AI, but you get very attached to like very specific coding patterns because this is how it was taught in school. This is how I've seen it uh exactly like this in my career or whatever. Like very specific coding patterns and it has almost nothing to do with like what is the context of this feature, this bug fix, what we're building for this user, whatever.

no context of that and it's purely what does this look like from a programming perspective and I think this is a little more rare but I have definitely seen this and again these people they mean well they're trying to say like these are like these are the right things to be doing we're we're programmers right like if you want to be a good programmer this is what good code looks like this is the right thing to do you might even see this kind of thing uh a good example or similar examples when I think a lot People can relate to this on a code review. You have people that are like hyper pedantic about like a like variable names or whites space or like like things where when you see people talk about this, it's like dude, it's a llinter. Like you don't like put a llinter in place if you give a that much.

Like it shouldn't be people arguing this kind of thing. Such a waste of time. Um, so sorry. Such a waste of time to be arguing about it. Not to say that like there isn't value in like clear variable names. I'm not saying that. But um, how it comes up is such a waste of time. Like if you really care, build it into a llinter so that you never have to have this conversation again. And so I think I've seen this kind of thing happen where you know it's uh it's it's just detachment from the context and then trying to take a strong opinion and it's not loosely held. So what do we do? Right? And so it depends on which side of this you're on. I want to try talking about this from the perspective of someone with strong opinions. Right.

And one of the best examples I've seen of this recently, um I won't So this is a a former employee of mine and uh I thought I just thought this was such a good example of of of this kind of thing. This person is a uh very experienced developer especially in a particular uh area of code uh for a particular domain. All right, they've been in there for years. They uh they could tell you the history of all the code and they could tell you like not only from like a highlevel architecture here's here's how I would keep building this thing out but they could tell you like more specifically by touching these classes or the this area of code, right? Like they they have it kind of mapped out in their head the direction that they just see all this going. And so of course they have tons of strong opinions.

They've been in that space for a long time, in that codebase for a long time, in a position where they're mostly driving it for a long time. It to me it makes a ton of sense. They have a lot of strong opinions. But what made this example so good to me was that they were having this conversation with me about um doing some code reviews and someone um someone had designed something or they had implemented something a certain way and they said look like they're telling me look it like it works right like how they built this it's a if you were to go run this it works. It's not that there's a a safety risk here. It's not like we're going to go deploy it and everything breaks or whatever. It works.

But they said the the challenge is that like we've been trying to move the code in a particular direction and like this this how it's implemented uh not only doesn't move in that direction, it kind of like is perpetuating uh you know this this pattern that we're that we're trying to move away from. And they're going the you I have this kind of bad feeling because like they did do the work and like maybe I should have caught this sooner. Oh, let me in buddy. Thanks. Um, but they're like, you know, it's at this point where like I'm I'm reading it kind of having this hesitation because I I'd like to encourage them to do the right thing, but I also don't want to be this person, you know, they're they're not describing it the same, you know, exact same way, but I don't want to basically gatekeep this person when they're their functionality is is arguably totally fine.

So, we talked about this, right? And I said like there is there's absolutely value in in communicating these things to this person because like um your intention is to be informative. It is to be helpful, right? Like that is the intention. How how you do this and what you do after can sort of dictate the um the impact that it has. So the reality is like for I think most of the time like we're working in code that the you know the next commit you do isn't the last commit that's ever going to happen for most software I think. Um, so it's kind of like, hey, look, if we're if we're progressing things forward and we're not painting ourselves into a corner and it's not risky, it's not like if it's truly adding value, um, do you stop dead in your tracks and then wait or like he was saying like it's not it's kind of perpetuating the problem that already exists.

and it's already kind of done and like it works, do you go undo whatever like weeks of work just to to say that or do you raise awareness to it and say, "Hey, look, like just letting you know like maybe we should have caught this sooner. Apologies for that." Obviously, we try to improve things over time. It's can't go back in time and say, "Should have done this uh different from the start." It's okay. we can learn. But do you raise the awareness to this person? Do you give them some of the context so they understand and then say, you know, like in especially in this case, I'm not gating your code on this, but I'm letting you know because if if you're hearing what I'm saying and you're like, "Oh, yeah, like I actually do feel that we should go address this now." Um, you know, if if that's the decision you want to make, then then go for it.

But if if not and you understand and we can follow up with the next work that's in this area then great we'll do it then because now now you do have more awareness and now more people on the team have awareness. So his approach was was that right it was let me tell this person let me help give them the knowledge and you said like they're a smart developer they're they're an adult they can make good decisions and I trust the decisions they make. So I will tell them and I thought like for me this is such a cool experience because um I think there's just a lot of awareness right and it wasn't uh it wasn't I don't trust this person it wasn't lack of awareness it was it was quite the opposite it was like again I have strong opinions I have a lot of experience in this area I want to help like all these ingredients and And then having the awareness to go because this person's lived through it, right?

Like they've lived through these types of challenges where it's like I don't want to be the person that just puts up a roadblock and no one gets anything done. I do want this to progress forward, but I want people to have in like to make informed decisions. So I thought it was such a such a good job. Um and of course that conversation could have looked different, right? He could have talked to me and said, "Look, like this this code's actually dangerous. Like if we do this, this is going to be a problem and my bad for not catching it sooner in like a design phase or anything else, but like I I need maybe I need help. I want to talk through like how we basically don't really disappoint this person, but say like you can't do that like that. it could have gone that way if if he had uh this opinion that uh this was a you know a dangerous code change but it wasn't.

So he was kind of you know trying to balance out his strong opinion. I just thought it was such a good example and I wanted to share that because I think a lot of the time I think a lot of the time we can get to that and I think a lot of the time I shouldn't say a lot of the time from my experience when I have talked to people that kind of uh act with the strong opinions strongly held that when I dig into that with them they actually do have a similar perspective to what I just shared where they are kind of like, hey, yeah, look, if this person wanted to give me some, you know, evidence or argument back that like, you know, this is why it's okay and we're going to follow up.

I've heard like I've heard from different people over the years where they're like, "Yeah, I would be okay with that." Like I just it's almost like again a communication gap where their expectations are they're waiting for the person to be like, "Well, no, like I'm, you know, I'm putting my foot down. here's the evidence and like we'll follow up and it's okay and then it just never happens. And like I said a little bit earlier, sometimes that's because of uh lack of experience, lack of confidence, uh sort of perceived power dynamic, that kind of thing. Bunch of I feel like fully legitimate reasons, but that's sort of why it happens. So anyway, that's the video. um strong opinions loosely held and I encourage you all like have your strong opinions, bring your experience, bring your knowledge and you know consider the context, consider that you

want to help other people, you want them to learn, you want them to be better, you want your team to be better but at the end of the day we need to trust each other and we need to progress software moving forward. And that might mean that that might mean that the thing that you really want to do is not necessarily the best thing to do, but you should be open to the conversation. So, thanks for watching. If you got questions, leave them below. Comments, leave them below. And if you want to ask things uh not in public, but you'd like a video response, go to codecommute.com. You can submit stuff anonymously that way. And I would be happy to try my best and make a video for you, obviously, to post on the channel. And um hopefully some of the perspective and experience helps. So I will see you in the next one.

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.

Is it good to have strong opinions as a senior developer?
I think it's really good that people have opinions, especially when you've lived through things and can back them up with data and examples. I think everyone should have opinions, and it's what you do with that opinion that changes the framing. However, if your strong opinion becomes a roadblock, that can slow progress and harm the team.
How should you communicate strong opinions to avoid slowing the team?
I think there's absolutely value in communicating these things to the other person because your intention is to be informative and to help. I believe that how you present it and what you do after can dictate the impact—it should raise awareness with context rather than gatekeeping. If you raise awareness and let them decide how to proceed, you can progress rather than stall.
What factors influence whether strong opinions help or hurt team progress?
I think trust is a big part of whether strong opinions help or hinder. I see how power dynamics and perceived seniority can make junior team members hesitant to push back. I also notice detachment from business context or an obsession with coding patterns can turn strong opinions into blockers.