Jan. 31, 2022

Struggling As A Self-taught Developer (Advice From 3 Successful Self-taught Developers)


I brought back 3 successful self-taught developers to share tons of advice for you. This episode is for you if you're struggling as a self-taught developer. Then, once you're done with this episode, if you haven't already, listen to the previous episode with these same 3 developers.

Previous episode:
https://www.buzzsprout.com/948958/7246522

Jeremy Wall (guest):
Linkedin - https://www.linkedin.com/in/jeremywall
Twitter - https://twitter.com/zaphar

Whitley Bone (guest):
Linkedin - https://www.linkedin.com/in/whitleybone
Instagram - https://www.instagram.com/whitley.png
Twitter - https://twitter.com/whitleybone

Aaron Billings (guest):
Linkedin - https://www.linkedin.com/in/aaron-billings-9b429610a
Twitter - https://twitter.com/abdevelops

---------------------------------------------------

🤝  Join our junior friendly developer community:
https://discord.gg/H69QqZ8MVJ

🔥  Want more personalized help from me? Here are the paid mentorship and review services I offer:
https://calendly.com/donthedeveloper

❤️  If you find my content helpful, please consider supporting me by becoming a channel member and get access to additional perks. Every little contribution helps and is actually used to pay my bills.
https://www.patreon.com/donthedeveloper

---------------------------------------------------

Disclosure: Some of the links below are affiliate links. This means that, at zero cost to you, I will earn an affiliate commission if you click through the link and finalize a purchase.

📚  Web development books and other products I recommend:
https://www.amazon.com/shop/donthedeveloper

Transcript
Don Hansen:

Welcome back to another podcast episode where we help aspiring developers get jobs and junior developers grow. We did, you might recognize some of this group, but Jeremy Whitley and Aaron joined me in a previous video, uh, video get a lot of use a lot more than I was expecting, but essentially we kind of just all shared our stories and all three of these wonderful people shared kind of their ups and downs with a self-taught journey, which we all know can be pretty rough out there. So I brought them back on. I want to start empowering self-taught developers to be more successful, more confident. So we're gonna dive into giving as much advice as we can for self-taught developers. So like usual, we will go ahead and start with our intros. Jeremy, would you like to introduce yourself?

Jeremy Wall:

Sure. Um, I'm Jeremy, uh, last name's wall. Um, I've done a, been doing this for a little while. Um, I'm currently a VP of engineering at go health, um, where I try to help all the engineers who report in some way to me be better at what they're doing. So, um, and I am of course, a self-taught engineer know schooling of any kind, just completely on my own.

Don Hansen:

I just got a recent comment. Someone said you have like a really, really bizarre trajectory on your LinkedIn of like how you became a software engineer. Would you, would you say it is bizarre? What makes it bizarre? A bizarre,

Jeremy Wall:

uh, I mean, I think, um, one of the items on my work history in LinkedIn is janitor. Uh, so like you could say I'm, I went from janitor to, to software near, um, it's, uh, I mean, there's some weird, like jumps. and there, like, that seemed really high. Like, um, I was just a contractor for a little while and in a small little town just doing like nobody, there was barely any kind of an software engineering industry there. And then, uh, I got a, an invite or an offer to come work in Chicago that came out by Google. So suddenly I went from like little, nobody in a small town doing one off software engineering jobs as a contractor to Google employee. That's a pretty large jump career wise. So cool. Um, so that, that's kind of why it's, I think looks weird, um, is like you, you see this, nothing, nothing, nothing suddenly Google engineer and that's weird. It's not what you see usually.

Don Hansen:

Yeah. That's um, That's amazing. And I think, um, but I think it showed with how you kind of told your story and your mindset that you were trying to encourage people to have. Um, I think people kind of got why you got hired at Google, so it's pretty cool. How about you Whitley?

Whitley Bone:

Um, hi, I'm Whitley, uh, super excited to do this again. It was such a fun time last year and um, now I get to do it again, but, uh, I'm Whitley. I am, I guess, um, I am two years into my career change from teacher to web developer, but, um, I was a middle school teacher and coach for eight years and, um, long story short decided I didn't wanna do that anymore. So I, uh, taught myself to code, um, via, um, bootcamp. And now we're here. I'm, uh, almost at a year and a half at a job that I really, really love. It's great. Now, I, I love getting the opportunity to encourage other people to do the same if that's what they want.

Don Hansen:

Cool. I love it. How about you, Aaron?

Aaron Billings:

Uh, yeah, so my name is Aaron billings. Um, currently work at, uh, Warner media slash CNN. Um, I do all the ads on CNN currently and, uh, some of the other core features. So, uh, I've been there for about, uh, six, seven months loving it. Um, we are hiring, so, yeah. And, uh, yeah, so we've been doing that for about six, seven months, uh, before that, uh, started my journey as a self-taught slash boot camp developer, um, with Treehouse, um, and, uh, yeah, just now I help other developers, uh, mentor some people, um, inside and outside my company and, um, happy to help anybody, uh, on their, uh, self-learning journey. It's a, it's a wonderful, uh, wonderful career.

Don Hansen:

It is. It's a lot of fun. Um, I, I never hear anyone regret going into becoming a software engineer or a web developer and it can expand, um, on a lot of things. It, I think, I think so it's incredibly rewarding. It's a very long journey for most people. It's, it's very tough to get there and it feels very good once you finally break into the industry. And I, I would love for everyone to have that feeling eventually, but a lot of people get tripped up along the process. A lot of people give up, like a lot of people give up. I used to, I've always thrown this number out there. It's pretty accurate. 90% of the people that would come to my Chicago web development mentorship, meet up. They'd give up. Like it was a huge chunk and, you know, we would do everything that we possibly could, but I think like a big thing, there were two big things. One it's really solidifying the direction that you're going in and, and like really, maybe that just means, um, you know, figuring out what you love about coding and like building those types of projects to get you excited and continue pushing forward. Uh, but a lot of people, I feel like, you know, they just like, maybe it comes from old industries, old past issues, but a lot of people just don't have confidence in themself to push forward with it. Right. Like, you'd be surprised a lot of people are, are kind of heading in the right direction for the most part. And you can kind of like steer them a little bit closer to a more linear path, but like a lot of people get tripped up and they get fearful of the unknown they get. Um, mm-hmm, . They just get completely tripped up and they talked themselves out of the even being successful in this career path. So I'm gonna go ahead and ask a few questions that my audience has shared. They wanna know your opinions. So let's dive into that for the people that are fearful, that they're not gonna become developers for the people that feel like they're too stupid to become developers. How do you overcome essentially that imposter syndrome? How did you guys overcome it?

Whitley Bone:

Hmm, that's good. Um, I'll go ahead and start it off if y'all are okay with that, uh, imposter syndrome, the fear it's so real. Uh, and if you are feeling that it's absolutely valid and okay. Um, when I started to realize that our, when I started to learn to look at the fear as something. It's not gonna go away. I was like, this is something I'm gonna have to continue to learn how to deal with this. Isn't something I'm gonna conquer one day and I'm never gonna be fearful again. Cause I, I thought that was my goal that I was going to somehow become an expert and not have to deal with this anymore. And it's just not the case. Even, even being in the career that I wanted. Like there's still fear. Tech is always changing. There's always something to learn. Um, there's always gonna be people with more experience than you. There's there's gonna be a reason to be fearful. Um, what has been helpful to me? Um, and even thinking back when I was learning how to code and in those moments of like, gosh, I can't do this, going back a few steps and, and reviewing skills that I already learned. Um, for me, it was free code camp. So going, going back a couple, two or three units and redoing those lessons and reminding myself like, look how far I've come. I did not know how to do this like a few weeks ago or a few months ago. Um, that was a really good, helpful reminder to me that I, I move forward then, and I can keep moving forward now. Um, and I think I mentioned this in that other video, but also understanding that coding and web development and software engineering is not something that you're, it's a different kind of learning and it's, it's not something that you're gonna be able to memorize and just, no, you know, it's not a flashcard type thing. Somebody's not gonna, you know, ask you a question and you're always gonna know the answer to it. There's a lot of, I knows, and that's just the industry and that's okay. And so for me personally, coming from. Teaching, I knew stuff like that was completely different. You had to know these things and implement it every single day. Um, and yes, there are some aspects to that in, in development. But when I gave myself grace and allowed myself to, uh, to understand that this is something you grow in and you're not gonna stop growing that eased the fear at least a little bit . Um, but yeah, get comfortable. I would, I would, if you're not already get comfortable asking questions, get comfortable asking for help, um, and get just as good at Googling as you are coding.

Don Hansen:

that's good. I like that. Thanks. Yeah, I, um, it's a weird thing to tell people just like, you're gonna have to get used to it. They don't like have that mental model or that those habits to like, what do you mean get used? I don't, I want it to go away. What do you mean get used to it? Mm-hmm like I'm supposed to overcome this. Um, yeah. Okay. What else?

Aaron Billings:

um, I think for me, uh, you mentioned, uh, getting, getting used to it and I think that that's, uh, a big thing it's, uh, imposter syndrome for me has basically become, uh, my co-pilot that's so

Jeremy Wall:

good.

Aaron Billings:

Yeah. Um, and I, and I say that because, uh, you know, it, it was backseat driver, right. Uh, kind of telling you where to go kind of telling you you're just like, stop it. Right. Just stop it. Uh, but you have to kind of invite. Imposter syndrome to sit beside you, right. Uh, and hold its hand and just be okay with it, because that is, it is what it is. Um, but once you do that, you start feeling better. You start feeling better, you start saying, okay, you know what? I think, I think I can do this. I think I can do this. I think I can. And for me it was really kind of, um, talking to other developers, going through code, having code reviews. Um, you know, and, and, and like Whitley said, going back through, uh, my old code, taking a look at different things that I used to do and saying, whoa, this is how far I've actually come like this. This is crazy. Um, and it's interesting being back at the same company that I was, uh, actually when I first started my development journey, um, and being back here as a, uh, As a, a, you know, a full-time employee, um, sort of a contractor. I can see the code that I, that I wrote when I first got hired , which is not something that you can usually do. And I'm like, the code is actually still running on CNN, which is, I'm very surprised. Uh, but

Jeremy Wall:

I'm taking away code. I'm like, whoa, how did that get past code

Aaron Billings:

review? revealing this stuff. Like, you know, I wonder, but you know, it's, uh, you, you, you grow, you learn. Um, so you, you used to imposter syndrome being your co-pilot, you kind of used to used be riding shotgun with you. Um, and then you, you, you get to a point where you're comfortable. You're okay. Um, and the fear of failure is something that kind of keeps you motivated. Like, you know, you wanna, of course keep it in check. That's why you keep the imposter syndrome right next to you instead of the backseat. Right. Um, you keep it in check, but you don't let it overwhelm. That's the most important thing, cuz it will always be there, but do not want it to overwhelm you cuz the second overwhelms you, you, you lock up, you freeze and that's it. That's it. So, um, that's, that's what that's, what's kind of helped me.

Don Hansen:

Yeah's um, I've never heard someone give the advice to make it your co-pilot that's a, that's really interesting. I love it. I love that. Yeah. Yeah, it is. Um, yeah, you're really good with analogies. Um, with reviewing code, I feel like, and I'm just speaking for myself, but I keep up, like if someone wants to go back into my GitHub and look at all my old projects. From when I started, they're all still there. They're still very embarrassing, just as embarrassing as they were five years ago. But, um, it's like when you look at, I keep those up for a reason it's messy, but like people can look and kind of like, I think a lot of people just wanna gauge like where they are in relation to other developers, which can have its pros and cons and hurdles of itself. But, um, if you look at like a lot of developers that were hired, you look at their old code. Um, I think you're gonna find more often than not there repositories, like the first ones, like a lot of it, like if you've been at it for several months, um, six months, even up to a year, like 80% of the projects that I've built on GitHub, like you're, you're way past that your code's probably cleaner. It probably works. I think like half those projects don't even work at this point. Um, sometimes, I mean, yeah, if you wanna feel good, look at my old projects, but yeah. Look at your old projects, but see, the thing is the really tough thing is. people kind of hear, you need to self-assess you need to look like kind of compare what you're doing now to what you were doing like a month ago. But I think, I feel like some people still have trouble comparing that code. They don't really know what makes your code even better nowadays, because sometimes may like, I, I have my own thoughts on this, but like what let's, let's hone in on this a little bit. What should people use? Like what kind of metrics should people use to compare their old code with their new code did see if they're even making progress.

Aaron Billings:

Um, so I was recently, um, going through my old code bases and I remember, um, cuz I've been doing some mentoring with some people. And I remember, uh, asking, they asked me a question today and they said, how do I know when to use. A function with a parameter and when not to use a function without a parameter, like how, how do I know when to do that? Like how do I know when to even use a function period? Like how, how, how, how does that work? And I think that's the point when you start looking through your code and you see patterns in your code, you know, you're getting somewhere when you can recognize patterns of, oh, man, that actually should have went into a function. Oh, I can actually take this out and actually put this in a module. Oh, I can actually do this with this when you're actually looking your old code and you can actually think of ways to refactor it, to make it better. Mm-hmm you have grown as developer, like you're, you're growing, you're moving. You're you're getting better. You're moving to that point. Right? Um, that's, that's kind of what I look at. Like if you, if you look back at your old, old code and you're like, man, this is just amazing. Just this is the best code I've ever written, then you're probably not growing that much. you probably haven't learned too too much. You know, you need to push yourself a little bit harder. Um, but you can always go back and take a look and look at my code too. Like, man, I did not know where to put functions. I, I was just writing stuff all out, just global variables, everywhere, just like to run, you know, but that's, that's what you do when you're learning. You don't know, you don't know what you don't know and you don't know when to use certain things. You don't have that experience yet. So, um, that's one of the things I would say, uh, to look for. And when you start seeing that in yourself and start recognizing patterns of how to improve your code, you're really starting to improve.

Don Hansen:

I like that. Yeah.

Jeremy Wall:

I'll uh, I'll just piggyback off that a little bit. Um, Go back and refactor some of your old co in your portfolio projects, we learn by messing up mm-hmm um, that's like in our industry, maybe more than most, uh, we are, we learn by stuff breaking and we're like, oh, Hmm. Maybe I should like, do something different there. Um, so go back and fix your old code. Nothing. I don't know. I get satisfaction out of going back to some of my old projects and going, I think I know a little bit more about how that language works or this framework works now or, or whatever. Um, and I can do this much better than I did and go back now. I can't do it as much as I used to because frankly, like everything on GitHub, um, my, my list is massive, so, uh, I just don't have enough time to go and refactor all of it, but. It's it's helpful to go back and ask yourself, like, what have I learned since then? What mistakes have I made that I've learned from that would improve the code that I've written before? And then go ahead and do that. Uh, I think of, um, imposter syndrome, there's two, I think there's two, uh, ways people can think about it. They can look at it as a, uh, like it's demotivating. I'll be good enough, or they can look at it as, Hey, I'm not quite there yet. There's more for me to learn. And this is always the case. I'm my title now is VP of engineering. Um, I've been doing engineering software engineering for multiple decades now, I think, and I still learn stuff about how things work. I still. um, I still learn new languages that are coming out. I still learn new frameworks, but I also learn new ways of organizing, structuring, code, approaching problems, thinking about problems differently. Um, I still learn from the people I work with and it's not because like the temptation is to think, oh, they're all better than me. Mm-hmm but they're also learning from me some of the things. So it's an opportunity to learn when you feel like you're an imposter, like rather than just proof that you are not good enough for this, right? Like there's two different ways you could look at it. And if you choose to look at it as a motivational thing, Hey, there are so much more I could be learning from, from that person who looks like he knows way more about that than me. Um, that's an opportunity for me to like, learn a whole bunch more about how threading works or something, uh, where I didn't know

Aaron Billings:

it before.

Don Hansen:

Yeah. I like that. I feel like I wonder if inaction is, um, an issue because I feel like, so when you're encountered or when you encounter a problem, you encounter this, I guess this problem of like you don't, um, you thought maybe like you knew a lot about this framework, but now you realize like how little you know about it and now you need to learn a bigger chunk of it or a different part of it. And you have to, you have to dive further into it and you can kind of like think to yourself, like this kind of feels overwhelming. Like there's way too much for me to learn, or I'm not gonna be able to learn it. Or, um, like just any other self defeating thought. But I feel like a lot of people that get caught up. at this spot, it's because they're in their head too much. And I feel like sometimes inaction can get that mind, really racing in a, just a lot of self defeating thoughts. And I, I find that, you know, like even people that would come to my meet up, if they would just get stuck and I might kind of give them a little nudge forward, but just getting them to work on like a focus problem on trying to eventually get to that solution, um, is a lot better than them just like banging their head on. Like, sometimes it's even like changing the problem up and giving in a different context for them to try to understand it. But like, I don't know. I, I feel like some people just get stuck in this pattern of working on the same problem, the same thought pattern. And sometimes you have to like shuffle that up, but you have to continue moving forward. Cause if you're just thinking about like all the, I don't know, like. Yeah. If you're just getting stuck with your old dot patterns, is this sun health is some, I mean, maybe that even means like a good night's sleep is for you. Maybe that's gonna like shift your perspective. But, um, yeah. I feel like a lot of inaction causes these self defeating thoughts. I don't know. Maybe I'm way off at that. I'll

Jeremy Wall:

also say sometimes the good enough solution is, is good enough. Mm-hmm like, I think sometimes like I used to really get upset or like upset at myself. Cause I would feel like I did something that wasn't like good enough, but it did solve the problem. And it got me to the next step. Um, and like nobody, the business was necessarily complaining. Um, and I might come back to it in six months and go, oh, now's no longer solving the problem. And, but. six months later. I actually know like the next thing to do to like, make it even better. And so I refactor it and we move on. That's what all software engineers do. It's normal. You, especially when you're doing it for work, they kind of want you to do like the thing that's good enough. Mm-hmm for now. And then you're gonna come back to it and you're gonna make it a little bit better the next time. Or you might throw it away because it's no longer necessary. In which case if you had polished it, it would've been wasted effort anyway. So, um, don't beat yourself up if you think like, Hey, it's solving the problem, but it doesn't feel like it's it's super polished or anything. If you're solving the problem that's farther than you were before you made progress own it. Mm-hmm

Whitley Bone:

yeah. And there's usually, sorry. There's. Usually more than one solution too. I think it's tough in boot camp world, because you're listening to a tutorial or this, you know, your same teacher or whatever, teach you a certain way each time. Um, at least the different tutorials that I've seen are like boot camp stuff. They, they teach you how to solve it like that. And so I had a hard time doing my own projects. Like I gotta remember how he did it or she did it like, and I wasn't, um, it took me a while to realize like, I can figure out a way that works for me and you know, that, that makes sense to me, you know? And so that's another thing about development. Like there's, there's just more, more than one is an understatement. There's so many solutions to one problem.

Aaron Billings:

yeah, I, I, um, that that hit the nail on the head right there. I think like many, many solutions are one problem, I think, um, in, in bootcamp and stuff like that, you get taught, um, by teacher and it's, it's really hard when you come out of bootcamp or even self-taught going through tutorials and things like that because you have been taught, uh, with someone with their own bag of tools, right? So everyone as a developer has their own bag of tools on what to do when they get stuck, when they face a problem. But the problem is when you get taught by via tutorial, You are being handed a bag of tools that you really don't know how to use, and you have to develop your own tools on how to get unstuck. So you're like, how did he use that hammer again? I don't even know how to use that hammer. Yeah. How did he use that screwdriver? I don't even, do you need a screw for the screwdriver? How do you, so you're trying to figure out how to, how to do that stuff. You don't know mm-hmm um, so you have to go through the motions of struggling. You gotta struggle. You gotta struggle to develop your own tools, to be able to push past those blockers. You have to. Yeah. It's not gonna be an easy path. It's not gonna be easy. I've given up. I have given up, um, actually a couple times I gave up, uh, but came right back to it. Right. And yeah, you have, well, you have to struggle.

Whitley Bone:

that's so good. Like the, your own set of tools is so right. Like I, when I finally finished the bootcamp and you know, and I was job interview ready, and then I got the job, I was like, I'm a developer, you know, like I did it, I'm here. Like, let's do this. And then I get handed this giant code base that I didn't build. And nobody, nobody showed me how they built it. And you know, I get this task or this, you know, card that says, fix this, make this thing, do this thing. I'm like, oh, I, I think I know how to do that. I remember learning that. But then you're in this code base that has variables that you didn't name and, you know, they used a different med method in their function. Like, so it's, and I don't say that to scare anyone, but, um, uh, you know, it's just learning how to struggle. Well, like don't, don't try to not struggle. Just learn how to struggle. Well, , Don Hansen: I think that's I feel like. I feel like a lot of aspiring developers, like they're a lot of aspiring developers are really trying for this profession. They're putting a lot of effort in, but a lot of time during the day. And you know, I mean, sometimes half the battles, even just trying to become productive, like software engineering, forces, you, and like really forces you to look critically at yourself, are you truly efficient and productive at what you're doing? But a lot of people, you know, when they, they go to YouTubers channels, um, they ask on LinkedIn, they're just like, what course should I learn? What should I do? And you know, like you said, a lot of software developers, they have their own toolbox. Right. And they're going to share their advice based on their own perspective, but that doesn't always align with your background and who you are and how you learn. And so a lot of people will say, oh, okay, uh, free code camps, resource. I gotta go through. So I'll do free code camp and then they do it. And they're like, now what? And it's like, I feel like, and then they'll, it'll keep happening. I'll be like, oh, um, Oden project go do the Oden project. Oh, okay. I'll do that. And then like a month later, all right. Now what it's like, and at some point I think you have to start, like, you have to start building that toolbox. You have to start figuring out like what you wanna take away from those lessons. And also start thinking about like, what that means for your trajectory. What did you love about those courses? Like what really caught your attention? Maybe like you did this practice course, and you're like, you built a Spotify clone and you're like, I, that was actually a lot of fun. Like, you know, what did I really enjoy about this? I kind of wanna build more software like this. Um, because I, I think people kind of just go through the motions. Sometimes they put a lot, a lot of effort, but it's not like it doesn't have a certain direction because they don't really, I don't think they're analyzing what they love about coding or even solidifying that trajectory. So what am I trying to get at? I feel like a lot of developers, um, They ask, like they never figure out like what they truly love about coding. And they never really figure out like what kind of projects they want to build. And I feel like they're always letting everyone else tell them what to build and what to do. How do we start empowering software engineers to start thinking critically for themselves and start forming that path on their own. And maybe even like specialize a little bit and like get passionate about a certain aspect of web development, right? Like how do we start empowering developers to do that?

Jeremy Wall:

I mean, I think you have to do a certain amount of self-reflection right. Um, to find out like, what did appeal to you? Uh, why, what things excited you when you saw them, when you got to try them out. Um, but at some point you have to move past, uh, doing something for somebody else. To doing something for you? Um, I think a one hallmark of a lot of like, um, people who have done self taught is they, they moved, they transitioned at some point to a problem they wanted to solve for themselves. And it, the, the point of that wasn't to like show somebody else something awesome. Necessarily it might have been that maybe in an aspect of the project, but mostly it was out solving something for them that they wanted to be able to do. Um, which means they were motivated, they were passionate and they understood the problem. So they could be a good product owner in a sense for themselves to say, here's what it should do. And it doesn't matter because like you're, you're building for an audience of one at that point. And so you're, you, you don't have to like. Fighting against like three different ideas that everyone's trying to lobby for, or like you get to prioritize backlog, all those sorts of things that that's all owned by you and you get to just focus on like doing the thing and it, it could be anything, right? Like it could, um, my latest pet project is building a, a recipe management thing for myself because I hate all the ones that are out there. Um, none of them work for me, uh, like I could use them, but they're annoying and I'm a software engineer, so I could solve this. Right. So like, I'm just gonna solve it. Um, the thing I build may not fit anyone else's workflow. It may only fit mine, but it'll fit mine. And I get to play around with some stuff and learn some things and, and solve a problem. That's for me. And so I think that helps focus you, it gets you past that point where you're like, you, you may be struggling with a framework or a tool choice or a language, how to like properly structure things. Um, but you're motivated cuz there's a problem in front of you that you wanna solve for. and you're gonna do that and you're just gonna keep going until you do it. And you know, what done looks like for that problem? Like what good enough is. And so you're free to cut all the corners you want, cuz it's just for you. If like you may be struggling early on to like, how do I U I wanna try and make this a recursive function. And at some point you're like, I don't care anymore. I'm just gonna use a four loop cuz I need to loop. And I wanna, I wanna solve my recipe management problem. So I'm just gonna do a four loop so I can move forward. And maybe later you'll you'll tackle the recursive function thing. Um it's okay. Right. Like to do that. Um, and then, you know, three years later you'll look at your weird little funky recipe management that and go, I could totally do this a lot better now. I'm gonna refactor it. Cuz I still like cooking. and it's still solving my problem for me. And I don't want it to like bit rot and, and fall apart over time because I'm not keeping up with it. So I think those kinds of things where you're solving your problem and you're motivated to solve your problem. They're, they're a huge part of your journey as you're growing in this. And because it's just for you, you don't, there's no one critiquing your work. You know, if it works, you don't have to like try and meet someone else's ideal of perfection. You can make as many shortcuts and, and mistakes in there is you want to, or you need to in order to progress. And it's okay because this isn't for a job, this isn't for, um, you know, uh, a pristine sort. Thing that you're gonna put up and, and show on your website. You may not even have it in your portfolio, although I'll wager if you go down that path and you actually solve your problem, and then you're brave enough to like put it on a GitHub with all the flaws that it has. Um, if it's solving your problem, someone else out there probably has a similar problem and they may be interested and you may get some, you know, some traction that way, but the, the biggest value it had was that it enabled you to learn.

Don Hansen:

Yeah, I really like that. It, it, so would it, I guess, what do you say to, to people that are telling developers that they, um, So sometimes you get the advice that you shouldn't build those personal projects, right. That you should, there are better projects that they think employers care about. Like, you know, building an e-commerce system or B like building something that businesses might have on their platform. Sometimes you get like completely opposite advice and don't build those personal projects. Now I agree with you. And I'm a huge fan of exploring, you know, solving your own problems and exploring like the depth of growing as a software engineer that way. But do you feel like there's any merit, like, are there like specific or certain projects you probably should build that are gonna make you much more hireable as an aspiring developer?

Aaron Billings:

Hmm.

Jeremy Wall:

I think maybe there's two different things, right? Like there's the there's. How do you grow when it's not your career yet? Right. But if, if you're self-taught, if you're not going through a bootcamp, if you're not attending university for computer science degree, you need some way to like, push yourself, grow progress to the point where you could build things and, and be able to demonstrate that to people. And that's different than say a, a set of portfolio projects where you're like, here's my showcase, right? Um, if you look at like great artists, they do these studies, right? Like, uh, if they're sketch artist or something, like they've got these like studies and, and a lot of times those aren't, weren't done to show anyone. They did like a hundred versions of a dancer on a dance floor, and then they did their painting and that was their showcase, but they, they didn't really intend to show the hundred versions. Now, the funny thing is for all the great artists. All of studies are in the, in the museum too, because they were good artists. Right. And the studies over time, they got better and better. And so, and people like to see the folks progression and, um, and like, here's how, here's how the dancer happened. Here's the early versions. And like, here's how it began to flesh out and shape out. And then like, and here's the masterpiece. And like, it's definitely a masterpiece and you're looking at it and here's all this stuff he did beforehand while he was trying to figure out how to create his masterpiece. So I think it's, it's okay to not to do both right, to be like, I'm just playing around. And I built this command line tool or something that solved a little problem for me. And it's not the greatest thing in the world. Um, and the way I'm parsing my command line flags, you know, someone who, who does this for a living would, would like point out all kinds of flaw. but in solving my problem and I proved I could write code to solve my problem. And maybe later after I've done 10 small little command line utilities, and I've talked to some people who do command line utilities for a living, I've learned how to do better command line parsing. And I'm, I'm selecting the correct libraries. And, and like my 11th command line utility looks way better than my first, first. And that could be my showcase. Right? Same thing for webpages. Like maybe my first, my first webpages, like. I'm gonna date myself, but like marque tags scrolling across the top, those spinning gifts of like, they were noisy and they looked ugly. own it. And like geo city all the way. Right. Um, oh, wow. I don't think I even have copies of those anymore, cuz uh, I didn't know about source control at the time. Uh, they were terrible. I've grown quite a bit since then. Now I still don't know a ton about making a webpage look pretty, but I know how to make it semantic and I know how to use JavaScript and I know how to use CSS and I can make something halfway decent and tweak the things I care about. Um, there's a difference between your, your showcase project and the things that you're building just for you to learn how to do this thing. We call software engineer.

Don Hansen:

I like it. It's really good advice. Um,

Aaron Billings:

I, I go ahead. So when I was learning, um, I, I understand the, uh, I understand people's concern, I guess, cuz you get a lot of different people telling you, you need to build these type of projects and you need to do this and you need to do this. You get a lot of information when you're trying to learn how to code, especially if you're going self-taught route, you don't know what to do. You, you know, people tell you, oh, you need a project with this. You need a project with that. You need a project with this. Um, and I think that the problem is,

Jeremy Wall:

um, that people that

Aaron Billings:

are self taught, they try to run way too fast, too quickly. Um, so they're like, oh yeah. So if I'm gonna get a job, I need to build this masterpiece. And it's like maybe, maybe you. Maybe you do to get a job. Right. Um, but you're not even there yet. Like, you don't even quite know hello world. like, you're not quite there yet. Like, let's get past the hello world stage. Let's build some other applications. Let's, let's start to build your skills up first, you know, get to that point and then tackle that. Right. So, you know, um, it can get confusing though, cuz you, you think that you need to do that and you have this, uh, again, imposter syndrome, right? Telling you, oh, well, you know, if I don't do this, then I'm not gonna be able to get a job. And if I don't do this, I'm not gonna be able to do that. If I don't do this, I'm not gonna be able to do that. Um, and you have this little voice in your head telling you this, what you need to do. And then you hear all these other people telling you the things that you need to do. And um, it can get you to a point that you either end up giving up or you end up focusing on the wrong things for too long or you end up switching and bouncing between different things. You end. Going over here to learn, you know, going through this bootcamp and you say, well, that's not those, aren't the resources I need. And then you jump over to this and do this, and you're not focused at all. And it takes you five times as longer to get to your goal and you do. Right. Um, so I think it's, it's kind of narrowing your, your focus, finding out exactly what you're trying to do and then running for that. Right. So building up your focus, building up projects, if you're gonna go the self-taught route, right. Build the projects. Right. Do that. If you're gonna go to the bootcamp, do your research really do your research, like right. Really do your research and then go to a boot camp. Don't just jump in the first one you see. Right. Um, like that's the thing it's, it's being a developer is not an easy path. It's gonna be hard, even if you choose the so quote unquote, like right path for you, it's still gonna be really hard, really hard. Um, but it can be done, uh, if you're focused and if you're determined and if you stay on that path long enough, you will get there. Uh, but it just takes time.

Don Hansen:

Yeah. No, go ahead. Well, I

Whitley Bone:

was just gonna circle back to your question about, you know, bad advice to build this good advice to do this for employers. Um, you're gonna be able to talk about code that you love, you know, or that you really understand that you're passionate about. Um, so I think if we're talking interviews and trying to get a job, just be able to talk about your projects and your code. Well, cause, um, most of the time, at least in my experience, And all those interviews, um, they wanted to hear, they wanted to hear me talk about my code. And so if I knew it, if I loved it, it was easier to do that. Instead of, you know, this is a clone I made of whatever, because a website told me to, you know what I mean? Mm-hmm , Don Hansen: I don't, I don't know hear I'm supposed to build like an e-commerce website, I'm supposed to build this kind of website. I feel like there's nothing that gets me excited about that statement. Like nothing at all. And it seems like this very large complex, abstract, scary project. And it's like, I don't even know. I, I like usually. And like you said, Aaron, usually that advice gets pushed to developers way too quickly. They're like, well, I'm supposed to build this to get this job, but they're like on the skill level of even being able to create something like that, they're way down here. And I feel like a lot of developers get overwhelmed with that. Or even if they do start tackling it, I mean, let me know if you think differently, but like, I that's like to just build an e-commerce site just because I'm supposed to build an e-commerce site. That's like the most boring thing ever that mm-hmm, nothing about that gets me excited about coding. I don't want to build it. I don't care about that. And like, You know, um, Jeremy, to your point, I literally just solved a problem. Like I'm on Twitch. I built an analytics tool and that became the talking point, my main interview. It's what got me hired. Right. It wasn't like some, uh, templated project that I'm supposed to build because a lot of companies use that type of solver. It's like, none of my, none of my, uh, startup jobs cared about anything like I was building, but they wanted me to talk through it. They wanted me to talk through like, why did I implement it a certain way? And you know, walk me through this. So, um, and like what even got me interested in solving this problem in the first place and what happens when we scale this? Like what happens when you have like millions of rows in the database? Like, and I can tell you it shut my app really bad app. It's still live. It will probably take if you load it up, it'll probably take about three minutes to load. Every single time you click the refresh button and aggregates all the data all at once. I feel like the database is still live somewhere. Um, but it's, I don't know, but like then I get to talk about like how I would fit. I, I could even show them like how bad this turned out and I could add that conversation. I'm like, I made a wrong decision with this implementation and it's become, it has become unusable. So the next steps for this week, this is what I'm doing. Um, and this is why I'm doing it. I thought like that created a really fun conversation in the interview that it felt like it turned the tide in the interview. Like it, we were both just interested in the conversation. So I love the fact that like, man, just kind of solve your own problem. Like whatever gets you excited, like to wake up and start on your project the next day, if you're working on a project that does that, that's fantastic. Well, some people don't even can never even, uh, get that feeling. They never get to that spot, but like, if you can wake up and get excited about that project, like you are like, you're moving in the right direction. You're eventually gonna grow and you could build features on that project. You can create complexity in your project. So you are your own user, you know, the problems that exist, you know, like all the different solutions and features that you can add onto it to make it, maybe it, it makes it, so it accepts a wider audience, or maybe it becomes a little bit more specialized and targets a very specific type of user. But even in that sense, when you are solving your own problem, it's like, you're also kind of playing multiple hats. You're, you're understanding your user, essentially. You're thinking about the user perspective and potentially doing user research and what other apps. Do the similar thing, uh, that my app does. And, you know, you're, you might even test your app out and push it out and just share it on LinkedIn. Hey, can some people try to use it? Um, and if you get a user behind it, that's, that's freaking awesome. And you, if you can get feedback from that user and then iterate on it and kind of create your own agile process, like you can, I feel like you can build a lot of complexity, both with your code and your processes, um, with just like fun, personal projects that kind of just get you excited to keep coding each day. Um, but I, I feel like a lot of people struggle to find that

Aaron Billings:

yeah. I think

Jeremy Wall:

sometimes people are like, my problem's too complicated, or I need to like, do the other stuff before I'm ready to try and start solving my, my problem. And I think the key is to just be like, you know what, actually, you're gonna learn a lot just by struggling to solve your problem. Cause you're, and you're gonna be. Laser focused on finding just like only the tools you need to solve that problem. Not try to learn everything, just learn what you need so that you can like show that image on that web page, in the spot. You need it to, for your problem to get solved. Like that's, you'll break down the problems you go. Like, I just need to do this. And if I can figure out how to do this, then I can move to the next stage and I'll do the, the next thing. And it's really helps you focus on like problem solving, breaking things down, um, like being a software engineer, isn't just knowing how to write JavaScript or type script. Being a software engineer is about, Hey, here's a problem that we need to solve. And if I can break it into like enough sub problems that are small enough that I can tackle each one, one at a time. Then I will make progress and I will solve the problem. And that's what people are looking for when they're hiring software engineers. That's like, we're not always the greatest at doing interviews, but when we're doing good interviews, what we're trying to identify is can you take a problem, break it down and then solve it one step at a time using the tools that are available to you. And there may be better tools out there, but maybe they're not available to you because you don't work at that company or you don't have that library or you like your company. Doesn't let you use that programming language. You're always going to run into like weird constraints and other things, working on your problem. One step at a time demonstrates to people that you can do that you can do that job. and that you can learn what you need to get to the next step. And that's what our job is. Mm-hmm

Don Hansen:

yeah, that's good. I like that. I, I think, go

Aaron Billings:

ahead. Oh, I, I was thinking, um, just along those same lines, like there's, uh, speaking of interviews, um, I think something that trips people up right is, um, the difference between you doing projects and then you going for the interview, um, because those are two different skill sets that you will need to learn. Like you will need to learn how to program, to do your day to day job. And those projects that you're doing will help you in your day to day job, but you also do need to learn how to interview because there are different types of interviews that you will go for. And. You may not get that job because you don't know how to interview for that specific thing that they're looking for. Cause they may not ask you about your, hopefully they do. They ask you about your projects. Hopefully they do. I hope that they do, but , as I think we

Jeremy Wall:

all know

Aaron Billings:

the interviewing industry is kind of broken. So you will go through many different types of interviews, many, many, many, so it's good to exercise that skill, create that skill. You know, you just, it is what it is. Um, so while you focus on that, right, you focus on the tools that you need to do your job. You also focus on tools that you need to actually do the interview and putting those two things together will get you the job.

Don Hansen:

So how do you get better at the interview skill?

Aaron Billings:

You gotta prepare. That's the thing you gotta prepare. You gotta prepare and you gotta do interviews. That's a base thing. Or you

Don Hansen:

do interviews.

Aaron Billings:

Yeah.

Don Hansen:

I guess. Yeah, I guess my question is like you, you mentioned this idea, like a lot of interviews are very different and they are, a lot of companies are looking for different things. It almost kind of feels overwhelming to try to prepare for every type of interview. Right. Do you feel like, so, you know, you also mentioned this idea that interviews are broken, which kind of like, you know, you're, you're basically saying there maybe is like one or two styles that you kind of agree with the, you know, if some interviews are broken and some aren't like the, the couple of interview processes that are kind of ideal, and you, you mentioned like focusing on projects, they should be asking you about your projects. Right. I, I think you kind of like, um, started outlining what your ideal interview process is. Would you recommend. To prepare for that ideal interview process, or would you recommend people set a time aside to like prepare for a variety, like, you know, data structures and algorithms, maybe one focuses on strictly fundamentals, they don't care about your projects. Like, what's your advice for that?

Aaron Billings:

Yeah, like, so what I did when I was going through and, and applying for different jobs, um, I had a set, uh, structure that I would follow. So, um, there are different kinds of venues that you go through, right? So there's data structure and algorithm, algorithm, uh, interviews that you go through. There's um, ask you questions just about the language interviews. There's review your project interviews. There's um, Hey, fill out this multiple choice, uh, survey thing interview, Hey, take this test interview. Lots of interviews. So, um, I would focus on the ones that I specifically had problems with. So I would focus on data structures and algorithms, cuz that trips up a lot of people. Um, especially if you didn't come from a CS background, like if you went to school for CS, usually you're pretty okay. On those. Um, if you're self taught, you usually know nothing about data structures and algorithms don't know anything about that. So you gotta find a resource to help you with those things. Um, and then going through test questions on your language, the things that people will ask you, different things, right. And then going through coding problems, coding problems will help you. Right. Um, and then once you kind of get that general thing done, then it's going for an interview and then it's asking questions to, uh, maybe the, um, recruiter. Right. So I always ask them, Hey, what type of interview am I going into? What, what am I doing here? What is this? Uh, that's the question you ask and they'll tell you. Oh, well, you know, it's kind. No, no, no, no, no. I need more information. tell me what kind of interview this is. Sometimes they won't want to tell you, but you got a problem and they'll give you the information. Okay. Well, it's a algorithmic kind of interview. Okay. Well then I know I need to brush up on data structures and algorithms, and then I need to do this, or, okay. Well, I know that it's gonna be some kind of multiple choice thing, kind, some kind of test thing. Okay. I know what's gonna be on there. Um, and that kind of gets you in the mind frame to be able to tackle those kinds of, uh, issues. Um, cause if you don't know what to expect, you can't prepare. So it's always good to ask and that's something, I think that a lot of people don't do, they go to the recruiter, they go, oh, I got an interview and that's awesome. And then they don't ask the recruiter, any questions at all. They're just so happy to have an interview. They get in and they're presented with this question and they have no idea. Simple prepare.

Jeremy Wall:

Can't do that. Won't work.

Don Hansen:

Okay. Yeah. That's um, Hey,

Jeremy Wall:

go ahead. I echo a lot of what Aaron is saying. Um, I think that when you're trying to break into the industry, uh, you don't really have the luxury of trying to target a specific kind of company or a specific kind of interview because the world opens up after you've been in, like you've had the title software engineer for a year, suddenly everyone is knocking down your door. Mm-hmm . But until that happens, they're not knocking down your door. So interview like the, the biggest, I think like maybe the biggest, most important thing is put yourself out there. Do interviews participate. Mm-hmm um, You will get experience as you do them. You may interview for a few years and you'll get good at interviewing because you've just had a lot of practice. Um, and that's, that's fine. Right? In the meantime, you're also like building out your skill by building things. Um, and you maybe, you know, things you pick up on interviews will inform some of the stuff you wanna experiment with that on your projects, your side projects. Ooh. I liked it. My first interview where I actually landed the job, they asked me about unit testing and I'd never done unit testing. I was like, that sounds cool. I'd really like to learn how to do that, but I've never done it. They hired me that that's a little that like, that's, that's not always gonna be the case, but if I hadn't gotten that job, I would've gone home. And on my very next project, I would've figured out a way to do unit testing on. so that the next time I got asked the question, I would go, yeah, I've figured out how to do that. Like here's, here's what I've learned about unit testing. Here's a project. I did it on. Um, you know, here's what I found challenging about it. And I would've been able to talk about it because I would've done it. Um, and I think that's really important. Just like put yourself out there. Mm-hmm, , don't be afraid to go into interviews with the full expectation that you're just there to like, learn what you need to be prepared for in an interview that you may, you may not get the job. And then when you do finally get the job, it'll be a, you it'll be, um, an opportunity for you to begin to begin being more selective. You can be like, okay, I've got the title. Um, I have some credentials behind me now. Uh, I've got references and people I can point to who can back me up. I can start to be a little more selective and, and, and then looking at I'm looking for a place that's like this to work at, and I can pick up some of that from the way they're interviewing. Um, and, and that's that point, but when you're just, now, when you're trying to break in, I don't know that you necessarily have that luxury. Um, mm-hmm and you just need practice. Like you just need lots of practice. The other thing is, see if you can find a group of people, like there are a lot of meetups in our industry. Um, it's a little hard now during cuz we're right in the middle of a pandemic and people are in, in cities or like nervous about getting together. Um, but it's starting to open up and as it does, like, if, if you're doing JavaScript, see if there's a JavaScript users group somewhere, go there begin to form relationships, find someone who's in the industry and go, Hey, can I do a couple mock interviews with you? Would that be okay? a lot of 'em like, you'll be surprised how many people would be more than happy to do that. I did it for a couple like new graduates from the local college who were, um, ready to like go on the interview. And I was like, let me do some mock interviews with you, get you like comfortable. So you can feel like, you know what you're going into, and it's not just completely new to you. Look for those opportunities, build some relationships, build out your network. Um, it will be a lot of help.

Whitley Bone:

Yeah. I still do interviews. Like I love my job and have no intention of leaving, but you know, you'll see the suggestions on LinkedIn or something and be like, oh, company looks cool. And I'll still do interviews just for the practice. Cause I don't wanna lose that skill. And the, the coding challenges are still changing. So, um, . Yeah, I still, I still do interviews just to keep up the

Don Hansen:

practice. That's rare. That's interesting. do you,

Jeremy Wall:

so I should tell, uh, tell my people, I was like, you should interview every six months. You don't want to get out of practice. Mm-hmm , which is I, some people might think it's self-defeating for manager to tell people that, but I think it's important, right? Like you, you need to be out there. It tells what the market is like, what are, what are salaries like? Um, if, if you are hired at some place, if you're working and, and you interview, and you're like, I could get a, a $20,000 a year, raise you, come back to your business, like your company and say, Hey, you want a counter offer? Like, you could turn that into a raise for yourself and not even have to go like change jobs. Like, I think it's important for people to be, um, keeping track, like pushing their career that way every six months go out there and. . Don Hansen: Yeah, that's interesting. You recommended, um, for someone to potentially introduce it as like, do you want a counter offer? I get different. I get like a mixed bag of feedback from hiring managers of how they take that. Would you, let me ask you this. Yeah. Would you keep someone that basically, um, was willing to leave for a big salary increase? Would you pay to keep them if you had it in your budget or would you expect them to leave down the road anyways? I mean, it's gonna be dependent on the person. Um, but either way that's a positive outcome, right? Like if they're not someone I'm enthusiastic about keeping on the team and they go someplace else, they get a, like, they get a raise and I maybe get to replace that with someone I'm more enthusiastic with. So it's, it's win-win um, if I really want them like. I am aware that this person is under market and they're risk and that I can do something about it to keep them on. So I wanna know that information, like I'm doing market analysis through, through our HR department a lot, like to try and stay ahead of it. But that doesn't mean I am, especially right now, like salaries going through the roof right now. Um, and so, uh, like if someone is comes to me and is like, and they're excellent and I really want to keep them, and they're like, I've got an offer that like, gives me this much extra pay. And I'm like, well, thanks for letting me know. I would like to counter offer that because you're, you're excellent. Um, I think it's, it's across the board a win-win in almost every case for that, to, for that to occur.

Don Hansen:

Okay. Thanks for sharing. Um, I am,

Jeremy Wall:

um, I cannot speak for all managers.

Don Hansen:

Sure.

Aaron Billings:

disclaimer. right. It may backfire

Jeremy Wall:

there are people who let you go. But again, you like the worst case scenario for you. If your manager is like, I'm gonna let you go. Is that you got, you still gotta race, right. It's cool.

Don Hansen:

Okay. Definitely an interesting perspective. Well, let's, let's wrap up with, cuz I kind of wanna get your feel for this, but where do you guys see the industry going in three to five years? And I know it's a very broad question, but think about just like job opportunities for entry level versus like mid to senior level. Um, I even dove into like no code, low code movement, which is another interesting topic. Um, but like in general, yeah. What, like where are you gonna be in three to five years? If you stay in this. where, like, where are most teams gonna be? I like, I know it's a very vague question, but we'll just start it off with this. Where is the industry going?

Aaron Billings:

I think, um, there is a big push. Um, I don't know if it'll happen in three to five years. Um, but yeah, I mean, you know, there's a big push with like blockchain and, you know, the new web and stuff like that. Low code, no code, things like that. Um, will it ha will it like explode in three to five years? The industry moves fast, but I don't, I don't know if it'll just be like, you know, in three years everyone will just be, you know, doing blockchain. Right. I don't, I don't know about that. I know that, um, people are trying to, um, Get code as close to users as possible. So infrastructure stuff is probably gonna, is exploding. Cloudflare's doing some really awesome stuff with that. Um, so it could be, if that takes off, then there could be some stuff around that in the next three to five years. So infrastructure movement, things like that. Um, I'm excited about Terraform and, you know, AWS and, you know, CloudFlare and yeah, I think that stuff is gonna explode very soon.

Don Hansen:

Interesting. Real quick. Um, Jeremy, I just saw the time. How much time do you have left?

Jeremy Wall:

Um, I've I've got probably about 10 more minutes before. 10 more minutes. Okay. I do wanna say something on this though. It, it varies per industry, um, like, uh, We used to say, software eats the world. It's still eating the world. There's still a lot of the world to eat. Um, I think, uh, the largest segment of our industry is web development and I don't think it's going away, but I do think it's gonna change. There's a lot of things about web development that are kind of a towering, like a really high tower of things, stacked on things D on thing that's kind of wobbly and, and is in danger of falling down any moment. So I have a hot take. Um, it may completely wrong, but I actually think that, um, in, in three to five years, most web development will move to web assembly and that a lot of the, um, a lot of the sort of shaky infrastructure built around the node ecosystem and the JavaScript ecosystem is gonna be radically transformed by that because you get a lot of tools that backend developers have had and enjoyed for a long time that fund and developers haven't. And I think web assembly bridges the gap and makes a lot of things that are kind of painful right now, way more practical. And, um, so I think at some point, um, like a lot of things like type script may eventually just compile down to web assembly instead of targeting JavaScript. Like that may be a thing. Um, you may be able to use way more different languages, um, to develop your front end with, um, there's not a ton of choice there now. Like you're sort of locked into a very specific ecosystem and web assembly allows you to escape that ecosystem. And I think more and more places are gonna do it. And I think, um, that's going to allow more and more kinds of apps to be able to target consumers that haven't been before. Like we're backend engineers, like to complain about like electron and how bloated it is and how it eats all the memory. Um, a lot of it is just silly, uh, but like, there is a sense in which, um, you can get a lot of the same benefits of like being able to target all the platforms with a single code base and get it slimed down and way more performant and way more reliable if you're building some of that stuff in web assembly instead of pure Java script. So I think that's where we're gonna be. I could be wrong then.

Don Hansen:

Okay. That is definitely a hot take. Interesting take. Thanks for sharing. How about you Whitley?

Whitley Bone:

Um, I'm still just trying to keep my feet on the ground in this new career. I haven't really thought about where the industry's going, but, um, that no code movement. It's, uh, I'm, I'm just now looking into that and seeing what that's all about. Uh, there could be something there, I think. Um, but other than, I don't know, that was Jeremy, your hot take was interesting. I mean, front end is what I do. So I would be, I would be interested to see how that goes. Um, yeah, I don't have a lot to offer

Don Hansen:

Yeah. Um, and I did a video on no code, low code, and obviously my opinion, isn't the only opinion. Um, I think that's gonna be introduced more and I think engineers are engineers are expensive. I think. Um, I think engineers are gonna have to seriously like, be critical about some of their solutions and think about like how I think a lot more engineers are going to be forced to like make really efficient decisions for the companies. And because there are, I mean, shoot, there are no code, low code solutions that are getting a lot more complex that, I mean, can easily create a lot of applications that might have taken an engineer an entire month to create it's. Um, it, it's not quite there yet. Right. It still has some longevity before, you know, like, um, in my opinion, anything is truly gonna happen with that and for it to have a major impact in the industry, but it's um, I don't know. I'm interested to see cuz it could be like for engineers that are willing to adopt it and willing to stay up to date with their skills. I. It it's, they're not gonna be affected in my opinion. They're just not a lot of engineers. Um, you can take advantage of solutions like that. That just be more efficient. If you start considering the business finances and trying to provide more optimal solutions like at the end of the day code is just another tool. And sometimes you need to realize that for as an engineer, but, um, yeah, definitely hot take with Jeremy. I D I wanna hear my comments, uh, what everyone thinks of that. Um, do you completely agree? Do you completely disagree, but, um, Jeremy, I don't wanna push your time any longer, cuz I think we're almost set it like an hour and a half. So let's go ahead and do our outros. Jeremy, if people wanted to reach out to you, anything else you wanna shout out? Where could they reach you?

Jeremy Wall:

Uh, you can see me on LinkedIn. Um, I have a Twitter account it's at Zafar Z, a P H R. I do curate it fairly heavily. So don't feel bad if I don't refollow you back, but you can follow me there. Um, and that's about it for social media. I don't really do a ton of, of social media. So I am on GitHub, same tag za, far as the a P H R. So,

Don Hansen:

all right. Cool. How about you Whitley?

Whitley Bone:

Um, I'm on all the socials I love these in social media. Um, and I've been super thankful about people reaching out, uh, from the last, uh, episode that we did. Um, that's been really cool to hear people's stories and journeys, and I've loved being able to be a part of those, but, um, Instagram, um, is at Whitley P G. Um, and then everything else is Whitley bone. So yeah, that's me.

Don Hansen:

Okay, cool. That still is really cool that people reach out to you guys for this. Yes.

Whitley Bone:

I, I I'm really thankful for that. It's cool thing.

Don Hansen:

How about you, Erin?

Aaron Billings:

Yeah. Um, so I'm on Twitter and, uh, LinkedIn, I have an Instagram. Don't real. I'm not really on there all that much. Uh, but Twitter I'm on all the time. And, uh, LinkedIn, I've had a few people reach out, uh, on LinkedIn. So that was pretty cool. So happy to help anybody, um, and hear stories and things like that. Uh, but yeah, so reach out to me, LinkedIn and then AB develops, uh, will be my handle just about everywhere. So AB

Don Hansen:

develops. Okay, cool. And they're not just saying that all three of these wonderful people are very helpful. Um, I've had people even tell me they've reached out to you guys and, um, all good experiences. So, uh, that's why I decided to bring everyone back on. Hopefully this was helpful. I know there are a lot of self-taught developers out there. I know the struggle's real. I know it's a difficult journey and I promise you, you will eventually get that position as long as you don't give up. So hopefully this video gives you just a little extra context. Um, and if you haven't seen the other video. Go watch the other video. I will link it somewhere on this video, but yeah. Thanks for joining me again. I,

Aaron Billings:

this is always fun.