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
Has Cursor Cooked Junior Developers for Good?
Send a text and I may answer it on next episode (I cannot reply from this service 😢)
Cursor is an AI-powered text editor for coders. Let me be honest - if I was a junior developer, I'd feel a little nervous looking at what it's capable of doing.
But I'm not. So I'm not.
Let's explore why Cursor is an amazing tool that will cause a ton of headaches when used improperly and what you can do as a junior developer to to create a technical moat to be "AI-proof."
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 was just looking at Reddit Terrible thing to do, by the way. Don't go on Reddit at all if you can help it but sometimes I go on Reddit and I look at the coding communities on there and I saw this post that really stood out to me and I think it might be representative of what a lot of earlier career slash junior developer people are feeling right now. It said something like I'm a junior developer, I got my first job and I feel like Cursor has destroyed my confidence and my overall outlook on coding as a career confidence and my overall outlook on coding as a career. Basically, it was like if Cursor, which is an AI text editor, basically like VS Code it's a fork of or a clone of, vs Code, but integrated deeply with AI. I use it. I actually had a guy on the show a couple episodes ago that was showing me how to use it and he is all in on it. He's been coding for 20 years now and he thinks that we should be using AI tools over manual coding Whole other different discussion. But the interesting thing, of course, is that, yeah, ai tools like this can do a lot of code, and I mean a lot. I use it at work constantly. In fact, I'm trying to code less and explain to the AI large language model to code less and explain to the AI large language model what I want to have done.
Speaker 1:Is it always good? No, but let me be honest. If I was a super junior developer or person learning to code and I saw this thing and I was using Cursor, I'd be like I'm cooked. What's there left for me to do? Like, what am I going to do? How can I compete with this? What are the expectations now that this thing can do? What I can't really even do? And I'm going to explain to you I don't think it's time to freak out just yet, or probably ever, if I'm being completely honest with you and why we still need junior developers, why we still need software engineers in general and why we actually might have more software engineers, even with all these LLMs and things purporting and claiming that they can take over software engineering jobs.
Speaker 1:So let's dive in. First of all, let me tell you from experience. I am using Cursor on a daily basis. I paid for the pro version of it. I love it. I have nothing bad to say about Cursor at all.
Speaker 1:Now, the project that I'm doing at a really small startup with three engineers is so complex even at this stage that using Cursor to just write all the code is nonsensical. It's just not possible in any form or fashion. Now you may think, well, why not just upload all your files in there? That's not how it's going to work. First of all, the context window is way too large to keep all that in memory, and even if it could, when I need to explain to it what to do, it's going to look at some of the code samples I have there, whatever it's been trained on, and come up with the best possible response. Now we are doing some things with AI. At this job. We're using some libraries, databases, technology that is fairly new and emerging.
Speaker 1:This makes the responses even less accurate and less useful to use. It needs lots of reprompting. Sometimes it's faster for me to just actually write the code than it is to reprompt it many times, and the more complex the problem and the more files that the problem spans across, the less likely that you're going to get a good answer. If I need to do something like write a function that can strip out the domain from a URL, yeah, that's super simple. If I need to say, hey, refactor this entire file to be more modular and follow the single responsibility principle, and it can do what it thinks has improved the code.
Speaker 1:But oftentimes this isn't up to the standard of the head of engineering or myself or anybody else that would want to interact with the code. It's just not the kind of way we would write code and sometimes it's just plain wrong, like one time I had it try to write me a migration script. This is really important. This is a script that interacts with a database and it migrates data from one form into another form. It may drop tables, it may create tables. It does stuff that you don't want to have mess up Now.
Speaker 1:It gave me some instructions which would have caused a big issue. It removed a certain column and it added another column and I'm like why did you add this column versus this column? And it said, based on your instructions, it seemed that you wanted to do this. I said, yeah, but if I do that, then X, y, z would happen. It had some downstream cascading effect, what I'm trying to get at. I have too many examples of this happening, where, if you really just think that just talking to this LLM or using cursor or whatever and just having to write all your code is a viable path to being a software engineer and won't sting you dramatically and burn you you are out to lunch, my friend, and you got to come on back. Let me bring you back in there, brother. Let me bring you back in there, sister. You got to think for yourself, because if you just blindly follow what they say to do, you're going to end up in a world of pain and you're probably going to end up ruining your career, blowing up your database, getting fired, living on the streets of San Francisco and begging for change and hoping you can code HTML for five bucks on the streets. That's not what I want to have happen to you. Hey, I really hope you're enjoying this episode Now.
Speaker 1:As you may know, I've joined forces with an ex-Google engineer, zubin Pratap. He and I have very similar stories and we've combined forces to create a highly customized and personalized coaching mentorship program for career changers who are serious about breaking into tech. If you know that the outdated coding bootcamp model won't work for you. You're serious and realize that this transformation will take time. We want to speak with you. Our program is not easy, it's not short, but it's highly effective. If you're a listener of this show, you're likely the kind of person we want to work with. If you're ready to apply, click the link in the show notes and you'll be talking to Zubin or I on the phone about the program. Now back to the episode.
Speaker 1:Now I think I've broken down some of the many pitfalls of just offloading all your mental capacity onto an LLM, essentially a robot that sits in the cloud somewhere. But maybe I haven't convinced you enough, because maybe you haven't worked on enough complex code bases to believe what I'm saying. Or maybe you think that, well, the LLM will just get better and better and better. I think this also shows a lack of the entire software development life cycle. Let me explain. Let's pretend that you are a business owner and you have zero coding experience and you want to make an app and you somehow know to go download cursor. You understand what a text editor is. So now you're staring at a blank text editor and you're thinking great, I want to make a SaaS app, software as a service product. Think of something like an app that would look at Excel spreadsheets and give you some detailed feedback based on the Excel spreadsheet. Something super trivial and easy to make. Let's start there. Let's just try to start.
Speaker 1:This businessman, this businesswoman, whatever this person that has zero coding experience sits down, opens up Cursor, they say build me this app. And it says what language? And they think, uh, I don't know Java. I've heard that's really popular, why the hell not? And it builds it in Java for this person. And it builds a script and they say well, now how do I run this? And it gives them more instructions. And then they have to look up more instructions on how to actually run it because their computer wasn't configured to run Java. And then they think, wait, this is just a script, I need the UI. But they don't even know what a UI is because they've never heard that term. Do you see the cascading effect of knowledge and how they have to keep looking up at every step what to do Now let's say, by some miracle, they actually get something using Java and like HTML and CSS.
Speaker 1:Really terrible idea, or maybe not, I don't know. Somebody out there is probably thinking that's a great idea. We have too many frameworks. I'm not talking to you. Anyway, do what they want to deploy it somewhere. But big problem now you have authentication. You can't just deploy it everywhere. You have to take payments. How are you going to version control this thing?
Speaker 1:Let's say they've done so many iterations with the LLM that at this point they have zero clue what they were thinking at step one versus step 100. They don't even know version control exists. So they haven't used Git or GitHub. They've been writing all this locally onto their computer and trying to make it run. So after days and hundreds of prompts, burning through their credits on all those LLMs and OpenAI and stuff like that and buying Cursor Premium Pro Edition, they finally get something that barely works and they're thinking, ok, thank God, finally, now I want to get this out to the web. And then they realize they have zero clue how to deploy this thing. And so they buy a URL, they buy a domain. They think, how do you deploy this? And it gives them some options and they somehow managed to deploy it and then it breaks. They have zero clue where to even start debugging from. They don't know what debugging is. They start looking through the code, they say, well, how do I know where to find the bug? Do you understand where I'm going at this point?
Speaker 1:It's not so simple to just write code that works and then think that's the end of it. There are bugs, there's maintenance, there's version control, there's hosting, there's authentication, there's security, there's taking payments there's all these things that have to happen in a well-formed app. And this basic, super simple CRUD app is something that I honestly would expect a person at Parsity that's gone through about half the program to be able to complete in about a week and then deploy it. So this is trivial, easy, beyond easy thing to make, and if that's just something that you're struggling to think of how you can make, well, then you probably should join Parsity or just keep studying and figure things out. But the big thing here is that we do so much more than just coding. So, yes, use Cursor, especially once you've gotten past the basics and you're into your first job.
Speaker 1:Definitely know how to incorporate AI and LLMs into your daily workflow, because it's gonna make you a lot faster If you're writing out detailed instructions. It's gonna help you get that more high-level overview and almost make you like an architect over your code rather than just like a little coder. So in many ways, I think this is the most fun time to be writing code, because now you get to sit a little bit above, you can think a lot more high-level about what you want the code to do. You're still solving really difficult problems. You just might not be writing the actual little pieces of code to solve the problem and you absolutely are going to have to review, iterate, debug and make the code more reusable, better at matching the standards of your team, organization or yourself. Lastly, here's one way you can make yourself probably more confident and a little bit more AI proof. Quote unquote AI proof, whatever that means.
Speaker 1:As our jobs get a bit more abstracted and we sit a little bit further away from the code, system design becomes more and more important. This to me, is clear as day right. You want to be able to design, architect systems at some level. That's what a CTO does. What a software developer used to do, and still kind of does, is write little bits of code and if you think back, like from the 80s up till now, you had people writing like punch cards with code, so they were more and more detailed, so finer and finer detail until now, things like JavaScript less detail, more high level compared to like C++. And then you go a little bit further out and then you have things like no code tools, which came out in the 2000s and people were like, oh my God, this is the end of software developers. Now I've gone a little bit further out. We have LLMs where you say I'm going to use my coding language of English to explain what I want you to actually produce as code. But remember this the output is always code.
Speaker 1:Okay, computers need code to run on. They don't run on human instructions just yet. They run on bits and bytes and that's not going to change in the next 10, 20, 30, 40, or 50 years. So at the end of the day, somebody whether it's an LLM or you, a bag full of flesh is gonna be punching out keys and typing up instructions in code that a computer can understand. If you cannot understand those instructions that have been written to, the computer can understand, if you cannot understand those instructions that have been written to the computer, then you, my friend, are not a software developer and also you don't know how to bug fix, make, enhance all that stuff, the current code Now, knowing system design, understanding at a kind of a basic level how different modules of software interact with each other and what are good versus bad patterns like, what do you do when traffic spikes?
Speaker 1:What are ways that you can handle large amounts of asynchronous requests? How do you do something like, let's say, you have a billion users like you're at Facebook scale and each of those users does something like upload a CSV and they want some sort of data about that CSV? How do you handle those sorts of things? Then, at an even smaller level, how do you create and scale a database? Mongo versus SQL? Which one is the good choice versus the wrong choice? You have unstructured data that is mostly text. What's the good versus bad choice there?
Speaker 1:There are tons of books on this stuff. Alex Zhu is one of my favorites. In fact, he's kind of blown up and become like the guy to go to for system design. He has two books out there System Design 1 and, I believe, system Design 2. Really great names, alex. Anyway, those books are great. I bought both of them a while ago and I think that they are a really good investment. They're cheap, you can read them over the course of a couple weekends and it will give you at least some foothold into the world of system design.
Speaker 1:Now, related to that, things like DevOps could also be a really smart thing to explore, because, as much as we want our code to run and LLMs can produce code they tend to produce code that has way more bugs, significantly more bugs than what a human produces or what we've produced in the past. So this means we need to be able to debug, find these bugs that are often out in the cloud somewhere. Now, that means we need people that have some level of expertise, even a basic one, with cloud services like Amazon Web Services, google Cloud, provider, azure. If you work for some lame company or something like that, anyway, you want to have some sort of knowledge of how these systems work, how to get in, debug things. Some of the core services that they have, like AWS has S3, lambdas, ec2, cloudwatch and whatever the name of that auth service. They have IM2, I believe it is. Anyway, if you know a few of these things and how to navigate around and find things in there which you just can't tell an LLM to do, you can't say, hey, here's all my passwords to AWS. Go figure out this bug for me, come on, anyway.
Speaker 1:Okay, I think we've gotten to the point where, hopefully, I've convinced you at this point that just because Cursor can write some cool code on autocomplete, that it doesn't mean your job is useless or that you're worthless. It just means that you need to get used to being yeah, a little less useful than maybe you would have been five years ago as a junior developer. Even back then, you weren't super useful anyway. Junior developers are generally an investment, because they eventually morph into senior developers that can do all the things that I just spoke about. The big problem is, though, if you get into a company as a junior developer and you just decide to stop learning at that point and essentially just become junior throughout your career. I've done a podcast on this also. It's called the Junior Developer.
Speaker 1:With Seven Years Experience, I nearly turned into one of these people. Now you can avoid that by doing a couple things I just said. Read some books, try to build larger, complex web apps. Learn some AI beneath the hood, like linear algebra, how vector databases work, how embeddings work. Do a few of these things, and you're going to keep up with the trends and even be ahead of some of the trends that are happening in the future.
Speaker 1:So no, I'm not all doom and gloom at all, and if you are, then I'd say you probably haven't coded long enough to have a good opinion on it. But hey, what do I know? I'm just trying to figure it out, like all of you out there as well. As usual, I always hope that is super useful and I'll see you around. That'll do it for today's episode of 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.
