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
#218 - The 3 Worst Developers I Ever Worked With
There are enough stories out there about how to be a 10x developer, whatever the hell that means.
I want to share with you the 3 worst developers I ever worked with and what made them so awful.
The names have been changed to protect the innocent.
Except for the first one…
Shameless Plugs
🧠 (NEW) Parsity's The Inner Circle Program - a highly customized roadmap to take you from 0 to hired. For career changers who want to pivot into software.
💼 Zubin's LinkedIn (ex-lawyer, former Google, Brian-look-a-like)
👂🏻Easier Said Than Done Podcast
Already a developer? Check out 👉 Not Another Course
Serious about joining Parsity? Schedule a call with me ☎️
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 I think we've all heard enough about 10x developers or how to be the best software engineer, or how to crush the interview. You know what's helpful, I think, knowing what's bad. So I want to tell you about the three worst developers that I've ever worked with, because these can actually be useful things to know. They give us something to avoid. We know probably what we want to aspire to. You want to get hired, you want to crush the interview, and then you get to the job and then you wonder how am I doing? So I want to share with you some of the things you should not be doing, so you can avoid these mistakes at all costs. These developers that I'm going to share with you were some of the worst that I've ever worked with in my career. The names have been changed to protect the innocent, except for the first one. This is a little bit embarrassing, because the first one is me.
Speaker 1:I fell victim to what's known as the Dunning-Kruger effect. It's when someone greatly overestimates their knowledge in a certain subject because they're not aware of how little they actually know about that subject. Perhaps you're falling into that trap. Now, if you're just learning to code, you may think, oh man, I got this, this is gonna be easy, I'm gonna learn all this stuff, I'm gonna take this course and this course. This is all making sense. Maybe you're learning HTML and CSS or something like that, which is typically where people fall into this false sense of security, and maybe that they actually know more than they do. Youtube, by the way, is full of these people. They'll say things like coding is dead confidently and this dude has never worked as a coder. There'll be some guy that works at a startup not in tech, he's a sales guy and he's like hey, I already took your software engineering job. Finally, my favorite one how to get into FANG companies from a college sophomore who just got an internship at Microsoft right, and so I fell into this trap too.
Speaker 1:In my first two years as a professional developer, I would confidently tell our product manager that this feature was not possible. I'm like oh yeah, that thing you asked me to do, it turns out it's just not possible at all to do that. I was completely wrong. She actually schooled me on why I was wrong and basically how the web works at a fundamental level. She was actually a software developer herself and, thank God, she took me aside and said no, I don't think that's correct at all, and let me show you why it's wrong. So I was confidently saying things that I had no clue about, and that's because I was overestimating my own intelligence. It's a bit embarrassing, to be honest with you. It was a really terrible habit. I also was pretty arrogant. I refused to learn, react because I'm like oh, angular js is so much better. And if you're wondering what's angular js, well, that framework doesn't really exist anymore.
Speaker 1:I wrote code that brought down our production system because I didn't understand the basics of big o notation. Basically, how much would the time increase based on the amount of input when the input increases? How much would the time increase based on the amount of input when the input increases? How much does the time to completion increase? I didn't understand this very basic idea.
Speaker 1:I thought coding as a profession was just getting things to work at any cost. Forget performance, forget maintainability. I just want to get stuff out the door. This ignorance led to arrogance and it led to subpar code. So if you're an early career coder, you may be saying, oh my God, that's not me. I'm not arrogant like you, you're a fool. I'll tell you this much. I've seen this affect most of us. You might not be arrogant, but you're likely ignorant. If I'm just being honest, especially if you are self-taught or you're at a boot camp or some sort of non-traditional path to getting in. And when I mean ignorant, I mean ignorant to more like computer science fundamentals. So how do you get these fundamentals? Avoid my fate and just become a better programmer. There's a few ways to do it Read books on software design patterns. Join the Inner Circle. Plug for the program that me and my buddy Zubin worked for. Now this guy actually went to Google, passed the interview and crushed it. So if you want to know how to do that, or go the route I did, which is mostly working for startups and smaller companies and a couple of Fortune 500s in between, then yeah, joining our company could be a really good fit for you.
Speaker 1:Now next, learn system design. This is increasingly important. Ai tools are not great at system design. Alex Zhu has a great book on this subject. Alex XU. I can't recommend the books he has enough. I've bought both of them. I'm a subscriber on his email letter. I'm not paid or sponsored. I just think he's done a great service because I suck at system design until I started reading those books and practicing, of course. Suck at system design until I started reading those books and practicing, of course.
Speaker 1:And then finally just do some research. Think of like why does your favorite library or framework exist? And when I say your favorite library or framework, I'm almost certainly talking about React, because that's probably what you're using. So why does this exist? What problem does it solve? What problems does it create? This will lead you down interesting rabbit holes. It'll expose gaps in your knowledge and it will help you decide where to focus your learning efforts.
Speaker 1:The sneaky thing about this type of developer is that you don't even know you are this type of developer most of the time, and I really pray that I'm not anymore. Hey, I hope you're enjoying this episode, and the reason why a lot of people listen to this show is because they want to become a software engineer. So maybe you went to a bootcamp, or maybe you're just learning to code and maybe you want to make this the year that you actually become a software engineer. If that's you and you have the time and the dedication and you're not looking for some get-rich-quick scheme, you should join Zubit and I for a very customized program where we take you from zero through hired with an intensely personalized, custom roadmap that will help you see through step-by-step, to get interviews, pass interviews and learn the skills that will make you a professional grade coder. If you're serious and want to start working with us one-on-one, then schedule a call by using the show notes below or apply online at parsityio slash inner dash circle.
Speaker 1:Now back to the episode. Okay, next the code bro. We'll call him Brock or Brad Chad. Perhaps this dude was actually pretty good at coding, but that's just expected once you move past junior right. What made Brock a pain to work with is that he was how can I put this? He had an issue with the truth. He had an odd relationship with the truth. You could say so every day.
Speaker 1:As a software developer, you'll typically have these meetings where you'll go around and you'll say what you did yesterday, what you're going to do today and any roadblocks you might have. So we did this every morning. Brock was in charge of a pretty big project and he'd give a status update and every day it was like things are moving great, I just finished XYZ. They were pretty generic, which is a big problem at these kinds of meetings. People just say, yeah, I worked on ticket XYZ and it's going well. Today I plan to keep on working on ticket XYZ and I'm like oh great, thanks for that context.
Speaker 1:Like most teams, we had this arbitrary deadline to launch a feature. One of my least favorite things about the profession of software development arbitrary deadlines that are unmovable and might be really, really stressful to hit. This is one of the biggest stressors in the field of software that really no one talks about. I don't really know why it's super stressful, which makes sense when you think about the outrageous salaries that many of us get. It's because we're under the gun many times to get stuff out the door, hell or high water. Companies love deadlines, maybe even more than they like layoffs.
Speaker 1:So on the day that we were ready to launch, brock hit us with a bit of a curve ball. He says I need at least another day or two to complete this and everybody's kind of like visibly shocked on the call. Like every morning for weeks he'd been telling us he'd been working on this thing. Never said he was stuck, never said he was blocked. The manager made it really clear that this was due and like, okay, great, on track, right, we're on track right now. Oops, just kidding, not on track. And he just sits there like, yeah, well, you know, sorry, and a couple more days keeps delivering us bad news. I'll need a couple more days. And then you get in this vicious cycle where it's like a week later and he finally gets it out. And it was just not good. It didn't really work the way expected. It created a lot of tech debt that we ended up having to clean up.
Speaker 1:Don't be Brock. It was pretty obvious in retrospect that Brock probably was not working completely for this company. It turns out he was probably working for a few companies at the time. He was doing the old over-employment hustle and it didn't work out super well for him. And look, maybe you're not working multiple jobs, maybe you're just afraid to admit when you don't know something.
Speaker 1:We have a lot of people, a lot of people we mentor in the inner circle program and one of the issues that we have to deal with a lot is people being afraid to admit when they need help or don't know something. I know it's embarrassing, I know it can be difficult, especially if you're newer, but you have to get used to raising your hand when you're stuck. This is the fastest way to get over your hump of knowledge that you don't have and quickly get to a solution. Now there's a fine line between just relying on your mentors or the internet or AI to just answer everything for you without having a little bit of struggle yourself. Struggling to find an answer is good. My rule of thumb is that if you're struggling for more than I don't know an hour or so, it's probably time to ask either a human or an AI chatbot or something like that, and if you're on a team, really important to ask the team. Remember, software is a team sport. There is zero reward for just suffering in silence, but there is a very hefty penalty that the entire team will pay if you do that, because when you fail, the team fails and then people have to cover for you or pick up the work you didn't do, or we just look bad. Right. When you have a project due and there's a manager above your manager, they have zero clue what's going on at that level. All they know is the project is late. Boom Brock didn't really last too long on this team. He did this move another time at least I think he did it a third time and he wasn't even fired. He just left on his own to probably go do the same thing somewhere else and try to work multiple jobs at another company. Didn't work out super well for Brock. I hope you're doing well, though, man.
Speaker 1:And finally, this person is the worst person the asshat. I've met this person more than once. Maybe you know this person too. They're super smart. They're a super senior developer. They know how everything works and they actually have really good insight into the business and the code base. Maybe they're on Twitter, which is where these people often tend to hang out.
Speaker 1:One problem with this person they're an asshat. Here's how it may manifest itself. One they will just brutally take down anybody's opinion that is not their own. They like to berate developers, publicly or privately. They might hoard critical knowledge so they can be the hero. They will sow seeds of distrust among the team towards other devs or managers. These people are insufferable, but apparently a lot of you like them. I see them on Twitter and they tend to get a lot of likes. Some of them are even on LinkedIn and they tend to get a lot of likes. Some of them are even on LinkedIn and they tend to get a lot of likes.
Speaker 1:People like asshats. They like their vitriolic hot takes that they like to give out. These are fun to read, they're fun to read on Twitter, but imagine working with one of these people. I really hope you're not one of these people and please don't become one of these people. In reality, these people are bad for the business, even though they might look like they're good, because they look really knowledgeable, but they rot the team from the inside out. And the way they do this is because confident developers who are skilled will just leave. They'll just wait till the market improves or they'll just go to another company. They'll just leave. What are you left with? You're left with subpar developers who cannot move, and they stay and tolerate this person who cannot move and they stay and tolerate this person. This dude's power grows and the team weakens. I say dude because, let's be honest, the software industry is full of dudes and most of the asshats I've met have been dudes. Once this asshat does leave the organization, their critical knowledge goes out the door. The remaining developers scramble and they try to figure out what this person knew. No-transcript probably aren't that good if they've stayed and tolerated this. Sometimes this person doesn't know they are this type.
Speaker 1:I've actually met a few people that are reformed asshats. So if this is, you realize a couple of things. Sharing your knowledge is actually empowering the team and it makes you look stronger, and this sets you up for leadership roles. Two, resist your instinct to shut down less skilled people, whether in public or in private. Find out why we think like we do and then offer an alternative. And three, just fake it.
Speaker 1:Maybe you think we're all stupid. Maybe that's fine. Maybe you think we're just a bunch of dumb keyboard jockeys and boot camp grads that don't know the first thing about computers. That's fine. Just don't tell us and consider why, if you are so smart, why you can't break into leadership positions. Maybe you are an asshat that doesn't know it. Maybe you're really smart. Great individual contributor. You're a bit older and you're starting to see that I can't get into leadership positions at all. Perhaps could it be that maybe you, my friend, are an asshat.
Speaker 1:Like I've said, I've met a few reformed ones and they're often the best types of leaders because they don't rely on natural charm to reach consensus. They have methodical approaches. They've had to learn because they are not just naturally gifted people when it comes to building relationships or being likable, so they've had to learn how to do it. In fact, I had a manager who was really open about this. He told me how he was kind of a jerk back in the days, took some classes, almost got fired and then finally found out how to manage a team. He was one of my favorite managers, really excellent guy. His name is also Brian. I won't give away his last name, but I was really impressed that he was open to share that and basically show others hopefully that hear this story that yes, there is life after being an asshat. In fact, sometimes I wish I was a little bit more of an asshat myself, because I think I'm too nice sometimes.
Speaker 1:And if you're wondering, hey, what about all those developers you met that just sucked at coding? What about them? Maybe you're thinking, well, how do I get better at coding? You didn't say anything about that. Here's the thing I've been really bad at coding. You probably are really bad at coding at some point and you're going to have to be a terrible coder in order to have a wonderful career, you have to be terrible at first, because that's how you learn. In order to jump into different programming languages, work at different companies, take on different projects, you're going to have to get used to the idea that you will suck. Now don't take this to mean that you can just be a terrible coder infinitely and have a great career. That's very unlikely, highly unlikely.
Speaker 1:Any profession that involves coding is a lot more than coding. Right, if you're a junior dev and you can use an AI tool to write mostly working code, expectations in other areas have risen right. Coding is a learnable skill. There's well-documented syntax, there's patterns, there's use cases. What's much less obvious is the professional part of being a coder, which is exactly why we work on these areas in the Inner Circle program, because these are the things you can't just learn from a course, and obviously the art of writing professional code is a big piece of this too. But understanding how do you work within a team of humans, translating ideas from non-technical people into code that actually works, and how do you design maintainable software that others can extend these are the areas which will have the most impact outside of just writing code. Writing code is a given. So there's too many tutorials and talks about how to write better code.
Speaker 1:My hot take for you is don't worry about writing the best code right now. Worry about the reps, getting them in, especially if you're earlier in your career. Later on, you can read books that will give you templates and ways of thinking, design patterns that you can employ. That will make your code better. But if you're in the beginning, don't worry about that. Get the reps in. You have to be able to look at a problem, figure out how to translate it into code and get a working solution. That should be your ultimate goal. And then familiarize yourself with some design patterns and things like that.
Speaker 1:But if you avoid the three things that I just talked about being an asshat, being way overconfident in your own skills, refusing to ask for help, suffering in silence I mean, when we looked at Brock, he actually lied. But the takeaway from that, hopefully, is that, yeah, one don't lie, but two, know when you've reached your technical depth and once you've reached that limit, know that you should ask for help. I really hope that's helpful. Hope you avoid becoming one of these three archetypes, including the one that I was. As always, I hope it's helpful.
Speaker 1:If you have suggestions or an idea for a show, I would love to hear them. Please let me know. You can drop a comment or you can just write me directly at brian at parsityio. 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.
