Is My Developer Career JUST Maintenance?! - Principal Engineering Manager AMA

Awesome. I think we're getting going here, folks. Let me wait for Instagram to kick in and substack. Got to do all the all the fun things. Instagram always takes a second. It's not a good start, Instagram. [laughter] It's just a just a black video. Ah, okay. Let's try it. Whatever. If it doesn't work, we'll just turn it off. Nah, I think it's I think it's screwed. Okay. Well, forget Instagram. Reream. I'm coming after you. I want my money back. Um, okay. We'll go to We'll go to Substack here. Make sure that's going. Cool. There's people that join. Hey, Substack folks. Good to see you here. Thanks for joining. Uh I think I think we're all set. Let me turn off the Instagram stream. I don't uh I don't trust that. [laughter] It shows I don't know if people have experienced this with like Teams or Slack or whatever you use, but getting onto a call and um like something is weird about the icons that show like whether you're muted or your camera's working. and there's something about the feed, like your video feed's not working and you're like, I don't know, like you see yourself, but like you're not getting the other person's I don't know. You've been in these situations where like I'm not actually sure if my camera is on or not. That is such an awkward position to be in because then you're toggling the button. Anyway, it's uh it's uncomfortable and I don't want to be not that I'm doing anything weird here, but I don't want to [laughter] have what looks like a a black video feed that I can see going to Instagram and then I don't know like I don't actually know what's showing. So, welcome. Um if you're new here, these are AMA style live streams. Uh thank you for being here. I do these every Monday, 7:00 p.m. Pacific, unless something's going on in real life outside of this. And um yeah, I usually take a topic from uh something on social media that I'm covering. So uh usually it's from Code Commute, which is one of my YouTube channels. I'll talk more about that later, but Code Commute is a a vlog style channel where I take software engineering questions and uh so you mostly user submitted and if I don't have a backlog of them, I go to Reddit and uh I do about five videos a week. So Monday to Friday I put them out and they're on uh on Spotify as well if you want to check those out. But like I said, I'll share it more on that later. This topic was uh a question that was about maintaining software and essentially, you know, someone was saying on Reddit like, "Hey, like I feel like this isn't software engineering. What's going on here? I feel like I'm just working in someone else's code." And I was like, "Oo, this will be interesting." Um, but there's different um different perspectives on this, right? I think depending on people's journeys and their careers, like you may spend more or less time doing this. So, I wrote about it on Substack. So, Substack folks, you know where the newsletter is because you're on Substack and that's where it is. So, for other folks that aren't familiar, uh I'm just going to put it into the chat. It's just at weekly.devleader.ca. And so, the link that I just put in there, I think it goes to YouTube, Kick, Twitch, and Facebook. If you're on LinkedIn, it's just at weekly.devleader.ca. It'll be probably the second thing you see there because the first thing will be this live stream, which is maybe a little awkward, but anyway, you're smart. You can figure it out if you want to check it out. And that's a friendly reminder, too, that if you enjoy these types of live streams, if you go to weekly.devleer.ca, on Saturdays, I publish a new newsletter article. No, you don't have to subscribe if you're like, I don't want this. It's totally free, but if you don't want it sent to your email, then don't subscribe. Totally cool. Uh, but that will generally be the topic for the live stream. It's pretty rare that I code on these, but sometimes I do. I think we were coding last week, so um, you know, sometimes that comes up. Anyway, that's the topic for today. And jump into the chat if you have any questions. Feel free to interrupt me at any point. I'll usually try to finish up my thought and then jump over and answer whatever I possibly can. and hopefully have a good answer for you. That's helpful. Okay. So, I think maybe my I don't know, maybe it's my my perception of this stuff. Maybe maybe it's common. I don't actually know. I don't have stats on it, but I think that there's probably I don't know lots of people that get into the the industry of software development maybe having the expectation that most of your time is spent building new things. And I I think that probably most folks that get employed at companies where there's teams of software developers, that's probably not the most common thing that you're doing. And the the idea here is just like I think there's a big discrepancy between probably what many people expect to getting into it and what reality is. And and along with that comes this maybe concern, right? like, hey, if I'm not building new stuff, like, doesn't that mean that like I'm going to stagnate? Doesn't that mean I'm not really doing like software engineering? Like just maintaining someone else's code, right? So, I thought this would be interesting to talk through. I have a yawn that's trying to sneak out of me and I'm like holding it in. So, at some point, I'm just going to have to let it out. Just a heads up. But I thought it'd be interesting to write about because I I I think that this there's a a bunch of stuff like this in software development and I think that if people have a little bit more exposure to this or a little bit more, you know, perspective or understanding early, they won't be surprised in like a negative way, right? Because just because you're not building a new project from scratch like every week in a company like doesn't that doesn't mean that you're not going to be building cool stuff or innovating or or what have you. Um it's like the the same thing right like where uh you know completely different thing in terms of expectations in software development but sometimes people are like I want to be a software developer because you know I can put my head down and work on stuff and like I don't have to work with people but you do a lot [laughter] to work with people an awful lot as a software developer and uh it becomes like a limiting factor at some point if you're not really doing that. Now mind you my bias here if it's not obvious will be from the perspective of someone working on a team in a company and that might not be you right you might be uh a freelancer you might be a contract worker and your setup might look different I'll try to touch on that as we go there it is huge epic yawn I knew it was coming um [laughter] so I'll try to call out those differences as we So, sorry I've been on call today, so I'm a little little yawny right now. Jabon, welcome back. Uh, Jabon says, "I'm in a maintenance phase right now, but I'm realizing that I'm looking at bugs from a pretty cool pretty good uh uh systematic standpoint." Cool. Yeah. And like I'll talk about this in a little bit, but like there is like when we talk about maintenance, right? like when we talk about this kind of thing, I I think that maintenance is maybe like a loaded term and um the idea with like when people hear like oh like I'm working in, you know, an existing code base or I'm maintaining it, it's like maintenance is pretty loaded as a phrase because are we talking about a system that exists and it's been around for years and you're just you're adding new features to it and it's a live service maybe and that also involves fixing bugs and keeping it healthy. Like, is that maintenance or are we talking about something that is in a state where you're not even there are no new features, right? It's sort of like the legacy product that you have to keep afloat, but you know, it's a it's on a sunset path, right? There's still paying users, so we literally try to keep it running, but you're not building new stuff in there. It's like there it's only bug fixes or or whatever, right? like uh some part of the infrastructure or services around are changing and in order to like make sure everything else can keep moving, you might have to go, you know, make some adjustments to this product or service to to keep it alive. But otherwise, like you're not you're not building new stuff in it, right? Those are different. And I think that um you know, and based on Jabon's comment here, right? So I'm in a maintenance phase right now. might mean that like even just a literally a phase of a a product life cycle where and I've had you know some things I've worked on like this where we were pushing hard for new features and we got it out the door and then we were getting some feedback and then then it was like cool we deliver on the feedback but then we're at a point where we're like we actually want to harden this a little bit. So we're kind of just maintaining it and like waiting for a next round of like feedback and that kind of thing. that wasn't like a a super long period of time and there were other priorities that were coming up. So it's not like we just said I guess guess we're done. We you know we succeeded at software development. We're all done and we can go home. It's like no we're going to pause on this. We'll maintain we have all these other priorities over here. We'll shift gears to that. So maintenance can be very much like a point in or I don't want to say point in time that's not right. um small period of time. It could be something where a product is being technically like sunset, but you have to keep it alive until the last of the paying customers are are gone. And you could have something that is is an existing product or service and it is being kept alive but like so maintenance but you're also building new features and extending it, right? So lots of different flavors of this just to call it out. But I think, you know, if it's not obvious for some folks, cuz like I don't, you know, I I never know on streams, like sometimes I'll have a bunch of people that have lots of experience. I think most No, I actually can't even say that. Every time I've run a survey on this kind of thing, I'm very surprised that I often think that my audience is primarily like junior or aspiring software developers. My audience is quite literally when I do do polls and surveys and stuff, it is the exact opposite, which I always find very very interesting. Um, a lot of the content I put out is is truly aimed at people that are I feel like are, you know, it's aimed at people getting started. Um, so I can't make assumptions like this, but I I don't know who's going to be watching. And I I want to make it, you know, I I want to make it inviting for folks that are new. And so some people might not realize this because they haven't really had to think about it from the perspective of a business, right? They might have gone to school uh for software development, right, and computer science or something related. or you might have just said, "Hey, like I'm, you know, I'm interested in a career in tech and like you started learning how to code and like this type of thing, but you haven't really thought about it from the perspective of like what does it mean to run a software business?" And you know, I don't blame you for not thinking about that. Like I don't know, I I'm just thinking of something random off the top. Like I wear I wear shoes and I've never thought about what it was like to, you know, to to own a shoe or clothing business. I wear shoes every day, right? There's there's lots of I drive a car every day and I don't think about what it would be like to have a you know a car business or manufacturing business like that things that I just don't think about and maybe for some folks getting into software development they haven't yet thought about what that means to have and run a software company you know rightfully so. So you might have this perspective where you're getting into it and it's like well we're building things. I'm told as a new aspiring developer I need to be building projects. I need to be practicing this kind of stuff. I need to be staying on top of new things and and always trying to learn. And these are all, you know, great pieces of advice, but that's not the advice is not um hey, you need to go build projects and always be learning because on the job you will always be building new projects from scratch. Like that's not that's not the reason why building projects lets you build software, right? you're not you don't have the I might call it the luxury of taking someone else's running product or service and building on it. You don't like unless you're doing, you know, open- source uh contributions, which is great, or you're volunteering and um you know, helping build someone's thing. But if you're not doing those things, you are probably building something from scratch. And then when you want to go learn something else or practice a different language or tech stack or what have you, you go build another thing. So, we kind of get in this mode of like building new things from scratch, but that is not the common thing that you're doing in a software development job. And why is that? Well, the reason from like a business perspective is like usually a company aside from companies that like just get a lot of investment and they're like, "We have to go spend the money on things." Even at companies like that, you generally have a product, right? If you're not getting investors to dump cash in, how how is the company even around, right? Assuming it's a software company, like a software first company, how is it around? It's it's because there is a product or service that users are paying for, right? And if you kind of rewind to what I was just saying, like even if you don't have paying users yet and you're you're kind of building this product out and you do have investors, like the you you're still probably joining a company unless you're there right at the very very beginning. you're joining a company where the other sort of founding engineers have been building this thing already and investors are are paying you know the salaries and stuff. So point is that you're often building on something that is generating the money. And for a business to go make a decision, we should go build something new from scratch when we have this thing that is supposed to be the money maker. It's not that they can't do that. It's that it's literally a risk. Everything in business is some type of risk that you need to measure. But it's it's a different thing. So you're telling me that instead of having people that we are employing to go work on this thing that is literally the thing making us money, we should take people away from that and have them focus on this other thing that is literally not making us money and may never make us money and will cost us because we're paying developers and and you know other uh roles like product managers and designers and stuff. for paying them to go work on this thing, right? Spinning up new things has lots of risk associated with it. It does not make a ton of sense for a company to be constantly building new things from scratch. Now, a company that reaches a certain size, right, and they have different revenue streams are diversified enough and they have, you know, people paying for products and services. At some point it probably makes sense to go cool like we should continue to experiment and build things out. There's more prototyping going on. How you do this in a company can look completely different. You might have a dedicated team for that. You might encourage every team to have a little bit of that baked into their development process. You might have uh things like internal hackathons where you're dedicating time like carved out for the year for people to do it. There's like I said there's a million ways that you can go do this. do a combination of a whole bunch of them. But the point is that this is like taking time consciously to go do these things. You're building it into your business to go do that. It's very rare that that is just the core of the business is just doing all sorts of new things from scratch all the time. So hopefully that makes sense. Like I said, it is an AMA. So if you're like, I have no idea what the heck you're talking about, Nick. Can you explain more? give us an example, whatever, just jump in the chat. Happy to expand on that if it's just not clicking. So, that's something I wanted to clarify upfront. This is a good opportunity to also say out loud that yes, I am talking about companies that are building software primarily, right? You might people that are working as software developers will work at companies where it's not software first. I'm just going to make up the most random example I can think of. might be a chair company. They make chairs. That's what they do. But you know what? Internally, they might have a software team that's I really digging myself into a hole here. Um they might have a [laughter] software team because they wanted to they have some something unique about their process and they have a sort of a custom inventory need because they're procuring wood for their chairs. [laughter] Sorry, I'm terrible with examples on the spot, but uh you know, they're they need they have something custom they need and they're like, you know what, we're going to build the software for this in-house because this is a core part of our business. We need something custom for this. So, we want a team that's dedicated to it. Right? In this example, it might not be that the software is the thing generating the money. So I'm trying to give you what I'm like is my sort of bias where it's like you're working on a software development team where the thing that you're producing is the thing that's generating the money. Other examples that are different from my my primary one are like if you're a freelancer, right? Freelancing might might afford you some flexibility to do a whole bunch of different things. It may not be what you want to do, right? So with freelancing, you might have more uh say or control and like how much variety of things you're doing. Do you want to keep doing different things from scratch and like that's really scratching the itch for you where you're like, "Hey, I want to go build a mobile app." You know, that was fun. I did that for a client. I want to go build a website now. And you do want to build it from scratch and you do want like that's up to you. Like if you're a freelancer doing that kind of stuff, go ahead. That's your business. That's fine. Some people may be in that position and they're saying, you know what, like I have built a mobile app. I've done it a couple times. Like, I actually want to take pieces of that, reuse them. So, I'm not always building the same types of, you know, same things in a mobile app from scratch. You may get to a point where you're like, hey, I'm going to take this and what are the is it like white labeling? So, you build an app one time for the most part and then you're rebranding it and selling it right now. Now you're have multiple clients. You're freelancing, but you're still building like roughly the same thing. So there's so many different ways to do this. Got to block these people in the chat. Come on, man. Jabon says, "I still want a software engineer job at Home Depot or Lowe's." Yeah, like that's that's a thing, right? So, you know, it's it doesn't have to be like at a software company. Anyway, just wanted to give you some variations of that because depending on, you know, anyone who's watching this live or if you're watching the recording of this, you might say, well, hey, that's not that's not every software developer. I know, totally. I'm just trying to give you my experience from working in software teams. Okay. So, I wanted to talk about this what I feel like is a bit of a myth or a misconception with the only time you're going to be innovating is if you have this opportunity to work on new new things. Okay. And so, like there are many different ways to innovate without having to start something completely from scratch. And I think it's just misleading. Um, and it might, I don't know, it might be from a lack of experience. Maybe you haven't got to do something where you're like, "Wow, this feels really innovative without doing it from scratch." And, you know, that's entirely, you know, maybe your lived experience, which is fine, but um, there's absolutely a lot of opportunity to innovate in something that's existing. Brian Fairchild says, "Even at a software company, it's highly likely that you'll go into maintenance mode for something you built." Yep. companies don't want to rebuild it even though uh even though oftent times it should be. Yeah. So like I'm trying to think I when I worked at a digital forensics company before Microsoft I I remember when I started there we were porting over the founders code. We did there was uh effectively like what I would call a rewrite for the most part. One of the first things I did was I rewrote one part of the app. It was like there's like a search engine and like a viewer and I rewrote the the viewing part for viewing all the results. I rewrote that like one of the first things I did was just like, hey, we're scrapping this and writing it from scratch. Um, and that lived on for a while. That ended up getting rewritten, right? But we were maintaining that for a while. And I was there for eight years. And a lot of the things that survived, like we were, you know, maintaining them. Some things were kind of like I said earlier in this chat like some things were maintained in the sense we're like we are going to retire them and sunset them. We're not adding new things there. So cool like we got to maintain it truly but we're not adding more things. We're not extending it. There were other things that we were like, you know, you're maintaining it, you're keeping it alive, but you're also adding new features and and back to this point about innovation, you have this product and or this service that you have like that you're adding things to and you need to find um like think about over the last couple years, right? What did every company do that was that was already in existence, right? Every company that wasn't a brand new company was like, "Hey, wait. Like, we have this thing, you know, we I don't I'm trying to look around for a random idea. I'm really bad at coming up with ideas on the spot like this, like examples, but you know, we have a we have a calendar app. Awesome. Okay. Well, our calendar app doesn't have AI in it yet. We got to find a way to put AI into our calendar app, right?" Like, everyone was doing this. So this was an opportunity or I feel like this is a great example where like every company was like we need to find a way to take this new thing and add it into our products. I'm not saying this is the right move. Let me clarify. I think there's probably too many examples where like that's not a good fit, but that's an examp I think a good example of we need to find like a way to innovate. we're doing something new in our existing product or service. A lot of companies didn't say, "Oh crap, we have this calendar app that doesn't have AI. I guess we have to go scrap the calendar app, write the calendar app from scratch, a green field calendar project, and make it AI from the beginning." Why did a lot of companies not do that? because if they did that then they would be taking resources away from the thing that is literally generating revenue for them. So you have opportunities to innovate in existing products. Um I think that I don't know like this is maybe maybe other people have a different perspective on this but I I think that having constraints is one of the reasons like the primary reason that we have really creative things going on in software. Okay. So what do I mean by this? It might sound like counterintuitive. I actually think I've done live streams on this topic before, like specifically this topic, but I feel like it's a little counterintuitive if I said to you like we want to go build something and if we're talking about innovation or constraints, like you might not have a ton of constraints if you're building it from scratch, right, there's probably some would make sense, but it's a green field, right? Like you know what what language should we use? Well, we've been using C for a long time, but like it's a Greenfield project. Like maybe maybe we don't have to. Okay, so what are some of the reasons we might stick with C? Okay, well maybe most of the team uses it. Well, most of the team did know it, but we've hired a lot of people. Like there's people coming in that have C++, they have Java, they got C. Like now we have a sort of a mix. And you know what? I'm just I'm going off the rails here, but like you know what? We have this thing that we're trying to build and it needs to be extremely high performance if it succeeds, right? Maybe maybe we want to think C or maybe we want to think Rust. I'm just totally making this up, right? But this might be an opportunity where you're breaking through some of those original constraints you would have had. What database technology should we use? Let's assume that your product or service needs a database, right? Okay. Well, you know, I worked on my the digital forensics product I was talking about. Like we used a SQLite database. Might seem kind of weird to some folks like why wouldn't you use Postgress or something else? Well, we use SQLite because what users wanted was a literally a portable version of their data that they could move around. It was how they were used to doing that. So, does it mean that it's the best technology for performance? It's very performant actually. Um, it was simple. It was easy to use and it delivered what we needed and people were used to it. But you're starting something new. Do we need to use SQLite for that? No. We have have all these options we can consider, right? So when you're starting new things from scratch and we're thinking about innovation and constraints and how we balance these things, you generally have fewer constraints. And I think that people go fewer constraints must mean that we have more opportunity to innovate. We have so much more freedom, right? freedom to go do whatever. We have creative freedom like maybe it's not whatever but um we have more creative freedom. It's it's more opportunity to innovate. And um I think that is an opportunity to innovate. I just don't think that it's the only way. And I I like thinking about constraints a lot. And the reason I like thinking about constraints is because you have no choice but to get creative. Because when you have even boring things, things that seem boring, right? I need you to change the schema of this database. That's boring. It's a solved problem, right? That's not that's not innovation. Okay? But but this database is actually, you know, uh actively serving, you know, millions and millions of users. It is extremely high traffic and like we need part of our system to be able to do this schema change in a way that our system like we literally do not have support for that right now. You can't take the service down. How do you plan to do that? Right? There's there's often times when you have constraints that force you to be creative. Um, you can have like live services I think are a really good example of like you get some really challenging constraints to work through, right? You can't have downtime. Um, you have to, you know, roll out service changes over time. Like, does your technology let you, you know, press a button and blast it out to the entire planet instantly? Sure. Great. It can move fast. Should you do that? like probably not, [laughter] you know, especially if there's one little thing wrong. I mean, you can keep doing this and then it's going to take one time where you go really fast and you go, "Oh crap, we probably should not have done that." And then going forward, you'll probably change your mind a little bit about that. But point is that live services, I think, are a great option for thinking about constraints. And when you have constraints, even simple problems will require potentially very novel solutions. And that means that you need to find creative ways to go solve them. Okay. So I think when we have existing products, services to work on, sometimes you might have something that truly doesn't seem like that's it's all that groundbreaking. But when you go to dig into how to solve it, it's like, holy crap. Like we have to get pretty creative here. We have to innovate. we have to come up with an interesting solution to sometimes what might seem like a boring problem on the surface, right? So, I wanted to remind people of that because I think it's important to to consider that sure if you're starting Greenfield, you might have more options. You might get to go pick the shiny thing. Doesn't mean that you can't pick a shiny thing on an existing product. Doesn't mean that. But it also means when you have something that is existing, there's constraints to work within. And I think that that's um in my opinion like pretty interesting. Um I think like I'm just kind of going through my my newsletter topics here. Kind of talked about um well I kind of may maybe it's worth going over these again. So I was giving some different examples of like things outside of like a pure software development team, you know, like a company that's literally making their primary product or service is, you know, it's software and that's the thing generating money. Uh if you are like hey look if that's the more common way that you are going to be in a situation where you're like maintaining things you know maintaining and you're like that's not really for me like I kind of do want to start more more new things more frequently like is that wrong? Does that mean I'm never going to have that? The answer is like no it's not wrong and it doesn't mean that that's impossible. I would just argue that's probably the more common thing to expect. So, if you want more variety, some things I've already talked about a little bit, but um you know, one that I don't think I really touched on is like, and I've I've actually, interestingly enough, my beginning of my career was a lot like this, but different companies have like sometimes we'll have a prototyping team, right? So, I I worked even at as an intern, I worked on the architecture team at a company. We were making it's called Phoenix Interactive Design. And I think they were I think they were bought by a competitor, but we made um we made software to to manage ATM screens. So if you were a bank and you wanted to change what your ATM screen looked like, they did more than that, but it's primarily what I focused on. And so I worked on the architecture team where we basically got to play around with new ideas, right? So that was really cool. That was an internship, but it was like I I think in my four-month internship, I got to do a whole bunch of different things. One of the like I did a random thing like the last couple weeks I was there where I was prototyping a video. What was it? It was like a video streaming um like proof of concept where if you wanted support and you were at an ATM, you could like press a button and then it would do video like two directional video streaming. so you could chat with someone. Um, so I got to prototype that and because this was a company that was building like ATM customization software, the whole idea was like if someone if you know if a bank wants this as a capability like where should they put that? How would they configure this? So it's really cool. But that was a prototyping team when I worked in the digital forensics company at a different point in time. This kind of changed my career there. But I I ran a prototyping team right before I left. They were actually um one of the sort of teams that I was going to move into like a like a director position for was a prototyping team. It was uh sort of like their R&D team like specifically for trying out new ideas. So these types of things do exist at different companies. Not every company will do it this way, but that could be something you go look for. It is a thing that exists. And if you really want to scratch that itch, then that might be an option. I do want to call out though that I think at least in my experience during that time, I think that a lot of people had a misconception around what that meant because I on and off did prototyping for a majority of the time that I was at that uh forensics company, pardon me. [snorts] And um I think some people saw that as like a oh like it's not fair, you know, you're the only team that gets to do like, you know, touch the new technology or do the do the new fancy shiny things. Like that's not really fair. Like I want to do that. Um and I I don't think that people realize that a lot of the stuff that we built we had to throw away. So, I'm just touching on this because I this is just like I feel like another misconception, but prototyping uh at least the way that I think about it is not about it's not about just like building things or like making things fast or I don't know like there there's a goal and the goal is answering business questions with the least amount of effort as possible to give you an accurate answer. And so I would make an argument that you can have prototypes like some of your best prototypes might be a PowerPoint. They might be a single page document with a picture and an explanation, right? Depending on what the goal is, the the goal of the business and what question you need answered. What is the fastest way that you can get the answer to this question that's meaningful? So working with customers, getting their feedback. Like I said, maybe that's a single page document, maybe that's a PowerPoint they can click through. Uh what's really cool with so many AI things now is like I do think that AI can really help you get examples like this where even if the thing that you built with AI, I'm not I'm not generalizing here to say everything with AI is crap, but even if you built something really terrible with AI, you're like, I could never ship this. that might be a perfectly good prototype to have someone go click through and it's like it feels more valuable because it's tangible and it was still low effort, right? So that might be a great option, but the point is that it's my my focus for prototyping was always how do we get an answer for the business with the least amount of effort and still get a valuable answer. Once you have that answer, great. Your prototype has served its purpose. Depending on the answer, there was sometimes situations where the answer was like, "Holy crap, like we are actually on the right direction, like on the right path here." Like what is the next thing that you need answered? Right? In some cases, you'd have to think about graduating the prototype. Is it just graduating the idea where like okay that idea makes sense let's go get a team to start this off sure right do they take the prototype maybe like do you need a rule on that like I don't think so we talked about this a lot but like does that have to be a rule carved in stone like I don't think so no if the prototype had a decent enough starting point like go use it great be gone go use it otherwise if you're like great it served its purpose but there's There's no way we're building on that crappy foundation. And you used I don't know like you vibe coded it. No one can even read the code and we don't even use that language here. Like we're not touching that. Great. Toss it out. Start again. Fine. Right. But the prototype serves a purpose and be ready to throw it away because it did its purpose. And I don't think that some people were comfortable with that. So they saw, oh, you're doing new shiny. Oh, whatever. But some people are get I don't know depending on how much experience you have in the industry. You might be a person like this. I I am too. But like you know we get attached to things. You build it and you're like you're proud of it. Having to throw something away is hard. But like we had to accept like hey it served its purpose but sometimes it feels like oh I'm tossing my baby away. I work so hard on this. It's like some people aren't comfortable with that. If I did FPS, I don't know. I agree with that generalization. Was that about my the AI slop? Um, some other options that I I talked about a little bit earlier. If you're looking for more variety, right, you might want to um look into it's all crap. It's not all crap. It's not all crap. All of it. Yeah. Okay. [laughter] Um, contract and freelance work might give you some more options. I talked about this one earlier, right? where you can get a little bit more variety if you have more control over what you're doing, right? You might take a a contract position for a period of time that's relatively short and that's enough time where you're like, "Hey, I built some stuff. It was fun. Cool. But I want to go do some contract work somewhere else." and the type of work you're doing. I don't know, maybe that is depending like maybe it still is like maintenance on an existing codebase or whatever, but it's enough where you're doing different things and that feels like you're you're kind of scratching that itch. I mentioned freelance work earlier. If you're doing if you're your own boss and you're going around to different clients, if you want to start stuff from scratch, that's on you, right? Like you can make that decision. And then finally, um, side projects, right? I think that for me that's main that's always been something that I've kind of kept close with me, even while working on teams that did prototyping, right? Building side projects. That is always an option where if you're like, I just want to try building new things. I want to experience working with something completely different. Go build it. I realize not everyone has like uh what they feel like is enough free time to go do that but like that is an option to explore. Okay. Um, I think that like something else I wrote about here is around this idea of if you if you kind of come to accept that you're maybe spending a large portion of your career working in existing code bases, you know, maintaining things or just building on existing systems that if you accept that, I think it's worth kind of thinking about, okay, well then how do I work effectively like that, right? Because this is another missed thing. Um, I've been trying to hint at it a little bit more and I I kind of briefly kind of said it earlier, but one of the pieces of advice that I like to give new software developers, I mean any software developer, right, is like is building side projects, but especially for new software developers, I don't think that I've stressed enough that like [snorts] yes, um, building side projects is a great way to, you know, to learn different technology ies. It's a great way to practice building things, but that's also missing something. And the something that it's missing is like working on existing code. And um I think maybe this is a reminder for myself that like in some of my content I have to do a bit better of a job bringing this up. Like I the re one of the reasons that I wanted to talk about this was like I don't think that this is actually getting enough attention even from me when I'm talking about it and um and that almost feels like uh a little bit misleading not on purpose right because I do think that building projects is a great way to practice but that framing almost always seems to be yeah go build a new project right go build it from scratch go pick something go start it, right? So, anytime you want to go experiment or try something, what's the first thing you do? Well, if you're a .NET developer, you're opening up Visual Studio, right? New project. Let's let's rock and roll. But like, is that actually the most representative thing that you're going to be doing at work? No, it's not. For for a lot of us, it's not. And so I think that it's worth mentioning too for things like side projects. There's nothing wrong with if you have a bunch of side projects, right? Like the next time you want to go try out a new library or you want to play around with something like does it have to be a new project? No. Go take something that exists that you have, go build in that, go refactor it. Right? you have um a client server application and I'm just making this up on the spot like you have a server that's running NodeJS and you have a a client that's a an Android app. Cool. You want to learn, go rebuild your server, right? Go do that. keep some pieces of your front end, your your mobile app, maybe um I don't know, maybe the way you built your mobile app, you can go I I don't know enough about mobile develop, but you can like pick different pieces to swap out. You don't have to start everything from scratch, right? So, you can pick parts to rewrite, you can pick parts to refactor. Um maybe a better example is like uh I'm trying to think of a good one. Um, okay. You have a backend server and like you want to pick a different database technology, right? Like you don't rewrite the whole server. Like how can you keep your your your service deployed and go swap the database out without having downtime? Like that would be a cool thing. I mean, cool is subjective, I guess, but that would be a thing that you could try out. It would be really good practice. It would be hard, but it'd be interesting, right? So I think that there's lots of things that we can do with our side projects in terms of learning and practicing that that model what I would call like the the real world a little bit more closely instead of just like okay new project I'm Is there value in doing a new project and starting from scratch? Of course. Of course there is right? That might be the quickest way to get up and running in whatever the new thing is that you're trying to learn and that's fine. But I I I don't think that we should ignore like going back and working on things and extending them and building on them because that is a very common thing. So some things that I wrote down uh in terms of like trying to build up this skill set like this is kind of a weird one but I think it makes a lot of sense if you if you are working with like live services. Hear me out. Um treat it like it's a living thing, right? It's It's a little bit harder to get behind this if you're shipping like a desktop application or something that's not live. It's just like you build it when it's good to go. Push the build up, people download it, or you ship it on CDs or floppy discs or something. I don't I don't know what people do these days. Um it's a little bit harder to to kind of have that mental model as like a living organism. But when it's a live service, you can't just like take the service down to go add the new feature. You don't do that. You can't kill the service. It's living. It's breathing. Right? Um you're trying to go build new features. As you're building stuff, there's monitors going off and you're like, "Oh crap, something's going wrong." Right? It's it's kind of like a living organism having a health issue. You got to go check it out. You got to go fix it. you're putting a band-aid on it or, you know, it broke its leg and you have to go do some surgery and and fix up the leg and make it stronger, right? Like, treat it like a living organism. And I think that that's maybe um kind of like interesting framing for like if you needed to keep this thing alive, how would you approach that? Reading code and understanding code, I think, is um I don't know, like [laughter] underrated for sure. uh including myself, right? Like all of all of us that are talking to newer developers about being better developers, we're always talking about like go build this. Go practice. Go practice. But like read code, read code, learn how to navigate code bases, get comfortable like getting a little bit lost in like navigating call stacks and understanding things, right? How does the logic flow through this? I think one of the interesting things about learning more programming languages in my opinion is getting comfortable being like I don't really know what this you know I'm not totally comfortable with this but I can still find my way around this because that's very very very representative of working in the real world and having to jump into a project or um like an example from literally you know very very recently is when I'm on call, right? I'm an software engineering manager and I don't write code for my team right now. Okay? And when I'm on call, there's absolutely situations where it's like, hey, like we got to look at this call stack. Like I didn't write this code. I'm not coding in this every day. I do know how to write code because I like to do that daily still, but it's not part of my day job. So like I need to make sure that I understand how to do that. I need to understand how to get comfortable looking for part of the call stack and going cool like I got to go find this in the code and read through the code and try to figure out what's going on. Does that mean that I necessarily have to be the person to go fix it? No. But like in terms of debugging it and understanding it, like I still have to do that. So get get good at reading code um documenting things. So I think especially um I don't know be interesting to hear from folks if people are comfortable in the chat but like if you've onboarded to a team I feel like a lot of people have pretty bad experiences onboarding. It's like there's not enough documentation or things don't work or whatever it happens to be. It's just like it's feel like it's very commonly not a stellar experience. And I think something that helps with that is like it's kind of like documenting as you're going. So if you're the person on boarding and you're like this is a crappy experience for whatever reason, not to blame anyone, right? But it wasn't good. Cool. If you were trying to document the things that you were doing as you were going, you're calling out all the spots where you can be like, "We have blind spots here. This was not obvious. I couldn't find this." Right. Oh man, my chat says LinkedIn user. Who are you? LinkedIn user. I'm going to LinkedIn to find you. I'm doing it. Joining my own stream. Learning to decipher code. Yeah, that's right, Miguel. Awesome. Sorry. Just like I don't know why Reream is like that, but yeah, I I think that's uh it's a great point, right? It's like learning to understand is like what code is there is is incredibly important. We're doing it all the time. Um document what you're learning, what you're getting stuck on. Um you can call out blind spots to other people. You might have more senior people on the team that can help get that documentation added. You might be the person to go write it and then you can have someone more senior review it and make sure that it makes sense, right? You can be part of that. Then the next person that comes on can go through it easier, right? that this is part of like being on a team like you're trying to navigate the codebase and figure things out. Make it easier for the next person to do so, right? Um and then like yeah, I think automating is important too. So that was one of the last things I wrote down. Um kind of ties into the next point as well. just like I think when you're working in a an existing code base if you're finding like there's a lot of things that you're repeating because what happens is the longer a code base is around the more it evolves the kind of wonkier it gets right um I think everyone has in their mind like oh we're going to pick some architecture and it's going to be perfect and like straight up like [laughter] not long after you start coding it's not going to be perfect anymore or it's just how it goes. That's okay. Um the idea is that you want to make sure that you could have enough flexibility to to stay on track and and keep building things and you're getting the values that you want out of the system that you're building. But um you may find that there's common things that you're you're doing a lot when you're navigating code bases. So I think automation's valuable. Um, something I that comes to mind off the top of my head is like, uh, especially with how much AI uh, tooling we're getting, like can you wire up AI to help get some documentation going? Right? Like that's kind of that's why I said it's kind of related, but you know, can you instead of you going, "Oh man, like we don't have docs on this and I have I don't want have to go take all these notes." like can you can you get some tooling wired up and you can go get some some decent docs put together with a little bit of automation and AI support, right? Like can you find creative ways to do that? Because there's probably plenty of examples the longer that you're staying in existing code bases where you're like, I'm doing this same thing a lot. How do I make this something I'm not doing manually? Um, yeah. And you should be the person who wants to write it. Even at Uber, mid-level engineers wrote tons of documentation. Yeah, it's um it's interesting, right? Documentation is a funny one because um lots of people ask for it, right? People like, I want good docs. There's some people that'll never even read the docs, but like they're not there. Like, it's a thing to complain about, right? So, you'll get people like that. you'll have people that want them and will use them and you know make sense. Um but it it seems like more often than not like people don't want to write it [laughter] and it's hard because documentation is one of those things it's like the instant you write it it's like it's out of date because things change and move so fast. So, I personally think that, you know, documentation is super helpful and if you can find the lowest effort ways to keep documentation up to date that you can kind of like share the load across the team, I think that's a recipe for success. If you have like one person who's writing the docs, like man, that's going to be pain in the butt. [laughter] Unless you have someone who just loves writing docs and can teach other people, I I don't think uh I don't think that's a a stellar setup. So, you know, share the love that way. Um I think when people start seeing wins that come out of documentation, it's a little bit um feels more promising. It feels like you're not wasting time, right? Doesn't matter. Maybe it's a little bit out of date. Okay, no worries. that helped someone and when they got stuck on something and uh they still leverage your docs, they can be the person to go update the docs now, right? And that's what I'm saying. Everyone kind of shares the load a little bit. But truly, um find ways to make that a little bit more automatic and I think that's going to help uh a tremendous amount. Um I think that's mostly it though folks. Um I like I said, I wanted to talk about this because I I do think it's a bit of a misconception around maintenance, around innovation. um and sort of what is what I feel more common in software development if you are you know someone who's trying to get into the industry and your expectation is you know I'm going to I'm going to join Microsoft that's where I work right so I'm going to join Microsoft and like I I can't wait to you know day one start new project and start building the next thing like it's it's probably not what it is it's probably not how it's happening And that's okay. It doesn't mean you'll never start a new project ever in your career. Uh doesn't mean there aren't teams doing more of that. Like I wanted to make sure that you saw different perspectives on some of these pieces. But uh I certainly think the more common ways that you're you're building on existing products and services. Um yeah, people just copy what's already documented on websites instead of linking the docs. Yeah, hate that. Yeah, it's hard because uh especially if you're copy that's a good point. If you're copying documentation and stuff around one of the challenges with that is that it's kind of like code, [laughter] right? You have copies of documentation and stuff everywhere and then it's like, oh, we have to update the docs and it's like in how many spots, man? Like it's copied in 20 spots. Link it. Um yeah, I think you know having having good documentation is uh you you notice it when you have it. I like giving uh it's not even something that I use at work, right? But I love giving Jod Denetti a shout out for Fusion Cash. Give me one sec. I'm going to share my screen. I just want to pull it up. Fusion Fusion Cache on GitHub. Um I love his documentation. I think it's amazing. And I say this as someone like I've said this before. I am the kind of developer like I don't read the docs. [laughter] I don't uh when I'm building stuff, I like to mess around. I like to get in and if I have to spend time reading, I know it's probably faster. Been doing this long enough that I know that's probably the right answer. I just don't like doing it. Um and it's feels kind of stupid because I'll get stuck on really trivial things and I'm like, "Oh, finally read the docs." And I'm like, "Yep, it was right there." But Jod Denetti has um he's the author of Fusion Cache and I feel like his documentation is it's like enjoyable to read because it feels like someone's talking to you. Okay, so I'm just clicking on I haven't read it in a while, but like he's got pictures, right? We're not going to go through like all of his docs, but like he's got pictures. Um he explains things, he gives examples, right? And it's not just like, you know, what's a factory? Here's the code for it. Next, what's a, you know, what are cash levels? Here's the enum. Next, back plane, you don't know what that is. Cool. A back plane, like, you know, oneliner. Next. It's not like that. It's like he explains things and then look, read more. Okay, I'm just picking random stuff, right? So, here's pictures accompanied with text explaining what a backplane is and how it works with examples. I love reading Jod Detti's documentation on Fusion Cash. I'll be transparent. It's not something where I'm like, "Oh, time for bed." and I pop open the fusion cash talks. But like I think he's done such an incredible job and like I would strongly encourage anyone who's watching this if you're like I want to go, you know, build open source stuff. I want to, you know, build a package and I want people to I want to have good docs. I would I'm not saying you can't like use AI or you can't write your own or whatever. Do whatever you want. But if you're looking for some inspiration, I think that he's done such a good job with uh with his documentation. I'm just picking another random one. Discash like it's just it's just so good. Um but anyway, this is I think a stellar example of this kind of thing. So, you know, I I don't love reading docs just because I don't know like it I'm the kind of person who just likes to jump into the code. But, um I know that when I was using Fusion Cache, probably got stuck and then was like, "Ah crap, like fine, I'll read like I'll go look on GitHub and I'll check out the documentation." I was like, "Oh, crap." Like, "What else can this thing do?" I'm scrolling through reading the docs. Like, it kept me pulled in there. So, um, Pay Wang at Walmart writes beautiful docs. Great shout out. That's awesome to hear. Um, but yeah, like, um, and he's saying, "Yeah, you can tell when they love writing docs." I love writing dogs, too. I use color coding, all kinds of Yeah, it's it's interesting, right? Like people, um, I think you can like you can tell when people like doing it because it doesn't feel like it's the minimum amount of effort. It's like someone put in effort into that [laughter] and it like you can tell when you're reading it and uh it's cool. I think it makes a huge difference. So, um anyway, I think that's it for the stream, folks. I wanted to say thank you so much for being here. Um I'm going to go through a couple of things that, you know, just to share so you can see uh more stuff. So, I'm going to go back to this um this Oops, I'm picking the wrong thing. Was I sharing my screen? I was sharing my screen, right? Or no, because I just realized I have [laughter] two I have two OBS instances and I might have been swapped over to the other one. Was I sharing the Fusion Cash Docs? You guys got to see that or am I being dumb? There's a bit of a delay in the chat. Please, someone tell me you saw the Fusion Cash Docs. Yes. Okay. Thank you. [laughter] I have uh you can't see, but like I have a vertical monitor to my left and I had two instances of OBS and then I went to go um to share my screen again and I picked the other OBS and I'm like what what's going on? Um but thank you. I I appreciate that. And Miguel, thank you for joining and thanks for the the comments. I I do appreciate it. I think that was still Miguel. I'm just refreshing LinkedIn. I don't know if anyone else from LinkedIn was on. Yep. All Miguel do appreciate it. Didn't see them. Well, Baron Bite says yes. So, [laughter] someone someone saw them, but these are Yes, you. Okay, perfect. [laughter] Okay, so this is uh where the newsletter is. So, I'm just going to put the link again in the chat. And so, like I said at the beginning of the stream, if you're not interested in email newsletters, don't worry. Don't subscribe. Like, I it's free, but like don't do it if you don't want to read it. But, um, the newsletter is generally the spot where you will see the topic for the live stream. So, if you want to join next week, 700 p.m. Pacific, if you go to weekly.devleer.ca, you can see what the topic's going to be. And the way that works is I will just jump over to code commute super quick. But code commute is my vlog uh YouTube channel. And so this is all basically userdriven, right? So I have people that will submit questions. So you can do that here. Um let me pull up code.com. So I do have a site where you can submit stuff anonymously as well. Right. So there's my cars. And then if you go to contact, you can submit anonymously and then it'll send me an email. So if you're like, I don't want to just leave a comment on a YouTube channel with a with a question, like totally cool. You can submit this way. Otherwise, like just send me a message on social media. If you're like, I don't trust whatever this is and whatever, just send me a message on LinkedIn or Twitter. Um, you can pick any platform really, but like I would say LinkedIn is probably the best if you're trying to get my attention for what it's worth. Um, just as a heads up. So that is um code commute, sorry, is this channel and mostly it's me driving, right? That's why it's code commute. Uh, but there's sometimes like, you know, this week for example, I'm not going to go to the office much because I'm on call and it makes it a little bit trickier when I'm working on call. So, sometimes I'll film it right in this room. Uh, other times I did one in like my my dining room, but yeah, mostly on the commute. Now, other channels I have Dev Leader, which is my main YouTube channel. I have ported all of this content to essentially just be focused on uh C development and programming with AI tools. So, you can go ahead and check that out. I will put that in the chat as well. I think um same [laughter] bad channel, same bad time. Um yeah, I think the uh this channel is probably where most people found me from. Although I do get a lot of people coming from Code Commute, which is pretty cool. Um Dev Leader is where like things started for me, right? So I started blogging with a B this time. I started blogging like in 2013. Kind of gave up on on that because I'm like, "Oh, no one reads my blogs." But, you know, I wasn't blogging for very long at all. And uh in 2023, I said, "Time to make YouTube videos. Let's go." And tried just basically publishing content everywhere. So, uh this is the channel I think most people have found me from. I have the Dev Leader podcast, which is where I'm live streaming from right now. So, if I give this a little refresh, will it show the live stream? It does say that I'm live. Nice. Okay. And then there's one more YouTube channel. And I just realized I feel really stupid, but I thought I got through all my YouTube recording for the weekend. And um I didn't because I think I have a couple of résumés. But ré reviews are on this channel, Dev Leader Path to Tech, if you're interested. So free ré reviews. Check out a video if you're interested. They're not a um it's not like roasting or making fun of people. Yeah. SEO. SEO, bro. Uh, I'm just tired of it. I was trying to do like SEO optimization for forever and I'm like I'm just I just don't care. Just I'll make the content. It hopefully does its thing on social media. But yeah, um, this channel is all resume reviews for now. I might branch out into some other interview type stuff. So, it's really about um, you know, prepping to get into the industry. But, uh, just to jump back to the Dev Leader podcast. It's a live stream, but I also interview software engineers here. So, I've had lots of fun, interesting guests. Uh, one of the things that I do on every interview is I I force my guests to go through uh their career journey. Uh, I say force, but I I ask them politely and so they know what they're getting into. But it's super interesting. I think my goal with doing that is that I want to spend a little bit of time with every guest to show the audience that everyone has a different journey. Every single person, right? So, some people like there's people that switched careers at 30 or past 30. Um, one of the ones I did recently, I think I mentioned her on last stream, but uh Samantha here like [laughter] was so funny. She's uh cuz I'm like, "Let's, you know, we'll talk about your your career so far." And she's like, "Oh, there's like a you know, buckle up because there's it's there's a lot of different paths." And I'm like, "Yeah, I've done a bunch of these." Like, I I know I know people kind of go different directions. And every single time she was telling me about a job, she'd tell me about the next job and I was like, I did not see that coming. So, it was like every single time it was something completely different. And um one of the reasons I loved that though was not only was it kind of like a truly like a roller coaster um every time that she said I I was ready to switch jobs. How she thought about her next job wasn't hm what's the way that I can just make the most money which I don't think is a wrong decision to make. You're allowed to make any decision you want. But what I loved about her thinking through it was like, "What do I love to do?" And I thought that was so cool to hear someone say, and that that framing just took her in so many different directions. I was like, "That is that's awesome." So anyway, thought that was really fun. Uh, one of the ones I did most recently that I posted here is I have two others that are coming out. Um but Bavia is actually a former classmate of mine. So that was super cool to reconnect. We went to university together. So um a lot of fun to catch up. But yeah, there's a lot of interesting folks. Uh if you're a net developer, I had uh Scott Hanselman. He was on uh Scott's awesome. I had Hassan Hhabib. He's Where is he? He's hiding here. There's Hassan. Um yeah, lots lots of awesome guests. uh very fortunate to uh be able to sit down with those folks. Um otherwise courses. I can't have a live stream without doing courses, right? I'm just a I'm just a tech influencer trying to to shill you my courses, but I make courses on domain. I'm trying to be sarcastic. Um [laughter] I make courses on dome train. Uh the courses are the thing that essentially does uh sort of power the rest of my social media and content creation. I lose lots of money making YouTube videos. [laughter] I'd love to tell you that, you know, I'm crushing it on YouTube and whatever, I'm going to retire because I make YouTube videos. Absolutely not. I make YouTube videos and I lose lots of money from doing it. So, um, courses are the thing that helps, you know, facilitate that, which is great. So, if you are interested in learning C and net development. I have the getting started and deep dive courses on dome train and then a couple others in C but then I have other courses that are more like soft skills and career development and I partnered with Ryan Murphy for those ones on dome train. So do go ahead and check that out. Uh Nick Chapsis generally has sales on so um is get 40% off everything with forever code black Friday 25. So there's one. Check it out. And finally, I will do a Brand Ghost shout out. Brand Ghost is the platform that I'm building. So you'll see a lot of my YouTube videos and content I make. I actually use a bunch of examples from Brand Ghost because it's very relevant for me. Brand Ghost is the cross-osting and scheduling platform that I use for all of my content. So given that you're watching this, if you didn't come from uh you didn't come from kick or Twitch, then you might have seen my content somewhere. By the way, thank you so much uh on the public speaking skills. That's awesome. I will touch on that in just a second. Um the if you see my content posted on social media, it is posted through Brand Ghost. So, I mentioned a little bit earlier on the stream that when I was blogging and gave up and I said, "Okay, it's time to make YouTube videos in 2023, a decade later, I knew the reason, one of the reasons I gave up was it felt so overwhelming to post content everywhere and then still have no one watching it. So I said when I go to make content this time and do it for real, I'm building a system for myself where I can just make the content and it will post everywhere all the time. That's what brand ghost is. Uh just to pause on that for a second on the public speaking part. Thank you so much because um something that I've shared on streams before, if you watch code, it comes up. But one of the the things is like public speaking for most of my life. I labeled myself as afraid to public speak. I hate public speaking. Um I remember being a kid and it was like if I had to do presentations at school, I would have anxiety like crazy, you know. Um, once I got speaking, it was kind of like I was okay. Like I hated doing it, but I'm like whatever. I'm up here and it's fine. But leading up to it, especially the moments before, I was like there was nothing else in my life that I would [laughter] that I would uh hate more than like those moments. And so for a long time it was like, you know, public speaking is the worst. And then when I started making YouTube videos, um it took me uh a year. It took me a year before I was like, I can talk to this camera, but still was like, it's kind of awkward, but I can do it. And we're on, this is year three now. I've been live streaming once a week for about a year, maybe longer, I don't know. Been doing those podcast interviews, but I would say the live streams have made the biggest difference. And uh so it's uh you just wanted to say thank you so much for the compliment. U I do appreciate that. And um so brand ghost and I am reading uh blogging platform to get you hella viewers. Perfect lighthouse scores. Wow. I I definitely don't have perfect lighthouse on my my website, but [laughter] I have uh all of my content going through Brand Ghost. If you're interested, it is 100% free to use for crossosting and scheduling. I always like showing people this. So, I'm just going to jump back over to Brand Ghost and pull it up in this browser. Give me one sec. So, this is my calendar for content. You can see that for November, it's pretty busy, right? Got a lot of stuff going on. If I pick uh a nice random day, let's pick the 26th. And I realize that the chat is covering it. So, one sec. Where's my mouse? I got too many screens. I move my head over too. Okay, so this is on the 26th. This is my set of posts that will go out. Okay, scheduled. Like I have a a short form video that's going out. I think that's 12 platforms. Okay, like that's that's everything that's going out on the 26th. Now, I just want to show you something really quick. I'm gonna jump to um I don't know what's a good month next year. Do we want to see uh July? July looks like a good month. Anyway, all my content scheduled for July. So, if we want to check out July, the 4th of July, right? That's I'm in the US now. That's a thing. So, cool. All of my content is scheduled for the 4th of July in 2026. Here's another short form video going out to 12 platforms. Here's Code Commute. All of this stuff is perpetually scheduled for forever. And I don't schedule it myself because that takes time. So Brand Ghost does it for me. I just create the content. So if you are interested in this kind of thing, the perpetual scheduling, that is part of the paid tier. So if you're like, well, if we get all that stuff for free, what are we paying for? That's what you're paying for is the perpetual scheduling. We have some other advanced features like you can see on the I got to move my head again. One secoop. That's what happens when you're live streaming, right? But you can see on the left I have this feed here. This is where I can go to answer all of the comments on my posts, right? So I got 26 unread ones across platforms. I think yesterday I had 65 to go through. Um so you can do your commenting and stuff all in one spot which is super helpful. But uh yeah, my content is perpetually scheduled. One of the benefits of Brand Ghost is that I can just make content, right? And I think for me that's been a total gamecher because I got to move this chat out of the way. Um it's been a game changer because I have time to go make content. So just to give you an example, yesterday I filmed three videos for Brand Ghost. I did two podcast intros and then I did three No, I lied. I did two um two YouTube videos for Dev Leader and I coded in brand. Like I I basically just made a whole bunch of content and wrote code yesterday and I could do that because I wasn't going, "Oh crap, I got to schedule all my content for the week. I have four YouTube channels, [laughter] right?" Like when you get to having a lot of different platforms to post on, it becomes really comes becomes a lot of work just to schedule. So um so I use brand ghost. So this what I build. It's innet. It's carb based inn net. It is hosted in azure. We do have a nex.js front end. So we got some typescript going on. I stick to the backend stuff because I like my C. But um it's a lot of fun to build and yeah, if you watch the Dev Leader YouTube channel, you'll see some stuff about Brand Ghost. And uh I do kind of uh mention like how I use AI in Brand Ghost as well. So just to give you a heads up for some of the upcoming stuff um especially related to AI, I'm going to switch back so you can see my face. This is me. Um, one of the more the video I filmed yesterday was talking about how I'm trying to put better guard rails in place for AI agents. So, I was talking well I you know, everyone knows like get your co-pilot instructions or whatever you're using, right? Your agent MD and then you can have custom agents now. So, you have more markdown for like guiding your agents. And then you've heard it from every AI bro out there. Like skill issue, bro. You're just crappy at prompting. So, you got to get your prompts down, right? Like, we all know this, right? And you can keep getting better, and you should. You should keep practicing. The models will keep getting better. The tooling will keep getting better, but there's still going to be this little gap where it goes off the rails a little bit. And you're like, it's so sometimes it's so close to being, you know, the perfect solution. And you're like, but I also asked you to write tests and the tests are trash. Like we were so close. It could be, you know, something small, could be big, whatever. Point is that it seems like no matter how good we try to get at giving prompts, proper guidance, the agents can go off the rails a little bit. I'm sure. I'm hoping, but [laughter] I feel very confident in like five years, we're not going to be talking about how, you know, how difficult it is to keep the um the agents doing the right thing, right? But for now, we do have to focus on that. And I've been realizing that um it's I feel more and more like it's like keeping people on track. And that sounds kind of weird, but what do I mean by that? Like if you were to invite a different developer into your codebase, my philosophy, and I know this is like it's not easy to do and it's not really that realistic, but if you could invite a different developer into your codebase, I personally would want them to feel confident that they could contribute meaningfully into the codebase and they could write stuff and it would follow the patterns and I would go to review it and I would be like, "Hell yeah, that's great code. I love it." Like, I would want that. So, how do I get people to do that? Right? So, I've been trying to think about this more and more, and there's one example that came to mind, and I didn't I'm not like trying to claim like I invented this by no means, but kind of clicked for me where I was like, hold on. I think for most of us if you've used an IDE where you have something like um IntelliSense or you have something that's like uh I don't know like you're getting immediate feedback for what you're typing being correct or not like if if as soon as it's coming out of your fingertips you're getting that feedback about whether or not it's the right or the wrong pattern that's the earliest right that's the earliest time we can get that feedback and we have something like that forn net developers and it's Roslin analyzers Not only that, we can have Rossen analyzers that are like, "You're doing the wrong thing. You shall not pass." Right? Gandalf pops out of Visual Studio and he's like, "Bam, you're not you can't write that." That would be that's a good plugin to go make. But, you know, you get this feedback immediately and you you can't do it, right? So, that would be the ultimate thing for a person. And I was like, "Wait a second. We should be like I should be doing this for my agents [laughter] because my agents are writing things that will compile. They will work for the most part, right? Like that's great. That's really cool. But it's it's inventing new patterns in my codebase. I jokingly was talking about this the other day, probably too many times now. Most tests follow some type of a range act assert format, right? It's pretty pretty common. But what I don't want or need in my tests is the comments that say arrange act assert. And I have this everywhere in my documentation that says don't leave these stupid comments and the agents will keep leaving these stupid comments. I could go write an analyzer and I should make this YouTube video. [laughter] I should make this YouTube video where we go write an analyzer that looks for stupid comments like that and it says no. [laughter] It's a that's a compilation error. You can't leave dumb comments that say arrange, act, assert. And I think kind of giving the guidance like this to the agent where it's like, you know, it might have made the wrong decision. It's trying its best, right? It read the instructions and still was like, I'm putting a range assert there, Nick. You can't stop me. And then MS build is like, actually, no, you can't. I'm hoping and I'm trying to play around with this more that the more analyzers I put in place, the more that we can guide agents this way. So, I did make a video just highlighting that um to start. Still TBD. I'm going to need time with it to see like how much better it's making it. I have one fear. I have a couple fears. Spiders are one of them. But one of my fears with this is that the agents will go, "Oh, it doesn't compile. Oh, it's an analyzer error. H, let me suppress that. Right. Let me add the line that says suppress compiles. So, I will see how effective this is. Um, but that's one of the strategies I'm trying to do. So, yes, my co-pilot instructions, keep beefing them up. Yes, my custom agent, keep beefing that up. Yes, my prompting skills, bro, need to get better. I will keep working on that. But I'm going to put more analyzers in place because I'm not letting this code compile unless it's the right thing. So that's what's coming out this week hopefully and I will keep trying to put out some more content like that on Dev Leader which is my main YouTube channel. Um DJ Neil, yeah I I honestly started making the front end of Brand Ghost and Blazer and then when I started working with my my co-founders on it, they were like we should probably use like Nex.js JS or something and I was like if you guys want to build the front end like you use whatever you want and uh truth be told they're significantly faster building stuff in the front end uh then I would be even with Blazer. Um but yeah, if I was working solo I absolutely would have used Blazer. Um I just I'm very comfortable in C for that. Um why why you should rewrite something that's just created. Sorry Claus I didn't understand your question. Uh, do you want to would you like to reask that in maybe a different way? And I'll try. Uh, Miguel says, "They used to have llinters that force you to use semantic HTML and they magically disappeared." Uh, yeah. I I think, you know, a llinter is a great example of just like the you know, if you're not a .NET developer and you're like, "What the heck is a Roslin analyzer?" It's a llinter, but it's pretty powerful. Um, AstroJS, get out of here. I don't want to see those those two letters together. JS or TS. No way. We don't do that here. [laughter] I'm just kidding. But I like I like my C#. Yeah. Sorry, Claus. I I don't know if you're still there and I I apologize because I don't think I understood your question and I want to make sure that I can try to answer. Yeah. Yeah, and I think uh DJ that's a a really good point, right? Like even for me like I'm a I am a C developer. Oh, thanks Claus. I I missed that. Um but yeah, I'm I'm a C developer and you know not having Blazer before it was like I kind of had to jump into React and like can I navigate React? Sure. And like especially now with like leveraging AI, if I had to go spin up a React app and go add stuff, like it's pretty pretty damn good at like [laughter] putting together user interfaces in in React, like better than I could for sure. Um, but the nice thing with Blazer is like it's just so familiar in terms of what I have access to and the parts that are unfamiliar. Like I've talked about this when it comes to learning things. At least like my my philosophy is like if you change too many variables it feels overwhelming but if you change like you know change a couple right you fix a bunch of them and change a couple or change one then uh learning feels less overwhelming. Um so I found with Blazer like that was a good match. Now, there's a bunch of stuff that like I wish I had more time to go do like if I didn't work a 9 toive job. Um, I would spend more time like I'd go I haven't built anything in Maui yet. I'd love to play with Maui. I'd love to use Blazer more. Um, you know, the video I recorded yesterday and I was just telling you folks about analyzers and stuff. I said in that video, I have wanted to go work with analyzers and source generators for so long now. And I'm like, I just I just don't have a use. I don't have time. I got a million things I'm trying to do. And um even to go make those. I think I have 30 something analyzers in my in my codebase right now. Those are all vibe coded. All of them. Every single one of them vibecoded. And so I told C-Pilot what I wanted. It did the first kind of pass of it and then I checked out the branch and I messed around with it and I just said like I'm changing this thing that I want the analyzer to check. Does it catch it? Oh, it's catching these other patterns. I don't want that to match. And I messed around with it. And I literally just vibe coded back and forth and I've done like 30 of them like that. Now I have what's really cool is I have a bunch of examples of analyzers. Now are they trash? like the code is probably not great, but now I have some examples to go through and now it's like I don't really have a choice but to have some exposure to this and I'm hoping that you know over the next I don't know how many months it'll take but I'll spend more time with them and then I'll try to get some content out on analyzers and same thing with some source generators. Um, perfect for lighthouse. Okay, I'll be dipping my toes in Maui within the next few months. Nice. Somebody spin up your Hangry app. Oh no. Oh, like you're going to make Hangry. Good. Yeah, I think it's a cool idea. For those of you that don't know what Hangry is. I DJ, when did I even talk about Hangry? I can't remember. I'm I'm sure I said it on Code Commute or something. I had this idea with a buddy and um it was a really fun thing to build like I think it was during the beginning of COVID. Um, I don't know if I can say that word without my my video not getting views. Um, but we built it was like Tinder for restaurants. It was it was a lot of fun to go build. And so the idea was that uh you've been in this situation if you've been with your significant other or even like colleagues at work and it's like we got to go out for lunch and it's like where are we going to eat and it's like no one makes a decision. So, the idea was that you would go into a hangry session and it was like you would get the restaurants that are nearby in your area and you'd swipe on the restaurants. What do I want to eat today? And basically, it was just a way to vote, right? Like it's not really it's not really rocket surgery, but uh it was a lot of fun to go build. I I picked a whole bunch of stuff that I wasn't familiar with and just went and learned it. It was it was pretty neat. Um never caught on. That's why I'm still making YouTube videos and working at Microsoft instead of being retired on my yacht with my my hangry app swiping away. But that's okay. Now DJ can go build it and and it will be successful and you can have the yacht. Um [laughter] Spotify's a few months behind. Nice. Yeah. So that's a thanks DJ. Good reminder. Um code commute for folks that are interested if you want to watch it on Spotify or listen to it. Okay. You can go to spotify.codemute.com. Um, the Spotify channel is a little bit behind YouTube. I think I'm Oh, what did I say last week? I got 300 episodes now. 300 plus episodes scheduled on Spotify. Um, and I think YouTube's just under 400. So, um, but yeah, DJ, that's the perfect use case is when your wife says, "I don't know what I want to eat." You say, "Great. Bust out hangry and you swipe away because I feel like people don't want to tell other people what they want to eat, right?" It's like we feel awkward about it. Sometimes I really know [laughter] like we're we're getting this. Uh, fortunately, my wife and I I think we're we're pretty good. We like a lot of the same food. So, kind of rotate between like like there's a Thai restaurant that's near us that we really like. Um, it's mostly Thai. I love Thai food. So good. Anyway, folks, thanks for being here. I will see you all hopefully next Monday, 700 p.m. Pacific. And in the meantime, if you thought this kind of format was cool, minus the chat, you can join Code Commute. Um, I post a video every morning or during the week at least at 5:00 a.m. Pacific. And if you have questions and stuff that you want answered on the channel, you know where to go, right? Just go to Code Commute and leave a comment. So, thanks so much for being here. I will see you folks next time.