[00:00:00] I'm just gonna say it. aI is sabotaging inexperienced devs,
it's a ticking time bomb
hey guys, and welcome back to Easier Said Than Done and how to get it done. Today I want to talk to you about the impact AI is having on inexperienced devs
every time I interview junior devs now it's a problem.
Over the last few years, obviously I interview and I work with inexperienced devs who are new to the industry. And you know, I've worked with 'em for years, even before the AI thing has happened, right? And I've noticed a big shift. The younger devs, the new newer devs to the industry are really struggling to actually be engineers.
They're able to produce code, but they're not able to do much engineering, which includes the debugging and stuff like that.
Welcome to Easier Said Than Done with me, Zubin Pratap, where I share with you the tens of thousands of dollars worth of self development that I did on my journey from 37 year old lawyer to professional software engineer. The goal of this podcast is to show you how to actually do those things that are easier said than done.
The younger devs, the new newer devs to the industry are really [00:01:00] struggling to actually be engineers.
They're able to produce code, but they're not able to do much engineering.
Over the last 10 years I've witnessed. Big shifts in this industry, but nothing like the current AI revolution.
And
and to be really clear, I love the ai. I think it's a fantastic tool.
It's made coding so much more fun, especially for people like me who are at a management level and spend less time on the tools we can now use, the less time that we have to do way more than we could before the ai because you can actually still code without needing all the time required to code, right?
It's made life so much easier to build and explore tools and prototype things. But, and this is a really, really big, but AI assisted coding is a pretty seriously double edged sword right now. I know. It's great. There's an influx of AI tools like copilot cloud, GPT, whatever, right?
Undoubtedly, this is accelerated code production. Big fan, very useful.
But inexperienced developers are now spitting out code way faster than ever before. And on the [00:02:00] surface, I know that seems like a win.
So you hear me out, but I truly believe this "efficiency", this speed is actually a big fail and it's a ticking time bomb.
I'll talk about examples from work or when, when I'm doing stuff with inner circle students. When people apply, we baseline their technical ability. They're producing the baseline starting ability for most people who are joining the program looks to be way higher because they produce some pretty cool looking stuff on the basic projects that we give that, and everyone gets a different project, right?
But when I probe these people on the intricacies of their code, like, why did you do it this way? What are the edge cases that you may not have considered? Or what are the edge cases you did consider? I'm often met with these... silences this total panic and confusion, right? Even a simple enough question for someone who's written a code that takes in a file and has a web ui, you know, a front end UI on it, and it's uploading a file to a server.
Something fairly simple like that. I could say something like, Hey, look, I like the potential edge case you've handled with the file IO. [00:03:00] What other methods did you consider on the design side of things that would take away the need for having to handle this edge case? Is there a UX element or a UX experience you can bring to this for the end user to follow that would take away the need to handle this file IO upload exception.
Total speech lessness right now. And that's fine. If they don't know what file IO is, that's fine. If they don't know what UX is required to actually handle that kind of stuff, totally fine. That's what the point of the baselining exercise is, but it's in their code.
It's reasonable for me to assume that if it's in their code, they should be able to explain their thinking and their analysis behind it, but they can't, and it's not that they don't understand the question.
They understand the question, it's that they don't understand the problem I'm talking about. They don't understand the problem that this AI generated code that they pasted has solved. They didn't even know what the problem was. They didn't even know there existed a problem that this code is meant to solve.
So when you probe them on the analysis of the problem, which is ultimately what a professional engineer is paid to do, [00:04:00] is take business requirements, understand the problem statements, convert that into code in a way that solve those problem statements for the end user. That's the whole customer journey that we are trying to solve
for as engineers.
This is foundational knowledge. And it's foundational knowledge that traditionally and typically came from grappling with complex problems.
And unfortunately,
that grappling process these days is noticeably absent because the AI just kind of does it for you and you don't need to understand what's going on.
So let's talk about this lost art of problem solving. if you look at any, anybody who's been an engineer on the hiring side for a while, they'll tell you, problem solving is one of the things we look for, but we are losing that. We are losing the ability to problem solve because we are losing the time taken to do trial and error based learning.
Now, for those of you who've been around a while, you've been coding for a while, and I'm not talking about decades. I'm talking about even if you've been around five years, you remember that debugging meant hours of going down rabbit holes on Google searches, et cetera. Or you hope to find a kindred spirit on stack [00:05:00] overflows face the same issue.
There's a great XKCD comic on this. And
if you're watching this podcast on the YouTube channel, you can see the video pasted up here, right? But this is great. It's, it's a great comic. Anyway, those experiences, those going down rabbit holes,
the trial and error, of course, they were really frustrating, but they were also incredibly valuable learning opportunities.
Now, I'm not glorifying the hardship. I'm not glorifying the suckiness of that older way of doing things. What I am saying is
that it was a critical part of the foundational period in a software engineer's life. The critical part of having to build those muscles, right? It's like it doesn't matter if you're gonna spend the rest of your life driving... as kids
you want to be playing and exercising with your body so you have proper musculoskeletal development. It's the same thing in programming. When you're starting out you want to have the trial and error based learning. Because it forces you to dig deep, understand the systems thoroughly, get stuck, have to reason your way out of that stuckness.
Trust me, that's where the learning is, right?
Now, I believe, [00:06:00] and I'm not glorifying, I'm not romanticizing, but I truly believe that those of us who are lucky enough to have gotten stuck a lot while we were learning to code, we learned enormously, exponentially more things from being stuck than we did from the times that we copied and paste code from Stack Overflow,
and it worked, but we didn't really understand why that didn't teach us anything.
It was getting stuck that really, really taught us the stuff we knew. And crucially, we learned valuable lessons the way nature designed the human brain to learn through trial and error.
For those of you who've got kids, watch how the kids learn to walk.
Watch how they learn to ride a bike. Or think back to the time you learned to drive. Think about the time you learned how to ask people out on dates. These were trial and error rich activities, alright? There was a lot of feedback and, and failure. And you got better. And you got better.
And you got better.
But those of you learned sport. It's the same thing. Nature designed us to learn through the trial and error loop.
Ironically... aI also learns through trial and error. That's why it has training sets and it does millions or [00:07:00] billions of repetitions and gets better on the training It learns through trial and error.
Human beings are now in a situation where we are not having to learn with trial and error. When it comes to the coding stuff or even writing or in creative writing or video editing or music production, all the trial and error is being sucked outta the system. Sounds great. I see huge benefits. There's another video I've got, there's another blog I've got on another podcast.
So if you're on LinkedIn, you'll see it in a blog. If you're on, Spotify, you'll see it as a podcast. If you're on YouTube, you'll see this as a video podcast as well. There's another one that I have where we talk about vibe coding, right? What Andrej Karpathy talks describes as vibe coding, and I call out how it works for people like Andrej Karpathy for people like me, et cetera, because we've got enough experience behind us to know how to use vibe coding as a technique.
Beginner devs. Inexperienced devs will set themselves up for massive failure.
Hey, hope you're enjoying this episode. Listen, I bet you're tired of the social media BS. You're confused and overwhelmed. And all you want is for someone to just show you [00:08:00] a clear path to a coding career. Right? We get it. My partner, Brian and I. We changed to code in our thirties and we can help you do it too.
Brian and I have done all sorts of engineering work from startups to Google, and now we've built an exclusive private mentorship program designed to get you from beginner to professional developer, whether you've done a coding bootcamp, you have a computer science degree, or you're starting from zero, it doesn't matter.
We'll build you a step by step and customized plan not just for the coding stuff, but for the entire career change process Look, i'll be honest. The program is not easy and it's not short But if you do the work, you'll get results that will change your life If that's what you want go to parsity. io slash inner- circle or find any of the links in the show notes And you can schedule a free call with us speak to you there
Massive failure. You'll have very quick sugary hits in the short term and have massive problems at the workplace, which we're already seeing. And I've linked to all kinds of things in that podcast and blog.
So check it out on LinkedIn [00:09:00] or YouTube or Spotify, whatever, right?
So experienced engineers are already talking about this, that today's AI first approach. Of course, it's very convenient, but it bypasses this crucial learning process. And so what's happening is people are trading the depth of understanding and good mental models for quick fixes and rapid productivity in the
code that they spit out, right? It's a terrible trade off because if you don't understand the code you spat out. You're creating a problem for tomorrow, ticking time bomb. And I fear, I really genuinely do worry that we are gonna pay for this trade off down the line, both as managers, but also the actual inexperienced devs are coming in and are learning in the trade ?
It's a trade off and we're gonna pay the debt for it later on. Experienced engineers , a lot of them say we already are. I'm kind of inclined to agree that I'm starting to see that, you know, younger developers are really having a tougher time. And when I say younger, I don't mean age, I mean newer to the profession, right?
Also, it's not just in engineering. I'm seeing this for my friends in the law, in clinical science, in marketing, and even in medicine, right? So this is happening everywhere where people are trading in the ability to learn and research.
For the [00:10:00] ability to produce an output without understanding how that output is produced.
So maybe then we should talk about how we bridge this gap, this, this gap between AI and deep understanding. And there's a big gap, right?
So how do we harness the power of AI without sacrificing that, uh, depth of knowledge that makes people great developers or great at anything. Here are some strategies that I found effective back from my time when I was learning to code in my late thirties, and also now, which, you know, in the post AI world, how I use it, right?
For me, AI is just another learning tool, not the only another learning tool, right? And you don't just accept its solutions at face value.
You interrogate it, you ask questions, you get it to explain its reasoning. You probe, then you triangulate with primary sources of data. You also triangulate with primary sources of data.
If you look at the blog, you'll see the link to what primary and secondary sources of data means. You know how to use them in your research process.
Number two, method You is you want to enga engage with experienced developers or developer communities. Now, experience being the operative [00:11:00] word.
Don't spend time on the Discord platforms and other places in Reddit where you're surrounded by other people at your level or behind you. You're not gonna grow quite frankly. You want to be surrounded by the "greybeards", so to speak, and engage with them, or at least witness how they solve problems, right?
That's number two Technique.
Number three technique is we wanna reimagine code reviews. So those of you who are doing code reviews at work, or on projects or whatever it is, shift the focus from assessing the functionality of the code to understand the rationale behind the code, right? You want to encourage discussions about alternative approaches to that particular solution that was chosen, and the reason behind those design and choices.
You want to understand that you don't have to agree with them. There are lots of opinions around the place. Ultimately, it's a judgment call and there are trade-offs, but at least understand the richness of the debate behind a certain decision.
Number four, try and build from scratch.
Now, I know everyone's obsessed with portfolios.
My personal view is that you don't need a portfolio. You need one really good project. That's what, that's how I did it. That's what got me into Google, I believe.
Well, among the many things, I don't wanna be reductionist. It's not like one thing got me into Google, but the [00:12:00] project that I had, I had only one.
Pretty substantial project, which is a personal tool that I developed and I'll, I'll talk about this on another podcast, right? But you wanna build things from scratch. Occasionally you can use the AI assistance, but... once in a while, just put it aside and try to build something from the ground up. Is it gonna take you five times the amount of time it normally would?
Probably. But it's not about getting the result, it's about the learning. Old cliche journey, not destination, same thing. It's about the learning for those four or five hours, not the fact that you haven't built anything at the end of four or five years. 'cause the goal is not to really build something.
The goal is to LEARN by building.
So learning is the emphasis now. Yes. When you do so on your own, when you're doing it from scratch, it's gonna be tedious, it's gonna be tiring. The code may not be as polished as you think it is, but you're not gonna be in a position to assess that anyway. But the understanding, the insights that you gain will be invaluable.
Guys. It cannot emphasize this enough.
Another thing you could try to do is, okay, if you're getting the AI to generate the code for you, fine. Leave it in that window. But then hand type it in yourself. Don't just copy and paste big chunks of text [00:13:00] because when you hand type stuff, you're forced to pay attention to everything you're typing, and it's gonna reveal gaps in your understanding that would otherwise get hidden when you simply copy and paste a slab of text.
So hand typing, yes, it's tedious. Yeah, defeats the purpose of using a completion ai, et cetera. Sure. But use the completion AI as almost like a teacher who's written something on the blackboard. Remember the old school way of doing it,
and then you kinda write it down because that process of writing will make you say, hang on, actually, I've just written this line.
I don't understand what it does. Great. That's the learning, right?
Number five tip for learning with ai. Increase your reps. You don't need more courses. Okay? I've said this on LinkedIn a million times. You don't need more courses. You can learn to code with maybe two or three good long, deep courses, right?
Do them twice over. Increase your reps. Then when you build a project that you conceive of independently, don't copy another clone or some stupid YouTube video. Think of a project because the, the important parts of a project is solving the problems. There's another blog on this and there's another video on this and there's another podcast, and this is all the same thing [00:14:00] on, you know, Spotify on the EASIER SAID THAN DONE channel.
There's another one about how to get out tutorial health and build projects independently, right? It's not actually very complicated. It requires you to make the effort of doing some independent thinking and research and then
and building it. But if you're doing something with that, then build it twice and for each iteration of your build, use a different ai LLM.
That'll get you to understand how different ais. Spit out comments because trust me,
they don't know things. They're inferring things. That's why the AI process is called inference. It doesn't know it's inferring things. It's using statistical probability. When you use different ai, you'll probably get different results.
They may look the same to you, but when you study them, you'll see they're different. And that's the learning. It's like you had two different people give you two different solutions to the same problem that look kind of the same same on the surface because they produce the same UX maybe, or the output, but the implementation detail, how it's done.
Two cars kind of look the same, four wheels, a bunch of doors, an engine, a drive train ,runs on some sort of fuel. They all kinda look the same. Then the design may also look quite [00:15:00] different superficially, but the engineering of the engines could be vastly different. The engineering of the drive train could be vastly different, right?
The tire thicknesses, the tubes, the tube less-ness, all of these engineering decisions that are different, the wheel base widths. All of these things,
suspensions, all of that is different engineering, but the car kind of looks the same no matter which brand it is, right? The fundamental, the basic, recognizable shape is the same.
The principles are the same, but the engineering decisions are vastly different.
That's why you want to get multiple points of view, and you can use AI to do that. Provided you understand the code, it's pattern out.
Again, watch that other thing about vibe coding and how important it is for you to treat yourself like the boss, not like the AI is your delegate.
It's not your delegate. Your AI is like your direct report or, or very talented intern,
but you are the boss and you've gotta be accountable for output. So watch that other video 'cause I break down all the tips on how to code with the LLMs there as well.
Okay, so now let's, let's look ahead a bit, right? Um, not that anyone knows the future, future, but I'm pretty
confident that the AI revolution is here to stay. So, you know, barring some regulatory risk, I think that it's [00:16:00] probably gonna be here to stay in one form or the other. And I suspect that its pace is going to accelerate and drive more acceleration of speed of change, right? So it's, it's a loop. It's a positive feedback loop.
There gonna be positive for all of us, but it's a positive feedback loop as a system. Now our challenge isn't to resist this change, to complain about it, to throw up our hands in despair. Our, our, our challenge, our opportunity here is to adapt, to learn faster, to get better. It's gonna level the playing field for some people there, I can promise you, in 10 years people are gonna have completely different lives because they seized the AI opportunity and others are gonna have different lives because they did not seize the AI opportunities.
Right?
So develop yourself, develop the practices, develop your mindset. It's something we work on very much at the Inner Circle because no one can predict the future. All I focus on in the inner circle is giving my people the skills and
the meta skills that they can combine into packages to architect their own life.
'cause they have to be the CEO of their own career. Nobody can do it for them. No one can predict the future. So the only power I can give my students is to show them how to learn really fast, when to learn how to learn, how to [00:17:00] analyze things, and how to get a change in mindset around these things, which is a big part of it.
I believe that developers who are gonna thrive in this new landscape, this new world , the post AI world won't be those that can generate the code fastest. 'cause you can't beat the AI generating code that actually spitting out lines of code. But. Those who can leverage AI to spit out useful, commercially viable, and,
and robust code, while maintaining a deep understanding of the broader system within which that code fits, and solving real problems that customers value, because that's what businesses do.
Again at the Inner Circle Program, and the links are in the bio,
we emphasize the fundamentals built over a sustained period of time because no matter what the trend around the system, whether it's React or VueJS, or Rust Language, or AI, LLMs, whatever, the fundamentals of programming a computer to accept your instructions and execute them is the same. Now, if you're instructing the LLMs that's still instructing a computer, don't forget you're still instructing a computer.
Hi, if you want a no BS [00:18:00] insight into how to change your career, whether to code or something else and how to actually get job opportunities in tech, then please subscribe and like.
It's no BS because I have zero incentive to mislead you. I just want to help you and give you tons of value so that you will consider working with me to get to your next career.
Take a look at the
description text below to learn more about the training I offer. But I do post content here regularly and by subscribing and liking and hitting that notification bell you will get to know when I post new industry insights for you. You'll also know within about three seconds if you want to learn more, but at least you won't miss out.
Oh, and please follow me on LinkedIn too. I pretty much post there every single day. Just look for my name, Zubin Pratap. All right. So please like, and subscribe to this channel and let's get back to the episode.
whether it's React or VueJS, or Rust Language, or AI, LLMs, whatever, the fundamentals of programming a computer to accept your instructions and execute them is the same. Now, if you're instructing the LLMs that's still instructing a computer, don't forget you're still instructing a computer.
It may not look like a programming language, [00:19:00] but you're absolutely giving instructions to a computer. Okay. It's exactly like the graphical user interface. When you click on a file, it's still sending instructions to the computer. You're not typing out those instructions. You could do it from the terminal of the command line, but you're clicking on something, right?
It's a different way of interaction, but underneath the hood, you're still giving instructions to the computer. And it's the same with the AI LLMs. You're giving instructions to a computer that'll help you be productive, right?
So as we navigate this transition. I encourage you all commit to using the ai, not just as a shortcut, but as a jet pack, right?
Something that makes you faster and better, not something that makes you do less effective work. It's a tool for deeper learning if you use it the right way, more nuance and understandings are possible, but you've got to put in the work to build the ability.
The future of software development, I truly believe depends on our ability
to balance the speed and benefits of AI with the depths of human judgment and insight, which is something that's uniquely human, okay? That comes from experience and observing the real world.
[00:20:00] Please engage with me on this because this is really important. You know, I'm very passionate about how people can transition their career into coding or code adjacent professions.
I did it myself at a very late stage in my life. It is extremely hard. There's a lot of social media BS that tripped me up for five years, to be honest. I'd like to hear from you, what strategies have you found effective in building deep understanding? How do you use ai? What are the challenges? What are the benefits?
What are you worried will happen? What would you like to be better at? Just put them all in the comments. I will answer the question and I'll try and help you out. Okay? And if you want, look for other links to the program. If you wanna work with us, let us know. We'll be happy to see whether we are a fit.
Alright, have a super day. Bye.
Just subscribe, you know you gotta do it.
