.png)
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
#257 - Career Landmines: Three Developer Traps to Avoid
3 traps to avoid in your career, that I nearly fell for:
1. The Framework Developer Trap
2. The Developer in a Hoodie Trap (might be the most surprising revelation for many aspiring programmers)
3. The Hype-Driven Development Trap
Got a question you want answered on the pod? Drop it here: https://form.typeform.com/to/Q499M9kl
Shameless Plugs
🧑💻 Join Parsity - For career changers who want to pivot into software.
✉️ 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. I wanna share with you three career pitfalls which nearly derailed my career as a developer and, more importantly, how you can avoid these same pitfalls. When I got hired nearly 11 years ago, I knew less than most of you know, or that many of you know, about coding. In fact, I guarantee I know less than 100% of people that have gone to Parsity. I made a ton of embarrassing mistakes way too many to count and I thought I'd be fired on more than one occasion and, honestly, I probably deserve to be. I'm not saying this to glorify being bad at what you do or saying, hey, you can just be terrible and have a long career. No, Through a lot of trial, error, grit and the patience of some really talented developers that I've met over the years, I got better incrementally. So through a lot, a lot of hard work. Honestly, I didn't come into this game prepared at all for this kind of career and over the years I've had to pay a lot of money and do a lot of studying outside of work just to keep up, and I'm finally at a place where I feel comfortable giving advice back to people that may be in the same situation as me. Unfortunately, though, I see a lot of you out there especially early career developers and people learning to code making a lot of the same mistakes I did. You don't need to spend tens of thousand dollars or take 11 years to learn the stuff that I'm going to share with you here. First off, fake it till you make it is not an actual career strategy. Coding as a profession is a lot more than writing code. In fact, my buddy and my partner, zubin, who I work with at Parsity he's the one that kind of told me this. I think he said this in one podcast I did with him. He said writing code is the obvious part, and I could not agree. More Tech changes fast. Your current tech stack will not prepare you for the future. Titles matter way more than people admit. You're gonna be ultimately paid for good judgment way more than whatever language you know, and public speaking is gonna go from a nice to have to required sooner than you think. I'm a firm believer that anyone can learn these skills and ultimately avoid the pitfalls that I'm gonna lay out for you, because, before learning how to code, I was addicted to drugs, alcohol, I stuttered, I was bald I'm still bald, by the way, but I'm sober and I'm mostly stutter-free for the last 11 years. So the tips that I'm gonna share with you won't keep you from losing your hair, but they may very well keep you from losing your career. You won't keep you from losing your hair, but they may very well keep you from losing your career. Let's dive in.
Speaker 1:The first trap is a very, very common one. I nearly fell into this one myself the framework developer trap. Have you heard this phrase? When your only tool is a hammer, everything looks like a nail. A framework developer is basically a programmer who's only productive within their given framework, for example, like a React developer. One time I was doing a mock interview with this person and it was using vanilla JavaScript and they tried to use something that's only available in React. And when I said, hey, you're trying to do something as if this was React, but this is actually just vanilla JavaScript, and they said, oh, basically, what's the difference? And that turned into a lesson on hey, you should probably learn JavaScript before going into React.
Speaker 1:So this is the pitfall of this kind of career strategy where basically, you can work within this one particular tool really really well, but as soon as you take away the tool, the person ceases to be productive. It's really not a good thing and this can really hurt you. Basically, it's like career jeopardy. You're just playing here. It's like a russian roulette with your career boot camps honestly churn out a lot of these types, and they really did during the pandemic hiring spree, because at one point, or even maybe now, you could basically just know, react and get like a multiple six-figure job in many places. It was a pretty wild time where the bar was super low and knowing something like React was enough to just get your foot in the door and just like go crazy. So that time is over. It was during a very unique four-year period or so when that was a thing, and now we're out of that time. Right, but I get it.
Speaker 1:Companies basically hire for React developers. They don't hire for the layer under the framework, for the layer under the framework. So a lot of people go into these job interviews or go about their career thinking well, I just need to know the framework and they're not wrong. But the danger in becoming over-reliant on an abstraction like React or Next or Vue or Angular or whatever, is that once your role changes, once the framework changes or once you have to debug something that requires some deeper knowledge. You just can't and this is one of the reasons why we're so big on fundamentals at Parsity. Like as much as I want to just go deeper into, like frameworks and all the cool new things out there, I'm lucky I have a partner like Zubin who says wait a minute, what are we teaching people? Are we teaching them how to have a solid career as a software developer or how to just like get that first job? We have to think deeper than that, because that's not a career strategy. That might be a strategy to get you a job, but it's not enough to keep you in a job and soon it won't be enough to even get a job. You're gonna have to know your fundamentals, especially with the rise of AI, which I'm gonna talk about a little bit more at the end, why this is so important nowadays.
Speaker 1:We've had people at Parsity, by the way, go on to become full-stack developers backend developers, blockchain developers, cloud developers, mobile and data. We don't teach blockchain, cloud, mobile or data. We teach software engineering fundamentals and principles, which is the reason why why people can go do these things. We've had people obviously go mostly into full stack, but people have gone into all these different realms. I started off myself as a full stack developer. I've gone into work with data, I've gone into work in full stack stuff. I've gone to work on backend things. I've gone into work on mostly front end things.
Speaker 1:There's a lot of ways you can manage your career if you have the correct fundamentals. This is just the thing. You don't need to worry so much about the language. I'm not saying you can learn any language, but honestly you probably could. The reason why we like to start with JavaScript is because it's easy and accessible to learn. It's a great introduction to programming in general, so that way you can learn this language. You can easily run it on your computer in your browser and you can just get introduced to coding and programming without all the overhead and learning about types and all these other things that are just difficult to approach. That's why we choose JavaScript. Could we choose something else? Absolutely. I learned JavaScript and then I wrote C Sharp. I learned JavaScript and then I wrote Ruby or Python or Scala or whatever.
Speaker 1:Anyway, the way that you avoid this dead-end career path is pretty simple, but it's not easy. You have to really understand your primary programming language and how it works beyond a basic level of command. And if you don't have that basic level of command, a plug. You know I got to do a plug for Dev 30. Dev 30 is the best program for you if you're a JavaScript developer or you want to learn JavaScript and you do not Go to dev30.xyz. It's 30 days of not only working on JavaScript but setting you up with the foundation for personal development, teaching you how to build a schedule, stick to it, post on LinkedIn and learn beyond the basics of JavaScript. So do that. If you're like at the very, very beginning. I guarantee you it's worth the cost of 49 bucks. It's like the best deal you're ever going to get.
Speaker 1:Number two read a book. Books are still in style. I know everybody wants to jump to AI, despite the hallucinations or the fact that it just will tell you whatever and you can't always really verify it. Read a book or two on people that have written books about the language that you choose to study, whether it's Python or JavaScript or C Sharp. Read a book or two on these things and learn about the quirks and how it works just a little bit under the hood. And if you're a JavaScript developer, it's really simple. Buy the you Don't Know JS series by Kyle Simpson Excellent set of books, I think it's pretty cheap and some of them are even free on GitHub, which is nuts.
Speaker 1:Number three remember this frameworks are just abstractions over the language. Look up the patterns that Angular, vue, react. Next, what are they using and why? It's not magic, it just seems that way. And if you don't understand the magic, peel back the curtain a little bit by looking at the source code. Or just looking up what are the patterns used in X language or X framework? Oh, these actually are patterns that are used across all software. This isn't some magical Nextjs or React thing. This is like functional programming or this is pub and sub pattern. And lastly, just look up design patterns. Maybe read a short book on the topic.
Speaker 1:Back to books. Call us old school, but at Parsity we actually give people books to read because we want them to know more than just how to code React or JavaScript or Python or Java or whatever. We want you to understand some deeper first principles because that's going to help you in your career, not just getting the first job. This next trap is the developer in a hoodie trap. I call it the developer in a hoodie trap because when most people imagine a software developer, they imagine some dude usually sitting with their hoodie on coding in a dark room or something like that, eating pizza and slamming Mountain Dew or something like that. In fact, when I speak to people on the phone that are interested in joining Parsity, we ask them often hey, what makes you interested in learning to code? And one person straight up told me this. In fact, a few people have told me this. I don't like working with people and I'm like huh, okay, I hate to break the news to you, but it's all about people.
Speaker 1:I tried my best to basically hide in my coding hole for the first three years of my developer career, one because I was a lot more shy than I am back then. I was much less confident and I was just worse at what I do. Obviously, I was coming into this game completely unprepared and it was like a total culture shock. It was a complete change from everything I'd ever done, and so I basically just tried to do my job and blend in and it looked a little like this I would never speak in meetings, I had no opinion on the product or what we were doing. I only talked to the other developers and I basically avoided everybody else outside of our department and I didn't get a promotion. I did this for about three full years and then finally I got called out while working at a really small startup, by the CTO.
Speaker 1:We were on our lunch break. I'll never forget this. We were walking around Salesforce Tower. We actually saw Mark Benioff eating a hot dog and I was like whoa, isn't that Mark Benioff? He's like yeah, it is. Anyway, san Francisco is a magical place, anyway.
Speaker 1:So he says hey, brian, you know we really need you to speak up during our planning sessions. And I'm like oh, okay. And he told me we're trying to build this app with you, not just tell you what to do, the reason why we hired you. We're a team of like five people. It's hard to just like blend in and not have an opinion on anything Like. We genuinely want to know what we should be building and we want all different ideas so we can come up with the best thing. And at the time I was kind of like man. What audacity, right? Like me, you want me to speak up. You're the CTO. Why is it my job to speak up? I didn't say this. I was just thinking this in my head. I was being naive, I was being silly, I was being arrogant, I was being whatever you want to call it. Now I'm super grateful that he called me out that day.
Speaker 1:Since then, my career took a really dramatic acceleration. When I started having an opinion, I was no longer the invisible guy in the room. I was someone who was helping avoid problems early with good questions. I was helping shape the direction of the team. I was volunteering to give opinions on things and raising my hand to share opinions never got easy and, if I'm being honest, I still don't really feel comfortable doing it. But I had to have a process and maybe this will help you. My heart still races, my mouth still gets dry. I still do it anyway and I know how to do it now from years of practice. But here's how I first got over that initial fear.
Speaker 1:Before any meeting, I would look at the meeting notes and if there weren't any meeting notes, I would often ask people hey, what's the nature of this meeting? Is there anything I can read beforehand, and that also just helps set better expectations for meetings. It's kind of lame when you go into a meeting and there's like nothing that you're going to talk about. It's like, just come to this meeting, well, no, what are we going to talk about? And so what I would do is I would write my questions down early on a piece of paper, before the meeting even started, so that way I could just read it from that piece of paper. That way it wouldn't be so intimidating when there was that long silence or something like that. I would just be like, oh, let me just read off this piece of paper. And that worked pretty well for me. And then I forced myself to do some things that were uncomfortable. So I would force myself to volunteer for something. It's like, hey, in one or two months we need somebody to volunteer for this thing, or put your name on this list to volunteer, and I'm like, well, that's far enough away that I can do it and I'll just do it. Screw it, put my name on there, give me a month or two to lead up to this presentation, and then I would be forced essentially to do a presentation, and I would do one per quarter.
Speaker 1:Lastly, I was recording myself going over complex projects or features that I had done. So I worked on remote teams and in person, and I saw that recording myself was a really good way to scale my impact. For example, if I built something or wanted to talk through a feature, something that was fairly complex or really technical, I'm like, well, how can I make the people in the marketing department understand what I built and why would they care? When I started thinking like that, like why would they care? What do they care about? Well, they care about how many people are going to come to the website and the kind of experience they're going to have, and the thing I built is going to help them track that number. So I'm not going to talk about how I built it. I'm just going to tell them well, what's in it for you when you're doing that? I really suggest you take the same approach. What's in it for them when you're talking to the CEO, what do you think they care about? When you're talking to the CTO, what do you think he or she cares about? When you're talking to your buddy on the developer team, what do you think they care about? Always know your audience and present the material in a way where you're telling them what's in it for you. Oh and very lastly this one is really, really important. This kind of goes hand in hand with speaking up, because the more knowledge you have, I think, the more you're going to care and the more you're going to feel comfortable giving opinions on things that you know something about.
Speaker 1:Learn how your company makes money, because it turns out companies like making money and if you know how they make money and you kind of gamify that and say, huh, so they get money. When people go on a website and they buy this particular product and all the things we do are in service of them getting to this product, how can I make that better for the person? What are some tried and true ways to get people to buy stuff that I can support, through my code or maybe without code? Maybe there's something on the side I see that we can improve that's going to help this business make more money. Or maybe there's a way I can take down costs. Maybe we're using a really expensive API or maybe our AWS bill is really high. Maybe if I get that down, that'll save a good amount of money. People that save or make money, are really sticky in an organization. They don't want to let those kind of people go. So if you learn how to do that, I think you're going to be in a really, really good spot. And also it just makes the job more fun, because now you're like huh well, how could we make more money? And if you can do something that directly correlates with money, I mean, that's a pretty cool feeling right there and that'll often be tied to raises, promotions, all sorts of things. So their money can be often tied to how much money you will make if it's a decent company.
Speaker 1:Okay, and the last trap this one is particularly relevant for you new coders out there Hype-driven development oh my God, I see this way more often than I should. It's basically trying to pattern your career after trends, right? So, for example, I met this dude a few years ago. I was on a BART train in the San Francisco Bay Area. Basically, I was taking a train from work back home and I see this dude that I had met years earlier while working at a coding boot camp and I'm like oh dude, how's things going? And he told me well, yeah, you know, I started in web dev and then I went to cybersecurity and then I went to cybersecurity and then I tried to do like blockchain or something like that. And then now I'm trying to get into AI and machine learning and I'm just sitting there like, oh damn, it's been like five years and you're still learning. But you know, you can't say that to somebody, right? You can't say what the hell, what are you still doing? You're still learning. Just stick to one thing, you dummy. And so I did, and I said, oh, that's cool, you know, because I'm like, okay, see ya, I feel bad, though, because in reality, I see a lot of developers making this mistake. They're like, oh, I'm gonna jump on Java, c, sharp, because I think that's gonna be the hot thing in my target market area. Or, oh, now everybody's using Python, now I'm gonna use Python. This is how Swiss Army Knife developers are made. They're basically people that just go chasing technology after technology and they can do a little bit of everything poorly. Instead, try this approach Identify megatrends versus microtrends.
Speaker 1:Megatrends might include large language models, nextjs, rag, retrieval, augmented generation. These are some trends. What I consider mega trends, some micro trends might be model context, protocol, basically this mcp server craze right now, where basically you're building these servers which allow your site or your data to be easily inspected by a language model. Anyway, it's an emerging trend. Edge computing could be an emerging trend or a trend that's not massive yet, but a lot of people are starting to look at these trends could become mega trends. Ai agents could be considered a mega trend. Right now, I'd still consider them a micro trend because I've read more about them than I've seen them actually be used. I think there's a lot more hype than reality, but you'll have to be reading about these things.
Speaker 1:Read Medium, go on LinkedIn, go on Reddit You're gonna find all sorts of people. Go on Twitter You're going to find people that have opinions on these technologies, and you're going to read about a ton of things out there. What your job to do is to be discerning and try to filter through the noise and see huh, how many people are talking about this? How many professionals are using this? Are the people that are talking about this relevant, trustworthy sources, or are these people that are, like you know, just trying to sell me some junk, right? And then you make a decision. Gamble a little bit with the microtrends. If you're lucky, some of them will become megatrends and you'll be the first person in line to take advantage.
Speaker 1:And the way that you tackle this and you approach this is you use side projects to gain some experience with these technologies. I've done that throughout my career. It's the way I was able to switch from AngularJS to React. I didn't get a job where I used React. I built a project where I decided to use React, even though I hated it at the time. I'm like I'm gonna make a project using React because I see it's the future, and thank God I did, or else I'd probably be writing AngularJS somewhere. Your career could be decided by your company if you let it. So if you're using an old, outdated tech stack at your company, you have a couple choices Leave and go to somewhere where you can learn more, or what is easier to do is just build a project using those technologies.
Speaker 1:A final side note for us because now we're in 2025, it is harder than ever to just stick to the basics, because AI marketing is so good Junior engineers, by the way. I understand why this stuff looks magical, because it basically can do everything you can do. But remember this if you're really early in your career or you're just learning how to code, you're solving the simplest problems that are known, right? Every single problem you're solving has been solved a hundred times over. That is why AI tools make it so easy to do the work that you could do. The more senior you get which, remember, is the largest amount of time you'll spend in your career the shortest amount of time in your career is as a junior, the first one to five years. Let's say, beyond that, if you're gonna work for more than five years, which is in the industry, you're gonna be working for more than five years, right?
Speaker 1:The problems get increasingly more complex. The people, the systems, the scope of what you're building gets larger and larger and larger. It's not sufficient to say, hey AI, hey Claude, hey, whatever tool, just build it for me. And if you're of the opinion that these tools are going to get infinitely better, I would say, well, look at how space exploration programs have gone. Look at other tools and technology over the years, over the decades, have they got exponentially better? Why would AI do that? And I don't think anybody has a real reason to believe that is true.
Speaker 1:Now, I'm not an expert on the matter at all. I'm just telling you my experience and from what I've read from actual studies, not just vibes and people online talking. So after a year of working with these tools, I am more convinced than ever that having good judgment is going to be the true superpower moving forward. The basics are actually more important now, because coding agents can write sloppy code at scale. And let me take it one step further.
Speaker 1:Anybody telling you that coding is obsolete or that AI can do most of your job as a developer has no clue what they're talking about. Or they just don't code for a living, or they don't code on a team that's more than two or three people on a very, very early project. Beware of the junk that they're peddling, and also beware of the stuff that I say too. Make your own decisions, read studies, look up things that make sense to you, use the tools and walk away with a better understanding of what is reality, and not just what people online are telling you or people like me. You really need to make your own judgment.
Speaker 1:Anyways, I really hope you found this useful. I hope you avoid these career traps and, if you want to not just learn to code, but have a career in software development, which is so much more important than just learning how to code. Go to parsityio slash inner dash circle, and if you're not quite ready for that, go to dev30.xyz, our flagship program for helping people develop the mindset, the skills and the habits, as well as the JavaScript fundamentals, to actually have a shot at being a software 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 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.
