These Junior Devs Just Don't Get It! - Principal Engineering Manager AMA

All right, let's see if this thing's going here. So far, maybe. I think we're getting there. There is Instagram. Let's see if Substack wants to do the thing. I think the answer is yes. Substack is about to do the thing. I will check out this stream myself. Awesome. I think it's working. Welcome, folks. Welcome to the live stream. For those of you that are new, um I do this live stream every Monday 700 p.m. Pacific, generally on a topic from Dev Leader weekly, which is generally on a topic from Code Commute. And so try to make a lot of software engineering content as much as I can in my free time. And so Code Commute is my my one sort of personal brand where I try to do Q&A style um vlog entries answering people's software engineering questions, stuff like that. And then what I do is I try to look at the week's worth of videos, see whatever had the most views or the most sort of engagement based on people asking questions and stuff. And then I go write a newsletter article about that. So that's at weekly.devleer.ca. And I always remind folks like it is an email newsletter, but if you don't want email, totally cool. Don't subscribe. If you just want to check out kind of what the content for the the live stream is going to be, if you go to weekly.devleer.ca, you can see it kind of like a blog post. Totally free. I paywall them after roughly a month or so. So, if you want to go check out the over 100, I think I this was issue 110. Yes, 110. And so if you want to check out the other 100 issues, uh they're all archived. There is a monthly fee for that. It's pretty low, but uh again, literally no pressure. If you just want to come to the live stream and see the topic, then I'm happy to have you here. So these live streams are very much an AMA format. So I have a topic. We're going to be talking about um this this sort of Reddit post that got me to do the code commute episode which got me to do the newsletter article and it's really about uh junior developers and sort of this takeaway that you know there's there's work to be done from the more senior people on the team to help empower junior developers to to help them to help them learn to navigate you know if they're early in career understanding like how to work uh in Teams. So, there's a whole lot going on. Just got to turn off my my phone so I don't see my work notifications. And so, I thought that this was an important topic and I think the response uh was pretty overwhelming from code commute. Uh for context, this had I probably have it on my screen somewhere. It had like something like yeah 16x the normal uh views. Um which is cool. I think people really responded to it. I honestly think that some people interpreted the title as clickbait because I'm basing it off the Reddit post. So, I think people saw the title and they're like, I'm a junior developer. There was even someone who commented and they were like, I haven't even watched this video, but here's my opinion. I'm like, dude, you can't have an opinion yet if you haven't even watched the video. I'm on your side. So anyway, um yeah, I I was, you know, interested in talking about it. And I think that there's some common lessons with this kind of stuff. So again, please use the chat. Uh I have, you can't see my setup from my side, but I got three monitors. I got the stream coming in and I got chat all over the place. So if you have questions you want to ask about software engineering, career development, that kind of stuff. Um please just feel free to ask in the chat. I will, you know, wrap up my thought and go to your question and I'm happy to try and answer. But that said, let's talk about junior developers in the workplace and how we can do something to try and help them. So um the context for you know what this person originally wrote about was that they are on a team and they have some junior developers and what they started to notice is that it feels like the poll requests and the code reviews are kind of getting bogged down and the way that they wrote their post originally I suppose had some people triggered a little bit. I think rightfully so. there's a lot of people that are on edge as software developers right now and um so they had said something along the lines of like hey like you know really like the juniors that I'm working with like you know um they're awesome and stuff but uh it seems like they're like we're kind of grinding to a halt with our code reviews and like they don't seem to really understand the code I'm writing. So apparently, like I'm assuming all of the, you know, original comments that were coming in were people being like, "Well, dude, it's cuz your code's too complicated and like maybe you should write better code." And this person had to go back and edit their post to be like, "No, no, no. Like, hold up." Not what I'm saying. Like what I'm saying is I think that these junior developers don't actually have some experience in some of these areas. And as a result, I'm not sure how to like help them because I'm trying different things and it's not really working. So that's the framing for this and I wanted to bring that up because depending on you know your work environment you might be a more senior developer encountering something like this and you might be the more junior developer in this case being like I don't know you put me on this code review and I don't really know how to help. And so that's the framing. I think with that said we can kind of dive into some of the thoughts here. it. Um, the first thing I wrote about was like just like not having exposure to some of these areas. And I think it's really easy for a lot of us to forget this kind of thing, especially if we've been in the industry for a long time or maybe you were someone that as a junior developer like in your, you know, unique journey, maybe you did go learn a whole bunch of different stuff and different tech stacks and whatever. Like I I think I can't remember the math on this, but like I think so I started not like super super early, but I've always like you know really been into computers. Started programming I think in grade nine. So I would have been 14. And by the time I landed my first full-time job, I'd already you know been coding for what high school and university nine years. and I like to program. So, I was programming basically every day, right? Like in and out of like my six internships and stuff. So, like I had done a bunch of stuff before getting my first full-time job. But that's like certainly not going to be the case for some people. And like what is normal? I don't really know. But I think that it's very easy for a lot of us to get in our own minds like well whatever I did must be normal or I came into the workforce knowing all these things or this particular tech stack or whatever. And like the reality is that that's not really the case, right? Like you can't really know that about everyone that you're working with. I've talked about this before on different videos, but like you know at Microsoft one of our programming languages that we have is C. And I can't remember I did the math on this before, but in the two teams that I've managed at Microsoft for the employees that were hired on sort of like with me or right after me, I think it was like two people that knew C and had worked in C in some type of professional capacity before. So like they don't know C. That's fine, right? But like if I went into that being like my expectation is that you all know this and like if you don't like you're the ones holding us back. It's kind of it's kind of misaligned. So I think one of the important things to remember here is that when you have new folks coming on whatever their experience was before it's going to look different for everyone. And you would hope of course that there's some baseline of like some technical ability of course some problem solving skills like things like that. But in terms of the text stack, in terms of the languages, people are going to be coming from from different sort of walks of experience. So in this particular case for this original Reddit post, I think this person was saying, you know, I think they're working in React. And he was kind of calling out like, I don't think these these, you know, more junior people like actually understand some of like the underlying JavaScript stuff that I'm writing that's that's not just part of React based on whatever they're building. So he's like, I go write this stuff and because it's not like straight up just, you know, some stuff that's like raid in React, they're like, I don't know what you're doing. Right? So already like and obviously React is like TypeScript and JavaScript. So like it's it's not like it's completely different. It's just that they have this framework sitting on top of it. And when you pull that apart, some of these individuals just weren't getting it. Okay. So, I think we have different technology backgrounds that can come up. I think that I've seem to notice that some individuals, and again, I'm not pointing fingers or blaming anyone, whatever. It's just different experiences. But I've noticed that some individuals kind of like especially when you want to debug things and like understand how code is actually being put together. Um some people have difficulty like rationalizing like call stacks and like how you know some more abstract systems kind of come together because if it's not like within the function and they're kind of just like looking at it line by line there. Sometimes like when you start expanding the scope of that it seems to fall apart pretty quick. But okay, like they're they're junior, right? Like if they don't have a lot of experience doing this ahead of time, like I don't know. The first programs I was writing, I like, you know, I I remember like like half bragging to my teacher in high school. I was like, "This program I wrote 10,000 lines long." And I remember like him kind of like trying to hold it in like, "Dude, like you don't even know what's going on." And I remember being like, "Yeah, this is cool. Like 10,000 lines of code. Like that's crazy." Yeah. because it was all copy pasted if statements. I wasn't really writing functions. So like if I'm thinking about myself as a junior developer, there was so much for me to learn. So the whole point of this section that I wrote in the newsletter and one of the things I wanted to call out first is really like having a little bit of empathy and understanding that people are coming from different backgrounds. Right? your background, your experience when you were junior might have been, you know, one way, but that's not the same for everyone else. Um, Mac, is that you from from high school on Instagram? I don't know. I don't think I know any other Mac Hilton, but Mac is on Instagram. You can't see it in the chat, but uh Mac says, "We see that a lot in our business. We use less common languages for GL from Postgress." Sure is, buddy. Awesome. Good to see you, man. We use less common language 4GL from post uh Postgress soft or progress software sorry Postgress you see what's uh 4GL from progress software we almost always have to find developers and teach them the language awesome right so like again Mac's talking about being and thank you so much for joining dude in that comment that's awesome but uh he's talking about they're already getting developers in I'm talking about React and JavaScript and it's like I don't have stats on that. But I'm pretty sure literally every single person who's going into being a software developer right now, that's exactly what they're learning. And so Mac's talking about this situation where it's not even a common language. You like you don't even have a choice but to expect to teach people that when they're coming on board, right? But sometimes we forget about this kind of stuff. And I think that it's um you know I I wanted this to be a reminder near the beginning of this topic to be like look we didn't all have the same background and stuff right I think like when I was going through university um I I can remember like some of the courses in the beginning I'm like why the heck do we why do we go through this like I'm here for computer engineering. Why do I why am I taking some of these math classes these physics these chemistry classes? I'm like just like can we get to the the cool like computer stuff? And really like in hindsight it's like they're setting a baseline of expectations to get everyone on the same page so we can move forward. And I think that you kind of have to think about the juniors on your team in a similar capacity. Okay. So that was the first part. Um for folks that are like where is this going and what's the takeaway? I like kind of trying to put the meta point out there near the beginning, too. So, if you're like, "Hey, this is cool and all, but like get to the point, Nick, and stop rambling." Um, the whole live stream's a ramble. It's a live stream. So, the the meta point that I'll be talking about is something that comes up in other topics as well. And that's really that um this is kind of difficult for some people, but like unfortunately, I think in these cases, you need to slow down to speed up. And what I mean by that is if this person's already like, "Hey man, like our poll requests like they're taking too long and like I have to figure out a way to help the juniors and like it's kind of slowing things down." Like hate to break it to you, but to make this better, you probably got to slow down even more at least for a little bit. And the idea behind this is going to be that if you're sort of not trying to avoid the problems but actually address the problems or in this case you're looking to you know implement solutions to some of the challenges that you're experiencing then those things will pay dividends long term. So slow down it's a little bit more costly upfront and then longterm it makes things better. So that's the meta point just as a heads up. So, if you're like that sounds boring, well, thank you so much for joining. And if that sounds interesting, then stick around. So, the next part that I'm going to talk about is uh taking some opportunity to pair up. And this is part of being able to slow down because I think when I was trying to talk about this on the code commute vlog, the thing that I was kind of hinting at was like I think some people try to avoid like whatever is um whatever they're perceiving is the thing that slows them down. So to give you an example, this uh this whole talk is about, you know, uh a Reddit post that someone made where they said, "Hey, I'm putting these junior developers on these poll requests and like it's not going so well. They're slowing me down." What if you had this brilliant idea where you said, "Hey, look, if the junior developers slow me down, what if what if I stop putting the junior developers on to the poll requests? What if I just get rid of that problem?" Right? Take the juniors. Thanks. You go do your junior stuff. I'm gonna go put the senior people onto my pull request. I don't need you juniors to look at this. Right? So, what happens when you start avoiding problems, right? We'll get into that in a little bit. So, this is the exact opposite strategy. It's not avoiding the problems. It's actually literally going to address where you're having challenges. So, um, pairing up for folks that have not done a little bit of pair programming or haven't done mentoring before, I think that there's an opportunity on your code reviews to introduce a little bit of this. Doesn't have to be super heavy-handed. You don't have to do it with all of the juniors all at once. You can, if you want, you can do a mix and match where like, you know, if I'm just making this up, if you have a handful of juniors on your team, maybe for your one pull request, you pull on Billy and you say, "Billy, we're going to get going to get on a call. We're going to go through this this PR together. I'm going to talk you through it, let you kind of see what's up, let you ask questions and stuff, right? And then maybe the next time you go to Sally and you do the same thing or maybe you get Billy and Sally onto the same call kind of two birds with one stone. What's the there's a more positive way to say that and I never remember it but we're not killing birds with stones. Um so you can address that more in volume, right? So you can kind of mix and match this however you want, but the idea is that instead of just adding the junior developers onto the code review and being like, "Okay, go do the review thing." Obviously, um it's really about kind of setting them up for success and inviting them to be curious and ask questions. So I think there's a lot of interesting things that can come out of this and it's really not that big of a lift. So you could spend what did I even write here? Like, did I even write a time? Like, you could do like 15 to 30 minutes, right? Um, if you think about it, depending on the questions you're getting left on your poll request, maybe you're spending more time trying to think like thoughtful ways to answer stuff. So, spend a little bit of time up front, walk people through some of the poll request, explain what's going on, and then give them this opportunity to like like let let you know what they're thinking. I don't know the better way to say that but kind of like if you probably have tried this yourself where uh someone's explaining something to you and you go okay in my own words are you saying blah blah blah and then you're kind of letting the person know you're listening and your interpretation of what's going on. Give those junior developers that same opportunity. Right? So you're walking through some things and then say hey like based on your understanding like can you tell me what you know what this code's doing? Right? And if they're if they're getting stuck or they have questions, it's a really good opportunity to be like, "Cool." Like, "Let's talk about that." Then it might be that uh maybe it's a little overwhelming at first. Maybe they need some extra time to go read through and leave comments. But again, that's another opportunity for you to say to them like, "Hey, cool. Like now that we've spent like 15 to 30 minutes on this, like now you know sort of the main areas that I'm touching and my my rationale for doing that and high level what I'm trying to accomplish. if you have any other questions, right? Either you can ping me on the side in chat, um, you know, if you're open to it, you could have another call with them or you can say just leave comments on the review. And then one of the other really cool things about that is you're inviting them to ask questions and you can let them know is this is a really I mean you have to find the right words to do this in your own your own words and phrasing but inviting people to ask questions and like share things is such a good way to like let them know that other people will also have questions. It's almost like a chain reaction. And you might have seen this depending on, you know, different experiences you've had. Like if you've done like icebreaker type things or if you've ever uh tried to lead a small group of people in a conversation, you know, no one's speaking up or whatever. As soon as you break the ice a little bit, then it's like, hey, like, oh, it's not so bad. I can ask questions. So, I would recommend like invite people into, you know, asking questions. when it's in a poll or sorry, when it's on a poll request, then you can have someone ask questions, you can answer it right there, right? Other people can read those answers and that way it's an opportunity to help educate other people on the team. Um, so couple questions in chat across platforms. So, I'm going to shut my mouth for one sec. I'm going to Mac on Instagram again. Um, so, and by the way, I do see Akib and Tarzan is live. I see your questions on YouTube. I I'm just going to pause to do Max and then I'll come back over. So, how Max says, "How do you manage training junior devs uh when one of the measurements your team is measured on billable utilization?" Yeah. Uh I see that as a common situation where problem avoidance comes up. Yeah. And I think this is like I think the reality is Mac I don't know the situation for like how your work is structured but uh this is something that I would want to bring up with the manager or whoever is kind of coordinating these things because when it comes and I full disclosure I've not actually worked in an environment where we have to do like billable hours and stuff like that but I would say that if that's a consideration it needs to come into like the decision-m process for whoever is managing those interactions. So just as an example, I like to exaggerate things on different sides of a spectrum to kind of paint a picture, but if you had, you know, so Mac, let's say you're the senior developer and they're like, "Okay, well, we're going to put six junior developers with Mac. Mac's the only person who knows this stuff and then we're going to build a client like crazy because we got these developers on there. It's going to be great." And then you're like, "Cool, except I have to spend all of my time as probably the only productive person that knows the tech stack or Mac was saying a language like I have to spend all of my time teaching them. Like there's a ramp curve. They're not going to get anything done in the first x days or weeks and like who is that going to fall on?" So the reality is like that shouldn't fall on Mac and it shouldn't fall on the other developers. That's not really fair. So, I think that this is something that you would want to discuss with the manager to be like, "Hey, look, like I say the manager here because I don't know what the structure is like, but I think that needs to be a factor." And probably what makes more sense is in some capacity is like you have more tenur people uh mixed in with some like juniors. So, you might have like, you know, someone who's really high level or a senior or a couple seniors, some mid-levels, and a couple juniors. And you, in my opinion, always want to have sort of this staggered um like experience level situation so that there's always some more junior people to ramp up and teach and always some people who can really hit the ground running. And you mix these things in so that you can kind of spread out the amount of I don't want to say like handholding is such like a feel like a condescending thing to say. you can spread out the amount of like coaching and mentoring for the really junior people that they're just not going to be effective right away. So Mac, I think my number one suggestion here would be like having that conversation for whoever is the decision maker for for getting things build out and stuff to be like look if we need to have junior developers and you probably should in some capacity like how much how much time needs to be spent making that really clear if they're pushing back and being like you know there is no time for it like I don't I just feel like that's not a good setup and I don't know how much decision- making or influence you have on that. But I don't know if that helps, but that's kind of how I would push back on that thing is just to to give some visibility into the amount of time and effort that goes into training people like that. But let me know. I'm going to jump to the other questions and if you're like, Nick, that made literally no sense or you completely missed it, just try again and I will try my best to answer. Um, Ake says, "Uh, what do you think about vibe coding? Uh, I feel like it's ruining junior devs." Um, in sorry, in what sense, um, in what sense do you feel like it's ruining junior devs? Do you mean, uh, people vibe coding ruins the need for junior devs, or do you mean that, uh, junior's vibe coding is ruining juniors? Um, I'd be curious to know which way you think about that because that will help me try and clarify how I want to focus on answering that. So, I don't know if you have um any followup to that. I'm going to jump to Tarzan is live um their question because if you have a little bit more context you want to provide that will help me try and answer. But Tarzan is live says uh on in college right now I applied to many jobs no success any suggestions this is a really difficult one to answer because it's uh it's very generic and I can't really know all the details. Um so the thing that I like to remind people uh for applying to jobs is that the job application part of you know getting into software development is basically like um you need to find ways to stand out. And you're probably like thanks Nick that's the most obvious advice I've literally ever heard. And then I would say okay but how are you standing out? Because if I were to totally guess at the different sort of, you know, uh, skills and experiences that are showing up on a resume, it's probably something like React, TypeScript, JavaScript, maybe some type of database, maybe Python instead of those other languages I mentioned. And then for side projects, either one side project or none. and then going, it's really hard to go, you know, like no one's saying yes to me. And like I'm not saying this in a way to try and be rude or condescending. Not my intention at all. My point is that, you know, this part of the job search is like standing out. And it's really, really, really difficult to stand out when so many people that are kind of entering the workforce or trying to, right, like are all coming in with a very similar set of skills. like how do you stand out? What are ways that you can do that? So, some thoughts, right? And like, you know, I've had people tell me the number of jobs that they're applying to and I'm like, I don't even know how that's physically possible. On the order of like 80 to 100 a week, I'm like, good for you. I have no idea physically how you can do that, but okay. So, there's people that are taking the volume game. Uh the feedback I've heard on that too is that um it lets you have a little bit more signal for trying out different things on your resume. But again, that's a lot of volume. So you have volume of résumés for your job application. You have things where you can be like networking. Networking is a very slow thing. I think a lot of people miss this. Networking is extremely slow. But networking is very very helpful. needs to be done intentionally. And in my opinion, you want to approach this in a way that's not like, hm, who can I contact to extract value from, right? To give you an example, I'm just going to use myself because I'm the one talking and no one else has a microphone right now, but if you were like, okay, there's this bald guy on the internet and he's live streaming. So like he's saying to network what I should do cuz I bet you this guy works somewhere and I bet you if I reach out to him and I'm like hey give me a referral I can get the job referral from this bald guy right like you're if your thought process is immediately how can I find someone to extract the value to get the job I think like you are missing networking. Networking is slow but networking increases your surface area for luck. But I think to effectively network it needs to be intentional. It needs to take time and it needs to be approached in my opinion in a way that is not supposed to be like how do I extract value from people to to explain more what I mean about that is like I have lots of people that will reach out on LinkedIn the the one message that they send is like hi so and so I don't even know if they know my name here's my resume I'm interested in applying for some position that like doesn't I don't even know where that's coming from. I don't know if it exists. Like interest in this position. Here's my resume. Can you refer me? Like I don't know who you are. And pardon me, but like I have so much other stuff to do. Um so like no. The answer is just no. But there are people that show up repeatedly. Thanks Matt. Good to see you. Thanks for dropping in. Um, yeah. I I hope you're doing well, too, man. It's it's it's really cool to to run into you on the internet. So, thanks for being here. Um, yeah, like it's just it's not intentional. And I have people I was just saying I have people that show up repeatedly and they've never asked me for anything ever. And like those are the people they seem genuinely interested. They're trying to, you know, form like a I don't know, like almost like it almost feels like a friendship and like cool, but I get to learn more about them, right? I learn tons about them because they're just showing up and interacting, right? I'll give you an example. Jonathan Baron's been on this stream. He's putting messages in the chat right now. Um, and he's saying, "I can't attend, so I don't even know if Jonathan can hear me." But I know Jonathan shows up a lot. There's Devon who shows up a lot, too. Devon comments on almost every single code can be video I have. Devon's never asked me for anything, but I've learned lots about Devon. Devon Goble, I don't think he's on here right now. He's he's missing his streak. But there are lots of these people who have, you know, they've been in touch. They've they just they're networking, right? And they've never asked for anything, right? There was a a recent example. Um, and because Jonathan's mentioning commit your code, I just want to explain with a very simple example. Sorry, Tarzan is live. I I realize this is like the longest winded answer for your question that's conceivable, but I just I just want to keep rambling a bit. I So, Commit Your Code is a conference I'm going to speak to in Dallas uh later this week. I have a small speaking slot, but it's really cool. I like to I'm not a public speaker, but I get to try it out. So, um, I had originally gone to Dallas before and this is hosted by Danny Thompson and Danny was hosting a meetup and I went to speak there. Okay. So, I, you know, got to meet the people that attended. There was, uh, someone who had, um, you know, that I I met at that conference. We were talking on LinkedIn. We did, you know, good opportunity for a podcast interview to hear about like, you know, um, how they're navigating getting into the tech space. Did a podcast interview. That's a cool networking opportunity. I mean, for me, I get to have a podcast. That's awesome. And I think for that person, they were I'm assuming they're probably like, "This is pretty cool." And you know what happened? Someone who works at a company saw that podcast interview and they said, "Wow, that person's so good at focusing on communication with software developers. They reached out to them and offered them a job. I think they had to interview for it, but they offered them a job interview and that person got that job." So, like, is that guaranteed? No. Like I'm not saying that anyone who like sends me a message automatically like you know you're getting a job from somewhere. It's it just created the surface area for these opportunities. Okay. And that all started from someone who never asked anything from me. And I think that that's a my biggest recommendation is to start networking, start trying to form connections with people genuinely and do that over time. It's slow, but it creates a surface area for these opportunities. Um, sorry, And I don't know if um I don't know if I ever got to answering your question, but I I I'll try to answer the vibe coding thing. I don't Is vibe coding d uh ruining junior devs? Um, I don't think vibe coding is ruining junior devs necessarily, but um, I'm going to take this approach as in junior devs are ruining themselves with vibe coding, I think, is maybe what the question is. I think some are. Um, and I think it's just coming from a space of not really understanding. And that's that's okay. Um, cuz I think that there's a course correction that can happen. Realize my camera's aimed too low. Like if I'm sitting in my chair, it's supposed to be like this. But that's not I have to like slink into my chair to get on the on the stream here. I should have prepared this better. Um so I think with vibe coding, um what ends up happening uh is that there's a bit of misconception. And so I think there's some things that we haven't realized about vibe coding yet. And we won't have data on this for for years, I'm sure. Um, I'm very curious to see if people that get into vibe coding and like they're like, "I only know how to vibe code. I don't even know what I'm doing, but like I'm making stuff." I am super curious to see, and I mean this genuinely, if long-term that that ends up being a more effective way to build software. And I realize it sounds ridiculous, but I'm curious to see if that's the case. I don't believe it, but I'm keeping my mind open to it because I'm very curious to see if the way that tools evolve that you can just do that. You can kind of ride this wave of being like, I don't actually really need to know and I can get by and then the tools get better over time and you're so used to working with um um you know, with these AI tools. Okay. And I see there's a bit of a delay in the chat. Sorry, but no worries. reason that makes sense use of AI specifically to complete projects. Um, and I think it can be crippling, but this is I think I think what happens is that people um it's not a dumb question. I think it's a very good question. I think what can happen is that um people misunderstand what the goal is. And I've talked about this many times on code commute and at least a couple times on this stream, but I think people misunderstand the goal. So what do I mean by that? Well, we had this question uh from Tarzan is live about um you know uh applying to jobs and that kind of stuff and like you know what's one way to stand out? Someone might answer well you need a portfolio, right? You need a portfolio so you can stand out which isn't bad advice, not bad advice at all. But then what happens is that someone hears that and they go, "Okay, I need a portfolio. Well, I'm starting from zero. How do I get from zero to portfolio of awesome things? Okay. Well, like any human who's looking for the path of least resistance, if I need to go from zero to portfolio of awesome things, hey chat GPT, hey cursor, hey co-pilot, hey Claude, hey whatever else, you open up 10 windows and 15 terminals and you type a prompt into each one and you say, "Go build me the thing. I need my portfolio. I need it so I can stand out for my job, right? And then you have all these AI tools go whip up the most random stuff. You're like, cool. And you press play on it. It runs. You have a little website. Great. Take some screenshots. Push it up to GitHub with all of your secrets. And I'm just kidding. Don't do that. Um, and then so you you have these results and you go, "Yes, I have the portfolio, but there was something that was missing." And that is um you know the goal of the portfolio was not like can you have all of these these fancy projects. My opinion and this is just my own opinion. I think the goal of the portfolio is to show people that you are learning different things right you don't have the professional work experience. You're just getting started. It makes sense you don't have the professional work experience. That's basically impossible if you haven't worked. So right so you how do you get experience then? Well if you go doing side projects you go go do side projects go try to build things you create your own experience. It might not be professional work experience but you can say look I wanted to learn Android development. Okay, so I started building an Android app and I needed to store data in a database, but that means that I also needed to have a server to go store stuff on and like I don't know, I need to make sure that I can uh have updates to the server that's running. So I had to figure out cloud deployment. So suddenly you start building these things and you're piecing these things together and you like basically don't have a choice to go learning about them. But if all you do is go to your favorite LLM and you say go build me it, you won't learn. And I think that's the maybe when Ake is asking if it's crippling like or dangerous like I think that's the dangerous part. It's misunderstanding what the goal is for myself, right? Like there's things that I build now. I've been programming for over 20 years. There's absolutely stuff where I'm like I'm give me the shortcut. Give me the shortcut. I don't need to go spend time learning that. Why? Because like I'm I know it's a one-off thing. Like do it as fast as you can. Or there's things where I'm like, I know I'm not deploying this. I need a little proof of concept to see something working to see if I even want to go down that path. Build me the fastest crappiest thing you possibly can that just shows me the concept works. Great. or there's things I know that I can have uh AI go refactor some code or do some small UI changes or whatever else and it's mostly vibe coded and I go that's fine I can review the code I know what I'm looking for I've been doing this for a long time but my goals are different right like my goals are very different like what I would not be doing even with AI tools is I'm not going if say I wanted to leave Microsoft and I'm like I need like I haven't been programming at work for the last 5 years. I should have some projects to show and I got to catch up on those five years of not having projects. So, let me go use AI to go build stuff. Like, it's the wrong answer. I need to show that I'm learning about these different technologies. And really, blasting some AI stuff out, I don't think helps unless you are trying to prove that you know how to use AI tools, which could be interesting, too. So, um I don't think that's a dumb question at all. Um, I hope that perspective helps. I have to block this kick person for spamming my chat. Um, and then, uh, Jaban was saying, "Jaban, I don't know how to pronounce your name. I'm so sorry." Uh, no dumb questions. Don't take it like that if you don't know. Yeah. Um, Akib, you were also uh uh saying, "Can two years of internship experience in Unix administration help with getting an SE job?" Yeah. So, um, if you're not familiar, I have another YouTube channel called Dev Leader Path to Tech. And, um, on that channel, I do ré reviews. And one of the things I always say in resume reviews is if you have non-developer experience, you can absolutely lean into some of that experience and call out different things you were doing because there's a lot of uh experience that's not programming that you could gain from other jobs, other roles that could be very applicable for working in Teams as a software developer. Um, as a you know, Unix administrator. Um, I think that you have some technical things that will overlap, but I'm assuming from that internship there's probably even some non-technical things like did you have projects you worked on? Did you have to work in teams? What did that look like? You know, did you re you were an intern, but did you ever have to mentor other people like other other new interns? Like, you know, going through some of those experiences and calling that on a resume can be very helpful. Um, I can't pronounce your name on Instagram. I'm so sorry. Uh Kixi61. So sorry, there's probably two names or something in there. Um hello, good to see you. Thanks for joining the stream. Um I also saw Oh, a comment on uh networking. Definitely this is from uh Jabuan. Uh definitely slow. I finally got two tech lead referrals after three years of being in my job. or if that's for the um just the market I guess or maybe that was networking related but yeah things are things are slow but I just like wouldn't give up right like the thing is when things are challenging if you just go well then no I mean there's going to be other people that go well yes and then they stick around and then they they keep trying to make progress towards their goals so I would encourage like one of the reasons I try to make content and I mean this genuinely One of the reasons I try to make content is that I don't want people to give up on stuff because I have, you know, uh I have loved being in software development. I literally cannot imagine doing another career. I'm very fortunate and I'm glad that I got into things like when I was younger and I'm glad that I found that out for myself when I was younger that I really like to do it. So that's great. But like because I have gone through and been in the industry like I I I want that for other people that are interested and it makes me so sad to see people that are like oh like I don't think I could do that cuz I'm not smart enough or I'm not good at math or now it's like well it's too competitive and it's like I mean it for anyone like if you're interested please just you know don't give up on it. Please don't I mean I'm not here to say like if you literally need a job to like you know afford food and keep a roof over your head. Don't please don't take my advice as like well Nick said don't give up so I can't do anything else. No like you need to take care of yourself but don't give up on the goal that you're looking for. Like that's one of the reasons I make all the content I do is just to give you as many perspectives and different experiences I can so that you see what things are like in software development. Um cool and so a I'm glad I hope that helps. So uh thanks for your question. I think it's a good one. Jaban says I'm turning into a mid-level next month. I am learning more about systems as much as I can. what was your uh transition if you can get into that here. Um let's see. So okay so for myself when I was my my career is really weird um because I I became a manager like really soon in my career like really early and that's just out of necessity at like a startup. But um the other thing that's a little bit unique too especially compared to now is like there's a lot of web development and a lot of like people deploying systems uh a lot of web system or web services and like systems at scale. I didn't have that. We were building desktop applications. So the first eight years of my career after my internships were were building desktop applications. And it's kind of funny because like I said I had been programming by the time I had my first job. I've been programming for nine years after my my internships. I mean, so nine years. So for nine from nine years into like 17 years in of coding was almost all building desktop applications. Like it's a lot of desktop applications. So my what that looks like for me will probably look kind of different uh when I go to answer this. But I think I think for me like when I think systems, right, systems for me were not about um they weren't about how do I scale systems horizontally? How do I deploy things in the cloud and like horizontally scale and like deal with all this traffic? like it that's that's not a question I had to answer but something that I think like that I needed to start kind of seeding in my brain early like kind of going from junior to more mid-level was like and you kind of get at least for me like this feedback kind of happened like really quickly at a startup but we started to see like or I can say at least for myself you're like trying to deliver all this code right like we're at a startup every day it's like something new. We got to get these features delivered. It's really awesome. Really awesome experience. But it kind of like okay, but now I'm trying to do this part and like this thing's falling apart and like okay, but we keep going and then like now we're working over here and like okay now now we can keep progressing. We got to go back to this other thing and it's like oh man like not this code again. So like starting for me it was really starting to realize like a couple things like one um that there are some things like I it's going to sound cliche because I already talked about this in a different context but like some things we like literally need to slow down a little bit on so that we can build in resiliency. So things like uh different types of tests to have in place. I went through school we never learned about testing at all somehow. Like that's not important at all, but like yeah, we you know, okay, we got to have tests in place. Okay, well now that we're coming back to touch this code, like okay, like I feel like now that I'm touching it again, I feel like this is the worst code I've ever seen. And like I wrote it and I wrote it like two months ago. Like why the heck did I write it so poorly? And I think that I started to realize like not that I had a good solution for this, but we have to do something better so that every time we want to go touch code again, we don't feel like we need to rewrite it. So there was like starting to see this like idea around like what does it look like to not need to try and rewrite code every time you go to touch it? Because I don't think I really understood that. It was pretty apparent in my own personal projects, too. So, I'd work on something, take a break from it, maybe for a year or whatever, come back and I'd be like, "This is a cool idea, but like I cannot work in this code." I was never designing stuff or writing code in a way that you could do that, right? Like, um, and starting to realize like, hey, there's all these patterns and stuff we can apply, but I'm not applying any of them in a way that I would think is effective. So for me like that mid-level kind of time frame was like like pattern recognition and like going hm like I don't really have solutions for these things but like I'm starting to see like patterns emerging like code I write's terrible very shortly after um hey when we have some tests in places that seems to actually help us how do we get better at doing that I don't know um all sorts of things like this I think were kind of my my experience going to midle level. Um, I don't know if that helps, but that's kind of what mine looked like. And yeah, the weird thing was like I was also managing people at that time, too. So, um, should I have been? Probably not. Um, but I was. So, unique experience. Cool. I don't think there's any other questions. I'm going to go back to the article. We got about 15 minutes left. Or sorry, in Canadian, that's about 15 minutes left. Um, I'm Canadian. I'm allowed to say that. So, um, I talked last on this article about pairing up and like making some space to kind of walk through, um, you know, some of the poll requests, giving people the opportunity to ask questions and kind of invite them, right? Um, I think the next thing related to that is like I think sometimes more junior people get stuck especially on code reviews because you're like hey putting you on this review and they're like K like what do you like what do you want me to do with this right? Like what what's actually expected here? And sometimes like especially being more junior you may not actually have the experience to be able to offer feedback yet. And I don't mean that in like a condescending way or anything. You may be looking at this code that someone's put up and you're like, I just don't know what feedback I would give here. Maybe with more experience or more exposure to different patterns and things like that, you'd start to be able to do that. That's fine. That'll come with experience. But otherwise, you're kind of like, thanks for adding me. Like, I guess looks good to me. I'll just approve it. And I think that one of the missed opportunities here is like is is asking questions. So one of the things that asking questions can start to uncover is like this is going to sound weird. I don't really know a good way to explain this, but I'm going to try is like instead of going on to a pull request or a code review and then just reading the code and like trying to tell someone like you're doing this wrong or change this, right? You probably have experienced this at some point in your careers, right? Or if you're not working yet, like, you know, if someone's reviewing your code in any context, you're getting comments that are like, "Change this or don't use this pattern or whatever." Like the other thing that can come up that that's actually I feel like is more helpful is actually when people ask questions about things. They get you thinking and that's almost like immediate value that you can start to add onto people's code reviews and poll requests. But you can ask questions for you to learn, right? So if you're a more junior person, you're like, I don't know what this code does. Again, I think create the place and the space for people to go ask that kind of stuff and feel comfortable, right? That helps the juniors learn, but juniors can actually help the other people with their code reviews, not by saying, "Ah, like line 37, don't use that pattern." Like they they won't know or maybe they do, but you know, maybe not that common. instead like you could be asking questions about what the code does, right? So I wrote down in the newsletter article a handful of different examples of just like different things that you could be trying to think about. You don't have to know the answer. You're the one asking the questions. So like for example, you see a code change somewhere, right? So someone's changing code and you happen to notice that none of the test files were touched. Okay. Right. This is this is a pattern that we can pick up on. It doesn't mean that that's the wrong thing to do, right? Maybe they made a code change because they had someone could commit a code and the test was broken. So, they're actually going to make the change and the test should pass. Now, I don't know. But it's not like a rule, but you could say if you notice a situation like that, I happen to notice like, you know, can we talk about or can you describe to me like the code coverage for this or what does code coverage look like or do we have a test for this? Right? You can I like I said in the newsletter article, I wrote out a bunch of different examples. You can take that list. You can come up with your own whatever. The whole idea is that giving some junior developers some things to go feel like they can ask and explore. What's interesting is like they may go try to find those answers themselves, right? So that that example I just gave about tests, right? One of the things that you might want to consider when you're looking at a pull request is like, is there some test coverage on this change? Right? Do you do you know how to find the answer to that? You might, right? So you might go and look at the pull request and go, okay, I see like touch these three classes and like, okay, well, I do see that there were some test files changed. Let me go read that. And like, okay, one of these test files is for one of those classes. Awesome. And then like you don't see the other there's no other test files touched. Does that mean that there's no coverage on that code change? No. Right. It might be some type of functional or integration test and only the one test file had to get changed and we get the right coverage over the scenario. Like there's a million different things that could happen here. But the point is it gets you thinking. And one of the goals with all of this entire topic is about trying to expose some of the junior developers to things where they can learn and grow. These are all things that aren't going to be like boom immediate like juniors are, you know, all-time high productivity. It's going to take time. So, give them some tools to work with so that they can practice and learn. Um, I think something this is like another sort of generic thing, but you can apply this as well. Um, time boxing I think is super important. So, you know, if you're setting juniors up to go helping like looking at code reviews or anything else, like set some type of expectation for them. say, "Hey, look, like goal is like, you know, I want to have this reviewed by the end of the end of the day tomorrow." So, like, you kind of have like half of today and like the full day tomorrow, but like I don't want you to like feel like you don't know what you're doing the entire time and then like not ask questions and then like get nothing done. So, like let's time box this so you have some opportunity to ask. you know, if you haven't responded to me, I'm just making this up by like, you know, tomorrow morning or something, then like I'll reach out and I'll check in with you. But kind of time boxing and setting some expectations, I think can be tremendously helpful. Um, I know for myself, I shy away from this a lot because I don't like sometimes I feel like it's micromanagy and for me that's a huge like cannot stand doing that. But I have learned a lot from junior developers that setting little milestones like that can actually be extremely helpful because it makes the expectations more clear, right? And if you were to go sense like this is a thing for uh for problem solving um letting junior folks get a little bit more stuck and letting them think through things and try to like be resourceful and figure things out, that can work really really well. Just time box it, right? Because if you're like, "Okay, it's been a day. It's been a week." Like, "What did you leave them stuck on for a full week that they couldn't get done?" Like, that's maybe that's too much, but maybe, you know, stuck for 15 minutes is too short. So, like working with them to find a sweet spot where they can try learning, getting stuck, and then you kind of help them after. Um, I see a message in the chat. Uh, should someone who comes from legacy.net what forms learn MVC or Blazer? Uh there's sort of like I don't know. I think Blazer is the like if you're building Oh, what's a good way to answer this? I think depending on what you're building, right? So like if I were building frontends in .NET, I would just go Blazer personally, but I think it's like they're just different technologies to play with. Um for me like I build ASP.NET Core backends. I have some some more like uh internal tools and stuff like that that are Blazer. My blogs in Blazer. Um so like just give me one sec just so people know what's like it's a real thing because everyone's like oh Blazer you can't use Blazer for production things. Um is that coming through on the stream? I think the answer is yes. So like this website I mean it's nothing fancy but this isn't Blazer right? So, if you wanted to go read my blog post, right, this is uh one of the newsletters I put out every week that's just like snapshots of stuff and then like my actual newsletter article that I'm talking through right now. All right. Like this is a Blazer site. So, like it's all you can totally use it to build, you know, real things. They don't just have to be internal apps. Uh, I find that right now, like especially if I'm building stuff in smaller teams, like out outside of work at least, because I don't do any UI development or anything at work, um, we might like I would go straight to a C# back end and then like probably some type of react based front end personally just because the the um I don't know like the support the community just feels like obviously more mature for for JavaScript. front ends. But um if I wasn't building in a team and it was just me, Blazer, like 100%. And not because, and I'm saying this with complete honesty, not because I think Blazer is better than everything else. Blazer is probably the better tool for me because I live and breathe C. I'm not saying that's a good thing because if I spent more time in other languages, then I'd probably be even better off with some of those other ones. But um I hope that helps. I I don't know like I don't I don't think there's a right or wrong answer, but that's kind of how I approach things. Carlos, welcome back. Um how do you deal with pressure as a manager when things are not going well? Example, the team is behind schedule. You know, the team can't work fast or upper management complaints. Yep, this is a good question. uh mostly panic and uh I would remind people that I used to have hair on my head as well and my beard used to not be white and then the stress kicked in all of the hair left and my beard is white. Um but in all seriousness I think uh handful of things. One is that for me personally uh number one thing that I try to focus on at least for my team is and I don't I'm going to say this I'm not saying it's like the right thing but this is like my sort of philosophy is like when there's a lot of pressure I try not to make I try not to add that pressure onto my team. I have never been in a situ and I mean this in all honesty. I have never been in a situation might just be have been very lucky where my team and I were under pressure and like they didn't feel it from someone else other than me. Like if there's pressure coming in, it's not because I'm the one like you better get to work. We're under a lot of pressure. they're already feeling it from someone else or sort of like an organizational pressure or some deadline. They already feel the pressure. What they really don't need really don't need is me chasing them down, adding more to that pressure. So, sort of rule number one for me is like I might be under a ton of stress and if I'm feeling a ton of stress, I know that they're feeling a ton of stress. I'm not adding to that. or I will do my very best to not contribute to that. I almost have to play the opposite role, right? Hey, talk to me about what's going on, right? Like, are you stressed about this? Like, how can I help? Like, I need to make sure that they feel heard and they feel seen because doing what feels like the opposite of like, okay, well, you know, there's a lot of pressure. Like, I got to get status updates and move things along. Like, you literally don't help anyone when you're doing that. And so I say this as someone like when I was a manager for the first eight years of my career, I was an IC at the same time. I literally know what it feels like to be in the position where you have someone like chasing you down for updates and you're like, man, what the hell do you want me to do? I'm literally working as hard as I physically can on this. you trying to like chase me down like micromanage every step I'm doing is just not contributing in any positive way. So again my my rule number one is trying not to add more stress to the team. I think rule number two for me is I try as best as I can to like to I guess I don't know a good way to say this like almost like shelter the team as much as I can from additional stress. So when I understand the source of that stress, is that another team? Is that my manager, my skip? Is that some part of the organization? I try to understand where that pressure is coming from and do a bit of shielding. Why? Because they already are under pressure. Like it just you literally do not help when you add more. They're adults, right? like I'm I'm going to be 37 in April. If I know that there's a deadline for something and there's a lot of pressure, you know what? I don't need someone treating me like I'm not an adult trying to add more pressure. It just feels ridiculous and it makes me not want to do the work at all. So, trying to do a bit of shielding and try not to add more pressure for myself. The other thing is like I've worked on some projects that were really stressful and and really over a long period of time I try to make sure that I what's it again I don't know if if this is like a good strategy or not but this is something I try to do is like if I'm the person that's leading the team I want to like make sure that I can stay strong for the team. So what I don't want to do is kind of cave into the pressure and make the whole team that I'm leading think like I'm falling apart too, right? Which means that I need to make sure that I'm in a position where I can listen to the team. I can take on their burdens and as much as possible like not fold under the pressure as well. I need to try and alleviate their pressure. if that means taking on some stress myself even more, um, then I will try to do that. That's what I'm saying. I don't know if that's actually a good thing, but that's part of my my strategy with this kind of stuff. This is all kind of like internal and like how I navigate as a person, but sort of externally like things I try to do um, like when I say externally like outside of the team is when there's pressure a lot of the time this comes from not understanding visibility. Right? For example, there's a deadline coming up. You're feeling a lot of pressure. People keep asking for status updates. They don't have confidence that the date's going to be hit. They don't have clarity. They can't see the details of what's happening. That's why people do this type of reaction where they're like, "What's the update? What's the update? I need the status." Cool. Okay. So, there's a gap in you understanding visibility and status. What can I do to be proactive about that? How can I give you status? How can I get ahead of that to try and build confidence in you? Furthermore, if there's things that are not on track, like how can I put my hand up and say, "Look, this thing over here, we need extra help." Right? If I had I'm just making this up, so don't attach this to like my current manager, my current skip. But if my manager came to me and was like, "What's the status? What's the status?" Um, or my skip was trying to chase me down. I would be trying to find ways to give them information they need ahead of time. And then I would also be like, "Hey, look, if this thing's off track, if I need support, my team needs support, I'm letting you know right now, I need help. My team needs help." Because if I don't tell them, that's where we're not going to build trust. That's where something's going to go off the rails. That's where they're going to say in a retrospective like, "Why didn't you ask for help? Why didn't you let us know? We could have tried to do something to help." Right? So I think communicating a lot overcommunicating even and doing it um you have to kind of level up or sort of regulate your communication of the different levels of stakeholders that you're talking to. But I think yeah overcommunicating is like one sort of proactive thing out of the team that I try to do and otherwise um you know I my role as a manager is to support my team. So, whatever they need, whatever that looks like, that could be very situational for some individuals. Maybe honestly, maybe some people need to rant about what they're doing. Maybe some people need help coding. Maybe some people are blocked by partners and they're feeling really stressed. Maybe some people are blocked by people internally having conflicting opinions and I need to jump in to help moderate that. Could be anything. So, um, it's really about listening to people on the team, trying to shelter them from additional stress, and then communicating, uh, as much as possible. So, uh, Carlos, I hope that helps answer your question. I think that's a good one. I'm certainly can always improve on it for myself, so we'll do my best. But, um, yeah, I'm trying to think if there's anything else I wanted to add from the article. Okay. Yeah, to wrap it up, I kind of hinted at this earlier, but um this this last section I wrote here was really like if you're avoiding sort of uh where the the challenge is coming from. And this again for folks that have joined a little bit later talking about um you know junior developers being effective on code reviews. If you say look like the juniors are the ones that are slowing things down. Therefore, if we just avoid putting juniors on this stuff, avoid the problem, you're actually just perpetuating it. And it shows up in different ways. So, I put an analogy in the newsletter article where essentially I'm just using on call as an as an example. It's really hard to speak as an example of this because I've seen this happen across multiple teams. Okay? not not one, it's not like it was a coincidence, like not two, but like across multiple teams. And what ends up happening, it's pretty typical, is if you have really experienced people on the team, they're the ones when there is something that's on fire, right? They are the ones who can most likely fix it the fastest. They have the most history and most tenure on the team. They can debug and troubleshoot stuff really fast. they can come up with the strategies to roll out the fixes fast or to to mitigate like they can fight fires really well. Why? Because they've done it a lot. Okay. Now, what happens is that if we perpetuate this where we say anytime there is a fire, you put the person who can put it out the fastest in charge of putting it out. What ends up happening is that you don't allow the other people on the team to build up that skill set. Furthermore, you take the people who are most experienced who probably need to spend more time on, I don't know, like higher level work like architectural design or coordinating with different teams and stuff. You take them away from that work to go fight fires. Kind of a both parts of this aren't great. But what you get is the fire is put out as fast as possible, but you perpetuate the problem that only the really good firefighters can put out any fire and the non-firefighters can never put out any fire because they have no experience doing it. So, I think that I'm not saying that you you never let the more experienced people put out fires, but try to think about having people who don't have experience yet try some of the low hit my mic. Try some of the lower risk things. The same thing on like a poll request in a code review, right? Hey, this is something that's like a stepping stone. Let's get through this. Help you learn something about it. with the on call thing. It's like, hey, this is I could probably go figure out how to, you know, mitigate this, but this is a good thing for you to go investigate, right? Maybe to get someone to go root cause something. So, you mitigated it. You put out the fire because you're the senior person. And then you have them go, you guide them through some root cause analysis. Like, letting them take on some of the things that they're not comfortable doing can be really helpful. This goes back to slow down to speed up. Yes. by having people who aren't experienced go fight the fires, mitigate things, do root cause analysis. Yes, it's going to be slower. It's going to be slower because they haven't done it before. It makes sense. But this is the kind of thing that over time they will get better at doing it. There are more people available that can do it. And that means that over time you start to reach this point where the more senior people can get back to doing the more senior stuff. You have more people on the team that can put out fires or to jump on code reviews and understand stuff. This is exactly why I strongly believe that you must always try to have a range of different levels on a team. You can't just stack a team full of principal engineers and go we have the best team ever. It just doesn't work that way because all the work that you're doing is not going to be like for the level of a principal engineer just the same way that it would not work if you put you know only people brand new in their career on a team. You have eight people that have never worked before and you're like great we run a live service they're not going to be equipped to do it. So different levels of uh experience can tackle different challenges with work. And I strongly believe that you want to try and get people challenged, which means you're not always putting the fastest, most effective person on that thing. So if you're a manager, if you're a team lead, if you're the more senior person and you're like, man, like I keep I'm the one who always has to put out these fires, think about how you can try slowing down, right? How can you get some of the more junior people to help with that so that over time they have more experience doing it? And I think that's it for this stream mostly. So this is where I switch over. I do this kind of thing and I will share links and stuff with folks if you are interested. So this is where I have my newsletter for folks on Substack. You are already in the right spot. Big surprise. Um so this is it. This was uh created with nano banana and I think it did almost okay, but like this part of my face is not real. That's not real at all. It's way too smooth. Even this part's pretty smooth. But I think it did okay on this side, but like that's not my eye. There's no way. Not at all. But anyway, that's it. This is uh just to click on it. You can see this is the newsletter article I was going through. I kind of showed it a little bit earlier. Uh most of the time, like I said, it's based on a code commute video. So, this code commute video, if I jump over to code commute, just to show you quickly, uh that's this one here. It actually had um I don't know, like my YouTube channels don't get a ton of views. I make a lot of videos, but this one had 4,000 views compared to like I don't know 75 to 200. These ones did okay. Like 500 to a,000 kind of range. But yeah, this one had, you know, 4,000 views. That was the topic we did. So again, if you're interested, right, my newsletter articles have the code commute videos right on them. You can check it out. Um, I'm going to go through my other channels and stuff, but um, I have the Dev Leader podcast. This is where, if I refresh, the YouTube live stream should be going here. And it is. I'm live right now. Surprise. Um, I interview other software developers on this channel and then I host this live stream on this channel as well. And so some of you might not know these people. Um, I have a couple people that are like .NET developers. So if you're a .NET developer, you might recognize some. Um, so like Hassan Hhabib, uh, Scott Hansselman who is a VP at Microsoft. I think like every .NET developer knows, uh, Scott Hansselman. Uh, Derek K. Martin is of code opinion. He's really good at explaining things. I love that. Um his content is like like he there's no bias. He's very good at not having bias when he's uh walking through things for pros and cons analysis. So really enjoy Derk Martin. U Dev Leader is my main YouTube channel for folks that don't know if you want to look at you know how to program in C or AI tools and stuff like that. Um, this is my main channel. Um, this where all the the goodness is. It's kind of ironic that like yeah, most of my videos that I perform well are just like old. A lot of my content is like very much picked up in search. So like, you know, two years old, two years old, two years old, two years old. This one was about AI, so it didn't take two years. Um, a year old. It's just kind of how it goes on this channel. very slow to grow, but um my goal is that I have helpful information for folks. So, you can check out Dev Leader and then Dev Leader Path to Tech I hinted at earlier, but I do resume reviews on this channel. Trying to paste the link in the chat. Um so, you can submit your resume for free. Um I split this channel and the podcast channel out for my main one to try and help with traffic. Um I think the answer is right now that's not working at all, but I'm not going back. So, whatever. Here we are. If you're interested in having your resume be reviewed, you can submit it uh by watching one of the videos. It'll explain how. What else we got? Code Commute is on Spotify. If you want to check it out there, uh the podcast is also on Spotify, just not the live stream part. Code Commute, if you want to submit questions anonymously, you can go to this page here. There is this little button you check. Boop. And then whatever you type here just gets emailed to me. Um, if you're going to submit questions to Code Commute, it helps if you add a lot of context, the more the better. Um, when I get really generic questions, you kind of get generic answers. So, it's how it works. Um, otherwise, yes, I have courses and stuff, you you knew there was going to be a sales pitch, right? Um, I have courses available if you want to learn how to program in C or if you're interested in things like career development, getting promoted, uh, behavioral interviews, this kind of stuff. That's on Dome Train. Um, for those of you that don't know dome train, especially if you're not a uh not a net developer, you may not know, but Nick Chapsis is one of the biggest .NET YouTubers in the world. And so he runs dome train. He brings on industry professionals that can teach the topics that are on domain. So, I got I got picked. I must be an industry professional. That's right. And so, I got to uh you know, I got to cover the getting started in deep dive Courses. So, those are two things I'm super proud of. Um, for what it's worth, I lose a bunch of money making YouTube videos from editing costs and that kind of stuff. I would love to say that the ad revenue was so good, but it's terrible. Uh, so courses pay for me to have my videos edited and stuff like that. So, uh, courses really help cover my content creation. And speaking of content creation, if you're interested in the stuff that I build on the side, Brand Ghost is the social media and cross-osting app that I have built, uh, this is what I use. If you follow me on any social media platform, if you see the post that I make, um, it's from Brando. And so, I built Brando. It's in.net. It's hosted in Azure. Um, if you ever want to know the tech stack and stuff, I'm happy to share and talk about it. But, um, if you are a small business and you're like, "Hey, like we're not being consistent with our social media. It takes too much effort to post." Send me a message. I'm happy to get you started with Brand Ghost. It's literally completely free to start with crossosting and scheduling. There's a a trial period, but it's also just free for crossosting and scheduling. You don't have to put a credit card in anywhere. And I feel very confident that if I can get you started and being consistent with this kind of stuff that you will be interested in the paid for features because you'll see the benefit that we that we add. So, um, feel free to reach out to me on any platform if you want to try it out and you're not sure where to start with your content creation and I am happy to try my best to help. With that said, folks, thank you so much for being here. Um, next week's live stream because I'm doing a conference talk on Thursday, this Thursday, I will be recovering my conference talk on the live stream. Um, it will have code. We'll be going through some C# code and we'll be talking about plug-in architectures. So, would love to see you there. Thank you so much. See you next week.