Learning to Code For Self Doubters
===
[00:00:00] Every coding error you've ever been defeated by. Every late night stack overflow spiral. Every AI induced spaghetti mess of code that you hit delete on. Every time you whispered. Maybe I'm just not smart
[00:00:12] enough. I've been there, and it still happens to senior engineers, by the way, every week So this is the episode I wish had existed when I was a 37-year-old lawyer, desperately learning to code, but drowning in confusing and terrifying errors before I became a Google engineer. If you are ready to If you are ready to stop fighting your code and yourself and you're ready to start mastering it, then give me 15 minutes.
[00:00:32] That's
[00:00:32] it.
[00:00:33] Welcome to Easier Said Than Done with me, Zubin Pratap, where I share with you 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.
[00:00:46] Three hours.
[00:00:46] Three hours.
[00:00:47] That's
[00:00:48] That's crazy. Three hours is how long. stared stared at the same error message before I finally broke down.
[00:00:56] It was 1:40 AM at the end of 2018, and I was crying. The code was broken and frankly, so was I.
[00:01:02] I was a 37-year-old recovering
[00:01:04] Lawyer, and I was used to winning. I had won all the time in my career, but this, this huge risk that I was taking was proving to be every bit the terrible idea that everyone told me it was. I
[00:01:13] was looking at the screen and I saw argument of type, blah, blah, blah, not assignable to blah, blah, blah.
[00:01:18] This wall of text. I mean, it might as well have said, you don't belong here. What are you doing? Stop, give up. You're just not smart enough.
[00:01:24] It was a It was a horrible error message I didn't know that in less than three months I'd get four different offers as a developer and that a year later I'd be signing a contract with Google as a software engineer. Now, looking back, I really wish I could have myself this.
[00:01:37] Your code Your code isn't breaking because you're failing. It's breaking because you are learning.
[00:01:43] That's why today why today I'm giving you the survival kit to learn to code and eventually get a coding job that no one gave me.
[00:01:50] But let's pause for a But let's pause for a second and consider why this matters, why this is important. Okay. Look, coding isn't just about jobs and money. Don't get me wrong. They're great, okay? They're fantastic, but it's more than that. It's a lot more than that.
[00:02:01] Coding is a craft. Right? it's, it's a craft. And learning to And learning to code is very different from coding.
[00:02:07] There are two different phases altogether. Learning to code is about several things. It's about reinventing yourself. Kind of like what I did from going from a lawyer to being a a Google software engineer, and then since then in big tech, right? It's also about learning to solve problems that you've never imagined exists out there in the world.
[00:02:22] Now, they're not always hard problems, but they're always different and creative, and that's the kind that lights up my life and lights up my brain. And I'm sure it's the same for you, right? But you also need to change another thing. You need to develop patience with sticking to a great plan. And then you need to And then you need to be prepared to accept lots of defeat, which means you're kind of taking a hammer all the time to your identity and then rebuilding a new one. And you have to do all this while proving to yourself that you can do hard things over time. , But first, Okay, but first, before you can get to that stage of readiness, you do need to dismantle and remove what I call the three silent killers of aspiring coders. 'cause I was there, I tried and I quit for four years. Right? So the first silent killer is
[00:02:58] ambiguity, which is that stage when you're like, I don't know what's going on. I don't even know what to look for. I don't know what to do . The next silent killer is error messages. Okay? Now they look so unfriendly and they are, they're not great.
[00:03:09] And there's a reason. As you become more senior, you'll understand why the stack is very long and deep the more your code evolves, right? So these error messages are hard, and you're looking at these error messages like, I don't understand any of this. Why the hell want this damn thing? Just work. Okay? That's the other silent killer because that's a stage where a lot of people quit. And the third is. The imposter syndrome. This constant conversation in your head where you're not being very kind to yourself and you're often saying things like, I'm not smart enough. Everybody else is smarter than me. Everyone else gets it. What the heck is wrong with me? These three things will kill your coding journey.
[00:03:35] Now, unfortunately, social media social media has dumped a ton of lies on us and it just gets getting, getting worse and worse. Like I see this all the time with people who've not really done the thing they're talking about and then talking a lot about it, and it's a lot of bs, right? So the primary lie that you see out there in social media is that struggling means you're not.
[00:03:50] Good. You're not bad, you're not smart enough, you're not capable. The truth is that struggling means you are doing it right. In fact, to me, when I'm working with students in in the inner circle, I tell them all the time, are you struggling? Good. That's proof of progress. The best coders aren't geniuses, they're just stubborn.
[00:04:03] Right. And if you're not struggling, that means you're not outside your comfort zone. You're not learning things that you don't know. When you're learning things that you don't know, you are going to struggle and get stuck. So that is proof of progress. The things you get stuck on today are the things that become easy tomorrow. Just look back on your own life and you'll see this. Okay, now let's talk about getting stuck because this is a major reason why people quit.
[00:04:22] So there are broadly five reasons people get stuck. Number one, they get stuck in tutorial hell. And usually what that takes is it's not just tutorial hell, it's that they jump from course to course, right?
[00:04:31] They're learning much more than they're doing. So they're learning a lot or they think they are, they're busy work, but they're not doing very much. That's Number one. Number two, the panic Okay? For example, you have an error and then that leads to frantic Googling and then more confusion because you go down these rabbit holes and then you lose control of your mindset and your psychology. You panic, wrong. You, you know, Your entire biochemistry changes, and then you fall off the wagon. Right. Number three related to number two is that you then start comparing yourself. When your psychology takes a hit, you start to compare yourself. Oh, that 25-year-old prodigy or that 22-year-old prodigy just makes me feel ancient. Like I'll never learn, like I'll never catch up. I will never be as good as they are. They're native to this, all of that stuff, right?
[00:05:07] The number four reason people get stuck is they get very hinged and I think unhinged on perfectionism. I can't build a billion dollar startup in the next weekend because that's what all these smart kids do. It's not, by the way, that's what it looks like and that's what the YouTube clips will make it out to be, but Often, Heck, even Facebook was the product of many years of work in the dorm room before he before made made before Zuck made it a Okay? But everyone talks about it from the social media, um, movie,
[00:05:28] which makes it looks like it was in a weekend.
[00:05:29] It wasn't.
[00:05:30] Okay? The fifth reason why people get stuck is silent suffering. You don't ask for help because hey,
[00:05:35] real devs will figure it out, so I should know this. So you silently suffer and you stew, and it destroys your confidence in yourself. Okay? But here's the And listen carefully. listen carefully. Pretty much every developer you admire has carried all these emotions around inside of them, including me, by the way, for a long time. Okay? Actually, I should Actually, I should say, especially me, I was an older guy in my late thirties trying to carve my way into a very young person's game. And having given up a very successful legal career, which is tremendously risky. Right. Okay, so let's talk about how to fix some of these problems that get you stuck. Okay. Let's go step by step.
[00:06:05] 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 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.
[00:06:21] 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.
[00:06:34] 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
[00:06:55] Okay, so let's talk about how to fix some of these problems that get you stuck. Okay. Let's go step by step.
[00:07:00] Step number Step number one is befriend ambiguity. Embrace it, learn to be okay with it. It's part of your training. Okay. Everybody in the armed forces goes through it. People in the workplace go through it, Embrace ambiguity. ambiguity. what, what do you have to do here when you're stuck? What I recommend you do is write down in terms of the inputs and outputs of your code, okay? And in, in between inputs and outputs comes the expected transformations or operations or steps that your code needs to go through.
[00:07:23] So you have an input, you have a bunch of steps. You know, operations that are done on that input, which transforms it and then produces the expected output. Okay? Always try and write down as clearly as you can, as small and chunked down as you can, what those are. For example, this function expects this input, a type of object or a string or whatever it is, right?
[00:07:38] And then it updates that value, or it updates the values inside that object, which means for it to update it. Those values need to be present, right? If not, if they're not present in the object, you need to handle that situation. Without trying to update it because you're updating nothing, which is not an update.
[00:07:51] Right. And then you return the data. Once you've transformed and updated, you return it in this kind of data structure, the shape of data, then you write a test to ensure this works. Ideally, you write the test first, to be honest, but, um, but you may write it afterwards and you, you test has to then decide, well, with given these inputs.
[00:08:05] These are the outputs I expect. And then check that those outputs present itself, right? That's how you do it. So that's how you solve problems. So testing, writing, small tests are a great way to solve problems because it helps you understand inputs and outputs and where the problem may have a arise. Another reason why this works is you've gotta think of ambiguity as a kind of mental gym. A gym for your problem solving muscles. Now here's a
[00:08:24] huge tip
[00:08:25] huge tip for you.
[00:08:27] Senior
[00:08:28] Senior engineers aren't smarter. They're just more comfortable.
[00:08:31] And the problems they get stuck on are much more advanced than the problems you get stuck on. That's all. They still get stuck though. Okay. Now, I remember my rock button moment a few months after I joined Google. I think I spent over three and a half days on a bug, and other people weren't able to quite figure it out because it's, when you get into more advanced systems, you'll see that.
[00:08:49] The answers aren't always obvious, right? There are so many possible causes for a problem that you kind of gotta use a process of elimination. I hadn't yet learned how to do this quite right, so the bug that I got stuck for really the better part of a week when you think about it, which is a long I. well, the fix ended up being pretty stupid. It was that I'd not reinstalled updated that. I deleted the node modules and hadn't properly reinstalled it, and I hadn't, after doing that, recompiled my code to include those dependencies.
[00:09:11] And so I was getting all these weird errors that I couldn't understand, and I was too impatient to really look at the errors. When I looked at the errors carefully later on, I actually found all the clues there. It's just that because I hadn't controlled my psychology, I panicked and wasn't reading the error problem, but the lesson was valuable, right?
[00:09:23] And the lesson is this, I really understood after getting stuck for three and a half days. How the package.json package.json resolves things, and how to build and compile code in a way in TypeScript that makes sure that you pull in all these things where to look for these bugs. I learned so because I did made no progress on the code.
[00:09:37] I made huge progress on my learning. I. And that's often the dance. Okay? You're progressing in your learning, not in your code. Then you progress in your code because you've learned stuff. Then you get stuck in the next problem, and then you have to progress in the learning before you can progress in the code.
[00:09:49] That's literally how it works. Okay? So the struggle was real. It was painful. It cost me a lot of time. I was embarrassed at work, but it wasn't a waste from that point of view. Um, it was the tuition for my intuition, if you like, right.
[00:09:59] And now that I'm most senior, I see junior devs get snagged on this sort of problem all the time.
[00:10:03] I can spot it a mile off and I can help them, but often I'll let them. I reason through it, and I guide them with questions so that I'm not giving them the answer straight away.
[00:10:10] I'm helping train their brains to analyze the problem.
[00:10:13] They think it's magic when I know the answer. It's really not. It's just that I've seen this pattern a few times before. Right. Okay. Step two, you want to decode error messages like a forensic air crash I just referred to having to look at error messages very carefully. So the next error you see, you're gonna ask yourself, what exactly is this error
[00:10:29] trying to tell me. Now i's trying to tell you a lot. A lot of it's not helpful. I get it. Depending on the kind of error, it may not be helpful. Maybe this wall of text. Okay. I know. Frustrating. Annoying. Especially when you're on flow and you just wanna get moving. I get it, but read it. Take a beat. Even if it makes no sense, read it as patiently as you can Look for clues where it's happening. Okay. There are different languages handle bugs in different ways. The way code is designed will throw bugs in a different sequence, so it's not always clear where the right line of information is. So you kinda have to scan it while you're getting used to the language and the code, you're gonna have to scan it a little bit to see where, where it's at.
[00:10:58] So. Usually somewhere it'll give you a bunch of file parts. Um, and, you know, they list long file parts and there's a, there's a line number somewhere and you have to stop there and say, okay, so this line number is at that line number. If you know how to use debugging tools, this can get faster. You can just attach a debug at the right point and, and inspect the, the state of the app at that point of time.
[00:11:13] Right? But that's kind of advanced stuff. So then the next step is, okay, I think I have a hypothesis. And remember, you're not gonna know straight. It's not always that you're gonna know straight off the bat. So you'll have a hypothesis and you say, okay, well what's the simplest fix? Think for yourself here, right? For a moment. Say, okay, this is the problem. I think I understand where it's coming from. How do I check whether this is the problem? You know, what can you do to replicate this issue consistently at this part of the code? And think for yourself, well, if this is happening, what is it? What is the problem here?
[00:11:35] And how do I fix it? And really understand where the error is coming from. Before you even think of asking ai. Now the reason I say that is AI will find it faster than you most times, and that's okay because it's a machine, right? It, it processes information faster than humans can. But the problem is it also hides a lot of the decision making and a lot of the experiments, if you look at how thinking models work, they're trying different things and then they back out and say, ah, that didn't work. I'm gonna try this. Oh, I'm back out. And that didn't work. But they do it really fast compared to human beings. They're basically doing the same thing
[00:11:58] you and I do
[00:11:59] trial and error, but blisteringly fast. Now the learning is Now the learning is in the trial and error because every option or every hypothesis you discard teaches you a bunch about why you discarded it, why it wasn't correct, and where in what situations it may have been correct until eventually you narrow it down just like a forensic investigator would, down to your usual suspects or one or two people. Okay? It's quite investigative, so it's tediuos. yes, it's tediuos But nothing better than breaking code
[00:12:20] to learn how it works. I'm totally serious.
[00:12:21] Now, here's a pro tip,
[00:12:22] which I learned from a couple Google, right? The best places to learn about a completely new code base is look at the tests and then break some of those tests, okay? Look, the truth is, guys, you. Work when you start a new dev job is reading code that others have written, and this can go on for weeks, okay? Because you just don't know the code base yet. The bigger the code base, chances are, most of you'll work in companies with hundreds of thousands of lines of code.
[00:12:42] It's really hard. You're not expected to know the whole system. Most people don't know the whole system, right? So you want to try looking at tests, practice breaking one of those tests by changing the code, making sure that the code goes Uh, passing to failing the opposite, right? You want passing tests to suddenly start failing because of a change you made in the code.
[00:12:56] Now you start to understand the system by reading all that code. So this is why I think debugging is an incredibly underrated skill for really sophisticated engineers because it teaches you how to reason about the code. Now, do you see the mindset shift? That I'm talking about here, right? We are going from "error messages are terrible" to "error
[00:13:10] How do I, how do I get, How do I produce my own right? They aren't insults. They clues to the application and they help you unlock a code base of secrets, which makes you more Okay. Now Okay. Now for step three, let's try and weaponize that imposter syndrome. Let's use some judo moves in it to make it actually help you.
[00:13:24] So when you feel like a fraud or that you're not good enough, just say this to yourself. I don't know X, Y, Z yet, but here's what I've learned so far, which means I can learn that too, and here's what I think is the right next step that could help me get a little bit closer to the answer. So you're kind of coaching yourself, you're saying, okay.
[00:13:38] I don't get that. They have the answers. That's okay. I. Right, but I know enough, I've learned enough in the past. I've gone from a place of not knowing to knowing and other things in my life and in in coding as well, when you look back at your own journey. So this is just another step in that journey.
[00:13:49] Another brick in that wall. By the way, you can also use this kind of approach too, okay? Where you're trying to interviewer with the interviewer and you wanna show them that you have the confidence to say, Hey, I don't know the answer. I'm not sure, but this is what I would do to figure it out. Why is this powerful? Because it shows people that you don't think you have all the answers. You don't care if you don't have all the answers. All that matters is that you know how to figure it out. You know how to reason about the problem that instantly disarms critics who are sincere. There are some critics who just wanna prove you don't know something that they know, and that makes them superior. Don't try to win or go against those people. It doesn't work. But a good critic, one that's actually interested in your progress and growth will be positively influenced by you willing to talk like this, right?
[00:14:22] It also shows that you have a growth mindset, right? The entire idea of, I don't know this yet, is a growth mindset, and that encourages people to help you because then they see your attitude, which is known to be correlated with eventual success, and that makes. Interviews, think of you positively because they're like, okay, this person is not deterred or discouraged by not knowing something.
[00:14:39] They don't expect to know everything, and they're very open about it, which means I can trust them to figure it out. And they see you taking responsibility for figuring it out. So this is a big difference. It's not enough to just say, Hey, I'm not sure. Can you help me? You have to take responsibility. So, okay, so it's not a vague, Hey, help me please.
[00:14:53] You know, I can't do this.
[00:14:54] That way you, If you do that, you're kind of making it someone else's problem to fix your problem. Instead, you say, this is what I don't know. This is what I do know. This is the gap that I need to try and plug. This is what I'm gonna do to try and plug that gap. This is how I'd approach it. If I'm wrong, I'll do this if I'm right. This is what happens. Now, this actually happened in one of my Google interviews, right? I had multiple. Rounds, I think seven or something. And then they called me back for an extra round of system design because after my first system design interview, they felt that I should be at one level design interview, uh, for the upleveling process. And so it was a more advanced, uh, system design question to do with, I think from memory and moving large amounts of data between systems where the data could potentially exceed the amount of memory available in the system.
[00:15:26] Right. Anyway, I had some theories. And I wasn't a hundred percent sure of the answer. So I told my interviewer, I said, look, I don't know if this will work, but here's what I'm thinking. This is why I'm thinking, and this is what I think is worth exploring as the next step. And look, if I'm wrong, I will probably see this.
[00:15:39] I will probably get this kind of result, and it'll probably because of X, Y, Z, and there may be a far better solution, but at least it's a clue that there is a far better solution that is better suited to what we're trying to achieve here. Then I'd start researching that. Now that I know the constraints of the problem better, but I understand the constraints of the system here, this is where I would start, and then I'd figure it out.
[00:15:54] So I was openly stating that, hey, I'm not entirely sure. I don't really know the answer to your question. I've never encountered it before, but I know how I'd break down the problem and how I'd try to solve that problem. Right. And it worked it ended well. um, what I'm doing there is openly stating that.
[00:16:06] I wanna find things that'll prove my idea wrong, which shows that I'm open to be wrong, and I don't embrace the failure of being wrong as being a bad thing. I embrace it as learning. That is exactly the attitude that'll make all the times you get stuck when learning to code much more bearable because yes, it's not meeting your expectations.
[00:16:19] Oh, I'm gonna finish this course this week. Right? We put these expectations on ourself, but it doesn't matter whether you finish it this week or need, or next week, the point of the course. Is to help you learn. And if getting stuck is part of the learning process, then the course is delivering to you what it's meant to deliver.
[00:16:31] And you are learning, you are growing, you are improving. And that's the point of the entire learning exercise is to improve, right? So the fact that you don't learn as fast as you'd like or you get stuck for longer than you like is irrelevant to the goal of learning.
[00:16:42] Your personal preferences may be to hurry, but that's a personal preference. It's not necessary for your learning. Okay, now step four, the last step is
[00:16:49] learn to build ugly, broken, embarrassing things
[00:16:52] and then keep improving on them. You do not need a hundred portfolio projects. Okay? For God's sake, stop watching tutorials.
[00:16:57] Stop watching TikTok. Stop watching podcasts. Stop watching this podcast and just start building things, Okay. It doesn't matter if it's ugly, no one's expecting you to create the next Airbnb. No one. Just build things from scratch that require research, not blind- following along some tutorial. If you decide to follow along with some e-commerce tutorial or some YouTube clone, you are not learning. You're not learning because most of the learning comes from research of a problem that you're not familiar with. And by the way, gonna happen to you at the at the workplace. You're not gonna be given a tutorial to follow at the workplace. Someone's gonna say, Hey, we need this functionality.
[00:17:28] This is the business use case. These are the constraints. Go out and make it happen. What are you gonna do then? You don't have a tutorial, then what are you gonna do? So start. Practicing, make your learning simulate what the real world will look like. That's what we do in the Inner Circle program, is every piece of learning that we give our students, which is customized to their goal and their starting point, is trying to simulate what a real life situation would be like.
[00:17:46] And yes, our students get stuck all the time, and yes, sometimes they'll reach out for help and sometimes I'll respond them like hiring managers will saying, that's not a great question you've asked. Go back and try again with the question. Get the
[00:17:55] Hi, if you want a no BS 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.
[00:18:02] 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.
[00:18:09] Take a look at the
[00:18:10] 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.
[00:18:22] 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.
[00:18:29] right, right? So don't not being, real world will look like. That's what we do in the Inner Circle program, is every piece of learning that we give our students, which is customized to their goal and their job. Don't just blindly follow along with your tutorials. That's not the job. So build ugly things and keep improving. Keep improving, keep adding to it. Take one project that means something to you, right? You don't need a hundred generic websites or a hundred generic projects. One good project is good enough, just make it mean something to you.
[00:18:52] And then describe meaningfully the problem that you're solving and why you think it solves it well. So look, I know that's a lot, so let me try and break it down for you. Okay? Here's how you would do this. When it comes to picking a good project, pick a project that you care about. Maybe an app that connects with a hobby, something for your mom, something for your grandmom, for work, for anything, a problem, an opportunity, take a problem and convert it to a solution. That's your app idea, right? Even if it's small and tiny and it's, don't worry even no one's gonna pay for it. Don't worry, there's no market for it. That's not the goal.
[00:19:16] You're not building a business, you're building app, right? A project. Then you build it Seriously, I. at first, build it badly. Just embrace the mess, build it as badly as you can or build it as fast or you know, as badly. Don't worry about optimizing and making it pretty. Just build it, make it work.
[00:19:28] Just making it work will teach you a lot of things about what needs to be built next to improve it. 'cause it's a constant process of iteration. I. And it's a fantastic way to learn about testing and simple design patterns because there's no point in learning about design patterns in the abstract when you don't know what real world situation to apply them in. Right? This is a very common problem. Oh, great. This, um, this pattern works really well. The factory pattern, the observer pattern, whatever it is, right? Uh, you know, or SOLID principles in object, object-oriented programming. Great. It's all very abstract until you see it in a real code base, ideally something that you've built because then you're like, oh, now I see why I need to isolate concerns.
[00:19:58] Now I see why I need to separate the responsibilities. Now I see why I need to observe what's happening here. Now I see why I need to create a factory that'll keep producing these kinds of objects with their own data in it. Right? That's why these pattern exists, because you're building it. Your code is messy.
[00:20:09] There's a lot of repeated code. It's hard to maintain, it's hard to read. So you're like, okay, I need to apply a pattern to make it a little bit more readable, a little bit more maintainable, a little bit more testable. Right? And that's also the role test plays, because tests can help you write new code with confidence.
[00:20:23] If you write a good test, then you can do and you will know straight the code and you will know straight away whether it's working. So that's why test driven development write the test. It's basically putting down the specifications for your app. And guys, you don't need to over-engineer this. You don't need to write a Facebook level test.
[00:20:34] Okay? Just write a simple test. Is this button, when it clicks, is it loading this page? Is it fetching this data? If that's what you're doing on the front end, if it's on the backend stuff, okay, when I get this input, do I get this output? Just write those tests and then write the code around that, right? And then ship your ugly because you are. you're going to still work in it, right? Ship it, ship it. Get some feedback from your mom, your colleagues, whatever it is, make a demo video, post it, put it on your LinkedIn. Um, get people to comment on it. And it doesn't matter if they criticize you. Some people will criticize anything. Okay? And hey. Here's what's gonna happen. By the way, this is something I've learned by watching people at global hackathons and then being at hackathons myself, right? Putting a good demo video is a great way to get a sense of a project creator's mindset, how they approach problems, how they approach teamwork, and. Fundamentally, I think the most important thing is how they break down a problem and think about problem.
[00:21:17] 'cause remember, at the end of the day, your job is problem solving, okay? So don't worry about the criticism. Someone's always gonna criticize you. No matter how senior you your code are, gonna judge your code and tell you it's rubbish. There's always somebody who's more experienced than you who will tell you why yours is not good enough.
[00:21:29] And that's probably true because we are growing infinitely, right? It doesn't matter. Whatever level you're at is fine because you're still on the journey. You'll always be on this journey. There's always a next level to unlock. Okay? And hey, the critics, Hey, you know what? Maybe they're right. Maybe they're wrong.
[00:21:41] If they're right, you'll learn something. If they're wrong, you'll feel better about yourself. worth And that's worth something too, right? You can't lose Okay, So that's your goal for this week. My call to action to you is to pick one tiny project that means something to you, and then just research and design it this week, and then strip it down, cut out as much as you can, make it as small as minimal as you can so that you can get started and make progress. Remember, it's not a product, it's just a project. In fact, do this. Please tag me on LinkedIn in your comments and I'll share it. Okay. And I'll take a look at it and I'll review it. If you want, you know, just I'd be happy to cheer you on. Guys, don't over brain this project thing. It's about the learning.
[00:22:14] It's not about proving to the marketplace that you're good at something because that comes later. Okay? That that is not the most important part of the project. It's for you to learn when you're getting ready for interviews. If everybody has a project, you're not gonna stand out anyway. So that's not the primary vehicle for differentiating yourself.
[00:22:27] Okay. Now, I'd also recommend that you take a look at some of my other episodes on this podcast. Um, for some more, frankly, no BS advice, right? I really recommend the one about the seven stages of career change to code because most people think that it's just about the coding. It's not. That's just stage two and stage three.
[00:22:40] There's another one that I strongly recommend, which is actually more. Pop popular episodes. There's one about the only three reasons why anyone fails at anything. By the way, this is the stuff I teach in the Inner Circle program a while to apply, but Just take a look at that episode and see there are only three reasons why people fail at anything, including code, right?
[00:22:55] Um, and it's, it comes down to the plan, the execution of the plan and the expectations you have. Okay? So. Remember guys, when it comes to learning, it's hard. Turn your frustration into fuel. Of course, it is frustrating, right? That's what growth is. That's the form that learning takes in the gym. Growth is in the form of pain and tiredness. Same thing kind of goes for code two or learning any new skill, but it's more emotional pain and tiredness than physical. Okay? Now I wanna leave you with one final thought. The difference between coders that succeed and coders that fail.
[00:23:20] It's not intellect. It's not math, it's not geography. It's not whose parents have what assets or work what job. It's not any of that. The only difference between coders that succeed and coders that fail is that the successful ones succeeded because they kept going past the obstacles, past the problems, the struggles, the failures. Even though they wanted to quit, they just kept moving forward. One brick or top of the other on the, and the wall gets built right. As Thomas Edison weakness. our greatest weakness lies in giving up.
[00:23:48] The most certain way to succeed is to always try just one more time. Now. That's super powerful. Try just one more time. Okay. Look, I hope you guys ready to hold this on board.
[00:23:57] Just subscribe, you know you gotta do it.
