How to Survive The Sprint - Principal Engineering Manager AMA

All right, let's get going here. Just checking to make sure the bits are streaming through. Let's go. We'll see if Instagram actually works today, unlike last time. So far so good. Come on, Substack. Feel like Substack. No, Substack is so silly. We're almost there. One sec. Looks like the Substack configuration was going to the the wrong stream or something like that. Uh, welcome folks. Um, this is a little little exciting for me just cuz I switched my YouTube channel that I'm streaming from. So, we'll see if anyone finds it. I still don't even think Substack's working. Anyway, we'll see. Welcome, welcome. Um, if you're new to these live streams, these are an AMA format. So, please do use the chat, ask away. The topic for the day though is how to survive a sprint. So, if folks have questions and that takes up all of the time and there's lots of cool questions and stuff, I'll just keep answering questions in the chat. Otherwise, I'll go through my topic. Uh, I'd really like to to get Substack going here, though. Give me one sec. I just want to see if I can get it to go. It's kind of disappointing when it cuz I only do it once a week and if it's not going to work, it's kind of it feels kind of bad. Um, yeah. I don't know. Sorry, Substack folks. Um, cool. Yeah. So, this topic is one that came up on code commute and I was talking about it last week and I wanted to start by saying that I realize not everyone does sprints necessarily, but this is something that I thought was good to talk about because the person that was sort of originally talking through this had some some concerns kind of getting to a point where they're fearful for their job. And I've seen this kind of thing come up with individuals as well. So I thought that it would be helpful to talk through and again even if you're not actively doing like a traditional sprint with you know agile software development that um it's still something you can think about with respect to commitments in terms of like the work items or bugs or features that you're working on. So we'll go through that. I wanted to do something a little bit different today and I figured it would be fun to start this off with with this. Give me one sec. I'm going to switch over to this. I thought it would be fun to get a couple of ideas for whoever is active in the chat. At the start of this stream, we give GitHub Spark something to build and at the end of the stream, we see if it did it. So, I'm looking I have an idea because I was anticipating that if no one has an idea that I'll put one in here and um but I'm hoping you guys got better ideas than me. So, um thought it'd be fun to do this and we can check in on it at the end. So, I will wait for folks to put any ideas in the chat. Silly. Um, infected FPS, welcome. Man, I would love to know how to get through a sprint without more things piling up. Yeah, and like this is this is part of that conversation. So, we'll chat through that. Um, my chat on my side just said that it's back to zero people in the chat. So, hopefully that's not the case. Um, but we'll see. Okay, so I'm gonna start by going through this topic. And before I start, one more thing. Um I because I want to remind people about this. If you are watching this on YouTube, you're watching it on the new Devleer podcast channel. Uh I will and have been starting to like repost uh podcast episodes from my main channel over to that. And I will be doing all of my live streams on YouTube from the Devleer podcast channel. Unless I'm doing coding live streams. I'll do those back on my main channel. I just want to remind folks and I will remind people at the end that um the the reason I'm splitting my stuff up on YouTube is because YouTube uh when it's trying to serve content, it it basically impedes my my ability to reach people when I have uh more diverse content. So most of my audience is C and Net developers. If I post anything else, I can see it in the data. no one views it and then as a result I if I post content like that it's really not helping my channel it can attract people that then aren't interested innet and C stuff and then when I do post that stuff they're not clicking on it so I'm creating these other channels um I will still post all the same stuff it's just being split across them so um for spark I want to see it burn a res a recipe gant chart generator with start timer and alerts a recipe gant chart generator. Am I understanding correctly? Like for for baking or for cooking. Just want to make sure I understand that correctly. That's a totally interesting idea. Um, we'll see. We'll see. Infected FPS. Yeah. Okay, cool. I got it right. Okay, I will wait a moment for any other ideas in the chat. otherwise infected FPS. You might you might be the winner of of a fancy GitHub Spark recipe gant chart generator. That'd be pretty cool. Actually, I think I think that my wife would use that and I could tell her I built it all by myself. And I bet you I bet you if I told her how I did it, she would probably want to try because she more more recently like discovered chat GPT for doing things. And um I think in the beginning when she was hearing me talk about AI and stuff, I think it was kind of and I don't blame her, but kind of like that's nice like I don't care and I'm getting excited about things and whatever. It's just techy nerd stuff. And then I think she tried using chat GBT for something and then um and then she realized that she can get it to help her with like Excel formulas and stuff because she was always coming to me like show me how to do this in Excel and I'm like you know what I would do and then walk her through chat GPT and then she would get really excited that she has like formulas coming from chat GPT. So I think that that maybe maybe she'd think this is cool. Okay. So yeah, infected FPS. Let's try it. Okay. I'm gonna I'm gonna do it. So, recipe gant chart generator with start timer and alerts. And do you have a thought on how we give it recipes or do you want do you just want me to say like recipes should be searchable from like an API or something? Curious if you have thoughts on that. I think it will go discover stuff if there's APIs. Okay. Uh, a random program says a a road mapap uh plus resource generator forn net learning material primarily videos. Whoa, whoa, whoa. You're trying to you're trying to replace me here. Um, it would suggest how to watch the content order include timestamps. Okay, maybe we can do both. Um, let's see. Okay, so this is another cool thing. I'm super excited about this and I will have two YouTube videos coming out this week that one of them actually shows Spark and one of them will show clawed flow and sort of uh getting that set up. The um the GitHub Spark one is really just about kind of showing like you know it's not a deep dive or anything but it's like hey let's try using it and see what it does. And the Claude flow one is really just how to get Cloudflow set up on your your computer over top of Claude code. Claude Fo Cla, my goodness, Claude Flow is like a swarm kind of agent system on top of Claude Code. But I just want to show you this because I think it's super cool that I can keep my hands up here and then when I do this, um, see how Oh, I'm not sharing my screen. Oh, let's try that again. Forget forget you watched anything. Let's try again. I think it's super cool that I can keep my hands up here and then talk to you guys and then when I do this, all of a sudden the text is on the screen. So, I invested into a foot pedal so that um especially when I'm working with AI more, I found one of the more frustrating things was that um when I'm arguing with AI for it doing really dumb things and I'm like furiously typing on my keyboard like how could you not run the tests again? Um, it's actually just way quicker for me to do something like, "I can't believe you would do something so silly and not run the tests again. Oh my goodness." And then it's right there. Um, so that's kind of fun. And I find a lot of the time too, um, like we're prompting AI. I don't know like most like I don't want to say all in natural language like I'm giving it code snippets and stuff but for the stuff that is not code snippets it's just way quicker for me to to talk to it. So what are we building? Build a recipe gant chart generator with a start timer and alerts. And I would like for the recipes to be sourced from a public open API that we can search for recipes on. Okay, rock and roll. Does that look okay? Infected FPS. There's a delay in the chat, but you got to respond. I'm Send it. Let's go. This isn't even the main part of the stream, but cool. And then the other one we're doing is You didn't see anything there. Um the other one we're doing is okay let's get the foot pedal rocking a road map plus resource generator for let oh man this is the thing a resource plus re you know what I can't even I can't even speak a road map plus resource generator fornet learning material primarily videos where you're guided each step of the tape. It should suggest how to watch the content in order and include timestamps. We'll send that too. Cool. Dei equivalent of a smack in the face. Yeah, I I well for folks like Devon that watch Code Commute, I have been sharing that uh I legitimately am I'm finding like I'm getting physically upset working with AI where like I you know I'll be coding stuff for the weekend and uh on the side I have like a few terminals up where I have like agents you know coding on side projects for me and I'm not kidding but like I feel like my blood is boiling just like the most most annoying like silly things. And I'm like I finish a day of coding and I'm like I don't think I'm enjoying this. Like I don't I physically don't feel well. Um so it might be easier to to be yelling at AI instead of furiously typing. So this is this is doing the thing. This one's doing the thing. Let's get back. That's my face. Look at that. We'll get back to this guy. So okay. how to survive the sprint. Um, so again, this was uh put together because someone was asking about a scenario where um they were saying like they feel like their their scrum master and you can replace scrum master in this conversation with your product owner, your product manager. It could be your engineering manager, whatever. It's going to look different everywhere. But um they keep filling the sprint with so much work and this person feels like they cannot keep up with it. And essentially they're getting to the end of the sprint feeling like they're like I'm I'm going to lose my job. It's any one of these times I'm going to lose my job because I I can't get the work done. And um kind of looking for some some help and guidance on this. So, I I just want to, you know, I want to say that I don't think that's the way for anyone to go through work, like for any kind of job where you're trying your best to do whatever you can and like on a weekly basis, you're like, "Oh my goodness, am I going to lose my job?" I, you know, I don't think that's I don't think that's right for anyone to to kind of deal with. So, um, I thought it was important to talk through and, um, we'll start things off here. So, it's pretty common, especially for more junior people, but, um, it could be that you're just new to a team or a company or something like that. But, um, you start off a sprint. And again, little bit of context for people that aren't fully familiar. When I'm talking about a sprint, uh, this comes from, I don't I don't actually know if it comes from agile. I believe it comes from agile, but uh when I say sprint, I'm talking about a time period. Um generally like two weeks, but there's places that do one week sprints, two, three or four week sprints. Anything more than that I feel like is probably not a sprint. Um I feel like even four weeks is not really a sprint. That's more of like a marathon. Um the idea is you have this unit of time and this is a window where uh you will start the sprint off or you start off this period of time and you're going to as a team make commitments for the things that you would like to accomplish by the end of that period of time. Um some places will do this more strict. Um they'll have processes in place for like what you do when your stuff doesn't land in the sprint. Um other things will be a little bit more fluid or flexible for that kind of thing. Um, some places won't call them sprints. Whatever. Idea is like some period of time where you and your team are making commitments for deliveries. Um, you could even think about this like if you don't do sprints but you have like a release cycle. Maybe you release software for people to download or something like every two weeks or once a month you have a big delivery. You could think about it in a similar way. But um the idea is that like it's pretty common when you're more junior or new to a team that like you kind of you know you're looking at the commitments or what's being discussed and you're like okay like I I think this will be okay. I don't really know and then you kind of start things off but like you maybe didn't really understand what the ask was or you're hitting some blockers. Um all these things like you can't predict what's going to happen, right? You can guess at some things, but you can't predict everything and uh and and know exactly what's going to happen. But you got to do your best, right? So the issue ends up being that if you're doing this every time and every time you're like, "Oh man, like there's everything's always a surprise or every sprint or every release, whatever you're doing, feels like there's even more stuff and you're constantly having this build up." Like this is a common thing that happens to people and especially because in software engineering one of the things that we think about is like we're a team. We want to be efficient. We want to make sure that you know if we especially if you're doing story points and stuff. I'm not a story point person, but it's like we did we did 80 story story points last sprint like we should be able to try and push for 85 story points this sprint or 90. Like it's always like can we do more? Can we be more efficient? And like it start like it can become pretty unsustainable. Um and this becomes even worse when you have uh you know people that are in working in engineering positions and not working well with the project or product managers, not working with the scrum master. Like if this is a very disjoint group, then you really get this bad situation where someone's like, "You got to get all this stuff done." And the engineering team's like, "Oh my goodness, we can't." In fact, at FPS says, it's also not just packing more into the sprint, but also packing more developer responsibilities on the devs. Yeah, that's a great point. I'm the more senior person on my team and having to do uh my actual story work along with refining new epics for sprints coming up, dealing with production issues, helping with less experienced folks. Yep. Being pushed uh to plan innovation things, code reviews starts to be too much. Yep. I'm not sure the scrum masters and leadership realize the amount of responsibilities they push on us. Yeah, this is a great point, right? This is um and I don't even think I talk about this in the article, but this this idea that when we're looking at sprint commitments, and this is something that I I urge people to do on their teams to find something that works, but a lot of the times we're looking at like, well, what are the the work items or the stories or the bugs, right? Like these go onto a board or or whatever system you're using. And it's like you you're visualizing or you're building this list of like here is what we're going to commit to. But a lot of the time that's stuff that's like tangible in the code. It's a bug fix. It's a feature. But as infected FPS is saying, there's a lot of stuff that like can build up over time and it gets to be weird to try and account for. So for example, if you have people that are really, you know, embedded in the tools and stuff for tracking and it say it's everyone, you know, everyone hates Jira. I actually love Jira, but um I think people hate Jira because we end up like anchoring all of these process processes to Jira. So imagine if it was like well we use Jira for tracking everything. So if you're telling me there's these other things that aren't actually, you know, bugs and features um you have to go I'm just reading through like you need to dedicate time towards um you know planning or doing code reviews. Like well go make a ticket for it. Go add a ticket to Jira for your code reviews. And you'd be like, are you kidding me? Like everything I do has to now be like granularly documented in Jira. People would lose their minds. But then what happens is like, well, if it's not in Jira, how do we account our time for it? And this is like it's a problem when people are so anchored to the tools and processes that it's like like why do why do you have to do that? like you can look at things and say like especially if you're using like story points or other things like yourap your team's capacity or an individual's capacity if they're taking on more things you need to account somehow that they're going to be doing that so you don't necessarily have to like add in stories or add in you know work items and stuff in in Jira or Azure DevOps you don't have to do that um I would say if you find it helpful to track and it's not extra work then like sure like you can use it for tracking But as soon as it's like, you know, every single thing you're doing, like put it into Jira. I think that's chaos and I think that's the reason why people hate Jira. Um, I actually think that it's I haven't used it in like over five years, but I used it all the time before Microsoft and I really enjoyed using the software, but tried not to make everything in Jira um for processes, but then random just make comments. On the other hand, could it be that management is probably prepping you for a manager role? My god, I hope not. It's a lot of fun. Do it. Um, yeah, it's uh, but I think it's a it's an unfortunate reality and what I urge people to do in situations like this is to raise awareness to the other things. We'll kind of get through that as we're as we're talking through this, right? So, um, the next sort of section of my article is about healthy conflict. And I I really believe in this like a lot because I've seen it work incredibly well and I like I look forward to this. And if I don't have that in a team, it feels kind of weird to me. So, um, when I talk about healthy conflict, I actually think that you should have healthy conflict in teams, like that means, you know, with your peers and stuff. I think people don't like words that seem strong like conflict. I'm not saying like you have to fist fight people like, you know, go arm wrestle them or like yell at them and stuff. I'm not saying that. I'm saying healthy conflict. And that means that if you disagree on things like you should be able to talk about it like conflict is not like a a bad word healthy disagreement healthy difference of opinions so that you can have discussions about things. Again when the word conflict I'm using here is not to say that like so I'm I see Devon in the chat right if Devon and I had a different opinion about something I wouldn't be like okay well Nick said healthy conflict. Hm. Like, okay, like I better go try and prove to Devon that I am better or right in this situation. Not what I mean. I mean, if Devon doesn't agree with me and I don't agree with Devon, that we should be able to talk about our our opinions, talk through them, listen to the other person, and probably when you do this kind of thing, you realize that like you have two different views and the, you know, the happy spot is somewhere maybe not exactly in the middle, but somewhere between the two. And if you're not able to have healthy conflict, then you end up getting more friction. You don't build as much trust with people. It's I just find that it's not effective overall. You end up getting some sides that steamroll. So healthy conflict in this case in the concept of like sprints and stuff. Yeah, there's get the get the gloves. Um, I mean healthy conflict between people that are organizing the priorities for product like these are the things we want to ship to customers that with engineers and I have that dichotomy. It could look different but I have it that way because that's the way that I've worked and I've seen that work really well work really well when there is healthy conflict. Now if let's remove the healthy conflict. If you have these two groups, engineers and product, I have seen where there is not healthy conflict and you have the engineers totally overruling the product people. And what happens? Well, in stereotypic fashion, you have engineers that love adding code and refactoring code and doing things where they're not actually adding value to customers. Yes, I am generalizing but yes, I have absolutely lived through observing this not directly with my team but I have observed this. So that's a thing that to to watch out for and I'm not saying it's going to happen every time. I'm just saying that is a consideration and you can flip the entire thing around because now if you're like okay well the the product people or whoever is you know trying to or I product owners product managers whoever whoever is kind of controlling what's going into the sprint commitments or the release or what have you if they're not listening to the engineers what they will do in typical stereotypical product fashion is well we got to ship more things we need to deliver more value to the customers. So, here's here's more stuff. You guys got to get it done. And then the engineers, kind of like the whole topic of this discussion and what was done in the the code commute video and the the newsletter is like you have people that get into this situation where they're like, I don't know what to do. People just keep stacking up more and more stuff. I think it is critical, personally, I think it's critical to have healthy conflict between these two groups. I love when product comes and says, "Hey, like we have all of these priorities and like we really got to get them done." Because I love being able to go back to the engineers and say, "Well, like we we know that's not possible. We know that's a lot, but like we have to go back to them with a good story about what we can do, right? And then we can challenge ourselves because instead of just saying like, "No way, man. Product. Screw you guys. We're not doing that. like we got better stuff to do. Like no, like what what can we do? And like what's what do we think is comfortable or like what's blocking us from doing that work? And you start to tease apart all of these things. And you might find that it's like, well, we can't do that work because if they want us to go touch that part of the code, we've known for like a year now that part of the code is absolutely gnarly. Like we have to go refactor that. There aren't even tests on it. Like if we go touching that right now, we're totally screwed. Okay. Interesting. So you're saying if product really wants that to get done, that's actually going to be really risky to start shipping code in that area. Okay. So could we go back to product and tell them that? And then product might go maybe this could pan out a couple ways. They might go actually you know what like that's like if it's going to be that risky, we don't want it. Or they might say that's the most important thing on this entire road map and we can't risk that. And you know what? So like if we have to cut this other thing out because you guys have to do some tech debt for it, get that done and get it done right away because that's the most critical part. We'll follow up and make sure we can deliver that feature on top. I'm not saying it's always going to work out that way, but my point is that you get input from both sides and you have this like healthy sort of debate or conflict or you can start surfacing concerns. But it does require that both sides are open to the other perspective. If you don't have that, it gets crappy. It means communicating, right? It's if you watch or read any content I put out like 99% of it is like aside from level set expectations which is about communication. It's all about communication. It just is. I feel like almost every single problem we have in software engineering is probably the result of communication at some point. Devon says healthy conflict can be can really be just multi-threaded rubber ducking. Everybody gets to validate their ideas and the end result is better. Absolutely. Right? So making sure that there's awareness um you you get the perspective of other people that might have been a blind spot to you. Right? I have I can tell you in at Microsoft over the past five years um at least my la my current manager and my manager before and I can say this totally you know totally with confidence and not like it's a bad thing but in a sit at least one situation with both of them I've had them say hey like can we get you know this is a priority can we go get someone to work on this and in in my mind I'm like you know I'm like oh man we got so much going on we got so much going on I don't have anyone they can focus and or like focus on the things we currently have and then it's like I get pinged by them and they're like hey like this is pretty urgent we have someone look at this and the first thing that happens in my head is like oh man like I know that the team is already stretched and then I kind of do the the exercise I walk through and I'm like okay is someone finishing up soon or what what are the other priorities and then I get to this point where I'm like look if that is truly the next biggest priority if it truly is I said, "Here are some of your options that we can do." And sometimes that looks like either waiting to do it or it could mean like I can pull someone off of this thing. You know, they're kind of getting to the next milestone. I can pull them off, but it means that you don't get that thing, right? That's going to be delayed. And I can and then I can go pick another person and say, "Oh, we could pause this other project. Maybe maybe it just started and like, you know, was a priority, but it's just started. if we were to move someone from that it's not really a big waste because they just started but I have this conversation and this is still within engineering right just my like my manager it's only engineering side and then what happens and like I said in uh with both my current manager and my previous one scenarios where they were like oh like thanks for explaining that I didn't realize like so and so was working on this we had this other thing going on and they're like you know But that's okay. That's it. Right? I know that what they just talked to me about is the next priority. I understand that. But at least we've now kind of gone through our capacity for humans and said like, "Here's what can happen." But it required a conversation. And there's absolutely been times in my career where a similar conversation like that goes the other way where they're like, "Oh yeah, you know what? Like that other thing, pause it or can it switch someone off, whatever. this thing right now is on fire. We need someone to start looking at it. Cool. But like we had to have a conversation about it. So I think healthy conflict is good. Um but that means that you have to be willing to have conversations, right? So, for people that are watching this right now or listening or watching the recording, like I'm not trying to minimize or trivialize the amount of effort that has to go into that. So, if you're listening to what I'm saying and you're like, "Yeah, right, man." Like, there's no way we could have that conversation. Okay, that's the thing that needs work then. That's the area to go spend time on, invest in because if you cannot have like healthy conflict and good conversations around this stuff, it's not getting better. I shouldn't I shouldn't say it's never going to get better because I don't know, maybe. But I I wouldn't bet money on it. Not until it falls apart and then someone tries to put it back together. So I think that I would suggest that you find ways to to get that team culture around like having healthy conflict. That means speaking up. That means being will if you guys are speaking up that means being willing to listen to the other side. one of the um I think it was maybe like a year ago now I did um sort of like the inverse take on this where asking engineers to go build stuff and they report back like well it's that's going to take like six months it's just not it's just not feasible and it's like hold on hold on if we talk about the constraints we have if I say it's not there isn't a sixmon month window. The window is one month. One month. What can we build in one month? Let's change the constraints. It's not open-ended. We need some type of solution in one month. What does that look like? And if oh, I'm I'm busy. Got these other things. No, we're if we have to stop what we're doing to work on this thing and we have one month to do it. What does that look like? What can we do? And I think that it's incredibly important to challenge with these constraints, not to put like, you know, get people to commit to something that's impossible, but to challenge how we think through things. I I can't remember. I have a quote that I say and it's something along the like I should be better at this if I've said it more than once, but like uh constraints breed creativity. And I think that that is very applicable in engineering. So all of this to say that the healthy conflict thing can work multiple ways but it does require that people can communicate be open honest and transparent with each other. Okay. If you are in the position where you are feeling like your sprint commitments every single time you're like I am scared for my life or for my career that this is going to be yet another sprint or release and I'm not going to make it and I don't want to tell people because I'm whatever and I don't know like this could be for any reason and it's not for me to say that you're not allowed to feel this way. What you feel is what you feel. So if you're I'm I'm afraid. If you're feeling afraid or you're feeling embarrassed or whatever the emotion is, you are allowed to feel anything you want. And I am not here to tell you otherwise. What I will tell you is that if you are finding that you're off track, if you avoid communicating that because you are afraid or because you are embarrassed or whatever other feeling you're having, I would wager that it is significantly worse for many reasons to wait until it's due to then say I didn't do it or I was blocked or I didn't understand or I didn't even start. If your if your fear was like to be embarrassed because you were like, "Oh, I didn't know what to do." Or like you're going through this. You're like, "I don't know what to do. It's supposed to be obvious to me. People are thinking it should be obvious. You know, I'm a I'm a mid-level engineer now and like I shouldn't have to ask about this and everyone else on the team seems to get it. Like if I were to ask, people are going to think I'm stupid. like, you know, whatever is going through your head. I'm not saying you're not allowed to feel that way, but if you end up waiting to the end of the sprint before you say something about it, right? So, you get to the sprint delivery and you're going through the board with the team and they're like, "Okay, okay, infected FPS, tell us about how your delivery went." and you're like, "Well, every every standup for the past two weeks I've been saying that I'm working on this, but uh I actually didn't start because I didn't understand." Like that is a significantly worse spot to be in. Like I said, for a handful of reasons. One is if you're worried that it was embarrassing to ask for help, it probably is going to feel a little bit more embarrassing to say that you've been avoiding it or not talking about it for two weeks. Like that probably feels worse. Um it you start to lose tr or people start to lose trust in you within the team because they're like, "Oh man, like what the heck? Like why didn't this person ask for help? Like they they they told us they were making progress, right? or or they if you were avoiding people, they're like, "Well, how are we supposed to know if they need help because they don't ask for help, right?" Devin says, "The higher level you are, the more important it is to raise flags even sooner." Yeah, don't get me wrong. I know that there are team cultures that do not like or they feel like they they don't support this. I understand, right? I understand that if you're looking around the team and everyone else like no one is supporting this or the last time someone spoke up they got chewed out on the team like that's not a good thing like the team culture needs to support that I need to drink something much better. Um but it needs to be something that happens in the team. So, if you wait until the end to let people know that you were blocked or you needed help or anything else, not only does it probably feel worse, not only are team members probably like, "Well, what the heck, dude? Like, we could have helped you dude or do that or whatever, we could have helped you." Or like, "Well, what's going to happen now? We can't ship because this critical thing." or now like you know someone more senior on the team is like oh do I have to pick up Billy's work again like what the heck man there like all of these things and then ultimately what you are committing to as a team you're missing it that's almost that's almost not as bad I feel like in sprints a lot of the time we're committing to things and most of the time it's a bit of a stretch it should be like it should feel achievable but it should feel like a little bit of a stretch because if it feels the opposite where you're like we got tons of time to do all this like pe then what happens is people will look at the amount of time they have and they will fill that time by doing the work. It actually does not work so well to like to underfill a sprint. I think that it works quite well to make it feel like very realistic but a little bit of a challenge. And that way if something slips or whatever because inevitably there will be things like this, it's understood, right? But at least the team can work hard towards the goal and it can feel motivating when it's a little bit of a stretch, not when it feels like, oh my god, there's no way we could ever do this. But you need to be able to communicate early and often. Um, I will not walk through specific examples of this just because I don't think that's fair. Um, but I will say that I have absolutely worked with individuals that reported up to me where we get a certain, you know, amount of time in and I kind of start to realize like this person is not on track, but they had opportunities like in standup meetings and sync meetings to be able to to raise awareness and they they kind of avoid it or they they talk around it in some capacity. And then this repeat behavior of like, oh, I like, you know, I couldn't get to it or I didn't understand or something else or uh no, no one was checking out my poll requests or whatever it happens to be, right? The first couple of times through this, I'm like I I always want to be able to trust in people, give them the benefit of the doubt, but if I start to notice it's a pattern, it's like, look, I need to coach you on how to stand up and, you know, raise awareness to these types of things. The team wants to help you. We're a team. It's not, it should not be a group of individual developers or it's every person for themselves. It's a team. Um, I actually like things like like the conceptually like canban where you can enforce a work in progress limit. What can be nice about this if you've never done this before is that the different stage or different phases of work on your camb board, you can have what's called a whip limit, a work in progress limit. And if you do some interesting things like limit the number of things that can be in progress in a certain phase, it kind of forces the team to move work along without like without it piling up. So for example, I'm just going to make this up. Imagine that on your team, no one likes doing code reviews, but like they got to get done. So like what happens is like the sprint starts and then like everyone starts coding and then you know they get a a code review up and then they're like cool that's up now I'm just going to code the next thing and then everyone on the team does this and you're I don't know week and a half into the sprint and then it's like okay well like I'm kind of done all my work but like maybe I could pick up another thing from the backlog and bring that into the sprint and it's like well did did the code get reviewed and it's like, well, no, but like no one reviewed my stuff either, so like I'm just going to pull in some more work. Maybe a bad example, but like if you limit and you have to look at the different phases and stuff on your canban board because people organize these differently, but like you could limit the number of like features and bugs that you're actually coding and you could limit that to be less than the number of people that are developers. And that will mean that people have to focus on different things as part of the team. And you have to play around with it. I don't think it's like a perfect recipe, but I've seen that work successfully. I like the idea behind it. Um because if you've worked on teams and you've seen this happen before where stuff piles up and it's like you got most things that are like 95% done but not actually landed. You don't have anything landed. No value has actually been shipped to the customer. And I think that when you uh it doesn't have to be Canban, but using something like that, I think is a really interesting way to help help ensure that you get some value shipped. So anyway, all of this was around the idea of just being able to communicate early and often. Um I was saying a little bit earlier that you may be in a team where this isn't common. this isn't the um you know the team culture doesn't really support this kind of stuff yet and that's unfortunate and you know some people might say well you know I'm just a junior developer like I just got to you know no one else that's more senior than me is doing it so like I just got to kind of play by their rules kind of thing but like I I don't know I don't think that that's necessarily it's not what I would recommend personally Um, every situation will be different, but if you believe in the things I'm saying around being able to speak up, making sure that you're having these healthy conflicts scenarios, you know, the product owner is like, "We got to do more." And you're like, "Look, like I I think that we're at capacity. If we compare this to last sprint, this is even more." And we didn't even finish last sprint. like being able to speak up about these things and saying like can we look at the priorities and see like can we talk through what our highest priorities are and that way if we don't get these things done we understand which things are spilling over and we can agree that that's likely to happen. I don't know what all these conversations will look like, but my point is that if you're not having others speak up and you happen to be junior, that doesn't need to mean that you need to be mute and you can't speak up. I would recommend that you do find some courage to do it. Um, I think at the end of the day, like if no one else is doing it and like this keeps happening with sprint commitments, it's just not going to get better on its own. It's kind of what I said earlier, right? Like if you and if you're in a position, this is my personal take on this. If you're in a position where you're like, I feel like every sprint I'm going to lose my job because I'm not getting stuff done. Speaking up about it, like the the ultimate worst case scenario, and hopefully this would never happen to anyone. You speak up about it because it makes sense and then your manager, whoever's like, "No, screw you. You're fired." Like I mean, okay, you were probably like, it probably wasn't going to work anyway because the sprints are always being overloaded. I think it would be quite ridiculous for someone to get fired over some something like that, but can't say it's impossible. I just don't think that that's the logical conclusion of that conversation. So, I think that it would be worth having the conversation to raise awareness. And generally I I think that when people start doing this and they speak up about these types of things, you have more people that will talk about it. And maybe that means that you don't have the other engineers backing you right in the beginning, but you might start a conversation, some dialogue with the product owner and maybe the first time through maybe there is no change and you try it again, right? People don't get their commitments the next time. Sprint's being planned. Hey, this is the, you know, third sprint in a row now. I think we should talk about this. You know, we raised concerns last time that we were going to have to pay down some tech debt, but we didn't get to do that. And we got to here's some data that shows, right? The the mo most recent bugs for the stuff we shipped. Most of them are here, right? Like start having these conversations. Even if you're junior, I think it's worth um kind of leading the charge on it. Um, I unfortunately have had to say this a few times in like code commute videos, but I'm personally someone like I, how do I usually frame this? Like I never want to be working at a place where I feel like I can't be part of positive change, if that makes sense. So, for example, if I'm like I'm at Microsoft right now, the if I'm on a team, the team I'm on right now, if I felt like there was something on the team that was bothering me and I realized, yes, I'm an engineering manager, but this still applies, you know, for me even going up to my manager and stuff and and my skip. If there was something on the team that I was passionate about where I'm like, I'm looking around and seeing it and I'm like, I don't think that this is effective. I think we could do this better or this is something that I would just like to see being done differently. I think a good litmus test for me is if I don't feel like it's worth me even trying to speak up about it and I'm passionate about it, it's probably not a good spot for me. And I mean that's just genuinely how I feel about it. So, if I'm, you know, wanting to propose change or drive change and I'm like, I'm I can't get support on this and it feels like it's going to be too much energy for me to go invest into something, then it just might not be a good fit anymore, right? But that's my litmus test. And I genuinely always want to find myself in a spot where I'm like, "No, I want to go put energy into making a case for this. I want to go raise awareness about this thing. I want to have these difficult conversations. I want to do that." As soon as that spark kind of dies because like I'm not getting support or it feels like, you know, the culture of the organization or the team depending on the scale you're talking about. If that culture is not there to support it, then I'm like, okay, well, I can keep putting energy into it and if the culture around that's not going to change even after I have been trying to invest time and effort, like it's probably time to leave. And that's something that I I wanted to share as part of this conversation because I will always encourage people like I think you should try to stand up, try to drive the positive change to create the work environment that you want to work in, right? raise awareness to things, have these hard conversations. And if you are doing all of these things and it's constant resistance or you know you're not getting any support no matter what you do at some point, it's probably an indicator like maybe it's time to go, right? Like and I I realize that it's not like as trivial as saying, "Well, perfect. I'm just going to, you know, walk over to my next job." Like I get that. But it might be time for you to say, "Cool, like this maybe isn't the place for me. I should start looking." And then you invest your time and energy into that versus trying to drive all of this change at the place that you're at because you have been doing that and it hasn't been working. So I think that you like not that you have to do it this way, but if you're like, "Okay, I want to, you know, talking through this, I see these patterns. I want to dry drive. I want to try driving positive change. Like maybe set some constraints for yourself. If you're like, you know, if you're reflecting on this, you're like, I've been trying for the past three years to to change this place. It's like maybe that was too long, man. But like maybe if it's you know a few months of actively trying to drive positive change by getting involved in conversations around this like hey like these sprint commitments are getting crazy or hey we're not getting time to focus on tech debt or hey you know whatever it happens to be we keep changing priorities every sprint like so much we should come up with something as infected FPS was saying hey like we have all these other things that aren't being tracked in the sprint we need better visibility into our commitment ments sorry into things that aren't our sprint commitments because those are taking up our capacity as well. If you're trying to have these conversations and drive change and there is no support, I would highly consider time boxing that to something that you feel like after that it's not worth your your time. And it is, you know, it's a hard thing to consider, but I think that it's necessary. But overall, I think that you know, my advice in this person's case was like, and I just kind of said it all, but you know, really the team has to be willing to speak up about this kind of stuff to be able to say like these, you know, if these sprint commitments are getting crazy and we're not meeting them ever or or whatever these challenges are, team needs to speak up. And if the team isn't doing it, you can be that person. Doesn't matter if you're a junior, doesn't matter what your title is. If it's not happening and that's the change you want to see, I would start raising awareness to it. And after a certain period of time, if that's not, you know, not you're not getting support for it and things aren't changing, may not be the right spot. So that is surviving the sprint or or moving on. Um, with that said, so thank you first of all and I think we have something to check out. Maybe two things depending on uh when you join the stream. So for folks that join the stream not right at the beginning we were talking to GitHub Spark and we actually kicked off two things for GitHub Spark for us to build. The first one is in from infected FPS and this is a recipe gant chart with start timer and alerts. Are we ready to see if GitHub Spark built it? I don't know. I had some pretty crazy success on the weekend. I'm not going to lie. But I don't know. Are you ready to try it out? Okay. Infected FPS. This one is for you. Ready? Did it not do it because I was in a different Oh, one sec. That would be the most disappointing if it just paused the entire thing. I noticed this happened over the weekend, too. It's like no connection. I don't know why. It should be done though. Might have to refresh it or something, but come on. It doesn't know that we're live streaming, so it's trying to embarrass me. Or maybe it does know. Hey, Andreas. Come on. What do you want to change? I want the thing. Did it just not do it? You guys see this tool tip? Preview mode, code mode. Why not both? Excellent. Um, okay. Well, that's super disappointing. Can I Like I said, I notice on the weekend something like this happened. Oops. I'm yelling at it now. Let's uh Why am I typing things? Where is my application? I don't understand. Did it just not? Yeah, you better look at my project structure. I worked hard on that. Schroinger say hi. Yeah, that's right. Rebuild it. Go ahead. Okay, while we're waiting for this, see, I don't even want to tab away because I'm nervous. Oh, maybe it's cuz I was building two at the same time. I didn't think about that. Following grandma's secret algorithm. These are pretty funny. See, I wonder if I go to the other one. It's also kind of in this weird state, right? This is so disappointing. This was supposed to be the climax of the live stream. You're embarrassing me in front of my friends GitHub. Oh. Oh. What do you mean now? Let me generate the complete. Come on. You were supposed to have already done this. Oh. Oh, it worked kind ofish. We don't know. It did something. Are you guys ready? What are we picking? What's your experience with programming in general? Are we're comfortable? We're comfortable. Have you worked with C# ornet basics basic syntax? Seen a little bit. For loop, if statement, which are you most interested in learning? Um, web development, web APIs, we don't care about performance or security. No. Um, entity framework. No. Let's do this. I want to I want to build some web apps. And I want some C# fundamentals complete. What? What? Where is this stuff? Did it just make it up? It's locked. What? Why is it locked? Unlock it. We've made great progress. Okay. Where does this go? Yeah, you guys got to send in your $10 a month so we can unlock this. Starting with you, Infected FPS. I'll split it with you, though. But you have to pay, too. So, if you send in your $10, I'll give you a 50/50 split. How's that? Um, okay. So, interesting. It did it did a bunch of stuff, but like this this seems like typical AI like kind of stuff. Maybe it actually tells us like in some of the documentation, but just to give you an example, I one of the things I was trying to build was just to see if I could do a landing page that was like my YouTube channels and it would show a carousel of videos like not it's not a groundbreaking application or something, but I was like, "Hey, maybe I could generate this. I can press publish and like cool. There's a random site on the internet that if someone goes to, it's got some of my videos." But it kind of did something like this where it's like it's got the pieces but it's just not done. And like that's maybe totally fine because maybe if you wanted to all like if you're trying to consume this for yourself kind of sucks cuz you're like okay well I have to go do all the work to go find these things. But if you were trying to build this to offer it to people like for example I got a lot of C videos. Maybe I could take something like this and I could go point it at my video library, which is YouTube, and I could do this. And then I could let people build their own roadmap based on my own YouTube videos. Maybe that would be a fun thing for me to go take this and do that with. And maybe I don't have good video coverage on some topics. And that's like, okay, Nick, go make some videos. So, that could be cool. But um I think the problem with me doing that is like there's a lot of structure. There's a lot of structure that I put in here and if I don't have coverage like that then might not work. But overall, aside from not actually working, like in terms of being production ready, it's pretty cool, right? Like, can I search for ASP? Right. View chapters. But yeah, like I can check off the videos, but I can't actually watch them. Anyway, pretty neat. So, I think that was a great suggestion. Um, Bobo, you had a question. Might be a weird question, but I have heard using AI assisted coding agents leads to vulnerabilities. Yes. Yeah, there's a lot of um there's a lot of stories about this stuff online. I guess have you ran into this issue and how would you handle working around possible vulnerabilities? Sure. Um, I think a lot of the time, so you can have vulnerabilities in anything, right? You could be a seasoned software developer and still write code that has vulnerabilities. And it's just that when you're building stuff, usually you're going at a slower pace and it's like you are probably trying to think of all these things along the way and people will still miss them. Um, but when we're vibe coding and it's just like the, you know, finished product is dropped in front of you or you're iterating on it, a lot of the time that's just not something we think of. So, for example, I've seen situations where, this is kind of a weird thing to explain, but we have um like sometimes we'll build services where it is a like backend API service. Okay. So, and you might do this in like a in C sharp and C++, Java, whatever some like you're building some backend like application server and then a lot of the front-end stuff that we build now is like you know it's a react app but it's like it's react and NodeJS but those two things together are like the front end but you have the client side and the server side and I have seen stuff where the client side of the front and application has things like it shouldn't. Um, when I was uh vibe coding this, which will be a segue, um, originally when I because this whole, this is on YouTube, by the way. Like I vibe coded this site and when you go to submit a question, it put the stuff to go email into the client side. And I was like, or no, because then you have to go deploy this and put passwords and stuff into the client. So you could like go into the browser and be like there's Nick's email password like so like you have to know how to go look for this kind of stuff and understand like those types of things. Now if you don't know you could ask AI along the way or at different checkpoints to be like hey let's do a security review let's talk about like how we're authenticating or like whatever. This is why I I strongly feel like this is another good example of like it's not going to replace people anytime soon because we still need to do these types of things along the way and ask the right questions. Um hopefully that helps Bobo. Um this is why we have static code analysis tools and dependency scanning tools. I know there's free options for GitHub actions that can do that and alert to known uh vulnerabilities and such. Yeah, dependabot work. We use sonar and how do you say the second one snake? I've seen it but I've never said it out loud. This is the problem with live streaming because I like read the sentence and I'm like sneak. Okay. Like I see the words. I'm like I've seen that before. Um and then I only said it in my head but it stands for so now you know. Oh cool. Did not know that. Very cool. But yeah, the the GitHub one I think is dependabot. Um, cool. Let's see the recipe one. Okay. Infected FPS. What are we searching for? This is all you. No pressure. No pressure. But it better be the most delicious food you've ever thought of. Some ribs. Okay, let's go. Oh. Oh, man. Find recipes from the meal DB. Should I try another? There's no indicator if it's working or not. I suspect it's not working. Um, just barbecue. Oh, hello. Are you okay with that? Some sloppy some sloppy joe's. We want to try this one. Look at that. Are we going to start cooking? Okay. Why isn't it going? I said start. Oh, is this minutes? Maybe that's hours. No, maybe. Do I have to wait a whole minute here? Why is this bar not moving? I got questions. But it's cool. It's pretty cool that it did something. But so do you think that's supposed to be a running clock though? What? Do you guys see that in the chat from kick? How is that possible? The kick chat just sent a message. I didn't send that. Not maybe it's from the beginning of the chat or something. That's very spooky. Um Oh, it went up. We should Oh, okay. Hold on. So, I'm going to ask to put seconds in the timer. I can't live like this. This is cool. I'm going to publish this one. This one's 20 bucks a month. Infected FPS. We'll split it, too. Wait, sorry. I said we were going to split this first one, but that wasn't your idea. That was I got to scroll up in the chat. That was a random programmer. So, sorry. You You can split the recipe one with me. What else we want to do? We want to do pancakes. I like pancakes. Oh, yeah. Banana pancakes. Let's go. I said let's go. Oh, it went start cooking. What? Oh, it's still it's not it's still going. It's not even done. Come on. As a human, I could have fixed this in two seconds. First second would be Google searching how to format a string properly to get the the seconds. Uh, Bobo, um, you've been in tech for a while. Do you think the industry will ever go back to being more innovation driven? Lately, it feels like everything is heavily profit driven. Um, so what's a good way to answer this? Um, I think it's a perception. I don't think anything has changed at any point, personally. Um, I think that I think it's people's perceptions of companies. This is my personal take on this. Um, businesses are businesses. They exist to generate money and that's it. So, fundamentally, a business will be something. Let me let me before I finish answering this, we're going back to pancakes. I'm going to pick these pancakes and we're going to start cooking. And now we got the second timer. Let's go. Um, okay. And I see I didn't realize this before, but there's this Gant chart like it's grayed out cuz the grays are very Oh, they're behind my head. Sorry, folks. Right. Pretty good. Pretty good. We're going to publish that one. Um, cool. So yeah, my take on the companies being profit driven versus innovation. Um, most companies exist to deliver value to customers in exchange for money and business success is gauged by profitability. There are there aren't I shouldn't say there aren't any I don't have data to back up what I'm saying which is why this is challenging. This is why it's my opinion on this. But people you you would be hardressed to find individuals who are willing to take on the risk of running an entire company to just deliver value to end users and not profit from that because it is they would have to be so passionate about the thing that they don't care if they walk away with money which then becomes a challenge because good luck also finding employees to do that. This is why you probably have a lot of not for-p profofit situations but for businesses business businesses will generate profit. Now to the claim about like it's moved away from innovation driven like when when was it like who was being innovative when was that happening and when was it not for profit because again I don't have proof of this or like stats on it but I don't think that that has changed but I think the perception you you and others may have of certain companies may look that way. So, for example, you may look, I'm just making this up. You may look at Apple and say like, "Apple used to be so innovative, but now it's just profit." And then I would argue like it was always for profit. And were they innovating? Maybe. I don't know. I don't actually think that Apple's that innovative in the first place, but that's my take on it. Um, I don't know. Like, is is Nvidia not innovating? Is is Microsoft not innovating? Microsoft launched like a quantum computer like that's that's pretty innovative. Um so I don't know I think it's a perception thing personally but as soon as you have shareholders for a publicly traded company I it's profit. That's my take on that. So, um I think that there will always be the opportunity for companies to exist that are not looking to hyper optimize for profit and there's companies like this that will stay private, right? I know just to give you an example where I and it's a bad example, but I don't have the experience since they went public. the place I used to work for a very long time, the the founders were saying like, you know, they don't want to take investment because they want to be able to have they want to be able to run their company. They want to keep doing what they're doing. They're delivering value to customers. Company's growing. It's profitable. But like I'm assuming once they went public or I'm assuming because they bought back to private from an investment company. I don't work there anymore. But I'm assuming things changed dramatically. Why? Because once they are public or once they are owned by an investment company, what's the goal? To deliver value to customers? Sure. It's to put dollars in in shareholder pockets ultimately. How do they do that? By delivering value to customers. Um, infected FPS's innovation for innovation sake is always going to be a rare concept. At the end of the day, most folks are innovating to try and chase the bag of money. Yeah. Or, so I agree with that. Or you run into these situations where like the innovation is like you'll see this in Okay. Um, take like there's that F1 movie that's out right now, right? With Brad Pitt. Great movie, by the way. Um, that like they're going to there will be tons of innovation that comes out of like race cars. There's tons of innovation for it. There's tons of innovation that comes out of science. But at the end of the day like there are innovations and people will take these these concepts apply engineering and then people will create businesses out of them. So when we're talking about businesses it's going to be for money. So I don't know. I hope I hope that helps answer. That's my take on it. I realize that might not be what you were hoping for or expected but that's my take at least. Um, and so short answer to the very last part. Has something fundamentally changed? I do not think anything has fundamentally changed. I think that's a perception difference. Okay, I think that's it, folks. So, I got to do the thing I usually do at the end of these. By the way, thanks for the suggestions for these um these Spark apps. It's pretty cool. It's pretty cool. So, this is where my newsletter is. This is the article we were looking at. Uh, I remind folks that no, you do not have to subscribe to an email newsletter. Please don't feel pressured into that. But if you enjoy the live streams and you want to come back and watch next week's live stream, um, weekly.devleer.ca, that's where you can check it out. If you, like I said, don't subscribe if you don't want an email. Just go to the site, you can read it, click, boom, there you go. Um, it's completely free. It is paywalled after like roughly a month worth of issues. And that's there's over there's over a hundred of them now. So there's lots of them. Um I mentioned this at the beginning of this live stream, but my YouTube channel is now split across multiple. If you're watching this on YouTube, it's from here now, which is a new channel I spun off. So this is the Dev Leader podcast channel. This is where I will do podcasts and live streams from. So, um, as I'm saying this to folks, my goal is not to pressure you into subscribing. It's quite the opposite. It's please only subscribe to these if you are interested in them. So, that's the Dev Leader podcast. So, if you enjoy the live streams and you want to watch them on YouTube, I would recommend subscribing. But this channel, what it will contain are these software engineering interviews. Uh, there's 50 of them that I've done so far. So, I'm just re-uploading them. I'm doing roughly two or three a day until I run out and then I got to film more. So that's this channel and then I will do like general software engineering videos as well on here. So stuff that's not just like programming tutorials. Next up is my main channel. This is Dev Leader. This is where I mean most people from YouTube that know me come from here. Um, so all of the resume reviews and stuff like that, everything will be uh delisted from this channel because it will go to the other channels. This channel will be only C and programming tutorials. So when I'm explaining things with AI or putting stuff together for .NET or C, this is where it's going to be. This has been my core audience and I will continue to deliver content here. Um, this one is Dev Leader Path to Tech. I realized there's I'm actually surprised there's a lot more people are gravitating towards this one. Um, and it's surprising because these are the videos that had the fewest views on my main channel. Um, so this is where I'm putting my resume reviews. So, resume reviews and I will do like interview prep and stuff like that on this channel as well. So, I'm behind on the resume reviews right now. I'm so sorry, but there's been there's been a lot of stuff going on and um I will continue to follow up on those. If you want your resume reviewed for free, go to this channel. It explains how to do it. There's just a bit of a backlog and I apologize for that. Next up, Code Commute. I got a bunch of YouTube channels. Um Code Commute is the one where I film from my car. This is a Q&A channel. So, kind of like how we use the live stream here for for live questions. Code commute, if you have a question, send it into me either by writing a comment on code commute or going to the contact page, right? If you go to the contact page, you can submit anonymously. Just check that box. But basically, send in a question. I will keep you anonymous if you send it in this way. And um the more detail you add, the easier it is for me to try and understand. And then I make a vlog entry for you. And then that way everyone can learn um from the scenario that you're going through and I can try my best to help you. Uh people were requesting that um I'll just type it into the chat. People wanted Spotify for code commute. It should be at this URL. Um, if you don't have YouTube Premium and you don't want to keep your phone open while I'm just rambling in my car, Spotify is pretty good for that. So, check that out. Finally, or almost finally, we're almost there, I promise. Courses. Um, these are my dome train courses. Let me send that in the chat. Primarily, I think people know me for my C# courses. So there's getting started and deep dive. These together are 11 and a half hours. There is still a sale 30% off. So go get that. The bundles are already discounted together. So you can get these two already discounted. And then if you're not interested in C courses, I also have partnered up with Ryan Murphy and we have some more like behavioral interview stuff, career growth, that kind of thing. So it's more general for software engineers. So, uh, really really proud about all the courses I am working on. Well, I haven't started the new ones, but working on getting those organized. Cool. And then finally, Brand Ghost is the thing that I build on the side. And I use Brand Ghost for publishing and posting all of my social media content. So, this is something that I am very passionate about because I literally would not survive as a content creator without Brand. So, um, when I started taking content creation more seriously back in 2023 after a decade off from being a content creator or trying to, I said, I need to systemize how I post content because if I don't, I will burn out and I will give up again because I already did it. So, I came up with how the system for how I like to post content and that kind of led to creating brand ghost and um it's totally free to crossost and schedule. Literally, no credit card. You don't got to do it. Just sign up. Sign up. There's no catch. I promise. Um the catch on, okay, here's the catch. The catch is that you try it out and you like using it so much that you want to keep posting more content and you either do that because you have a business or you want to be a content creator and you go, "This works so well. I want to pay for the more advanced features to help me even more." That's the catch. Other than that, there's no catch. I just want to help people be able to create and post content and then get them to that next step where they're like, "Okay, I need more." And if you never reach that, that's totally cool. Keep using it for free. I'm not I don't need to take the money out of your pocket if you're not making money off of posting stuff on social media, especially if it's for your business, right? So, um this is something, like I said, I'm passionate about. I use it for all of my content. So, um one of the nice things about a situation like this is if you're like, "Hey, I'm looking for a tool that can do this." if it's not doing what you want or there's a bug or anything else, literally just message me. We have a Slack support channel, too. But like, you know where to find me. I'm posting content and stuff online all the time. I need Brand Ghost to work because I use it for all of my stuff. Uh unlike there's companies like Buffer or some other companies like Buffer's been around for over a decade. I use them back when I was trying to post content. Like if you read about them online and stuff, people are always complaining. It's like they just got to a point where I feel like they don't actually care and they don't need to care. They're big. I care because we're not big and I use this. So check it out. Um and I just remind people too if you are a, you know, if you got a small business or something like that and you're like, "Oh, marketing like it costs money. I don't have time to post on social media." That's the reason to get this and use it because you can create content and have it sort of recur in terms of posting. So you invest some time to create content and then you don't have to keep investing as much time as you go forward. So if you have questions about that, reach out to me. I'm happy to help because I'm passionate about helping people in that space. With that said, folks, thank you so much for being here. Thanks for understanding the whole YouTube channel situation and um yeah, I look forward to seeing you next week. But you can hang out on code commute until next time. So don't be a stranger and uh we'll chat soon.