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
#247 - I Was the Worst Developer on the Team... Again
Send a text and I may answer it on next episode (I cannot reply from this service 😢)
Have you ever felt like the weakest link on your development team? You're not alone.
The moment you land your first developer job, you're likely to face the crushing weight of comparison. Your teammates seem to know everything while your mind fills with doubts about your abilities. Seven years ago, this pressure nearly drove me out of the industry despite earning more money than ever before.
The stress was paralyzing - I faced panic attacks each morning and received direct feedback about my inadequate skills.
I developed a powerful three-step system that transformed my approach to professional growth that I want to share with you.
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. So I have a bit of a confession to make. I was the worst developer on the team for the second time in my career. Now, in my defense, this time was a lot different than the first time which I'll get into. Hence, this time was a lot different than the first time which I'll get into. This time it was just basically me and the head of engineering, who happened to also be a principal level engineer at a really big tech organization, and then there's me, who is not. It was still really humbling. And let me be clear, I'm telling you this not because I want to glorify being the underdog or I don't know, maybe I do, but I'm not saying it's okay to be the weakest link and just coast. You shouldn't want to stay the worst for long. But I am telling you this story because I think you deserve to know a practical way to tackle this when it happens to you, because it will. In fact, when you get your first job, it's likely you will be in this exact same position At Parsity. We have people that get into their first job. We just had two students get hired. I know they're feeling the pain right now. Their head is beginning to play tricks on them. It's starting to tell them things like you're not good enough. You're looking at your teammates. Oh my God, they're younger or they're older, they're more experienced, they know things. They said something I don't realize. How am I going to keep up? What do you do?
Speaker 1:Seven years ago, when I was in this position, it was bad. I was making more money than I'd ever made in my entire life and I thought I might have a panic attack every single morning. The pressure was crushing, to say the least, so I had to make a plan before it ate me up. Like I had lived a pretty wild life before this. I had guns pulled on me, I had been in high speed chases, but this pressure and the stress that I felt here was honestly worse. It just was because it was never stopping and it was in my head. I was in my head and it wasn't all in my head Like I was telling myself you're not that good. But then it was the reality and being confronted in a group setting and being told hey, you're not that good. So I had to make a plan and this is the self audit that I did.
Speaker 1:That changed basically everything and it's now somewhat of a systematized thing that we do for students that you can just take and use on your own, because I think that everybody needs a way to get over this when they first either get hired, find themselves on a new team or just really feeling like their skills aren't where they need to be. Some of this for sure can be in your head, some of it cannot be, and you need to have a plan and a system to execute so you don't just get in your own head, freak out, have a panic attack, leave software, go on the streets and beg for change and code HTML for pennies on the side of the road. I don't want that to happen to you. So what I did, what I suggest you do, is do a brutally honest audit of your skills. Here's a three-step process that I used then and now, and what we also encourage students partially to use, that you can just steal and use on your own right. So the first step is just understanding the gap right.
Speaker 1:Compare your skills to the skills of someone you admire or you work with Not a YouTuber, well, maybe, except for me, not a random person on Twitter that claims to know 12 coding languages. The reason you can't compare yourself to these people is because they don't really exist. I've met some of these people. I've looked into some of their work histories and they are not impressive, to say the least, and this is coming from somebody with what I consider a not very impressive work history. I am kind of blown away by the number of experts out there that have really never worked anywhere, that have a lot of opinions on what you should do. So don't compare yourself to these people. You need to find real people.
Speaker 1:So if you're already working, this should be easy. You look at your team, you study their code, you look at their pull requests, you can look at their Git history. You can see what they've done, what they're doing, and you can begin to audit your skills and say, huh, what do they know that? I don't know. If you're still learning, this is a bit harder. You're going to need to find a real developer. You can talk to, ask them what their day-to-day is like, what do they actually do and what tools are they actually using, then map out like a Venn diagram, like you might do in school. What do you know? What do they know? What's in between? And this missing section is the gold mine. This is what will determine your next step, which is part two build a plan of attack. Now that you know your gap, you need to turn it into a focused plan, and it needs to be specific. Most people's goals just suck. They write.
Speaker 1:I want to get better at JavaScript. I want to learn React. I want to get hired. Yes, we all can want these things. Let me give you some much better ones, right? I want to understand how to write unit tests using Jest. I will do this by adding a unit test to a project that I recently made. I want to get better at reading unfamiliar code bases. I'm going to clone a popular open source repo and I'm going to get it running on my machine. I want to learn how to debug performance issues in the browser. I'm going to audit our company's website or I'm going to get it running on my machine. I want to learn how to debug performance issues in the browser. I'm going to audit our company's website or I'm going to audit some public website and come up with a plan on how they could make it more performant and then figure out, like, if that makes sense, by maybe asking ChatGPT, if my diagnosis is in fact somewhat useful.
Speaker 1:These are things that give you a clear plan of what to do and how you're going to do it. You need to find resources for each one of these goals a specific tutorial, a course, a YouTube documents, a real world example, just something that you can use to actually ladder up to this goal. So, okay, I'm going to read this book or I'm going to watch this tutorial and then from that I'm going to do this thing. Next, you need to put dates on these things. This is step three. You have to have dates. You have to have a timeline, estimates, or else it just becomes this fluffy, kind of like cloudy goal that you're like oh yeah, I'm going to get better at JavaScript or React or whatever, and I'm going to just do this tutorial. When? When are you gonna do it by? How are you gonna finish it? How many hours will it take?
Speaker 1:Don't think in terms of days. Think in terms of hours. I like to think in terms of half days myself. That makes it a little easier for me to have buffers and if I overestimate or underestimate, it's like not way overboard. People tend to estimate things like weeks. I tend to estimate things like weeks. I'm like that's way too nebulous, it's too much room for error there. Half days is the largest amount of time that I would ever estimate something by. So I'm thinking, hmm, this tutorial is like 100 hours.
Speaker 1:Am I really going to watch the whole thing? Probably not. I'm probably going to go off on my own because I really just want to learn this one thing. So maybe I'll dedicate, you know, three hours of coding time per every one hour that I'm watching. I'm going to watch an average of 10 hours, so that should be 30 hours. I have about two hours a day, so this might take me two and a half weeks, maybe three weeks, to actually finish this if this is really how I plan to learn.
Speaker 1:This is also one of the reasons why I feel like at a certain point, you want to really get away from videos. They are a big time suck. I much prefer to look at documentation, look at some sample code and immediately try to use that sample code in a repo, my own code base, or spin up a quick project so I can just get my hands dirty because I don't want to watch somebody typing for hours on end. Like half an hour hour max is what I'll watch, but I'm not watching somebody code for like 10 hours. That is just not going to be me. I know for a lot of people that is.
Speaker 1:So if you put it on 2x speed or maybe you're doing something to watch it, you have to figure out how long will this actually take. If it takes three weeks, that's how long it's going to take. But now you have an idea and a plan, how long that plan will take to execute. So you can say, okay, by this date I will have done these few things that now have given me these skills. In the middle of that, venn diagram is now filled in. Now I've proven to myself that I have these skills that I was feeling unsure about, and now I actually have acquired them. And now I can actually go forward and, you know, go to the next place and restart the whole process over again.
Speaker 1:Timelines also give you some urgency. They let you track your progress instead of just feeling lost right, and they stop you from doing stuff that you shouldn't be doing. You just stick to the plan Now instead of just researching or watching YouTube tutorials on how to make a better portfolio project or updating the shade of green in your resume. Now you're doing the stuff that's actually going to level you up. So you don't get out of being the worst by just doing daily affirmations in the mirror or just waiting it out.
Speaker 1:I think that's silly advice and I think that's actually really detrimental to most developers. It's not going to help you out, and if you do suffer from imposter syndrome or this feeling like I'm just not that good, I think that's actually a good thing in many ways. Now, I know it can be neurotic like I'm particularly neurotic but I also think it means that you're self-aware. You understand that there's a lot to learn In software. Whether you've been working for 10 years or zero years, you realize that there's a lot in front of you that you don't know. In fact, I feel like every year that I'm in this profession, I realize fully how much I have left to learn and that I'll never even know more than a few percentages of what's out there. It's kind of humbling, it's kind of scary, but it also makes this profession, I think, really exciting, because you can go in all sorts of directions. There's a ton of things to learn, but you also have to use your time wisely, because we only have so much time. You can't learn everything. If you're trying to learn Kubernetes and Python and Docker and AWS and containerization and GCP and cloud and AI, you're not going to learn any of those things.
Speaker 1:Zubin, my partner at Parsity, has a really good catchphrase. He has a lot of bumper sticker-like phrases that are always in my head. If you try to chase two rabbits, you'll catch none. Love. That phrase Hits home because I've totally done this, whether it's in business or life or coding stuff or whatever. So the next time you're feeling overwhelmed or like you're behind or feeling like maybe you're the worst person on the team or in your cohort or in your class or boot camp or university or whatever, don't just wish it away.
Speaker 1:Audit, plan, execute, get back to the work, make a plan of action, do that plan of action. I know this is easier said than done. Most people aren't gonna do this To me. This is how I saved my sanity likely my heart and just made me a better developer overall. So I truly hope that's helpful. And I may not know you, but I can tell you this If you're the kind of person listening to a show like this, trying to better yourself, you're likely in the top. I don't know 10% of people out there learning to code, because most people aren't. They're just trying to take a fast path, a shortcut to get to where they want. They forget about the end game.
Speaker 1:Have a long-term vision for your career, because this stuff does come up, and it's, in fact, probably more important to have a plan for this than it is to just know like the latest JavaScript features. That stuff is easy to figure out. This kind of stuff, like keeping your mind in a state where you can actually continue to work, learn and progress in your career, which is gonna span decades at the least this is really important. So, again, I always hope this is helpful. So, to sum up, don't freak out. Make a plan. Do your Venn diagram, execute that freaking plan. Don't make goals that suck and you're gonna be a better developer. I'll 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 wanna work directly with me and my team.
