.png)
Develop Yourself
To change careers and land your first job as a Software Engineer, you need more than just great software development skills - you need to develop yourself.
Welcome to the podcast that helps you develop your skills, your habits, your network and more, all in hopes of becoming a thriving Software Engineer.
Develop Yourself
#224 - How Jeremy Went From Tutorial Hell to Front End Developer at Apple
Send a text and I may answer it on next episode (I cannot reply from this service 😢)
Jeremy spoke with a couple mentees at Parsity which led to a conversation where I learned about his unusual (and long) journey into software.
If you're a career changer and you're dealing with impostor syndrome or tutorial hell and need some practical advice on breaking into tech, you're going to get a lot out of this episode.
Connect with Jeremy here: https://www.linkedin.com/in/jrobinparker/
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, all right. Today, on the Develop Yourself Podcast, I'm joined by Jeremy, a front-end software engineer at Apple. He's worked with JavaScript, typescript, swift, php, react and my personal favorite or maybe my personal, not-so-favorite Ember, and he's gone from navigating brutal PR feedback, adapting new frameworks, pushing through to the deep end of his career journey, and he's built a mindset and technical skills that I think are needed to thrive in a high-stakes environment. He's also spoke with a few people from Parsity, which led to us speaking and thinking. This would be a great chance for him to share what he's learned on his journey, diving into things like code reviews, mentorship, learning, new tech and the reality of growing as a self-taught engineer. Welcome to the show, jeremy.
Speaker 1:Hey, thanks, ryan, it's awesome to be here, man, and you've got a heck of a career story. You currently work at Apple as a front-end engineer.
Speaker 2:Yeah, that heck of a career story. You currently work at app. Where is it for an engineer? Yeah, that's right. That's right, yeah, um, so I'm uh, I'm a uh, there's sort of multiple ways to enter, uh, some of these, uh, you know, fang companies. Um, I am what's uh referred to as a contractor, so I have a specific skill that being ember. Not a lot of people know ember nowadays. It was pretty big, you know, 10 or 15 years ago, that's right, it's huge said familiar with Um.
Speaker 2:so, yeah, I was brought on because, um, I have this uh skillset, um, and they've, yeah, they've, they've kept me on for uh, well past my uh, my contract. I'm sort of uh, you know, yearly at this point.
Speaker 1:That's awesome man, and so a lot of people hearing this they're like whoa, that's nuts. And they're probably thinking okay, he probably has a computer science degree, went the traditional route, he's at a big company like Apple. Can you share with us a little bit about, like, how that happened? 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, who's also an ex-lawyer and learned to code at the age of 37. 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. How'd you go from I want to code to I'm coding to I'm at Apple?
Speaker 2:Yeah, sure, try to keep it. You know I won't get too far in the weeds. You know I've always been interested in programming and you know it's something that I've always kind of been attuned to, whether it's, you know, kind of just tweaking the settings of my PC to, you know, trying out other sort of OSs and things like that. So I'd always been attuned to it. But the moment I would see code or just conceptually think about software, I would just think, eh, that's for the smart people, that's not something I can do. And I remember a friend of mine a long time ago. This was when Rails was like the big thing. He said, hey, you should give Rails a try, I think you'd really really enjoy it.
Speaker 2:So I took a book out. I checked out a book and I just looked at the first page and was like nope, can't do this and just put it away. I had such a deep kind of negative self-esteem about just having issues growing up with things like math and logic. I had just thought like you know what these are, things that are just not meant for someone like myself, and so it took a long time to really to get over that. I was sort of. But you know I would start to stop over the years. Like you know what I think, I want to give this another try. Let's check out JavaScript, and I was at such a point where I couldn't, conceptually grasp things like variables.
Speaker 2:Oh, it's a variable, like yeah, I just really struggled at a really hard time with it because the struggles that I had with math and things like that growing up just kind of made me default to think that I can't understand this even at the most basic level. And part of that was also because, for me, I was finding things like books were not taking me or getting me to a point where I really understood how coding could result in something like an app. You know, you start with Hello World. I'm like okay, well, what's the next?
Speaker 1:step, Totally useless yeah.
Speaker 2:Right, yeah, okay, here's how you loop through an array of strings. Okay, cool, but I still want to be able to do something that, um, you know, makes sense to me. And when it finally clicked was, um, I was at the time, uh, and this, this whole journey was while I was working at the same company. Um, I was working in the learning and development group and I was one in charge of putting the other courses and things like that, the things that no one really wanted to do, but I had to do it.
Speaker 2:I was looking at the, there was this authoring tool and within the settings, there were ways that you could kind of add a layer of interactivity with JavaScript. Oh, I know, I've heard of that. Oh, I can kind of make it look cool with CSS. Cool, let me look into that. And I remember I didn't really know, uh, still a whole lot about it. So I was like, hmm, maybe I can do something with bootstrap. I had heard about bootstrap, oh yeah, and I was like, okay, wait a second, this is not everybody's favorite Let me take a step back here.
Speaker 2:Let me take a step back, um, but I think what it was for me to finally make things click and that's what kind of um put me on the path of, you know, being more oriented towards the front end is that I needed, like the visual and the kind of the response of of of clicking and seeing some kind of feedback. Totally, yeah, it's funny at that time, uh, I had just gotten sort of a a bad review at work. It was not really deserved.
Speaker 1:Oh no.
Speaker 2:Okay, yeah. But I was like, okay, I got to change my life, like I got to get out of this. I've got my daughter coming soon. She's going to be born next couple months. You know, living in Southern California is not exactly cheap.
Speaker 1:It's not the cheapest place, yeah.
Speaker 2:So I got to figure something out and I thought, okay, I kind of made JavaScript make a little bit more sense to me. Let me see how far I can take this. So I started looking into, I started taking some tutorials and things were clicking, although at the time I took a Rails tutorial, so Rails was making sense, but then JavaScript wasn't making sense it was this weird thing yeah.
Speaker 2:I know it's strange, right, when you're still figuring things out, all sorts of things can trip you up, right. Like you know, ruby and Python look very sort of clean syntactically, and then I'd look at JavaScript and be like, oh, this looks like a mess, I can't figure this out. So I kind of got into this weird funk. But I knew that this was something that was really making sense to me and it kind of lit that fire within that I didn't have, because I was just floating through life, not really sure what I wanted to do. So I thought, all right, cool, let me see what's out there, let's check out. You know, maybe I'll do a bootcamp. Oh, bootcamps are like $20,000.
Speaker 2:Uh all right I've been. I've got a ton of student debt. Can't do that. Well, I know this is what I want to do, so I'm just gonna have to figure it out on my own.
Speaker 1:Yeah.
Speaker 2:Um, and you know, there's a lot of people out there and they're still out there, which is pretty crazy. Uh, you know however long, you know when you're buying your weeks.
Speaker 1:Yeah, three months.
Speaker 2:Yeah, yeah, exactly. Do our bootcamp and you can get it in 12 weeks. Um, son, I thought, okay, that's probably not. I had a feeling that that wasn't true, but I thought, okay, it could be a year. Um, well, with you know doing a you know full-time job. My wife's a flight attendant, so when she's away I'm taking care of my daughter.
Speaker 2:Then we had COVID and all sorts of stuff that just kind of threw a wrench into everything. So ultimately, from that first PR that I put up, it took about four years to get my first real full-time job. I was doing a lot of other projects at my previous job job and you know everything from like share, microsoft, sharepoint, like putting little jquery things in there and building some apps with python and and react as well, sort of like data sciencey stuff and automation, but it wasn't a full-time like 100 software developer gig. So, okay, it, yes, for me to like really fully completely break in took about four years. Wow, um, and that was again fuzz, you know, trying to juggle like um, the family and you know kovu came along, my part, my job, but also I can. I didn't think about even getting in touch with anyone over something like linkedin. I I just I would log into linkedin and be like I don't have anything useful to say and you know, everyone's gonna think I'm stupid.
Speaker 1:You know, everybody thinks that yeah, for sure, we all go through that.
Speaker 2:So what am I going to do? Just get in touch with someone and say, hey, like.
Speaker 1:Hey, how are you doing? Do you want to have a coffee chat? It's all awkward, you know. Yeah.
Speaker 2:Right, but, like the, that's what everyone does, because everyone knows that that's the effective way, especially if you're trying to learn on your own or if you're in sort of a program. And you know, I didn't have something like a mentor or just anybody. I didn't know anyone who was in the industry. Um, I was just totally by myself.
Speaker 1:You're just figuring out real time through trial and error. Yeah.
Speaker 2:Exactly, yeah. So when you're, when you're on your own, like you know, you don't know what you don't know, right?
Speaker 1:Oh, yeah, and for me.
Speaker 1:I just I didn't know anything, so it was just Really cool, though, that you kept at it, because one I mean four years is a long time, but not really in my opinion. I mean, people go to school for four years and we think that's completely normal, but for some reason, when people learn to code and they're like I didn't get a job in six months and they think it's a failure, I'm like you know it could take a while. We now make a commitment at Parsity. We say this is going to be about a year. You know we're going that, but it's a lot to ask of people. I mean, we talk about 15, 20 hours per week of work, and you actually met some students from Parsifix being on LinkedIn, which is something we highly encourage.
Speaker 1:We're like hey, be on LinkedIn. We know that, as cliche as it sounds, learning in public is effective. It just it works. I mean, I think that's how they came into your ecosystem, right.
Speaker 2:Yeah, I just I think that's how they came into your like ecosystem, right? Yeah, I just I think it was. It was Jacob. I saw his like yeah, maybe it was his post shout out and I don't remember. Yeah, right, he's, he's, he's a cool dude, um, but I don't remember how. I saw it just kind of randomly popped up and I didn't even know this was like. This was my first time. Over the past couple months I've been trying to get more active on LinkedIn and I saw him just kind of posting on his progress. That's awesome. I wish I did that. This is, this is great. Yeah, and um, I that I thought I want to be able to connect with with this, with him and kind of you know, talk about what I went through and kind of encourage him along the way and see if I can give, uh, kind of you know, know the lessons that I've learned.
Speaker 1:What is some advice for those people to avoid some of the mistakes you made?
Speaker 2:I mean, the biggest one was the fact that I kind of would put it into two kind of buckets. And the first one is something that we just talked about, which is talking to people getting out there, networking, asking questions, because for me, I just you know, networking is something I don't like. Um, I don't like it's changing now I'm seeing the value in it, but, just you know, I think back on being the kid in school, like looking for an open seat at the, you know, the lunch table.
Speaker 2:you know or like you know, like company events, and I get there and everybody's already talking. You're just standing there like, like, how do I, what do I do? Yeah, how do I get in. And that just every time, even though LinkedIn, like, is not like that, I still perceived it as that way For sure. So, um, yeah, I, I would say, yeah, networking, talking to people asking questions is just so big. Because, um, I, I, that would have taught me.
Speaker 2:Number one, it would have taught me some better sort of you know the best practices, right, um, because all I knew was just coming from tutorials and building my own stuff. So wasn't necessarily the right way, probably not, it worked, but was it the right way and probably not? Um, and then, number two, I was in this situation where I'm always I'd look at a job description and see like, okay, this requires React and Mongo and you know whatever. So I go, okay, cool, let me go learn those things. And I'd learn them. And I'd take a look at the next job description and I would say this needs experience in style components. I'm like, okay, go learn that. And then I'm just always chasing things, never feeling like I know enough that learning and so if yeah.
Speaker 2:And so if I, if I had talked to someone, I would have known. Hey, uh, I'm already in an okay situation. I already know enough to be able to do this. But instead I just thought you had to know all the things and be like this master. And now you know, I'm like you know if I'm building a new component or something in the front end. And now you know, I'm like you know, if I'm building a new component or something in the front end, I'm, you know, like, okay, this particular repo that we use is, for example, is using Tailwind, okay.
Speaker 2:And then my mind blags I'm like, okay, wait a second, I remember when I, like you know, when I first started, I have to memorize Tailwind. But when I, like you know, when I first started, I have to memorize tailwind. But then, actually, when you're in the thick of it for a couple of years, there's no way to know everything. So you're just always in the, you're always in the documentation, like you know. So that's something I wish I knew too. Was that like the this, this concept that you have to know all the everything is just not, it's not true, like there's no way to remember everything.
Speaker 1:A hundred percent. And then it's interesting too that I meet a lot of people that are really new and they're like what do you teach me, Cause I need to know, like, this particular skill. And I'm like and it's hard to explain to them Like, yes, you need to learn some skill. Like it's not probably a great idea to learn COBOL?
Speaker 2:There's a right there is a wrong answer, but it's also like we don't have to learn, like this particular version of react or something like that.
Speaker 1:It's more important that you're going to be a software engineer, not a react engineer. Which leads me to. You spoke about a framework which is near and dear to my heart, because I went to a startup, uh seven years ago, something like that, and I was using angular js at the time and then I started learning a little bit of react and then this place was using ember and it was like my brain broke. I went there and like I I felt like I didn't know how to code. I'm like, oh my god, I'm, I'm a fraud. What was your experience like with ember?
Speaker 2:exactly the same okay, um, that was, uh, coming from react, self-talk coming from react. It was like it was almost as if it was its own language. It wasn't JavaScript, it was something completely different, because it takes a lot from. It was developed, I think, as a framework kind of off of something Apple did a long time ago, so it's kind of rooted in more of kind of the patterns you would see in something like swift or another programming language, as opposed to something like react, where it's designed to kind of be like just get up and start building and, you know, quickly put stuff like you can just whip something together like instantly super quick yeah yeah, it's super quick, whereas ember it's.
Speaker 2:Not only is it really opinionated, but it's a framework, sort of like how nextjs is where it's got routing, it's got state management, it has all that built in. So, um, it's, it's more than just, for example, going from react to next. It's. You got to know the whole thing. Yeah, and um, the the coming from react, it just. Oh, it was really hard because there's not a lot in terms of documentation or tutorials like the things that I took for granted. It's, and that's where I that was like the first step of really learning the value of I mean, I think you posted about this recently actually um, being able to go into a code base, look at other people's work and kind of build something off of folks that are already experiencing knowledgeable. Yeah, and that was that that helped me really learn it. Like, okay, I have to do this thing. Let me see how other people have done it, how the people at this team do it within this framework.
Speaker 1:Pattern recognition. Yeah, it is incredibly difficult. What did what would? What was like your big takeaway from this experience? Because I know what mine was like. I felt like ultimately I think I had a much lowered or I didn't have a grasp on javascript the way I thought I did, and that's kind of what amber showed me. And then, once I kind of went back to fundamentals and really got what I consider much better at JavaScript, things started to gradually make more sense. I don't know what your experience was with that or if it was the same.
Speaker 2:Yeah, absolutely yeah, I would definitely think so, ember. When I first started it was just so difficult because it's class-based, sort of like the old school react, and I think angular is as well. So you have to make sure that you know when you're getting, let's say, you need to grab a piece of the state or something, um with uh, which react. Now with hooks you can just kind of call the name of the variable. But you know, with with ember, you have to this dot get and then you have to pass in the name of the the variable. Um, and just that alone was a hurdle for me. It was sort of like your point, like it felt like I don't know JavaScript.
Speaker 1:And you touched on something too you switched frameworks a few times, just like I have, and I think people hear that and say well, how do you do that? How do you go from like React to Ember, then from Ember to Swift, and then how does that work out? Won't people only hire you for the same framework throughout your career? Yeah, can you just briefly explain what it's like being a professional software developer and going to a company and they say here, here's the new thing you're using. How do you upskill in that?
Speaker 2:Oh yeah, you know a lot of things. We touched upon, of course, things like tutorials, and fortunately we have, you know, ai and LLms are trained on a wealth of data. Um, but one thing I've learned over the years and, um, it's not, unfortunately it. For me it doesn't feel like the the easy solution that I want to give, but a lot of this comes with time and persistence and struggle and just like continually just trying to push ahead until it makes sense, and then, once things do make sense, things click and just everything changes and you're off to the races. I can speak to that because it took me a really long time to break into the industry. But if I had given up over the years, I would be back at my meaningless job that I was at before.
Speaker 1:Can't cheat time in the saddle. I heard somebody say that. I'm like, yeah, you're right, it's as much as we want to shortcut. It's like also, when you think about you, know we're. I might not be young, but I'm not. I don't feel old yet and I also know that I have decades left in this career and I started a decade ago and I still, like I have a ton to learn and a ton that I don't know and things that are changing. So I think we're I think generally all of us, maybe Americans or the culture winner a little too obsessed with getting this really quick, hit Like we want, we want to do everything really quickly, but then like, well then, what, what?
Speaker 2:happens after you just know everything.
Speaker 1:What do you just show out at 30 and just like well, now I know everything, there's nothing left to learn. I know react and javascript and all these languages and there's not much else. So, yeah, I I feel what you're saying, like there's no substitute for just time. Um, I want to switch gears and talk about an interesting story that we talked about on the phone. Uh, a peer review, the peer review from hell, which I'm intimately familiar with.
Speaker 1:If you're a software engineer or maybe you're not and you're listening to this what is a peer review? So you write code as a software engineer and for that code can be integrated into production, which means it goes out for people to actually use on the web or whatever or some application. Before it goes out there for people to use, it'll be reviewed, kind of like a book, almost like an editor will look at it. Another software engineer will look at it, go through it and say I would do this wrong. Why'd you do this? Sometimes these can be really beneficial. You can learn a lot, and sometimes they can be really, really emotional and like deflating, and I've had some really harsh ones, and it sounds like you have too. I'm curious what was your peer review? Hell story?
Speaker 2:I went through one the other day. So it's still, the wounds are still fresh. But uh, you know those, those, those rough prs reviews. You know it doesn't matter how long you've been FPR reviews, you know it doesn't matter how long you've been there, you'll still sometimes get taken to task, no matter what. Yeah, and they can be rough. But yeah, you know that one that I mentioned before.
Speaker 2:It was kind of one of my first big refactors. It actually turned out to be a pretty rewarding experience. It actually turned out to be a pretty rewarding experience. But the, the refactor, by the way, since you know we're kind of talking about the, the pr concept, the peer review process, refactoring some old code just means modernizing it, cleaning it up, making it better. Um, and this was not only modernizing a very big feature that I'd never used before. I had also found that it was incredibly slow, so I had to kind of optimize some things as well. That was so this was. I was also new to Ember. So new to Ember, new to this company, new to this particular repo and doing a big refactory.
Speaker 2:Doing a big refactory. Doing a big refactory yeah, nice, you know um and um, yeah, my uh. It was kind of taking some other code from a different repo and sticking it into this, this one, um, and I thought, okay, cool, just know, it'll just be an easy copy paste thing. Ah no.
Speaker 1:Never that easy.
Speaker 2:Yeah, you know, I think the amount of comments that I had in that PR was just, yeah, it was the record books of things, of comments. It was a lot of comments to so many things that changed and um, it was tough. But you know, I remember uh sending a slack message to, uh, my co-worker, like once I finally got it merged and you finally approved it, I sent him an image of um, one of the game over screens from street fighter 2, like ken, just like covered in blood yeah, I just don't feel it right now yeah, I know that
Speaker 2:um, but you know it was um. It really made me question quite a lot of things, like am I cut out for this? Like if this is how all these prs are going to be for these these features? Man, I don't know if I can do this, and with with each kind of pr, it was a lot of those like just, it was like running through the gauntlet, like every time like, okay, in what way I'm just, I'm just gonna push this up and in what way I'm just it kind of be just like destroyed. This time, um, and I started implementing this person's feedback and at first I was like it's fine, it doesn't matter why you have to be so picky.
Speaker 2:Um, but I started implementing it and I started thinking a little bit more before I would push up a peer. Okay, what are my coworkers going to say when I push this up? Okay, Well, this thing right here, this could return undefined. So maybe I could put a guard in here.
Speaker 2:An early return you know, make sure this is safe and doesn't throw a bug. A guard in here at an early return, you know, make sure this is safe and doesn't throw a bug. Um, here's a good situation where, instead of doing uh, you know I could do the uh, you know, nullish, coalescing operator or optional option chaining, or you know these things that are more modern, um that clean things up. Or, for example, I was using a lot of um, you know, when I'm doing a fetch request, I was doing a lot of. You know the older way of doing it.
Speaker 2:So you know, then catch dot, then dot instead of async await.
Speaker 1:Okay.
Speaker 2:And so I would think before I'm doing this okay, how can I? At first it was how can I just get the minimal amount of comment?
Speaker 1:Oh yeah, just get the minimal amount of comment, oh yeah and then that changed.
Speaker 2:And then that changed to okay, how would they, how would my, my, the, the senior devs on my team think about this? And then it became just natural like, okay, this is how I should do this. And eventually those pr reviews became easier and easier, till eventually I would get a looks good and an approval like, or just a couple of nits and you know, an approval. I remember the first one I got that didn't have any comments from him. I was just like I have officially proven myself, like I can do this so good.
Speaker 2:And at the time it was, it was miserable, um, and at the time I just it was not something that I enjoyed, but it's hard to say. But you know, I'm really thankful for him and at the time I certainly wasn't, but now I'm like I'm really thankful for being able to uh have someone that was uh really demanded excellence, I guess.
Speaker 1:Yeah, Um, Because you know.
Speaker 2:I'd like to, I like to just get things done, like, all right, let's merge this and get things done.
Speaker 1:Me too yeah.
Speaker 2:There's a balance that you have to take of, you know, speed but also quality, and I was going too far into the speed and not really having the quality.
Speaker 1:Like we're. I feel like we're the same person. I'm living a lot of this right now. I went from engineering manager and now I'm a senior engineer at a startup, working with a really smart guy and probably, if not the best software engineer I've ever worked with at least one of them. He's got to be one of them and he's just been ripping my stuff apart. I'm moving really fast, he moves fast and he's just better than me, just to be completely honest. And the first PR I got I was like oh my, I'm getting fired. This is it. I'm getting fired from this place. There's no way.
Speaker 1:And since then, yeah, I've done the same process you've gone through of like, okay, how can I anticipate? What am I doing? How is he writing his code? How's he doing his PRs?
Speaker 1:Oh, I need to be a little really, really interesting and powerful. I mean, it's the best way to grow as an engineer, and I always know this because I've now lived this enough that I'm like, every time where I'm feeling really uncomfortable, this is like a season that I'm gonna be growing a lot, because I know when I'm chilling out the last job, when I was kind of chilling, I'm like I knew my skills were gradually decaying a little bit. That's the price you pay for comfort. Paying a little bit, that's the price you pay for comfort, especially as a software engineer. Those places where you feel like right on the edge is where you grow the most, because I remember spending nine months at one startup and just it catapulted my career, and I feel like the same thing is likely happening now. Sounds like the same thing happened for you, right, like it just increases your code quality, your software engineering trajectory, by a lot.
Speaker 2:It does. Yeah, yeah, yeah, I was kind of going through that recently with Swift. There's this framework within Swift called Composable Architecture, which is sort of like Redux for Swift. Okay, it's really complicated and I was just struggling with it. And you get to this point where you're struggling in this one particular framework. Then you go back to the one that you usually do JavaScript and you forget a lot and you're like wait, I framework. Then you go back to the one that you usually do JavaScript and you forget a lot and you're like wait, I already knew how to do all this. And then you go back to the other one thinking that you remember it.
Speaker 2:But you learned the new one, and then you forget it all again. So you're in this spot where you don't remember anything. But At the end of this particular PR that I was doing for this iOS app, I got into that eureka moment, that clicking moment, yeah, and where I was learning how to search for things that like framing my questions correctly not just to research the right solution online, but to ask my coworkers and asking more questions and that led me to finally understand things in a way that made more sense to me. Um, and that that was one of the things that I did want to mention too. I think we were talking about, um, you know when you're switching between frameworks and you're switching between, uh, languages and stuff. Um, you know, I mentioned things.
Speaker 2:I mentioned that you know time and persistence is really important, but being able to ask questions is just critical and being comfortable with doing it because nobody knows when you first start I mean, I still deal with it the feeling that you just don't know, like, oh, everyone's going to find out that I'm not smart enough. But you have to be able. I think one of the stoic philosophers, like Epictetus, said you have to be able. I think one of the Stoic philosophers, like Epictetus said, like you have to be content with being perceived as the one who doesn't know the fool. Yeah, because that's the only way to get better. You have to be able to be comfortable in your lack of knowledge to gain knowledge.
Speaker 1:True, yeah.
Speaker 2:Yeah, you have to, because there are some people who refuse to ask questions and I've seen people like crash and burn because they refuse to ask questions, they refuse to keep people updated on their work, and it just everything goes south. And this is something that I'm doing with this, you know, as I'm learning some more about this particularly tough framework asking a lot of questions, keeping people up to date, like, okay, I know this is taking a little bit while a little bit longer. Here's where I am. How can you help?
Speaker 1:Yeah, because the opposite of that can get you fired.
Speaker 2:And it's leading me to the answers that I need to make sense of some of those more complicated concepts.
Speaker 1:Yeah, I'm really glad you shared that and you're comfortable sharing that, because too many people think I think they look at you especially. They think Apple self-taught doing this for a while and they think he's got it all figured out. I don't know, I don't know what they think about me, even think, oh, he's just a dummy. But I enjoy when I hear people admit that too, like even when I work with the head of engineering at my place, the guy I respect a ton and he's open about, yeah, I don't really get how this works, but let's figure it out together and then do them pair programming and then seeing like okay, you're a human too and we're both kind of figuring this out. You have some more knowledge than I have in some areas and I might know a little bit in some other areas than you do, but that's really good advice and it's also the toughest advice and I've seen so many software engineers not do this.
Speaker 1:As a manager, I remember one of the biggest issues I ever had was not code quality. It wasn't like people just writing poor code, it was like that's fixable. People, you know, just writing poor code. It was like that's fixable. The hardest thing to solve was people not being forthcoming or truthful about what they didn't know and about where they were as far as their work was concerned, and that was a much more difficult problem than I had anticipated. I thought I was going to be just working on code reviews and making sure our code quality is up to date. Like you can teach that stuff, it's hard to tell a person, hey, if you don't know what was just talked about in this meeting, then you probably need to say something sort out like weeks or months off track, because that can really bite you.
Speaker 2:Oh yeah, for sure.
Speaker 1:There's always one question I like to ask people is if you were starting off right now learning how to code, what would you be doing?
Speaker 2:So one thing I think about is a lot about what I did was you know, people get into tutorial hell a lot, right, where you do one after the other and you're just doing the same thing one after the other. What I did that was pretty helpful for me was I took a tutorial and then I would do it and then I would do it again, but I would kind of take the core concepts of it and build something totally different, like I learned. For example, I took a React weather app and it was pretty simple. You know, fetch it from a weather API, get the data back. But it had some helpful concepts in there about like async, await and just sort of like general app architecture, front-end architecture.
Speaker 2:I mean, I took the concepts from that and then used that to then build this app that will search three different Japanese-English dictionaries. It'll send out a request and it doesn't have an API, so it just sends back raw HTML if you do a regular fetch request. So from there I was like, okay, how do I get these words out? I learned about a scraping library in javascript called cheerio yeah, yeah yeah, so that was a cool one, um.
Speaker 2:And then also I did a tutorial on um, a um just how to build a social media site with on the mern sack did that. And then I then built a use the concepts from that to build a video-based training platform for my dad's martial arts school so he could post a video, he could then create a playlist from that and a course he could see what people did. And all that was just the core concepts that I got from those tutorials. So I think if you're just starting off, don't just stick with the tutorial. So I think if you're just starting off, don't just stick with the tutorial. Take what you learn from the tutorial and build something unique that solves some real world, something real, whether that's an issue like at work or in your own life or something that you just haven't seen done Because those core concepts can take you far.
Speaker 1:It's a good one. Yeah, having that emotional attachment too is so important, because otherwise you're just building something by watching and typing and it's not as fun, doesn't keep you motivated to come back after a long day of work or your kids or crying at night, or you have to make breakfast in the morning and stuff. You need that emotional motivation. I think, to keep going.
Speaker 2:Yeah, some of that stuff. Then, once I built my own stuff like okay, I have the confidence to build some more things, not from following a tutorial Then I built some stuff at work using like Python and a bunch of different data science libraries. And Python, like apply it to you, the ability to apply it to your own life and use your way of learning, I think will really kind of take you kind of speed things up for you and take you far. Cause if you're just kind of stuck in one rigid way, you're going to be stuck there, whether that's just doing the same tutorials over and over again or just learning in a way that doesn't work for you.
Speaker 1:Yeah, a hundred percent, man. That that's funny because a lot of what you said is what I've done too, and it's just cool to hear that a lot of these themes end up coming through when I speak to people that learned, like, in a non-traditional way. They kind of learned on their own, and a lot of us have the same patterns we've used, which tells me something. It means that these patterns are probably useful for other people to know and to use on their own too, if they're struggling or trying to figure out okay, well, how do I get out of this? How do I stop like just watching somebody type, what do I do? And the simple answer is the hard answer, which is build something on your own that you actually care about and try to fill in the gaps as you're going along.
Speaker 2:Yeah, definitely Like that hard thing that you mentioned. Yeah, like there's this one band that I like and they have a song and the lyric goes sometimes the only the, the only path to take is the hardest one to walk, and like there's there's a lot of wisdom in that, because your growth really comes from struggle. I think and I think I don't remember I it was thomas that I was talking to you he mentioned, uh, someone who did, who talked about the warrior mindset, and I think that's just so important to have like this persistence and ability to just continue to, to push on, no matter what the circumstances.
Speaker 1:Yeah, a hundred percent. Yeah, the name is Aaron Cordova. By the way, he was also a guest here.
Speaker 2:Oh yeah, that's right, yeah, and if you want to look him up, amazing.
Speaker 1:Yeah, I really appreciate you taking out time to do this.
Speaker 2:Yeah, anytime I'd love to. This was awesome.
Speaker 1:Awesome. 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.
