Navigating Evolving Code Standards Without Chaos - Engineering Manager AMA

All right, just waiting for the streams to be streaming. Should be just a moment here. See some of them coming through. Instagram's usually the last. There's Instagram. We are good to go. Welcome folks. Um, if you are new to the live streams, welcome. Appreciate you being here. Uh, on these live streams, they're definitely an AMA format. So please by all means I'll be watching the chat. I encourage you to ask questions, participate. I have a topic for the day. But of course if uh you want to ask other questions about software engineering career stuff, just ask it in the chat. I'd rather spend the time on that. Uh welcome folks on Substack. I have you a little bit more elevated this time. Still not a first class experience with reream so I can look at my camera. still got to look at my phone, but um I will be watching the chat. It's kind of hard to see, so I apologize. If you're on Substack and you want a better viewing experience, if you want to check out Dev Leader on YouTube, that's where I would recommend until Substack kind of has this as more of a like a first class kind of thing because it's only supported on mobile and it's kind of a pain in the butt. Um, hey Justin, good to see you. Thanks for joining. Uh I apologize. Last week I wasn't on. Um, I had a busy on call shift and um, we get on call days off and I took my on call day off. AI won, brother. AI did not win. Not yet. There's still time. Um, it's ticking though. We'll hold out. Um, but yeah, I took off last Monday. It's my birthday on the weekend. So, um, last weekend. So, I had my on call shift. I had my birthday and then I said I'm gonna take Monday off and do absolutely nothing. So that's what I did. Hey infected FPS, good to see you. Thanks T man. Appreciate it. Um but yeah, I was just like I needed my on call day off. I needed to disconnect. I didn't write a newsletter. I did not stream. I just needed to be off. And so good to be back. I appreciate you folks joining in. Um the topic for the day, I'm going to link it from my newsletter. Let me put that into the chat. If you're on Substack, you already know what's up cuz you're where the newsletter is. But, um, it's at weekly.devleer.ca. Um, I say this every time, but if you think newsletters are dumb and you don't want to subscribe and get email, that's totally cool. I do not blame you. I work at Microsoft and I get like thousands of emails a day. One more email would push me over the edge. I get it. Um, but if you are interested in the topics at least, then uh you can check out the Substack page. Uh, you can read them like a blog. Uh, I have to go back and archive a bunch. Spoiler alert, there's a bunch. Actually, maybe I did this already. Um, I keep them unpaywalled for a month and then they go behind a payw wall. So, we're at 91 issues. So, there's roughly 97 of them that are paywalled or math 87 of them that are paywalled now. Um, but you can go check those out. Like I said, they're totally free. You don't have to subscribe if you don't want uh for the first month of them being posted. In fact, at FPS, what level am I at now? Did you say did you change your message or something? I'm pretty sure it said, "How old are you?" or something. Maybe it didn't. Maybe my my brain tricked me. I am level 36 now. Um, according to my wife, I am now officially in my late 30s. And I tried to explain to her that that's not correct. Um, and I will I will die on this hill. But it's if you wanted Okay, I claim that I'm in my mid30s. And the reason that I say mid30s is because if we were to break it into 30s. Okay, so if we break it into threes, we got the beginning of your 30s. We got the middle part. So like 34, 35, 36, right? And then like 37, 38, 39, that's your late 30s. I'm 36. I'm in my mid-30s. And she says, "No, that's late." So I'm very curious. And she's never explained to me what the definition of mid30s would be. Is it exactly the instant you turn 35 is now boom, mid30s. And like 1 second past that, you're now in your late 30s. I don't buy that. Right. So um, uh, hey Gaming, good to see you. Jonathan Baron tell her. She's also in her late 30s, too. See how that works out. Nope, I won't do that. Um, 33 claim mid-30s. Yeah, there you go. Right. Mid-30s, I'm with you. Oh, sorry. I missed your message. Infected FPS. Just turned 36. End of March. Welcome. Well, I guess you should welcome me because I came after you into this uh into the 36 club. Um, yeah, that's mid30s. Like I said, I'll die on this hill. Um although I I won't because I kind of just surrendered to my wife and I said sure whatever. Um we we know that she will be right. Um that's okay. I've accepted it. But to everyone else, no. Um mid-30s. Um yeah. See, Gaiman uses mid-30s would essentially be 34 35 36. I think that from what I'm seeing in the chat, everyone has agreed on this. I'm going to I'm going to 39 is 26. Oh, no. Um, yeah, I think I think that's right. Um, I'm going to go with that, too. So, you are mid. Yes, I'm mid in general. Um, I'm going to screenshot the chat. I'm going to send it to my wife. Um, can I I'm recording on my I'm streaming on my phone. Anyway, she's not going to watch the stream, but I'm going to send it to her. I'll report back on social media and uh let you all know how I was very wrong. You already know that though. Um, but yeah, it was my birthday so um yeah, I took took the Monday off. So, thanks for joining back a week later. Healthier at 42 than I was at 26. So, there's that. That's awesome. Um, yeah. I think, you know, there's a lot of stuff that like I think when we're younger, we kind of have we got a lot of stuff on our side, but if we're not taking care of ourselves, not paying attention to certain things, it's easy for us to take it for granted. And sometimes it takes a bit of a wakeup call for folks, which is unfortunate, but like still fortunate that we have the wakeup call to get things back into gear, right? So, um, I I kind of said this I've said it on stream before, but like for me, like I obviously I'm a computer nerd. I love sitting right here doing computer stuff and programming and all that fun jazz, but uh I'm not I don't play sports. You know, the my physical activity is bodybuilding, which some might say, well, that's great, right? Like you're going to the gym every day. And I'm like, yeah, but here's the problem. I'm 5 foot4, so I'm pretty short by basically every standard possible. And at 5 foot4 when you're carrying a lot of body weight, doesn't matter if it's muscle or not. And I'm not I'm right now I'm not in my my prime, but um it doesn't matter. Like your body is like that's a lot of effort. So it's not healthy for me to be 5'4 weighing between 180 and 200 lb. even if I end up carrying more muscle than the average person, it's not good. So, I switched, right? I was uh dieting down for two bodybuilding shows. I was 6 weeks out from the first one. I said, "No, like I've done this before. I don't need to go on a stage again. I think that's a legal It's close." Um, yeah. Yeah. I mean, I'm just reading the comments. I actually don't know what the the proper term is either, but I understand no harm was meant. Um, but yeah, I, you know, I withdrew about 6 weeks out and I said, "No, not worth it." And then after that, I said, "Well, you know, I I enjoy bodybuilding from what I do in the gym. Oddly enough, I enjoy just like the really regimented diet. It's just very easy. Just make the same thing in bulk and eat it every day, multiple times a day." Some people go nuts from that, but I love it. Um, so when I stopped doing it and I started going to CrossFit, it was more for let me get my cardiovascular health up and um, it's been less than a year, but oh man, it is brutal. Um, I am still terrible at CrossFit. For folks that watch Code Commute, you'll know because there's some videos I get into the car, I'm just in shambles, like sweating, I can't breathe, and I'm like, today's topic and then I'm like dying. But um thank you for watching code news. Yeah, but it's uh it's good, right? We have um we have tools at our disposal to try and get our health back in shape. So good to see Devin that you are healthier at 42 than 26. You know, we got to pay attention to this stuff. Okay, but that said, uh I'm going to dive into the topic for today. And I just want to remind folks because I see there's more people in the chat now. If you want questions answered, just literally drop them in the chat. anything you want uh within reason. Uh software engineering, career focus, happy to try and direct the conversation there. I will be going through the newsletter topic, right? Uh if you if you've been here before, you know how it works. And I will try to glance down and catch up on the chat. If things get out of control and I miss a bunch, I'll scroll back up and try to do my best. But let's dive into it. Um I put the link in. Um, and so the article is called Navigating Evolving Code Standards Without Chaos. And then I put together this fun thumbnail on Canva. If I share my screen super quick, boom, look at that. That's my stupid face. And then look at this Canva artwork. It's beautiful. Um, it's not beautiful, but hey, you know what? It's not my my skill set, but I'm trying. Um, so a lot of the topics that I do in the newsletter articles are from Code Commute. So if you haven't seen Code Commute yet, let me do a quick uh shout out to Code Commute. Here's a link to that channel. I know there's a few folks from Code Commute that are tuning in. Um, full stop. That's beautiful. Thank you so much. Um, but yeah, the topics generally. So on code commute, I vlog about things um software engineering related. On a day like today, I got two videos done going to and from CrossFit. Then I got another two done going to and from work. I got four videos recorded just today. It's a good start to the week. Um but I like taking those topics which are very much a stream of consciousness kind of like these live streams, but I don't take questions while I'm driving because that would be reckless. And it's not live, it's recorded. But um I take those topics. So when I write my newsletter article, I look back through the week and I said, "What did people seem to watch a lot of or engage a lot on?" And this was an interesting one. So this one was about um code bases and how they evolve over time and how to approach that. But it was based on a Reddit article or Reddit post, not article. Um the post was interesting because it was someone asking about a situation where um essentially they have I'll kind of paraphrase it, right? But they had someone who's on their team and they were working in the frontend part of their code and in that part of the codebase it seems like there wasn't a lot of people that had a lot of experience there. So they were kind of like sure like do what you got to do make it through that that's fine. Um, and then when this person started working more on the backend code, which is where the original poster was spending more time, they realized like this person's kind of like blasting away code, like they're they're rewriting everything. So, you got to go do a feature here. Cool. Let me start by blowing away everything and rewriting it and then pushing up the new code and then great, now I'm done. And then what was happening on the reviews and stuff, maybe I'm confusing two articles, but these are both from last week. In this case, what was happening was that this person was basically arguing and saying like, nope, like, you know, this is the way to do it and I'm leaving the code in better shape. I am confusing two articles. They're but they're both really good. And um so it's kind of ridiculous because what this person's doing is just like they're not learning how to read the code. They're probably looking at it being like, I don't know. And then blowing it away, right? Rewriting it. This actually might be from two weeks ago. Now, this other post, which I think is what this one's actually about, um, is this uh, this engineer that's not actually following the standards. And let me reflect on this one. So, we had the person that was I should have I knew this was going to come back to bite me on Code Commute, but I'm like, I'm not linking the Reddit article. I should have linked the Reddit article. Um, the what was happening in this article? See, now I'm I'm on the spot and I'm drawing a blank and I'm gonna get super embarrassed, but it's a live stream, so you can't really do anything about it. Um, what happened in this article? We could watch it on Code Commute. Um, Devin, you you watch this. What happened in this article? Why can't I remember? Because I I'm I have these both confused now. I could probably go look it up on experienced devs. I have the internet in front of me. I'm not sitting in the car, right? So, one sec. Um, I swear this doesn't always happen. You say not following the You mean not patterns of the codebase? Yeah. So that's I mean I wanted to recall what the actual po the post itself was kind of funny so I wanted to go through it but uh maybe we can just forget that for a moment and I will come back to it but because I want to circle back by the end of this and find the the article but coding mountain man says when you say not following the standards do you mean pattern of the codebase and that's exactly it. So, the whole premise of this article is that when you have stuff that goes up for review, right, there's going to be situations where um someone will put up a pattern, right? And people will review, oh, this is what the situation was. I totally remember now. Thanks, Coding Mountain Man. Um, so the idea was that someone was putting changes up and uh someone would say, "Hey, like you know, not that standard or that's not how we do it or whatever and giving them feedback about the change and the person was just like marking it as won't fix and then dropping the reviewer off. Bye." Um, and this is just what they did. Maybe it was the same post. I can't remember now. But anyway, the person who was writing this particular post was like, "What the heck am I supposed to do about this?" Right? Um, basically, it's like someone going rogue. So, the whole, not the only point, but one of the points for having a code review or putting a poll request up is that people have the opportunity to look at the code that's been written, offer feedback on it. Some people will have different perspectives on this. Some say you don't even need pull requests or code reviews. Some people say it's too late for this kind of thing. Everyone's got a different opinion. One of the things you can do though is take this opportunity to look at the patterns and practices and catch things before they go into the codebase. Okay. So, in this Reddit post, what was happening was the person was if they had a comment they didn't like, they just said won't fix and drop the reviewer. So, the original poster was like, "How do I get help on this? Like, when do I escalate it? Is there a coaching opportunity here? I don't know what to do. And I figured, you know what? I think this would be a good one to write about because this is something that's not not necessarily the person dropping reviewers off and saying won't fix, but this is a very common thing that happens in code bases. You're going to have um in terms of evolving code, you're going to have a code base that changes over time. the longer that it's around, the more that the team will learn. I hope so. If you had a brand new codebase, right? Uh if you've started Greenfield projects, chime in in the chat. If you've never worked on a brand new project at work and you've only ever worked in what would be called a legacy codebase, let's hear that in the chat, too. because I think you'll see a huge discrepancy probably where there's more of one audience than the other where it's going to be very heavily skewed in one direction I would suspect. So if you've been working in a codebase that is has been around for a while, all code bases we try to start off with saying like we're going to follow these practices like it's a fresh slate. We're going to do everything perfect and you might make some decent progress that way. Deon says, "Yeah, there was one about the person rewriting everything. Then there was another about one person not following standards or backtoback videos." Yeah, probably probably done in the same day. Thanks, Devin. Appreciate it. I knew I could count on Devon for that. Um, but yeah, if you if you've been working, you know, in a codebase, the beginning generally things are like, we got this, it's going to be perfect. And what happens over time is like things start to deviate. And yes, there are things you can do like refactoring. There's, you know, you can set the standards. You can try to do all of these things. What will happen over time is that the codebase will drift. It's inevitable. If the codebase is going to survive for years, it will start drifting from what it started as originally. And I don't think that that's the end of the world. I think it's a very normal thing to happen, but because it's a normal thing to happen, I think we have to talk about it. Um, Tayman says, "I worked in Legacy, but another teammate rewrote the whole thing while I maintained it. It was kind of a pain. Yep. Um I've done a couple of rewrites. Um when I graduated from university, the first like startup I worked at um I did a did a rewrite of one of their products, but it was uh everyone else is focused on like the main part. And they had converted the codebase. This is kind of wild. They did like a a converter that went from Visual Basics 6 to C. And um from there they had one of the products that way and the other one was just like in shambles. And because it was VB6 it wasn't multi-threaded. So you needed to run two processes to get the ability to multi-thread things. You needed multiprocess. There's no multi-threading. So um I remember I just like I had to take it upon myself to go rewrite the second application which was much smaller. Um, and it was like Windforms. So, like I had a ton of experience doing Windforms even though it's like my first job. I just spent so many years like building like stupid desktop apps. So, um, I did a rewrite very early on. Uh, I was part of a rewrite that we we still had to maintain stuff while another team was rewriting. Just like it's chaos. Um, but anyway, uh, welcome back, Harry. I didn't have one last week, so you're forgiven for for joining. Good to see you here, though. So, yeah, code bases, they're going to evolve over time, and we should talk about what that looks like, right? So, in the article, I said, uh, legacy patterns that no one really likes, but they're everywhere. You're going to have newer preferred approaches that aren't widely adopted yet, right? So, you start to say, "Hey, this is a new way of doing things. Let's start doing it." But if there's a hundred other spots in the codebase, do you go try and patch all 100 of them every time you do a new thing or do you let them drift? Right? There's you could do trade-offs here. Um you have well-meaning developers copying the wrong example. Right? So if we take that code review example, um what could happen is that you're in this situation where someone's like, "Hey, I'm working on this feature. I see this pattern over here. I copied. I pasted it. and you know obviously tailored it but I'm using the patterns that are established and then someone on the review is like that was established like two years ago but we've come like two more levels of indirection from there sorry uh you should go change this and then you do what the person on the Reddit article did and you just say you won't fix and drop the reviewer right so we don't want to do that no um you have frustrated reviewers trying to correct course or like this uh Reddit poster um and then unfortunately you can have situations where people are debating this stuff heavily on the reviews. If you're from code commute, you have to remember I talk about this on code commute a lot. If you're having long- winded discussions in code reviews, go discuss it offline. Get on a call, get in person, whatever it is, discuss it, speak to people like humans, and then go document it back on the review so that it's there for historical purposes. But going back and forth writing novels of comments, it's like having a a Twitter debate, like don't it's not going to be productive. Um R, I don't know your full username, but it's just R and that's awesome. Only found out you do live streams a couple of days ago coming from code. Awesome. code commute is where it's at. So, thank you. I appreciate you being here. You'll notice that these are very similar, but there's a chat, so I can use the chat. Um, and Andreas, uh, you're very welcome. Uh, happy to try and do these. So, take advantage of the chat, ask questions, anything I can do to try and help, I will do my best. Um, so when we talk about standards and code bases, I think it's important to acknowledge it. We want to set standards in my opinion to be more like guidelines. This is the direction we want to go. It doesn't mean that we set the standard and therefore everything must match. It must be perfect. There might be some things in terms of like um like linting and stylistic things or things that you can try and correct right more automatically with tooling like that's great. But I think for a lot of what we see in terms of tooling, we're not yet able to do that in terms of design patterns and more like architectural things. I will give a little bit of a spoiler. There is someone that I used to work with. Um I'm hoping maybe in a couple weeks I'm going to take a week off from work after um after April's done. So the first full week in in May, I'm going to take off from work. I'm hoping this individual has some time. Um, he's been doing a bunch of work in terms of refactoring, so like code generation. Um, so if you're f he's a net developer. Um, if you're familiar with like Roslin and and code generation and things like that, combining that with AI for some refactoring tools. Um, he's put together some interesting things. Um, he's been trying to do a he he wants to try doing a little bit more content creation to share this kind of stuff, but I think that um you know, very early on with it. It's it's obviously very uncomfortable to get started, but he's interested, right? So, I said, "Hey, like I want to try like I see a really big use case for what he's what he's putting together." And I said, "I want to try getting some videos and stuff uh put out for him." And um in a nutshell, the idea would be like, you know, we have like agentic programmers and we never have to code things again and we can all retire and live on a beach because AI just does our jobs. Well, I think a really interesting use case for for agents would be like this scenario right here, right? We have a code base where there's patterns that um it's not something that could be linted easily. It's not like you have trailing whites space. let's delete the white space or you don't have curly braces on new lines. They're like at the end of the whatever it's not consistent. You could use llinters for that. But if you're like we don't use this design pattern or this one's not really good. You can build things like Roslin analyzers and net. But like is there a like a a hybrid where we could have agents going and running and automatically refactoring code for us to try and bring up the standard of the codebase. I think that would be fascinating. I would love to use that. Like, hey, this is the new pattern. Go across my 50,000 other lines of code and go look for the old pattern and use the new one. And just keep doing this every time I'm coming up with the new patterns. While you're at it, make sure that it's tested, blah, blah, blah. I think that would be super awesome. So, I'm going to talk to him about that a little bit more. Um, Andre says, "Uh, what recommendations do you have when trying to collaborate with external teams within a corporate environment?" Uh, so just reread it. Recommendations to collaborate with external teams within a corporate environment. Uh, I think one of, uh, this is going to change a lot depending on your setup. Um, and and you can chime in if you have other details you want to add to the question. Um the I'm assuming when you say external teams like external development teams. So you're within a company called X and you need to collaborate with other developers at company Y. Um if that is incorrect and you want to add any other details, please just add it to the chat. I'll I'll try to course correct my answer. Um I think a couple things, one in particular is that you want to make sure that there's like clear ownership and responsibilities. Um you will run into a lot of problems if that's not really clarified up front. So what I mean by that is like there might be a common understanding of the goal you want to accomplish. So if you're trying to build a certain project or a certain set of features within a project or service whatever it happens to be the outcome might be understood but if there's not a clear understanding of like who is going to be owning what in terms of responsibilities I think that can lead to frustration um that's one part I think something that probably is like I don't know like overlooked uh far more than it should be is understanding like um privacy and security compliance type things right So if this is an external team um to what degree are you able to share information with them? Are you are you working in the same codebase? Are they building things and giving you source code? Are they giving you binaries to work with? Um you know who's auditing this kind of stuff? I think that's probably something really important to understand if you're working with external development teams. Um probably something around communication. So establishing cadence format for communication what's most effective for people. Uh if you are like actively both collaborating you know two sets of teams like one from company A one from company B working together on stuff you might have different communication tactics and if you assume the other group communicates the same way terms of frequency style tools it might be ineffective. you might get lucky and they line up, but maybe that's not the case and you want to clarify that. I think it would help a lot. Those are a few ideas, but if you have other thoughts or more context that you want to add into that, I can try to reshape my answer, but maybe those are some ideas. Uh Deon says, "Ago, I learned the pattern of opening a PR and then putting comments on the lines where I'm deviating from the pattern." Yep, this uh specifically calls attention to those things for reviewers. Yeah, absolutely. So, we get like situations. It's like ideal if your PR is very small, right? Hey, I touched a couple things, you know, it's one file. Here you go. Um, but we've all seen the reviews where it's like a 100 files were touched. You've probably submitted a review where there was a 100 files touched and you're like, look, man, like I just renamed something and it's across all these files like but then there was like one more change in there that wasn't a rename and like that's the thing that broke everything. So reviewers are like, "Dude, I'm not going to go looking through a 100 file changes at all. Change a lowercase R to an uppercase R." I'm just saying that because the person in in the chat on YouTube with the name R. But um you know, then they missed the one file out of a hundred that was like, "Here's a whole new thing that I broke everything." So I think it's a really good opportunity to uh leave comments to call attention to stuff. Um, some might even say depending on what your team dynamics are like, you could even do this before the poll request. Sometimes people will use like draft poll requests to show this kind of stuff to. So, we have lots of tools to do this and I think leaving comments to draw attention is a great strategy. Um, coding mountain says I'm on a team of 150 plus devs in government in several departments. We use teams for all those people to communicate. However, there are 12 sub teams. Each team has an anchor. Oh, so there is one level up down but also open door to tag anyone a group private threads. Yeah, very cool. So, um if I understand correctly, you kind of have like a like a core point of contact on each team, but it's not like you're not allowed to to contact the other people. It's just like you have one person that you can like they're going to be the accountable person. You can lean on them for that type of stuff if if I'm understanding correctly. Um, I think that's cool. I think like one of the things that we have to keep in mind in like everything is like I always come back to a couple of different like core principles. One is going and people that watch code can meet, they're like, "Dude, shut up. Stop saying this." Um, level set expectations, right? Applies a lot to uh relationships with between you and your manager, that kind of thing. But this still also applies with working with other teams, right? And then the other part is accountability and ownership, right? So you have these expectations and along with that comes some type of accountability and ownership. I expect that you in this particular role you are going to be accountable and own these types of things. That might not be a deliverable necessarily. That might mean that you are accountable for facilitating communication. So in coding mountain man's example, you might have someone who is accountable for relaying messages like hey I'm the person that you can send the message to and I will find the subject matter expert that is my responsibility in part of this dynamic right this could look different across different teams different projects but point is level set expectations and I think accountability and ownership are huge let's continue on uh by the way I missed a message from game and yune and I just wanted to say thank you says hit the like to support Dev Leader. That's right. Do the what what do the YouTubers say? Smash the like button. Hit that notification bell. Send me millions of dollars in Amazon gift cards. Um I don't know if the uh the the YouTubers say that, but in your role as a manager at Microsoft, is the interview process for incoming software engineers heavy on leak code style questions? Um, so couple different things. Uh, the depends on the level. I would say the we get put into interview loops. The individuals that are put I'll give you an example. If there's three people in an interview loop, I don't know why they're called loops, but it's an interview loop. Um, you might have three people that are interviewing and we are given a couple of areas to focus on in terms of like what I would call like behavioral interview questions just to make sure we're not overlapping, right? If we're all asking accidentally the same thing, probably going to be a pretty weird interview. So, we have different things that we have ownership over when we're interviewing. That's part one. But it's not just behavioral interviews. It's like generally like a uh coding or system design question. As the interviewers, at least in my experience, we've been given the flexibility to um to tailor that. So, for example, if I'm interviewing someone that's more senior, I might say, you know what, I'm not interested in trying to get um you know, a lead code style question out of this person. like I don't see I honestly I never see the value in it personally but like why don't I lean into something that's more of a system design question right let me see how this person's navigating and thinking about this system the um other way is when I do ask like a lead code style question I don't put tricks in my questions I literally tell candidates we're going to go through a coding question there are no tricks if you feel like I am trying to trick you please just ask because there aren't tricks and I'll let them know I might change the constraints and the requirements as we go through but it's not like I'm changing it to fail you or something. I'm changing it so we can see how your design changes in the code. Um other people because there is flexibility some people gravitate towards lead code style questions. Um in my experience like any interview loop I have been in they explicitly tell us as interviewers there is no question bank. So if people have a question bank from somewhere, it's not shared with everyone else um or no one's invited me or something like that. So um I think that people kind of pick from a few like questions that they they're comfortable asking, but definitely um in your role as a manager. Yeah. So I would say there definitely is a lead code focus on some of the questions. Um I don't I don't like that kind of stuff. I I don't think that it is representative, so I try not to ask it. Um, Jonathan Baron, huge thanks. Um, really appreciate it. Uh, says, "Selftaught aiming for back-end roles at startups by Feb 2026. Uh, how should my goals at at conferences shift when I'm far from applying uh versus closer to applying since I'm still building my skill set?" Um, cool. Okay. And I was in my head I was like, "Oh, this guy's going to speak at conferences." I think you mean like uh for networking at conferences, Jonathan. Sorry if I misunderstood, but I think that's what you're saying, right? How should my goals at conferences in terms of networking? Um I'm assuming, right? Um I think a couple things. So if if I have this right, just jump in and correct me if I'm wrong. Um, I think that the further out you are, this is again personal opinion, the further out you are, the more sort of information gathering you want to do. You want to keep as many things open so you can explore opportunities. I would say you might have some opinions about what you want to do, where you want to do it, but I think if you're further out, keeping like a a broader net or a wider funnel to be able to kind of be open to more different things could be very useful. Um, I say that because as you are approaching this, you know, this timeline of February 2026, if you are aiming for back-end roles and at startups, right? What you might find is over this period of time or let me back up. Maybe right now you're like, I'm just going to pick C and ASP.NET Core because it's the best. You might say, um, okay, I am a C developer currently. Like, I'm exploring that. I'm learning ASP.NET net core. If you started off going to these conferences and networking and in your head kind of narrowing your search to only that, you might be like, "Oh crap, like maybe it seems like it's pretty narrow. Maybe I'm not finding those opportunities." And you might have kind of closed off your how you're approaching things and how you're searching because you have something very specific in mind. So, I would start by being more broad. You might notice the more that you're networking and keeping sort of your your frame of reference open, you might go, okay, there's there's a handful of .NET jobs, but you know what? I'm really noticing there is a lot of, you know, NodeJS jobs for backend development. And you might say, well, I don't really love Node, but you know what? I don't really use it. Maybe that's why I don't like it. I'm certainly like that. There's a lot of things I I don't like because I don't use them. I don't like JavaScript because it's JavaScript, but Typescript, you know what? At least there's types and I don't use it that often, so I don't love it. But I think that I could learn to enjoy it if I spent more time. My point is that the more that you're exposing yourself to these opportunities, you might start uncovering some other things to go learn or to spend time learning. And then as maybe you're halfway through and you've kind of, you know, after six months you're like, you know what, I've seen a bunch of stuff now. Now I want to start honing in, right? I've realized that um from my experience I see that there I'm just making this up, right? There's a lot more NodeJS jobs than than ASP.NET Core jobs. Maybe I would like to go spend more time building stuff in NodeJS. That way I can build up that skill set, feel more comfortable. And then you spend the rest of your time. I kind of made up these arbitrary points, right? I said six months, pick something else, pick different points in general, but you use some of your remaining time to to hone in on like, okay, then building up my Node.js experience. There's a couple other things like I picked a a database, like I picked Postgress because I hear a lot of people talking about that. Feel pretty comfortable with these technologies now. build a couple of apps. been networking with more people that build with these types of things, picking up on some stuff like let me start focusing more and more and that way as you're approaching like towards this timeline you are not just identifying new technology now you're starting to say okay well these are the things that I've been spending time building who has opportunities that align with this right um or you might know someone who can point you in the direction of someone else so I don't know if that um helps, Jonathan, let me know. But I think that's kind of um how I would approach things, right? Especially as you said, you're still building out your skill set. I think, you know, if you go I'm not saying it's wrong, but if you go super deep on one thing and you haven't really uh explored too much, you might say, "Oh, well, it might feel like you've closed some doors on some other stuff." I just try to keep an open mind as you're searching, especially early on. Awesome stuff and thank you. I appreciate it. U Harry says, "I started my first full-time job today and lots of information overload. This live has been really relatable." Awesome. Um yeah, congrats. That's super cool. And um yeah, I mean, thank you. I appreciate you being here. You know, I try to put out as much content as I can to help other people. I I joke, but like you know, my my main YouTube channel costs me hundreds of dollars every month to go publish videos, like resume reviews and stuff. Code Commute is free for me. I also joke that it is about halfway roughly from covering my my driving in the fast lane. So that's awesome. So I do appreciate the tips. That helps a lot. Uh and Andreas, thank you so much. Um that's really great. I like I said, I do appreciate the tips and stuff. And by the way, never expected. Please don't ever feel pressured into that. Uh I do appreciate though it though. So thank you. Uh my goal is just to try and help share perspective and you know if you watch code commute in particular pretty regularly I try to call out like I will have perspectives on things. My goal is not to tell you my way is the only way or the right way. My goal is to give you some of my experiences and then as much as possible I try to talk about things from other directions too because then I get to learn, right? I get to challenge myself and think about things in different ways. So, um I just I hope that comes through. It's not my intention to tell you guys like this is the only way to do stuff. Just different experiences. You're all smart people. If you can leverage those experiences in different ways, you might say I don't agree with that. I'm going to avoid that. And if that helps you in some way, then then great. I think that's that's awesome. Okay, back to the newsletter. Um, so last thing we were talking about was standardization doesn't mean perfection, right? So we want to be able to set a direction with our standards and try to move towards that. Um, I wrote a little bit about the sort of the the Reddit situation. Um, won't fix and merge. Uh that's like it might be pretty obvious, right? But it that's like a process problem. That's a huge process problem. I think that it's it's not that you're not allowed to say won't fix. I think there's lots of things people will leave comments on reviews and someone can say won't fix. But you have to understand what the process is like on your team. For example, I don't regularly review everyone's code at work. There's other engineers on the team. They're working together on stuff. Great. Uh, I can read C code. I program in C every single day outside of work. If people want to put me on reviews, great. But I don't always have the context of of the code base. I don't work in it actively. But domain knowledge is building up for me over time. It will never be sort of like the intimate level that the software engineers have that directly contribute. That's fine. But I get some domain knowledge and then I have a lot of C background. So sometimes when I'm reviewing code, I'm just looking at things from a different perspective. And it's pretty rare that I'm going through a review and I'm like, oh no way, like we cannot do that. A lot of what I'm adding on to review is just saying like, hey, have we thought about this? Or like, hey, like inconsistency here, whatever. A lot of it's like nitpicking. just like if you're going back and you have to go touch this stuff anyway, you might want to address this. Otherwise, it's okay. Um, so someone might say, "Yeah, I'm not going to fix that." Like, "Thank you for calling it out. You know, wasn't a gating issue for you either. Cool. Won't fix." I think it's a big issue if if someone's like, "This is problematic. We need to get it addressed." And then you're dropping people off the review and saying, "Won't fix." Probably a pretty obvious one. I just felt like I had to kind of include it in the article or else um we're not covering all of our bases here. Um chat says, "So Andreas, I have a long commute, too. Usually tune into co-comute to listen to your perspective on things." Awesome stuff. Someone someone today said they came across the videos for the first time. And I've heard this before. Someone's like, "I was just cooking and listening to your to your videos." I'll hear people say like on the weekends they're cleaning their house or doing yard work and stuff and they tune in. So, it's pretty cool. Um, Boi uh from Serbia, just good morning from Serbia. Awesome. Uh, well, good morning to you. That's I don't know what time it is there. I'm assuming it's probably pretty early. I don't I don't know enough about the geography, but I know actually I don't know. I was going to say there's a few colleagues I have that work in Prague, and I just realized I don't know. I think they start hours from now, but um the end of their we've done some meetings like it's like 8 a.m. for me and end of day for them, end of the workday, but I never thought about the the beginning of their workday. So I don't really have much experience working with other people in like sort of the Europe area though. Um but thank you for joining. I appreciate it. Um, yeah. And then coding mountain man says, "Love a senior's approach when they say, "Do you think we should do X instead?" So they make you think. Yeah. Um, I've talked about I've written about it and I've talked about it when it comes to code review and like uh poll request comments and stuff. Um, oh 4:46 a.m. Man, that's earlier than I get up for CrossFit and that's too early. I get up at 5:00 am and it's too early. So thank you for being here. That's that's awesome. um when I talk about code review comments and like how you can I think there's ways that you can leave comments that are very unhelpful, right? When people say like uh I have all sorts of examples, but it's and I've been critic We'll talk about this a little bit too. People have criticized me for this when I've made posts about it. They say that sounds fake. No one talks like that or like did you use chat GPT for that? I'm like I just feel like I'm trying to speak to people instead of pardon my language I'm going to say it instead of being like an I'm going to treat them like how I would like to get a comment. So when someone's just like this is wrong dot I'm like well what's wrong about it? What would you rather see? Like I need some extra context. or someone will say this is the wrong pattern and it's like well what's the right pattern? Um you'll have pe like um this doesn't work or like anything like that where it's just like the person leaving the comment probably has some thoughts on this but they're not even including them. And I think that as much as possible, like number one, we have to assume that people writing code are operating with best intentions. Otherwise, you're going to have a hell of a time in your career. You're going to think everyone's just out to get you or everyone's dumb or something. People are operating with their best intentions, right? With the information that they have it on hand, they're trying to make the best decisions they can. Pretty simple. So when you see stuff in code reviews and you're like, "Oh, wow." Like don't agree with that or that seems like a problem, instead of thinking about things like this person must be dumb or they didn't even try or whatever else, just do the opposite of that, right? Like, hey, like I see what you're trying to do here, but um just wanted to call out that I think we're missing this type of coverage here. This scenario might not work. um to uh coding mountain man's approach when uh message sorry do you think we should do X instead it's like um can you can you walk me through how we might handle this scenario right like asking questions back instead of just pointing at people and being like this is wrong if you're going to explicitly say something is wrong then please provide the evidence right like hey this is a pattern that we don't use anymore here's an example of the new pattern. And here's why we use this. It gets like learning opportunity. It takes minimal extra effort and goes so much further, especially with like junior people. You're like, "This is wrong. No tests." Like, "Do this again." People are like, "Man, I never want you to review my code again." Um, my perspective on this changes dramatically if you're working with like some of your best friends. So there's people that I work with on Brand Ghost and we don't do code reviews. We just push stuff up. But um if we're ever reading through code like we will absolutely tear each other apart, but that's because we are really good friends. We understand the dynamic of how we work together. And I think sometimes people assume this a little bit too much about their colleagues. Doesn't work. And I know it doesn't because as a manager, I spent a ridiculous amount of time trying to coach people on the receiving end of this where they're like, I think all of the seniors hate me or I don't like talking to the principal engineers because they must think I'm dumb. And like they don't, but the way that they're being communicated to, I can understand why. Um, Andrea says, "What car do you drive?" I drive an AMG GT. That is the code commute car. But the car that I love. I don't have a good picture of it. Um, it's like on my monitors so you guys can't see it. The car that I have that's sitting in the driveway beside the car that I drive to work is my Audi TTRS. It's very heavily modified. It's a lot of fun. Um, but it's always got problems. So, it was my I used to take my car to car shows as a hobby I used to have. It's actually when I was doing more social media stuff before. It's because I ran a modified car account. And um so yeah, it's got like it used to be purple, now it's black. It's got Lamborghini doors so they open up vertically. It's got flashing lights and stuff. Um it's real fun, but have to fix it. um just to give you support to your work and what you're doing doing in parallels. I can make you a list if you want. Okay. And Cody Mman says, "Collaboration versus delegation." Um Devin says, "As much as I hate writing docs, I end up finding that every time I get a question about why we do something a certain way. Sigh. I'll go write a wiki page." Yeah. Um documentation is like a it's a hard thing. Um this is one of those things that I'm hoping AI can also do more for us. Like this is the kind of stuff where I'm like, "No one wants to do this." But so hear me out. Everyone I talk to is always like, "Man, I wish there was a wiki page for this. I wish this was documented. Why hasn't someone done this?" Right? You get that? Then the next part is, "Oh, this wiki page is out of date. Oh, this documentation's out of date." And then the next part is, "Oh, I don't want to go maintain the documentation. I want to go write the wiki page." And I don't blame anyone, right? It's a it's a pain in the butt. because it's at a date like almost as soon as you write it. But we all acknowledge how valuable it is. What if we just had agents running all the time and they were reading through the code base and interpreting what was happening in the code history and then just writing awesome documentation like go do that. Go do that. Let me build the software. I don't want to write the documentation. I never want to think about it again. I just want to use it. Uh, Andreas, thank you for being here. I appreciate it and hope to see you next Monday at 7 PM Pacific. Um, yeah, I think you know, documentation, it's hard, but it's uh it's one of those things like if we don't stay on top of it, then the value kind of disappears. So, um, I kind of talked about this part. I'm I'm scrolling through the newsletter article. I kind of talked about this, but like using code reviews and poll requests as like a teaching opportunity, I think is huge. Um the next part when we start to have I might have skipped over this part too so give me one sec. The idea when a code base is growing over time and we're going to have new patterns and stuff emerging. We might have something from day one where we're like this is a design pattern or a way that we flow through execution like this is how we do it. Here's all the good reasons um why we do it. Fast forward a year, you might go, "Ah, you know what? We found a better way to do this now. Here's why we do it. Here's how it works." Another year goes by, here's a different way. Right? Every time we have these scenarios where it's like, "Let's go try this instead now or this is the new way forward." Again, what you don't want to do, I keep referring back to the Reddit post from this guy's scenario, is you don't want to say, "Hey, it's new. You don't like it? Well, I'm dropping you off the review so I can push this through. Instead, it's a good opportunity to say, "Hey, look, this is a new pattern. I I keep saying pattern like a design pattern, but hopefully you get what I mean. It could be anything, right? This is a new style of how we want to do things." Go advocate for it, right? Go talk to the people that work in your codebase and say, "Here's why I'm suggesting this. I want to explain the benefits of it." Um, as Devon was saying earlier in the chat, maybe if it's straightforward enough, it's like, "Leave a comment, calling it out and saying like, "Here's why. I know it looks a little bit different, but here you go." Um, maybe if it's something small and straightforward, you can do that. And then people can chime in if they disagree. If it's more involved, you legitimately might want to use things like draft pull requests or do a one-pager design doc and go talk about it because the reality is what you don't want to do is get into this situation where you put up the change and then people are like, "Well, that's different." And now you're going to go debate it in the code review comments and you're going to have people that are like, "I just don't want to see change." And you're going to be like, "Well, this is better." and then you do like the Twitter thread kind of back and forth and it doesn't go anywhere. Just go talk about it, right? So go advocate when you are trying to advance the different patterns and stuff. Take a little bit of time, go talk about it, document it back now going forward because it's been documented in the poll request the next time that someone's like, I accidentally copied the wrong pattern. You can say, no worries, but here's the new way we do this. I recommend like link them to it. Here's the explanation for why. Here's what that code looks like. Boom. So, it's not that you need to shy away from having code bases evolve. It's that when you're doing this kind of stuff, you need to go advocate for the new patterns that you want to have. Um, okay. The I already talked about teaching moments. Um, one thing that if we go back to the Reddit post, because like I said, this is all based on a Reddit post. Um, what the original poster was asking about was like what should we do in this situation because like I have a person who is dropping the reviewers off and just merging stuff in. Um, there's a handful of different ways to look at this and I think there's a bunch of different dynamics that could be at play. We don't know the exact situation and you might see something similar but your situation is technically different. I would say, and I covered this in code commute, by the way, if you I linked the article, but at the top of the article, I'll just put it back in here and I'll switch over just so I can show you um because I do it on purpose. U yes, it's to get you to watch the video, but it's because the video talks about the article. Um what was I even saying? I totally just drew a blank. Um the reviewer, what section was I at? Sorry. Oh, I was saying I talk about this in code commute, but the um the escalation part, right? [Music] The wivebat is not among acceptable techniques. Exactly. Um when I talk about this in code commute in that episode in particular, um which that's what I was saying. It's linked up here if you want to go watch it because I dive into more details on it. I wanted to talk about this type of dynamic from a few different angles. So I was saying if you're a more junior developer, right? If you are and the person who's doing this behavior where they're just dropping people off the review and then merging it, you might be like, "That seems kind of weird, right? like I'm not I'm not a senior engineer, but it feels like we shouldn't be doing that. And then you might be like, well, who am I to go question this more senior developer? Like I'm newer here. They have more experience. I think there's still a way you can approach this. And I encourage people, I feel like this is a pretty good technique for having more difficult conversations. Um, just be curious. And yes, it's still easier said than done, but if you were to go as a more junior person to the more senior person and say like, "Hey, why did you just go do that?" Like it might come across as you're like suggesting they're doing the wrong thing, right? Depending on how you frame it. Point is, as soon as people feel like you are insinuating they're doing something wrong, people often get defensive. It's really difficult to have meaningful conversations if right away someone gets defensive. So, a lot of my strategy when I when it comes to like more difficult conversations is like I try not to start off by getting the person defensive. As soon as that happens, you need to put in more effort to kind of unwind that. And I'm not saying I do this perfectly. I screw this up a lot, but it's one of the goals I keep in mind when having difficult conversations. So, if you're more junior, instead of going to the more senior person and basically questioning them like, "Why did you go do this?" you could start by saying, "Hey, I noticed that there was this new pattern that you introduced." Like, could you tell me more about this new pattern? You're being curious. Cool. I noticed that there was this older style pattern. Could you explain like why this one has benefits over the other one or like what are the trade-offs? I'm just trying to learn and understand. Great. Odds are if you have someone who is more senior who is proud of the work they've done, they're going to want to tell you about this cool stuff that they came up with. Hell yeah. Who doesn't want to do that? So being curious instead of having someone get very defensive and being like screw you, like I'm doing the right way, they'll now open up and start telling you more about it. Great. Now you got conversation going. Cool. You can start to lean into some of the other things like, "Hey, very awesome." Like seemed like Joe on the team had some concerns about that, but I didn't really understand why. Like, uh, based on what you explained, it seems like I understand the the pros and cons you were talking about, but what was, uh, what was Joe's big concern? And then, again, it's a curiosity thing. You're not saying, "Hey, Joe told you not to merge that and then you dropped him off and then you merged it. I caught you. They're going to get defensive. So, you can approach things being curious and try to uncover. Um, I'm not saying it's going to work and be bulletproof, but I think that that's a way that you can progress a conversation. Um, you can I keep finding says, "I find keeping myself stupid helps." Yeah. Yes. Um, I will share with you a little technique. Uh, could you help me understand why these patterns were chosen? Exactly. a little technique I use. Um, sometimes sometimes it's on purpose, sometimes it's just because it's reality. Um, thanks Coding Mountain for being here. Um, keep in mind that there is a right way and right way always. There is way and right way always. I'm not sure. I don't know if I understood that, Bokei. I apologize. Um the the being stupid help part as a manager. Sometimes I do this purposefully like I mean like a strategic kind of thing and sometimes because it's reality and both are helpful. Um as Ara is saying sometimes when you're being uh like being stupid I'm calling it being curious. You're you're kind of you're not putting your opinion out there for others and trying to like tell people it. You're you might have a very strong opinion and you're just keeping that close and now you're inviting others to share. Now they're opening up, right? That can be very inviting to get conversations flowing. Then you can once things are like more comfortable, you can start to introduce different elements. Then you can get into a point where you need to debate things back and forth. Um, oh, on kind way and right way. Yeah, that makes sense. Um, my apologies for the I missed the the first time. The other way that I like to use it though is like genuinely when I don't know things and I have found as an engineering manager like I do try to remain as technical as I can, right? For folks that are on if you follow me on social media and stuff, I I talk a lot about software development. My main YouTube channel is like literally for building stuff in C, right? So, I program all the time. I'm not saying I'm the best in the world or anything, but I do this kind of stuff pretty regularly. But there are absolutely situations that like I just don't know about, especially joining a new team, new domain. And I have found that you can use like you know air quotes being stupid you can use this to help facilitate things right so when people are getting stuck on stuff you can ask questions right you don't know be naive right you're just being honest like hey explain it to me I just need I want to understand better and you will find that you can actually help progress conversations you can progress people's thought process by asking them questions Because we've all heard of rubber ducking, right? Rubber duck debugging, right? I am the rubber duck. I am your rubber duck. So when you're stuck on it, I'm naive. Tell me more about that. Why doesn't that work? That sounds really interesting. Walk me through it. And the number of times that I have like people go, "Oh, thanks so much for talking through that with and I'm like, you you solved it. I'm just a duck. Um the number of times that's happened is like astounding. So, it's a it is a really helpful technique to try out. Um if we're talking back to this dynamic, right? If you're someone who is more senior talking with someone who's junior and they're the ones who are basically dropping reviewers and merging stuff in, I think that's a teachable moment, right? I think Did I just lose internet? Oh, looks like it's back. I think my computer just froze or something crazy. Um, we've had so many internet computer glitches over the past few streams. Just survive, please. Um, but yeah, I wouldn't assume the person's being malicious. Try to take that upon yourself as a teachable moment. And I think as someone who is a little bit more senior, you're able to um you can change your strategy. You could still be curious if you want, right? Like, hey, tell me more about that. Like, why did that happen? Be curious. Uh or you can be a little bit more direct. It'll be situational, right? But you might find based on the individual being more direct about it and saying, "Hey, like by the way, I noticed that so and so left a comment on there uh and they had some concerns and it looks like you just dropped them off before merging." Um, actually based on our processes like uh that's not what we do. So, I'm not sure you can say like I'm not sure if you discussed it with them offline and you agreed on that, but like uh if you haven't, I think it would be really good if you followed up with them on that because if they were expressing concerns, then you know, then they want to make sure that's addressed before it's merged. You might find that someone's like, "Yep, we talked about that offline. I forgot to put a comment back on the review." You might have someone say like, "I literally don't even know how I did that. sorry, whatever. Whether or not they're lying, I don't know. But you might find that people weren't just being malicious or they didn't know, whatever. Now, if this is a repeat thing, right, someone keeps doing this, you've had these opportunities where you've discussed it, you still have concerns, you've tried to coach people or ask them about it, let them know this isn't how the process works. Definitely escalate it. Right. I'm I know this is like it's tricky for some people. I don't think a lot of people like um they don't want to feel like they're tattling on people, right? They're like we're adults like but this person's doing something that they shouldn't be doing. I don't want to get them in trouble, but like man, this is like this is getting problematic. Again, code commute kind of repeat thing I always say is like having a good working relationship with your manager goes a long way. There are people on my team that when they come to talk to me about stuff, I have people that will like every time they're like, "Hey, like I'm not trying to, you know, I'm just trying to be honest or I'm just trying to do this. I'm not trying to come across the wrong way." And I I think it's funny because I'm like, first of all, thank you so much for trusting me with what you're about to say because otherwise they just would be quiet and never bring things up. Um, but they're also acknowledging like they're like, I want to find the right words because I don't want to be like I don't want to tattle on someone or I don't want to sound like I'm whining. Like they're they have some awareness about it. So I I do appreciate that. But it's awesome because they trust me with stuff. So they'll come and talk to me and I encourage it, right? If something's going on and you've tried to address it and I always do. I always say like, hey, try to if you have an issue with someone, try to have a conversation with them about it. Like, it's easier said than done, but that kind of stuff goes a long way. If you've tried and things aren't progressing or you need help with it because you're not really sure how to approach it, please escalate it with me. Let's talk about it. Right? If you just need some coaching, let me coach you through it. But if you if you're feeling kind of stuck or you're not ready for this yet or whatever it happens to be, then thank you for the information. and I will try to go find a way to to navigate it. But if you're in a situation where someone's like really abusing the process and nothing is like steering it in the right direction, escalate it because at some point it starts to become kind of dangerous and negligent because you have someone that's whether or not they know it or intend it, they're kind of going rogue and just doing whatever they want. We don't want that to happen. We don't want other people to see that behavior and going, "Well, that's what we do, I guess." And then they start emulating it, right? If if if people feel like that's the direction they want to go, I don't know why, but if that's what people decided on, they're like, "This is the new way we want to do this." Like, it should at least be a conversation on the team. I just can't see why that would be a good practice, but I'm not here to dictate that to you. Um, what else? Sorry, I scrolled back up. [Music] Um, and I think yeah, the last thing I wanted to mention is like the the reality is like with code bases if you have like there's a really good video from the primogen. I think everyone knows the primogen. Um, if you don't, go look up the Prime. Um, it's a really popular streamer. Um, he had a video where he was talking about code bases and I did a on on Dev Leader, my YouTube channel. I did a like a a reaction video to this video that he put out, but I thought it was super cool because he talks about you're building code bases and it's almost like every codebase has like a lifespan to it, which sounds kind of like sad, but um he was saying like, hey, in a lot of these situations, you have someone who's like awesome and they build something and it's totally great and it's basically got like a lifespan on it. And he was like, if you if that thing can last like over six months of like being used, he's like, it's probably pretty good. But now from there, it's like you need to keep it afloat. And he was like, every time you keep doing this, like it gets harder and harder to do. So he's talking about it in a way that I thought came across really well, like it's really difficult for software to continue to live on. And eventually you get to the point where it either crashes and burns or there's a rewrite or something. But to be able to have software that lives on for many, many years, it's going to look pretty rough. There's going to be some rough spots. Yes, there, like I said at the beginning of this live stream, you can refactor stuff. You can try to clean stuff up. Um, there's like a strangler fig approach where you can do partial rewrites behind and then swap out the components for the new ones. Lots of things you can do, but code bases evolve. They will get messy. And I think instead of looking at like, oh, legacy code's like the worst. It's I wrote in the article like legacy code isn't the enemy. Most of the code that we work on in our careers will be legacy code. If you buy into that idea, it means that you want to be comfortable working in legacy code because if you're not comfortable working in legacy code, you're going to spend a lot of your career being uncomfortable in code bases. So hopefully going through this was helpful. Um, again, if you want, you can check out the article. I put it in the chat a couple times. Um, but really the idea is like, you know, code bases will evolve hopefully. Don't fear that, but try to come up with the right approach for your team so you can socialize the new patterns. You have strategies for these things. You don't need to stop all of your future development to go refactor all of the code every single time there's a new pattern because you might be touching legacy parts of the code that are four years old that were already working and don't need to be touched. Don't touch it. um lots of different approaches, but hopefully this was helpful in some capacity. So, with that said, thank you. I will um yeah, Devin says, "Leacy code is the code that's currently generating revenue." That's uh that's the code that's actually paying your salary. So, not a bad thing. Um I'm going to do what I do at the end of all my streams, um which is the the selling part. So, like I said, this is my newsletter. Um, you can check it out on Substack. The other, um, what are they called? These AMAs, these live streams, they are also on Substack, but uh, just for what it's worth, especially for folks that are watching this on Substack right now. Uh, you can't see the screen I'm sharing, right? If you're on Substack, that sucks. Unfortunately, Substack is only streamed from my phone. They don't have it hooked up to reream yet, as far as I know. So, if you want a better live stream experience, I would not watch the streams on Substack. If you can, I would recommend jumping onto YouTube, jump on to LinkedIn. I stream on I'll list them all. YouTube, Facebook, Instagram, LinkedIn, Tik Tok, X, Kick. What else am I missing? Something else. Twitch. Forgot about Twitch. Um, probably one more. Oh, I can't stream to Rumble because that was putting me over my my limit. So, I stream to all these other platforms. Um, I think YouTube's probably the YouTube and LinkedIn are probably the best ones for for visibility. So, I would check that out um if you want a better viewing experience. But, uh, Dev Leader Weekly is my newsletter. Like I said earlier in the stream, you do not have to subscribe if you don't want to get email. Please don't. It's a waste of your time. It's a waste of my time. But you can check out weekly.devleer.ca. Get the topics. They go every Saturday. That way you have a few days to check out what's going to be on the stream. I do also have courses. Um, yes, I am selling you things. Courses. Uh, apparently there's a sale. Let me refresh this. There still is a sale. Oh man, there's This seems like it's such a plant. It's not. Just very coincidental. Um, it says there's 3 hours and 44 minutes left. Um, I say like this seems like a setup. I don't run this site. This is on dome train for folks that can't see my screen share. Um, but that is the link to the courses. So, there is a 40% off sale. Nick Chapsis is the one who runs this site. He's uh if you're not familiar, not like a net developer, he's uh like the most popular C YouTuber probably in the world aside from Tim Corey. Anyway, um this is his site. He controls the discounts and stuff. So, there's a few hours left. That's pretty cool. But if you want to learn about C, I have Courses. Um otherwise, I have a couple of like more like career style courses. So paired up with Ryan Murphy, we have career management for software engineers, getting promoted, behavioral interviews, soft skills. So a bunch of stuff. Um I recommend them, but only if you're the kind of person who uh feels that courses are valuable. Some people will say, "Well, I can just go learn all that stuff online for free." Yep. There's lots of free resources. I put out tons of free YouTube videos, too, right? like I would be a hypocrite if I said no you can only learn from the courses then what am I doing here but I think some people feel the accountability with a course this is also why I don't like try to push courses down people's throats like if you don't find them effective then please don't use them as a tool if you do then I think it's a great option but I try to make sure that I have options for everyone so there are courses available uh otherwise if we jump over to YouTube. This is my main channel. This is Dev Leader. So, I think most people that are on the stream right now, aside from Instagram folks and aside from people, aside from people on Substack, uh most people, not all, most are on the main YouTube channel. Um you'll see like I have resume reviews. That's a new thing that I've been doing. If you're interested in having your resume reviewed, uh check out the playlist. So, you can just go to playlist at the top, check it out there. But, uh, they're totally for free and they actually cost me money because I have to get them edited. I just lose money on reviewing people's resumes, but people have said they're very helpful. Um, most these are like usually some of the least watched videos for some reason. I don't know, maybe it's the way the YouTube algorithm works for me. I had a ton of people request these, so I started doing them and they don't get a lot of views, but the people that watch them are like, "Oh my god, thank you so much." So, I'm going to keep doing them because I think it's helpful. Um, some of the most watched videos are like, I don't know, some of my oldest videos, like two years ago, that's when I had Can you see that? You can't on Substack, so sorry. Um, I have hair. Remember that? Those are the days. Um, I was so young, so much hair. Okay. Uh, otherwise, Code Commute is the other YouTube channel I've been talking about. Um, you can check that out with the link here. Uh, this is where I vlog. So, I have a ton of videos on this channel. Um, on a day like today, I said at the beginning of the stream, I filmed four vlog entries. Uh, generally the way this channel works is I'm driving to or from work, to or from CrossFit, and I usually will take a question that comes in from the comments or something that someone messages into me, and I try to make a video in response to it. If I don't have a bunch of pending questions, I jump over to Reddit, try to find something interesting, and then make a vlog entry about it. So, it's very much like these live streams, but and Game and Yune watches code commute. So gaming knows Devon watches it, R watches it. There's a bunch of people that came over from Code Commute, so thank you. Um, but yeah, these are just vlog entries. So if you like this style where I'm just blabbing about stuff and you're like, "Hey, I could watch that in the background." Do that. That's cool. Um, I appreciate it. So that is code commute. And then otherwise, this is probably less applicable for most people, but um still like to share it because this is what I work on outside of work. Should have said flashbang warning. So sorry. Um Brand Ghost is the social media content creation platform that I'm building. If you're watching on Substack, Brand Ghost might be uh helpful for you if you're a content creator or would like to try. But the idea behind Brand Ghost is that we can cross-post and schedule your social media posts to a whole bunch of social media platforms. What that means is you can write it once, post it everywhere, and that's actually free, which is pretty sweet because if you want to use competitor products like Buffer, it's not free. You get three for free and then it costs. We're just free for all of them. There you go. Um, the paid for stuff is a little bit more advanced. So, if you are a content creator that wants to make sure that you can have your posting done more automatically, you still create your content, but you can have the scheduling done for you automatically, recycle content, that kind of stuff. Um, our paid for tiers offer that kind of stuff. To give you an example, um, if you see what I post on social media, you might notice there's a pattern. Every night at 11 p.m. on Twitter, blue sky threads, I post jokes. Every Friday, Saturday, and Sunday, I post memes. Every day at noon, I post a blog article. Okay, so I use brand ghost for this. I haven't written, aside from my newsletters, I haven't written a new blog post, a technical blog post in one year because I've been building brand ghost and I had to cut out something from my time. I didn't have any more time to write blog articles. I was doing up to six articles a week. But because I have over 300 blog articles, I can post a link to a blog article every day and you won't see them repeat for almost a year. So I get free content to publish online. So this is how I use Brand Ghost. Um, whenever I'm talking to other content creators and stuff, one of the questions that comes into me, like when I do podcast interviews and stuff, how do you post so much content? It's because I built Brand Ghost to do the posting for me and I can focus on the content creation. So, if you are someone who is interested in trying out content creation, you can go sign up for Brand Ghost. I'll put a link to it in the chat. Like I said, totally free to try it out. Um, if you want to try taking content creation more seriously, you want to do some learning in public, that kind of stuff, send me a message, ask me some questions. I'm happy to go through this. Um, for those of you that don't know, I started Dev Leader in 2013, and I took a 10-year break, and then I started it back up again in 2023. So everything that you see online that I'm doing is essentially from the last, you know, since the start of 2023. So what is that? 24 plus 4 months, 28 months. But I do this every day. Do it on repeat. Could you imagine if I had another 10 years added to that? So what I'm trying to say is if you want to get started, reach out. I can try to help you be consistent because that's going to be the part that if you can be consistent easier, you'll stick around a little bit longer and then you don't need a 10-year break like I took. So, with that said, thank you so much for being here, folks. I appreciate it. These live streams are done every Monday at 7 p.m. unless it's my birthday last week. Um, so hope to see you again next Monday, same time. Thanks again. If you have questions in the meantime, send them into dev leader or go to code commute, go watch a video, leave a comment, ask your question, and I'll make a video for you. I'll see you next week. Take care.