Develop Yourself
To change careers and land your first job as a Software Engineer, you need more than just great software development skills - you need to develop yourself.
Welcome to the podcast that helps you develop your skills, your habits, your network and more, all in hopes of becoming a thriving Software Engineer.
Develop Yourself
#274 - The Cost of Being Nice: Why Good Developers Don't Get Promoted
Have you ever wondered why some developers keep getting promoted while others stay stuck at the same level despite their technical skills?
The answer might surprise you.
Through practical, actionable steps, I break down exactly how developers at any level can strategically increase their influence and advance their careers.
You'll learn how to gain credibility before speaking up, frame concerns as questions rather than criticisms, and pair problem identification with solution proposals.
For junior developers and career changers, I offer specific guidance on leveraging your unique perspective and starting with low-risk moments of leadership.
The truth is that being universally liked feels safe, but being honest and solution-oriented makes you invaluable. Your career won't skyrocket by becoming infinitely better at your tech stack—it will accelerate when you thoughtfully challenge the status quo and offer solutions to problems others see but are afraid to address.
Shameless Plugs
🧑💻 Join Parsity - Become a full stack AI developer in 6-9 months.
✉️ Got a question you want answered on the pod? Drop it here
Zubin's LinkedIn (ex-lawyer, former Googler, Brian-look-a-like)
Welcome to the Develop Yourself podcast, where we teach you everything you need to land your first job as a software developer by learning to develop yourself, your skills, your network and more. I'm Brian, your host. You know that saying nice guys finish last, the same thing could be said for developers. Nice developers finish middle, basically being the nice guy developer or the nice girl developer, or the nice non-binary developer, the nice circle developer, whatever you are, whoever you are being just nice and trying to ship code, keep your head down, don't cause trouble. This is a decent way to not get fired, but it's a really, really difficult way to get promoted or really even have a stable career. I actually thought that this was a safe career path until I joined a company, that this was a safe career path until I joined a company where I was a senior software engineer. Years before this, I basically was following this plan of just keep my head down, don't say anything, just learn. Who am I to say anything? Right, there's much smarter people here. I'll let them make the big decisions. I'm just here to be in my little code hole and just code, and that may surprise some of you who've listened to this show and see me writing on LinkedIn all the time and basically voicing my opinion about all sorts of stuff, but this didn't come naturally to me at all. So I get hired at a big company, big Fortune 500 company, clorox and I'm on a pretty small team of people at this company working on an e-commerce site, and we're in this meeting with the product manager and she lays out the timeline. She's like we're going to have three months to deliver this site from scratch. It's a team of like four or five developers. There were a bunch of third-party API integrations, a completely new content management system. We were going to also integrate payment systems, authentication it had to be up to all these standards for like accessibility and things like that and it was going to have thousands of users on day one and probably generating around a million dollars of revenue or something in the first month.
Speaker 1:And I'm in this meeting and I'm looking around, right, we're on Zoom. People are just nodding their head and I'm like so is no one going to say it? And I'm like, well, I got to say it. I can't not say it, right? And so I did. I raised my hand. I said, hey, this isn't going to work.
Speaker 1:And her face was like visibly shocked. Right, she looked at me like what do you mean? And I had done some estimations ahead of time. Right, I'd been laying out this estimation in my head and I wrote down a couple back of the envelope calculations for how long this could possibly take. I'm like, well, if we have to do this and this and this and this takes about a week, and this takes about a week, and this takes three or four weeks, and we have four people and we split this up and one guy goes on vacation, this will take six months. That was my rough estimate.
Speaker 1:And when she heard this, she's like what? And I'm like well, we could cut this and this and this and you know, have a much more inferior product, but we'll just have to like see what we can, cut what corners we can. And the rest of the team kind of nodded along and they're like yeah, I think Brian might be right. And I could see that she was frustrated. I could also see that she was like kind of spinning and just taking all this in Cause. She's like geez, we've already set a target with, like, these big CEOs at Clorox. This is a multi-billion dollar company. This is a website. They're like what is a website. They're like what do you mean, right?
Speaker 1:And so I thought, for some reason, that I'd be in trouble for this. And then she said something. By the end of the meeting, she asked me to write all this down and send it to her and the CTO, and I thought, oh great, now they're going to both chew me out and say what do you mean? This is going to take this long, it can't. Why did you say this in a meeting that catapulted my career? It would be that right. In a way, I did not expect at all. I went from senior developer on this team into staff engineer and then finally up to senior engineering manager Through some luck, through this particular incident, through a lot of different things that were happening at the same time, but this incident was the catalyst for everything else and it taught me a really valuable lesson.
Speaker 1:So after I said this in the meeting, you know, I started being in more meetings with the CTO, with the product manager, with other executives, and I started to get something much more important than technical ability. I got visibility right, I helped plan, I was setting the timelines and estimates. I was the person they were going to now to see hey, is this actually possible? Anything we should know about Brian? They're like well, this guy's obviously gonna tell us the truth, even if we don't like what he says. That was huge, huge moment for me and I didn't even realize it right. I thought how can I just let this go by? I can't just sit here and say nothing, right. And I felt pretty confident in my career at that point.
Speaker 1:I fired. You know, it is what it is. I'm always thinking I'm going to get fired. I've been fired in my head at least a hundred times over the years. In reality, I've never been fired. In fact, I've been promoted, had pretty good reviews all the time. I've never really had a big problem in the last five, seven years at any company I've worked at, but I always think I'm on the verge of getting fired. That's another story, for another time. I'm a bit neurotic, super anxious person, if you didn't know. Anyway, that project was still late. The story didn't have some beautiful happy ending, except for I was promoted many times over because of this incident, which led me to get deeper connections with the CTO, with the chief product officer and with other executives outside of this small engineering team.
Speaker 1:Next thing, you know, I'm on flights to Manhattan to speak at executives at Clorox Mind-blowing, and I want you to remember this. Before this, seven or eight years ago, I was in the streets of Oakland and Richmond, california, selling drugs, being under the influence of drugs, hanging with criminals doing awful things. So just imagine that transition from that to first class flight to Manhattan to give a PowerPoint presentation for the first time at like, 37 years old. Surreal to me, still surreal to this day. Even saying it out loud just seems nuts.
Speaker 1:This is not some sort of hack or anything, but I do want to really break down how you can apply this same strategy, no matter if you're a junior developer. A senior developer, maybe you're already an engineering manager and I most importantly want to tell you why playing it safe or being nice feels safe, but it actually just stalls out your growth as a developer. As a junior developer or somebody learning how to code, you might be thinking well, I don't even really know much, and it's true, you probably don't know a lot technically. You might know a lot outside of code, which is a lot of what we do as developers. We work with other humans. Still, I think we're well past the AI hype cycle and we're firmly living in the reality that we are going to be working with humans for quite a while now. The AI hype train has blown past. I hope it's blown past. Are we finally over that now? Are we finally over this ridiculous idea that AI is just going to take over developer jobs or whatever? If you're still thinking that, I think you're thinking six months ago. I think at this point most of us are saying, okay, that was a nice little fantasy. The bubble has kind of popped right.
Speaker 1:So being liked is good, but being liked and being invisible is not a long-term career strategy. Not only will you have a boring career, but you might not have one in the first place, or you might just hit a level where you just kind of top out, where you're just like well, why am I getting passed over for promotions? Why am I kind of stuck in this same position? Why am I just kind of getting that one or 2% raise a year and not really hitting higher targets or getting to where I think I deserve to be? So being liked is good, but being liked at the cost of being honest is just dangerous. Silence keeps you off the radar in the short term, but then promotions go to those people who actually say hey, here's the problem, I wasn't the best developer at this company. I'm not the best developer at the company I'm currently at. I've rarely been the best software developer on any team. I have been promoted successfully at multiple companies by now and I've seen a bit of a pattern here and I'm just gonna go through some very practical steps you can apply. No fluffy stuff, some seriously practical stuff you can do. Let's just get started.
Speaker 1:Step one you have to get shit done right. If you can't ship your own code, you don't really have business talking about other people's workflows or telling other people how to do things or really raising complaints, because then it's just like you're kind of an annoying squeaky wheel. If you can finish what you're doing reliably and document what you're doing and you're consistent, then you have some credibility. This is really important. You have to have a little bit of credibility. I've seen people take the opposite approach and they come on a team and, having no context, they haven't shipped anything. No one knows what kind of developer they are, they haven't proven themselves at all yet and they already have really strong opinions on what you're doing. Really quick way to make a group of people not like you and also a quick way to just look like you. Just look unserious, right? You don't look like a serious person at this point. You look like somebody who just came in. You don't know anything and yet you have super strong opinions on what the team is doing. Rarely ever will work in your favor, so get some shit done and then you can talk the shit you want to talk.
Speaker 1:Step two do your homework. Try to have a bird's eye view of what's going on within the team, right? Too often developers work in silos. If you're remote, this problem can be even worse, right? You get so stuck in your own work you have no clue what the rest of the team is doing. It's pretty simple nowadays Just read the documentation. Look on Jira or Linear or Trello or whatever organization tool you're using. Look in Google Docs. For all I care, it doesn't matter. The reason why you wanna do this is so you can see what's going on in other places, because work is rarely ever delivered in silos.
Speaker 1:You may be doing your work, which will almost certainly depend on somebody else's work being done, if you can look at where their work is and see what blockers are they coming up against what other things might be blocking the release of a project. Then you can ask in a meeting hey, I see that this ticket is blocked, how might this affect this release? Or how might this affect this release or how might this affect the timeline, and you're not meddling by doing this. It's a fine line between sounding like a little company snitch and being the person that's just like hey, I see that this thing might be delayed. I think we should take this into consideration when we're making estimates, or giving estimates to the execs or whatever, about when we can actually get this thing delivered. Then you can offer to help too. Say hey, I'm actually done with some of my work. I see this ticket is lagging a little bit. Do you mind if I added some help? Or would you like an additional set of eyes or hands on keyboard to maybe get this out a little bit faster? Which leads me to step three. Use questions as your secret weapon.
Speaker 1:Developers aren't really known as a personable bunch of people. Let's just be honest and I don't know if I'm becoming like that I feel like the longer that I've been a developer, the less nice that I've gotten. I'm too nice, first of all, but I think I've gotten a little less nice over the years. Right, because we use our code brain, and our code brain is like this is either right or it's wrong. Zeros and ones, black and white. This does not translate very well outside of coding circles. So when you see a project and you're thinking this project is ruined or this code is bad, instead of saying that, say something like this hey, maybe I'm missing something, but if this API is still in progress or hasn't been integrated, how do we plan to test it by tomorrow?
Speaker 1:This approach doesn't assume anything. It shows a little bit of humility. It invites people to give feedback and say, oh, you're right, or oh no, don't worry, I'm actually doing this. And you say, oh great, maybe we should have that reflected within the ticket. Again gives you more opportunity to present yourself as a leader or at least come across like somebody who cares and is not just the little developer playing in the background, and this can lead to the right kind of conversations. That doesn't make people feel defensive If you're saying there's no way we're going to hit this tomorrow because this person didn't do this ticket and we're expecting that to be done and it has to be done for me to do my well, that sounds like you're kind of an asshole, right? Which is a nice segue into step four.
Speaker 1:Don't be a little whiny complainer, right. Pointing out problems won't win you any points, right? Just coming into an organization and saying that sucks and that sucks and expecting somebody to be like damn you're right, promotion on your way, we didn't realize we sucked so much. Thank you for pointing that out to us. So whining can drain trust and patience. Suggesting solutions actually builds trust and patience.
Speaker 1:Even a rough idea. It doesn't have to be a great idea, right, as long as you have something. What I don't like is when people complain and they're like this thing sucks and this thing sucks and we're doing terrible. I'm like well, what do we wanna do about it? Just give us anything right. Say, could we cut this feature? Could we rotate our on-call shifts, because we're kind of getting burned out? Could we just delay on critical bugs right now? These are solutions, some of them good, some of them maybe not so good. These ideas don't have to be perfect or even really good. It's just something to get the ball rolling. It just proves that you're thinking beyond yourself.
Speaker 1:Step five is start small and then build from there. Your first act of courage doesn't need to be some letter to the CEO or the CTO or anything like that. Just practice really low risk moments On a pull request. Ask if you should add a test for an edge case or something like that. I remember when a junior developer joined our team at Clorox and she kind of ripped one of my pull requests apart and I really appreciated that she wasn't doing it just to be like rude or nitpicky. She was genuinely asking a lot of really good questions. I found that super impressive and I think that more developers should take that approach instead of just saying looks good to me, I've done this too. Trust me, I've done the same thing that you're probably doing. Looks good to me, and I have a whole show on how that blew up in my face spectacularly. Basically, just give a damn right. When you're in a standup meeting, say, hey, I think this thing might slip. Should we flag this right now? Should we update our estimates or our timelines based on this? I'm seeing that this is not done. Is this gonna block us from releasing whatever feature or thing we're trying to get out by this date?
Speaker 1:Just kind of give a damn about things that are going on outside of your particular code base and then, in Slack or in Teams or whatever communication tool you use, just step in. If there's no clear owner for something, either ask if there is one or maybe suggest that you become the clear owner. Like, hey, I noticed we don't have documentation for this set of repositories or we don't have, like any coding standards for this particular repository. Who's the owner of that? And if there is none, I'm happy to do that as well. Let me know what the next steps could be.
Speaker 1:Just try to step up when the because in the absence of leadership, it's really easy to step in. The expectations are low, the barrier to entry is low and people's expectations are just low. Right. So if you come into a place and there's no ownership of anything, or there's no ownership of documentation or code, standards or tests, and you say I'll own that, then if you have one test, people are amazed because that's better than no test. If you have 100 tests, people are mind-blown. They're like, oh my God, this person just did a massive change at our company. So, yeah, step in.
Speaker 1:When you see no ownership, this is a perfect opportunity for you to go and take it. Just grab it, just take it. Just take it At the very least. You're going to build some trust in the team and you're going to accelerate your own learning, even if you mess up, because every opportunity can be a learning opportunity. It's rare that you're going to beat a company for a long time anyway. So if you're playing the game the way I play it, which is like two years, maybe three, four years, five years, maybe max that I want to be somewhere, I'm probably going to leave and I want to have some good stories about things that I did, because these stories are going to come up in my interviews and they're going to help me get to the next position. So you always want to have a good story. Like the time I took over ownership of Clorox's test suite went from zero to 40% coverage right, sounds a lot more impressive than yeah, I built some React components with a team of other React developers. That's not a very interesting story Saying we went from zero testing to 40% test coverage, which is a real thing I did there Sounds kind of cool, right, at least I think.
Speaker 1:Step six this is specifically for you career changers or people that are maybe fresh out of college. I wanna tell you this. I mentored a dude who was in his 40s at the time when he switched careers into tech. He became the go-to person at the company where he was recently hired and they were going to him with the tough questions and he was giving them good feedback. He came from a very different professional background and he wasn't afraid to ask uncomfortable questions or give suggestions, and career changes often have this different perspective about what good leadership is and what good processes are, because they've seen them in other industries.
Speaker 1:Don't assume that your manager, who probably spent his entire life in tech, knows what it looks like I don't know in a medical profession, or maybe what it looks like on a construction crew or something like that or whatever. Even in retail. It's like there are processes which are tried and true, which can definitely be applied to software engineering teams, because we're just people at the end of the day and knowing what's good and knowing what looks bad, and seeing things from your perspective as a person that has some time in the workforce or maybe you just got out of school and you're thinking this doesn't seem right, maybe it's not Don't just assume, because people are doing it one way, that that's the correct way to do it Always, question the status quo, but do it in a genuine way and also do it in a way that doesn't come across as super critical, saying, hey, I noticed we're doing X, y and Z. Is there a reason why we do this? To me that seems a little confusing, and either they'll illuminate you, enlighten you and say, oh well, the reason we do this crazy thing here and the reason why we have zero tests is because we're moving really fast and we don't have product market fit yet, so we decided not to write tests for now, but don't worry, it's on the roadmap. If they say, well, we don't have tests because it takes too long to write tests, that could be a red flag and you say, well, you know, maybe I can help out with that.
Speaker 1:Again, opportunity for you to step into some leadership and the final step reflect and iterate. I wish I could give you some like step-by-step process. I mean, I kind of did give you a step-by-step process, but here's the thing your mileage will vary. So when you do these things, you're going to trip, you're going to stumble, you're going to fall a little bit. Ask yourself after these little moments of courageousness did it help? Did you frame it well. Was your timing right? Test these moments like code reviews right. Look at them pragmatically and objectively if you can.
Speaker 1:What was the result of you doing this thing? Did you elevate in status? Were you invited to a different meeting with people outside of the tech team? Were you given less status? Were you invited to a different meeting with people outside of the tech team? Were you given less status? Were you punished for this kind of thing? That's also the reality of doing these things. You could absolutely be punished.
Speaker 1:There's a saying that the tallest blade of grass is the first to get cut. It's also the one that's growing the fastest. I wish I made that up because it sounds super deep, but if you think about it, that's just the cost of trying to move fast. These are the gambles that you take, and if you want to win big, you're going to have to play big. And if you want to just have like a kind of middling career, that's fine too. I don't think there's any reason to just go out there and do these things for the sake of doing them. I'm just saying if you want that kind of career where you can go from senior into manager or go to staff or some technical leadership position, or at least be recognized, then I think you're gonna have to step out of your comfort zone.
Speaker 1:Necessarily, for most of us, that means not doing what the majority of developers are doing, which is sitting there, heads down, coding and not coming up with solutions or figuring out how to have difficult conversations and then presenting them in a way that is palatable to your teammates and people outside of tech. So, in closing, being universally liked feels safe, right. Who doesn't want to be liked? But being liked at the cost of honesty is how you just end up invisible. The bigger the team, more this is true, right. The larger the team and the less you want to say, or the less you want to go out there on a limb, or the less you want to go a little bit over the top in these instances. The less you want to a little bit over the top in these instances, the less you wanna take on leadership positions or say things in meetings. Just become a little bit smaller, a little bit more replaceable, a little bit more forgettable. So your career is not gonna skyrocket, in my opinion, if you just keep getting infinitely better at React or Python or whatever your chosen programming language is, or your tech stack is, it's gonna skyrocket the day you invite a little bit of awkwardness in and you say things like this isn't going to work.
Speaker 1:Here's how we fix it. Even as a junior developer or person learning how to code, I think that you can choose small, well-timed acts of courage. If you speak up with care, if you pair problems with solutions and say what others are thinking, but afraid to say, you're going to find yourself more trusted, invited and accelerating past your peers who are still just kind of nodding along. Anyway, I hope that's helpful. This is something that I've been thinking about a lot.
Speaker 1:I've been really wondering huh, what were these instances that kind of took me from this position that I was in into, like this leadership position at a Fortune 500, which is still pretty mind-blowing to me, and I'm seeing this play out now at the current company I'm in. I'll see how this goes. I'm living this right now as a matter of fact, and I have no clue where this ends, but I do know that this is a lot more fun and a lot more fulfilling than just sitting back and kind of letting things happen to me. Anyway, always hope you find that helpful. See you around. That'll do it for today's episode of the Develop Yourself podcast. If you're serious about switching careers and becoming a software developer and building complex software and want to work directly with me and my team, go to parsityio, and if you want more information, feel free to schedule a chat by just clicking the link in the show notes. See you next week.
