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
#241 - The Bootcamp Era Is Dead — And That’s Great News for Developers
Send a text and I may answer it on next episode (I cannot reply from this service 😢)
AI didn’t kill bootcamps — shallow learning did.
So what skills actually matter now that building a CRUD app is a commodity?
And can you learn them without working at a company or getting a CS degree?
In this episode, I’ll break down why the bootcamp model no longer works, what’s replacing it, and how to develop the old school engineering mindset that will set you apart in the AI era — even if you’re self-taught.
If you’re serious about becoming a software engineer and want mentorship that’s not just YouTube and vibe coding, check out Parsity.io or hit the link in the show notes to chat.
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. Bootcamps are out. Old school software engineering is back, thanks to AI. Let me start off by saying that I think the end of the coding bootcamp era actually might be a good thing. Schools like Turing are closing down. There are less bootcamps now than there used to be.
Speaker 1:Now, part of me is really sad to see this, because I think they provided a ton of value. They were a way for people to get into an industry without spending a ton of money in college. The problem, though now the fundamental issue, is that they just don't work. Why did they work? What happened? Well, at one point, we had a demand for developers, which way outpaced the supply, and so we had some good coding bootcamps and some not so good ones, and they were, overall, fairly effective. Right Like. People just needed software developers like a lot, especially in that 2020 to 2022 era. That's when it was like an explosion where you could literally just know, react and get yourself a job.
Speaker 1:Those days are very far behind us. This is ultimately why Parsity moved to a mentorship model and way away from anything that would even resemble a coding boot camp Like. I don't use that term at all anymore because we're so far away from that that it just doesn't mean anything to us anymore. Now people still call it that and I get it because it's just a word people know. So coding bootcamp is part marketing and partly just a term that'll probably always be around forever. It's an alternative path to get into software engineering. But now that coding bootcamps have failed and I think why they failed is because they tried to take a one-size-fits-all approach, kind of like if we give you this magical mix of technology and you just learn this technology at a surface level really and you don't really learn much else behind it, you can get a job right Because employers just need you that badly. Those days are now over, right, and so what does that mean for you?
Speaker 1:Whether you're an early career developer or maybe you're a person that's already employed and you went to a coding bootcamp and maybe you're not feeling great about your skills right now and I feel you right Like AI has basically exposed shallow knowledge Because what you used to be able to do right as an actual valuable skill like you used to be able to build. Like I'm building a CRUD app or I'm building a portfolio project that can be done in literal seconds, minutes by something like V0 or Cursor or one of the other AI tools out there Probably one just launched today that could do that right. So if your skills stop it, I can build a to-do app. Then AI is going to be faster than you and better than you, and going to do it with fewer bugs. If your skills stop at unbeatable in this era, in this anti-boot camp era, in this AI era, where we're finding ourselves kind of getting pushed to the edge of like well, what are we supposed to do now as developers? What is our real skill? And the old school skills are becoming the skills I think that more people than ever are going to need to adapt to and adopt, if they haven't already. The good news is a lot of these things you probably already know.
Speaker 1:Debugging this is one of the top skills that I see that many developers just don't have this investigative mindset where they can look at something, they understand their tools and they can walk through step by step to reproduce it and try to figure it out. Now there is surface-level debugging and then there's like, advanced debugging. If you're early in your career, then surface-level debugging is fine and you can acquire this skill by literally just opening up your Chrome DevTools. Open them up, for the love of Bob, and then learn how to use them. Learn how to put a debugger in there. Learn how to use the network tab. Learn how to use the performance tab, the memory tab. Look through there, figure it out. Learn how to debug your own janky code, so that way, when you get to the job, you'll understand how to debug others' janky code. Ai still can't really do this. Honestly. It can debug your simple JavaScript code right, but once you put it on the web, you need to figure out how to debug it.
Speaker 1:Now, advanced debugging comes from looking at different systems and how they interact. It's very rare that your code lives in isolation, so you'll be needing to be able to debug. You know why a backend system is not interacting correctly with a frontend system, maybe why your data pipelines are not putting the data in a shape that you expect. Why is this third-party API not working the way you expect? These are more interesting things that can involve lots more investigation. Sometimes the investigation is like, oh, that service is down in Korea and we're just screwed until those guys in Korea figure it out right. And sometimes it's like, oh, there's a line of code here which shouldn't be here. Who put this in? Well, let me go yell at them. That could be the end of your investigation as well.
Speaker 1:So if you're on a team of developers, you know, shadow some of the people that are doing the debugging and see how they're doing it. This is a great way for you to pair with people to learn from them. I love doing this. When I get to a new job and it's like my first day or the first week, I will typically ask somebody to walk me through debugging, something like oh, is there a critical issue happening? Hey, do you mind if I kind of shadow you? Or do you mind, after you're done, if we can chat about it so I can learn how you debugged it? It gives me a lot of insight into what they're doing, their systems and how I can put on my investigative hat if I need to do the same thing. And then it also makes you just look good because you're being proactive. So debugging is a skill that is not going away and it's not a skill that you can just offload to AI quite yet, and it's something that just is going to be part of your job in general. So get good at using the tools.
Speaker 1:Speaking of tools, git and version control these are tools. You still want to learn and learn them well, and I'm going to make kind of a controversial statement here. I think you should learn how to use Git with no additional tools. You should learn how to use it in your terminal. Why? Because you're not just guaranteed to always be working on your machine. What if you have to help somebody else out with a Git problem? What if your CEO, who now can use Cursor and other tools too and they say, hey, do you mind helping me get this code from my machine into our code base? First of all, terrible. Don't let them do that. But if they absolutely have to and you need to walk me through using Git, or you're using some other person's computer, or you have to SSH into a server somewhere out there on Jeff Bezos' server farm you wanna learn how to use Git and learn how to use your terminal pretty well. I think this is actually a skill that, surprisingly, a lot of newer coders don't really have. I'm not going to say I'm some terminal king or terminal god here, but geez, learn how to use Git. Learn how to use Git revert. Learn how to use CherryPick and then why you should probably never use CherryPick. Learn Git rebase and probably why you don't want to use Git rebase. Learn Git merge strategies. Learn Git branching strategies. Learn about Git a little bit below the surface and you're going to thank yourself and your teammates will thank you. And then when big issues happen that require a little bit of knowledge of Git beyond Git add, git commit and Git push, you can be the person that knows how to do it.
Speaker 1:Next up is system design. You can't really just AI your way through scalable infrastructure decisions. It's not enough to ask ChatGPT to say, hey, how do I make a scalable e-commerce app? And then you build something with several microservices and all these crazy tools and your boss is like why would you present this? What the hell is this? We're a team of three people. What the hell Peter or Susie think about it. You need to put on your thinking cap when it comes to these things.
Speaker 1:You can read books like Designing Data-Intensive Applications. You can read System Design. You can just get a subscription to Medium and read about System Design. On there you can learn about how systems are created, some of the constraints, some of the ways that you'd want to build something for 10 people versus 100, versus a million versus a billion. Just you know. Learn a little bit, read a book on this stuff. This is not like knowledge that's gatekept anywhere. This is literally everywhere. So learn about it and then you can talk about it intelligently and then try to apply it in real life.
Speaker 1:Lastly, this one reading and navigating code AI cannot really teach you how to understand a 10,000 line legacy code base, now 10X that to 100,000 line legacy code base. Or how about a million line legacy code base? If you're working at a big company, that's what you're gonna encounter. You're gonna encounter tens of thousands of lines, hundreds of thousands of lines, maybe a million lines, and if you say, oh, we'll just dump it into you know cursor, no, you can't. And even if you could, is that really the way you plan on interacting with the code? Waiting minutes for a cursor or whatever other tool that you're paying for to tell you how to do stuff? That's not a way to have a career. That's a way to be an advanced chat GPT user and have a career. That's a way to be an advanced chat GPT user.
Speaker 1:And if you're saying, well, I'm super early in my career, I don't have a way to look at really large code bases. Two words for you, my friend open source. Or maybe that's one word, I don't know, look it up for me. Anyway, open source, do this project. This will be a fun project and I'm going to say some things that you may not know. But this is going to get pretty tactical Really quickly.
Speaker 1:Don't worry, I'm not going to go off on a tangent here too much, but pick a library that you like. I'll give you one Nextjs, react, redux, everybody's favorite right. Go there, clone down the library and then learn how to NPM link it to a project that is using that library. For example, if you have a Nextjs project that is using React which of course it is learn how to npm link to your own version of React. Now, learn how to basically break the code or make useEffect or useState, do something weird that it normally wouldn't do. And if you don't know how to do this that's the point. You're going to learn how to do this by going and looking up what is npm link. How do I npm link? Well, how do I then interrupt the source code and add my own version to it? Well then, what? What happens if I break it? And this is going to be way, way better than going and trying to find a typo and a readme as a way to contribute to open source. You're not going to contribute jack to open source this way, but you're going to learn a ton. Npm link, look up a library, link it up and you're going to learn a ton. These are the skills that are going to make you unbeatable.
Speaker 1:The next big trend I'm seeing is the rise of the product-minded engineer. I'm in the San Francisco Bay Area. I'm just seeing this a ton, and this is basically an engineer. That is more than a code monkey. It's like okay, you know why you're building the product, you have an idea about it, you have some sort of opinions about the user flow, how it should generally work. You can talk about the features and why they might be important or what you would do differently. You're basically like a partner, like a thought partner.
Speaker 1:It's not enough to just write code and say, well, just show me how it should work and just tell me, spec by spec, exactly how this thing works. That's not enough anymore. People are trying to do more with less. Is it fair? No, is it reality? Yeah, so this is what people want now. They don't want just a full stack software developer. They want a full stack software developer that can also help them build the product.
Speaker 1:Now, how do you develop this product mindset? I'm going to dumb this down for you a ton. I honestly don't think this is hard at all. I think this just really boils down to do you care? Do you look at something and think how could this be better? When you work at a small startup, do you think, huh, what is the business goals? Can you describe the business goals? And if you know the business goals and you can look at what you're building and saying, does this actually matter?
Speaker 1:Something I learned when I was working at Clorox and I became a manager is I used to try to chase code goals like how am I going to make this code run faster? How am I going to add more testing coverage? All these silly vanity metrics that no one really cared about. And then, at one point, a much more senior person said you know, you're chasing the wrong stuff, and so I started thinking like this what is the most impactful thing I can do for the business? And every week I think what's the most impactful thing I can do.
Speaker 1:Some weeks that would be writing code. Most weeks that will be doing literally anything else. It'd be like I'm going to talk to somebody in product this week and I'm going to understand their pain points and see what we can do to have a better product and engineering relationship. I'm going to make a newsletter this week that's going to explain this new service and why it's important and what we're doing, so that way my team gets some more acknowledgement in the organization. Or maybe this week I'm gonna lead a lunch and learn where I'm gonna teach the entire org how to use this particular tool that we're using.
Speaker 1:That took me a whole lot further than just writing code all day, and this is honestly what's just becoming now expected at most small organizations and Newsflash. If you're working outside of big tech, you're working at a small organization, so just giving a damn thinking what's impactful? Learning things like basic UI and UX design. You can just read a couple articles honestly. If you can just speak just somewhat intelligently about accessibility or things like how to make a website more intuitive to use, or metrics that a business might care about, like the time that a user's on the site, or SEO. These are things that are going to really make you stand out. And finally, learning some DevOps. This kind of goes back to this doing more with less thing, which I know. Is it fair? No, but just look, we're in reality, right, like I'm just trying to tell you what I see as the trends that I'm seeing personally and through people at Parsity, what they're going through. Right, so, learning a bit about DevOps.
Speaker 1:Can you not only write code? Can you ship that code out to production? Can you deploy and manage multiple environments? Do you know just a little bit about setting up a CICD pipeline? Basically? In a nutshell, how do you write code that checks whether your code is working, has some tests and when those tests pass, it then pushes that code out to a URL that everybody can then enjoy or hate, right? This is a skill. And then, on top of that, can you have multiple environments? Do you have a developer site versus a production site?
Speaker 1:So you may have a URL like devcom slash, whatever, whatever your site's name is, and you may have a production site likecom slash, whatever, whatever your site's name is, and you may have a production site like wwwmysitecom. Now why would you want to have two sites? One is for you to test your code on a live site, because code that is on a live site will often behave in different ways than it does on your computer. Right, and you can do everything you want to in the world. There's nothing like having it on a live site. You can do everything you want to in the world. There's nothing like having it on a live site. So, before you deploy it to the world, you have this, basically, little testing ground that is actually a deployed URL that you can test and anybody could maybe access. Or maybe you put some sort of a gate in front of it, like some sort of password or something like that, to check it out.
Speaker 1:So what you do is you could set this up for yourself. You could use GitHub Actions, no-transcript. It's completely overkill, because it's going to teach you a lot. So, finally, I gave you some really practical things to do and I really hope you do one of them. In fact, I think the NPM linking one is probably the most complex but the most fun one you could do, and it's going to teach you way more about working with open source than anything else you could probably do.
Speaker 1:But, in conclusion, I think this is a good thing for developers. Like we're entering into an era where, if you actually want to learn this stuff, you're going to have a really good time because your competition if I'm just being honest, you're going to have a really good time because your competition, if I'm just being honest, is not ultimately prepared to do these things. If you're competing with people that are going to one of the few remaining bootcamps out there that are essentially just money grabs, you're going to beat them. If you're doing these things, so like, have an actual desire to be a software engineer, have a desire to learn past the surface level and have a desire to be more of a craftsperson than just a person that's copying and pasting code, it's like, yes, we want speed, obviously right, you don't wanna take forever to get code from your machine out, but you want craftsmanship, or craftspersonship if I'm trying to be more gender neutral here, right, but go deeper than just code generation. So, if you're frustrated or scared by AI, if you're scared about all the stuff you're hearing about bootcamps, maybe you're in a bootcamp and you're not at Parsity. Hey, you know we all make mistakes, right. But anyway, you can do these things on your own.
Speaker 1:I don't think there's anything wrong with coding bootcamps. I don't think there's anything wrong with self-teaching. I don't think there's anything wrong with learning. However the hell you want to learn. I just know that it's going to take a lot more than writing code, deploying a to-do app or a movie finder app as the barrier to entry.
Speaker 1:Those days are gone. The fluff is getting filtered out. So what's left? People who can think, who can reason, who can debug and who can deliver. If that's you, you're going to be where you want to be.
Speaker 1:I really hope that's helpful. Hope I didn't scare you away and if Parsity sounds like the right step for you, it might be. I suggest you schedule a meeting with me or Zubin and we can talk more about it If you're interested in it. We have, I don't know, not that many spots for the year. We're not one of those big old boot camps. We're going to be taking tons and tons of people. That's just not going to work. But anyway, hope it was helpful and hope you have a great weekend. 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.
