Engineering Management Is Being Gatekept?! - Engineering Manager AMA

All right, folks. We're just getting started here. I got to find the chat. This uh reream is having a lot of [Music] problems. Everything is busted for their off. So, and there's these weird UI bugs. I have to like I can't type and to change the the title of anything. I have to like I can't even like use my keyboard to like select text. I have to use the mouse like a select all through the right click menu paste over top. So it's just really silly. Something's definitely busted. It logged me out of everything reream related. Oh well, that's part of streaming stuff. Hey folks on Substack chat should work. Yes, it's seems to be working. So, thanks for letting me know Jonathan. I appreciate it. Um, I think all the platforms are platforming. Sounds good. Cool. Awesome. So, welcome folks. I do these live streams every Monday at 700 p.m. Pacific. Uh, thanks for being here. If you're watching on something that's not YouTube, this is basically streamed on my main YouTube channel, which is Dev Leader. And I take topics from the way that this all works. I take the topics from my code commute vlog channel on YouTube. I pick the topic that had the most views or the most interactions. Then I write a newsletter about it and then that becomes the topic for the live stream. So I try to connect all the dots together. So this was a conversation that I had had on code commute. This stems from a Reddit post that was on experienced devs and the topic is going to be about gatekeeping engineering management as a role which I thought was kind of interesting. Um and I don't know for like be interesting to see from folks in the chat like how many of you are Reddit users? Like are you actively on there? Are you posting stuff? Are you just a lurker? Do you avoid it? Uh, I am the kind of person that generally avoids it like almost at all costs. But, uh, it's kind of tricky because as a content creator, I know there's people that post onto Reddit. There's a lot of people that use their pod groups. They post onto Reddit and then they all boost the posts and then that's how you become a creator. I don't do that. And um, I also have had pretty bad experiences with just like getting banned from subreddits for like helping people. So, I'm like, I'm not I'm not doing this. I can't win. But I do like going on to experienced devs to get topics. And um it's always interesting. I find that on Reddit, well, this is the case for anywhere, but on Reddit, you definitely get people posting topics and like we only ever get one side of the story, which is pretty typical. So, when I talk about this stuff, I try to look at it from different angles if I can and then I talk about it on code commute. So, for folks that are new to the stream, I'm just going to put a link in the chat. Um, for folks on Substack, I'm just putting a link to the newsletter. So, you're on Substack, you know where the newsletter is. That's where it is. Um, but yeah, you don't have to subscribe to the weekly newsletter by all means. If you don't want email and stuff like that, please don't subscribe. It says my chat is not working. Ah, okay. I can see I can see in the video stream my my message. It just removed it from my own window because I saw Devon's message come in after and I can see it all in the stream. So, uh, folks, if the the messages that I send don't work, just let me know, please. But that's the link to the newsletter. If you don't want email in your inbox, don't subscribe. It functions like a blog, though. So, if you're like, "Hey, the live streams are cool. I want to see what the topic is coming up on Monday. Goes out on Saturday mornings. Just go check it out Saturday, Sunday, or Monday, and you can see if it's a topic you're interested in. Um, that's the wrong link. Maybe that was a sign. Was a sign. Don't uh don't send that one. This is the right link. The one that I put in the chat, that's from last week. So, this is one I made the thumbnail. It's me behind a set of bars. Look at that. Right. Beautiful thumbnail. It's great. Okay. It's not that great, but that's not my forte. You know, I like uh I like software. I don't like making thumbnails. So, that's going to be the topic for today. For folks, again, if you're new to the live stream, the chat is there for you to use. So, please do. Um, I would much rather spend time like engaging with stuff in the chat, having conversations back and forth, trying to answer questions. So, if you're like, "Hey, interesting topic. I just want to ask something totally, you know, offthe-wall I want to ask about something else in software engineering or career related stuff, just ask away. Uh, let me finish up whatever thought I'm doing and then I'll go back and read the chat." And, uh, it's, uh, it's pretty cool. There's a lot of people that come over from code commute or they are, you know, watching the streams pretty regularly. They engage in the chat, too. So, uh, you know, if you have opinions on stuff that we're talking about, share them, right? I am only one person with one perspective. I try to share things from different angles, but um, the benefit I feel like on the streams is when people come together and kind of share their different thoughts, too. So, with that said, we'll dive into it. So the um the framing like I said for this post was really around this idea that it seems pretty common that um the role of an engineering manager seems like it's being gatekept from from developers and I'd be curious for folks in the chat if you're comfortable answering this. Have you experienced this kind of thing where like I mean not everyone is interested in being an engineering manager. Totally get it. But if you have been interested or you're like, "I'm curious to know what it would be like to move in that direction." Have you ever had a conversation about this and you'll have a manager say something like, "Oh no, like you know, engineering management sucks. Like you wouldn't even be interested in it. It's totally not for you." Um, or you know, you need to be more senior, like you're still so many years away from that, so don't even think about it. Like it's fine. Just like just focus on what you got going on. Not a big deal. like you know maybe in 5 10 years like you can consider that kind of thing. Um and then or even like challenging you like why would you even want to do that? Like you know even if it's an interest of yours they're kind of like seemingly not acknowledging that and just skipping right over to like that seems weird like don't waste your time with it. So, I'd be curious if that's been something that you've encountered. Maybe the whole audience, like no one no one has ever brought this up with their manager, but I've I feel like I've heard this kind of thing even from like aside from this Reddit post. I feel like I've seen this kind of thing come up not only with engineering management roles, but um even in that context, I feel like I've had people that I've talked to in my career where they've said like, "Hey, you know, I'm having a chat with you because I'm interested in hearing about this stuff, but I, you know, I've been kind of dismissed when I was trying to bring it up like I don't really know what to do because how do I even get started on this track?" So, be curious to hear from folks if that's been your experience or you're like, "Nick, I don't know what the heck you're talking about." But just uh a reminder, right? So, um this there's my stupid face. On that channel, I don't make any uh thumbnails. So, sorry, Substack folks. You can't see my screen, but um the the video to the code the link Oh my my goodness. The link to the code commute video is uh is here. So, if you want to watch that after, um, you can check that out. But that's the, uh, that's the vlog entry I did for it. So, there you go. Um, so I think the way that I wanted to talk through this is like couple different angles, right? The first thing that I wanted to do is talk about when this kind of stuff happens. I think sometimes we we're assuming uh I don't know like ill intent it's malicious or something else. Malicious is a pretty strong word to use here. But gatekeeping to me is like active someone's actively trying to like stop you from doing something. And I'm not actually sure that most of the time, I don't have stats or anything like that, but I feel like most of the time it's potentially not even that people are gatekeeping this stuff on purpose. I actually feel like there's some other stuff going on behind the scenes, whether it's subconsciously or consciously. And then engineering managers don't really know how to navigate this, which seems kind of weird because I feel like that's part of our role is to be able to navigate this kind of stuff. So, a couple things I wrote down. If you're having this conversation and it feels like a manager uh or your manager is trying to like I don't know persuade you to like not even be interested in it, I think a couple things going on. there might not be any engineering manager roles open or any plans for that kind of thing. So when you start bringing it up, they're going like I don't like what am I going to do with this, right? Like I don't have any roles like that open. So like uh and because they're not familiar with how to navigate something like that or it's uncomfortable, then they're like I'm just going to kind of react in a way that will maybe push this idea away, right? It's not really urgent for me as an engineering manager. I hear it might be an interest for you, but like I don't know, we can kind of just push this off because I don't know really what else to do with it. And I'll talk a little bit more about this from the side effects of investing into it. Um, the next part is like if there's not a clear growth path. So again, you can couple that with not having available roles. But say like I've had people that are junior come to me and they're like, "Hey, like I, you know, they might have been kind of working as a software engineer for like a year or something and they're like, I feel like I have an interest in going down this track where I'd like to be doing more work with like people um and some like I don't know when I have these conversations, it's I mean people are early in career and it's great that they want to explore, but is it more of like is it genuinely that they're interested in working with people. Are they trying to talk to me about that because they're looking like for that seems like a path for promotion even though like they've just started in their career and they want to get into management. So I don't know like if they're that early what is the clear career path that they should be working towards to become a manager right and I would say a lot of the time just to kind of connect some of these pieces I think a lot of the time engineering managers have not necessarily had success with getting people from an individual contributor all the way through to an engineering manager themselves. So, they're like, again, it's not to be malicious. They're just like, I don't know what to do with this. Like, I hear that you're interested, but like, how do I get started with it? Right? So, it's not um I don't know, like purposefully being malicious. I think it's more just like inexperience or they're not sure what to do. So, to kind of summarize those things, some of that is like there are elements that are a little bit outside of the engineering manager's control. And then couple that with inexperience or difficulty navigating it or ambiguity even for the engineering manager, they're just like, I don't know what to do. So, it's almost like, like I said a little bit earlier, maybe it's subconsciously, maybe it's not, but they start to react in a way that's like if we push the conversation off, then we don't really have to talk about it. We can just focus on the other things. So I think mostly that's what people are experiencing when this kind of thing happens. Give me one sec. Just cool. Just checking notifications on LinkedIn. But sometimes like the LinkedIn stuff like I get notifications and then the chat's not showing up. So I just wanted to make sure no one in the LinkedIn chat was waiting. Um okay. So that's that's part of it, right? And I think the other thing is that sometimes we do have gatekeeping going on. And gatekeeping certainly isn't something that I want to have encouraged. I don't think in like any role really. I don't think there's like a need for that. So um when we have people actively gatekeeping, a couple of notes I wrote down for that is that maybe the engineering manager does feel threatened. And I think that this is possible if you have uh someone who's very new to being an engineering manager in a in a small or something like that. You might have someone that's new to it. They're kind of trying to find their footing. Maybe they're finding it challenging. Going from an individual contributor into an EM role is a very weird kind of experience because depending on your job setup, your success is no longer about, you know, your code deliverables, right? It's all about enabling your team to do their best work possible. So all of a sudden like you're a support role whereas you might have been very used to just like coding a lot of things and um and delivering in terms of your individual contributions. So you may have managers that are like they just feel threatened when someone else is interested in this. They're going hey I don't like I don't know I don't see any other engineering manager roles. If this person wants to do it like what if they're better than me? Am I going to lose my job or are they going to, you know, look better than me and then I'll get replaced? So, I think sometimes you can have that kind of dynamic going on. I don't think that that's good. I'm just saying I think that's a possibility that could happen when it comes to gatekeeping. I think something that's probably like in my opinion, again, I don't have stats on this stuff. This is gut feel. I think a lot of engineering managers are very concerned about losing good individual contributors. Which is kind of weird because I would also say that I've I think that over many years we've seen people like engineering managers go I don't know how to like to promote this person to prove that they're doing better. Let's put them into a manager role which is also ass backwards. But I think that a lot of the time when you have this gatekeeping kind of effect going on, it's because engineering managers aren't really sure like am I going to lose this IC that's very good, right? They're good because they do have people skills. They are technical. And what's happening is if you start to give them some more responsibility in terms of the people management whether that's mentoring or doing some other things that you're going oh crap like we don't have an EM role right you depending on your org you might be like so in my case just to give you an example I have in North America I have sort of like a a peer engineering manager I have a couple of peers like in different uh countries but I have peer engineering manager in North America. We both report up to my manager and then a bunch well that's not quite true. Then there's him that reports up to my skip and then there's a couple of other engineering managers that also report up to the skip. So we have a level of indirection between our skip and that's why he's a skip by definition. But the point is that like we don't have other engineering manager roles that are open, right? So, if I had a good IC that was like, "Hey, Nick, I'd like to have a conversation and talk about like, you know, I'm interested in sort of moving into the people track, right? Maybe I have someone who's operating as a team leader, technical lead right now, right? Principal, senior software engineer kind of doing that and they're going, "Hey, it's been really cool to be able to, you know, mentor the more junior people on the team." And I've actually found that by doing that, like I think that I'm starting to enjoy that kind of thing more than just like, you know, focusing on, you know, purely on my own coding. You know, when I'm working on projects together with other team members, like that's a lot more energizing. Helping others is a lot more energizing. And I'm starting to think that like that might be a good direction that I should at least consider. Like what are your thoughts, Nick? Do you think that maybe we could have conversations about what I should be doing in my career to start exploring that? So let's let's go with that example, right? I'm going okay, we don't have engineering manager roles. If I was afraid of losing this individual contributor, you know, I'm this is not what I would do. I'm just saying to go with the um the worrying about losing good IC's kind of train of thought is if there is no manager role, what's going to happen, right? I'm like talking to this person, here's a bunch of stuff you can do to try getting some more experience that lines up with an engineering manager role. And then after some time, they're like, I feel like I'm ready. And I'm going, we don't have roles like that. And they go, I know, but I found another one over here. Oh no, I've just lost my really good IC. Right? So I think that what happens is often engineering managers go, I'm connecting some dots and I don't want to lose this good person. So like, nope, you don't want to be an engineering manager. Oh, it's crappy work. Middle management, no one likes it. You're such a good coder. I think if you focus more on the technical stuff, you'll do so much better that way. right? That would be actively trying to gatekeep the role and then sort of keep that person from potentially exploring that part of their career. And then I think the other thing that's kind of maybe related is I think that potentially some engineering managers may not see the value in growing other people as leaders. Um, I feel like I've been pretty lucky in my career that like my managers do value that, right? They talk about um, you know, whether they're people on my team or across teams that are high performers that it's not just, oh, that person cranks out a bunch of code. It's like that person is very good technically, but they also operate as a leader. Right? They lead by example. They're showing other people how to um how to navigate these things, how to how to ramp them up, how to guide them through problem scenarios. Sorry, I'm just checking my chat. Are you guys being very quiet in the chat today? You guys still here? Devon's still here. Devon's got to be here. Last week, we had the whole I I couldn't even keep up with the chat. I was just like getting nervous. I had to go like watch the video feed to make sure the chat was still working and then I didn't see any other messages coming in. So, I don't know. Maybe you guys are asleep. I know it's Monday. Um, but yeah, I think that if you have engineering managers that Oh, Cinco de Mayo. How could I have I have forgotten? I guess a lot of people are probably out trying to party and stuff because that's what that's what you do for Cinco de Mayo, right? My my wife was talking to me about this. Um, and I I don't know enough about Cinco de Mayo, but apparently it's someone can correct me if I'm wrong on this, but our understanding is basically that like it's not that it's not a um sort of an event in Mexico. It's just that it's like a very um I don't know like Americanized holiday and people just use it as like an excuse to to go drink and party kind of like St. Patrick's Day. I don't know if that's true or not, but I don't know. Thanks for letting me know the chat works. I appreciate it. So, I think that with the last few examples I gave, in my opinion, those are all like not good things that engineering managers should be doing. Okay. So, when I wanted to write about this, I didn't want to say, oh, there it's not gatekeeping. That never happens. I wanted to say like, yeah, this is what gatekeeping would look like. But I also wanted to provide the perspective that I think sometimes people aren't consciously doing this. They're just not actually sure what things look like. They're uncertain. They've never done it before as engineering managers to try and coach people through this. Right? It might be, I don't know, maybe it is surprising, maybe it's not surprising for some people. I've had conversations with people even at Microsoft that have moved into engineering manager roles, okay, and they go from being a very strong individual contributor and they are good like working with people and that kind of stuff. So, I don't feel like they were put into an EM role for the wrong reasons or something like that. But, it's challenging, right? because they're going, "Okay, I've spent however many years of my career as an individual contributor. I know what that looks like. I know how like what success looks like for me. Now things are different." And I've had conversations with them and they're just trying to find their own footing in their new role. Okay. So if if they were like, "Hey, someone on my team is also interested in like the path engineering manager." I could imagine some of those individuals that I've coached through that if they brought that topic up, I could imagine they would be like, I don't know what the heck to do here, right? Like, I just became an engineering manager. How am I supposed to help this other person figure it out? So, I can I can see why people would be kind of confused by it. and their default behavior might just be kind of dismissive or kind of trying to navigate away from it because they're just not sure what to do. Again, I'm not trying to defend that in the sense that like, oh, that's good behavior. I'm just trying to give you some perspective that, you know, it's this is kind of like the adult conversation, right? Like I remember being younger and being like when I grow up I'll be an adult and then when you're an adult you just have things figured out. I'm 36 now. Just turned 36 a couple weeks ago. I think I think I'm an adult at this point based on the fact I got a lot of white in my beard and no hair left. I think I'm an adult. I have no idea what I'm doing. So, I feel like it's like you get into this role, engineering manager, and it's like, hey, like you should know all these things going on. You're in a manager role. No one goes to school, I shouldn't say no one. Um, you don't often go to school for this kind of thing. It's not like, you know, a lot of people that went to college or university for being a software engineer, they'll go for, you know, minimum, it's like a 4-year program if you go to college or university, right? I was, my program was an internship based one. It was 5 years straight with two years of work experience layered in. But that was that was software engineering, right? Young birds are just big kids with bills to pay. Yeah. And anxiety and depression and emotions that we don't understand. And then medical bills start racking up because you got weird problems that you're like, I no one else has this, right? And then you start talking to other people and they're like, "Oh yeah, I got all sorts of weird stuff going on." Being an adult is super weird. And I mean, similarly, being an engineering manager when you're starting out is also super weird because now you start getting brought into conversations where you're like, I I'm supposed to help with this. Like I I was just writing code like and now I need to go sort this out. It's weird, right? But like you have to go learn about it and it takes time and it takes experience. So um again not trying to defend the behavior and say oh don't worry about it it's it's good. I'm saying I just want to give you some perspective that people are trying to figure their stuff out. Okay. So with that said I just wanted to kind of tie up some some ends here. Uh this stream actually might be shorter than I thought. So, I'm hoping there's a lot more conversation going on. I'm looking for those questions rolling in. But I I wanted to talk a little bit about like in terms of, you know, now that you're hearing some of this. I don't know if you've never thought about, you know, should I look into being an engineering manager? Is that in in my career? Like, I don't know, some point. Um, I just wanted to talk about things that I think are important if you want to go down that track. Okay. Um, and let's let's kind of tease things apart. I think that in order to excel at being an engineering manager, it will mean that you have less time coding. In some cases, no time to code. So, this is something that's going to be very different from company to company, team to team, that kind of stuff. the um first eight years that I was an engineering manager, I was writing code with my team all day, every day. Um at some point when I had multiple teams and I was still trying to do the same thing. I'm coding less and less. By the end of that eight-year period, I was basically like I still could code, still did code, but there was so much more time spent doing other activities that would enable teams to do more effective work. So whether that was coaching the individuals, whether that was having conversations with other managers and sort of um across the organization working on things instead of me just putting my hands in the code, things just started to take a different shape. So you have less time coding. I would say that um and I I have a very strong opinion about this engineering managers that have you know more than like five direct reports I don't know what the magic number is somewhere around five if you think that you can code effectively and manage a team of around five or so direct reports effectively my news for you is that you're doing one of those two things inadequately most likely or you are spending more than a normal amount of time working. Yes, there's exceptions. I'm not saying I think if you watch my other material I don't like saying always and never but a strong sort of opinion on this is that you cannot do both of those things simultaneously effectively without putting in more time. So even for my eight years as an engineering manager before Microsoft the reason that I could do I I feel like both roles effectively not in the beginning okay not in the beginning because like I said I'm learning a lot still learning a lot but by the end of it the only reason I was being effective with two teams and coding as much as I still was because I was working all the time. When you have more hours in the day to work, yeah, you can get more done. But if you're trying to work a normal work life balance as an engineering manager, you will not have time to code like you used to. With a smaller team, perhaps with a newer team, perhaps. But if you're trying to scale up as an engineering manager, absolutely not. And in fact, I would say if you find that you need to put your hands in the code, you're probably not solving challenges in a way that an engineering manager should. Devin says, "Sounds like we as an industry need to find ways to get IC's onboarded and productive with less overhead." Yeah, that might reduce the fear of loss. AI. Oh, yeah. AI is the solution to all the things. Um, Roma, I will answer your question. I think that's a good one. Jonathan, let's jump to Jonathan. Thank you very much, Jonathan. Hi, I made a mission statement to guide me for backend in edtech as a teacher. Is this too narrow, too broad? No, I think um if you're if that's an interest of yours, right? If you're like, I want to get into that space, like that's the direction I want to go in. Um I think that that is a good thing to do, right? So, and you're saying mission statement is to provide focus on transition. Absolutely. Right. I think that this is a useful exercise. Um, your question is like too broad or too narrow. Um, let me let me put it this way. If you are focused on this and you find that you're spending a lot of time and it's not progressing, you might say maybe it is too narrow or maybe something else is going on. Right? So, it's not like a a definitive answer. So, you might say it's been too long. I've been trying to do what I need to do. I've been using this mission statement to guide me. Now that I've waited x amount of time and perhaps I'm not seeing the results. Maybe it is too narrow and I'm willing to open it up a little bit more. But I think the exercise is good, right? Because now that you have that, if you were to I'm just making up a random timeline just for the sake of conversation. You have this, you're trying for 3 months again, random timeline. Now you revisit that and you're going, "Okay, I feel like I'm not getting the traction I want to see in whatever way that looks, whether that's um callbacks, whether that's the way that you're progressing in the technology when you're playing around, however you want to define that. Do you then go back to your mission statement and say, "This is what I wanted to focus on for transition based on how much time I spent. Do I want to broaden this or do you keep it as narrow and refine it to point in a slightly different direction? Right? So, I really like the idea. I would say kudos to you for doing something like that and trying to get your thoughts down to guide, but I I personally think that if you're going to have something like that, make sure it's not carved in stone and that you use it to reflect on as well. So, um I don't personally I don't think that's too narrow or too broad. I think that sounds like it's very helpful. So, that would be my sort of perspective on that, Jonathan. Let me know if that answers your question though. Um, if not, you want to tweak maybe part of how you asked that, please let me know and I'll uh try to uh enhance my answer. But, thank you very much. Devin, I just realized that YouTube decided to delay me, so I was commenting on what you said 10 minutes ago. Yeah, sure. Sure. Was it uh just lag or was it like a YouTube like slow feature? I don't have any slow features turned on in the chat, so sorry, but I'm blaming YouTube for that one. Um Roma, okay. How did you ever handle a project that is at risk of being late? Did you add another engineer, push the deadline back? Uh all the above. Um uh late projects are like the most common thing in software engineering because uh estimates are never right. The end. So I think it depends um depends on the constraints. Okay. So generally we have three constraints in software engineering. You're going to have a timeline. You're going to have scope and you're going to have quality. I would argue that and when I talk quality I mean like this it's a little vague, right? So quality in terms of what you're delivering to the customer, but one could argue that's quality of the codebase, like if you're accumulating tech debt. So you can kind of slice and dice this however you want, but generally I would say like those three constraints, quality, time, and scope. Okay. So I would say that most often we are not willing to when I say we I mean as software engineers it's unlikely we're willing to compromise on the quality of the feature that we're delivering right we might take shortcuts in code and we make a conscious decision to acrue tech debt where we're saying the right way we would want to build this is like you know we would go refactor this thing first and then we would go do whatever but we're going to um we're going to take a bit of a hit on that. So then we're going to introduce some tech debt, right? But time, quality, and scope. So if your timeline is fixed, I would say that we have to cut scope. So we're bring we're taking features out or we're scaling them back, right? So it's in my opinion when we're doing projects of any kind, I always like looking at what are like can we structure things in a way that I can start trimming things off and we can still feel like there's success. So that one of the big projects that I just delivered for work that was five months long and without getting into the details of it there were so many work streams going on and the really nice thing is that when we were measuring success of our project um it's not that the other the work that like didn't get done isn't important or won't ever get done but we were able to conclude with data and evidence like we have met the requirements, we've met what we've set out to do. Those other things can fall outside of the timeline. We can rep prioritize them. There might be other stuff that's coming up, but we can literally conclude with data that we have achieved our goal, right? So, we cut the scope out and we kept the timeline. The other thing could happen though, let's take that same project. If we were like, look, we still got all this scope. timeline's creeping up and we're going okay but we haven't actually concluded that we've met what would be the exit criteria for completing the project. At that point we could say look we don't have um the ability to move the time like u whenever we plan to exit the project can we get more help? I don't like being in positions like that, especially at the end of a project, because it's too late. It's too late. You have to ramp people up. It's going to take way more time. So, I hate being in that position. If I'm going to bring in more people, I would love to do it earlier. So on something that's like a four or five month project for example, if we're like two months in, like the halfway point, I would consider maybe bringing in more people to help with peripheral things, not like core deliverables. I would want the people that have been core to the project to continue to focus on that and then going, cool, I need some help with these smaller things that have to get done, but they're distracting me. So I don't need to go ramp up someone with all of the depth and you know all of the knowledge of this project. Carve some pieces out get some people working on that. But generally um if the scope is fixed or we haven't um we haven't met like a condition to exit on the project or call it concluded I would push the timeline if it's allowed. So that's how I would navigate something like that. But every project's going to be different. uh my framing is I go back to those three things, right? And almost always it's just a move on the um the time frame and the amount of scope. I much more prefer to trim scope because I would much rather land something and launch it and go this is still really awesome and we can always iterate. I'm of the mindset of iterating so I'd much rather land something smaller and add more after. So let me know if that helps. Um, Roma. Um, Jonathan, thanks again. Uh, so do you do you think in terms of good versus tolerable versus good tech debt, how do you determine what which bucket you place tech in as a category? Good versus tolerable versus bad tech debt. Oh, typo above. I didn't even see the typo. I believe you though. Oh, bad tech debt. I see. Good versus tolerable versus bad tech debt. I think this is a really interesting question. Um, so there's a lot of definitions and stuff that float around about tech debt. Um, when I talk about tech debt, I think I kind of bucket it into almost like two things. Uh, and arguably a little bit more, but I like thinking about tech debt in terms of like conscious tech debt and unconscious tech debt. Those are my two major buckets. And I would say the most common one is actually unconscious tech debt. And this just happens. And I I think if you have any code base that has grown over time, like I would I'm confident that I would like bet money on this kind of thing. I don't know what the time frame is, but if you have a codebase that's actively being used and built upon for like multiple years, I would guarantee that you have tech debt that's accumulated that wasn't even planned for tech debt. So that's the subconscious tech debt and that's just because a code base is growing and evolving over time. You could have the best intentions. You could say we have these architectural patterns like this is the direction we set off in. We feel like hell yeah this is the right thing to do and you keep building things. Inevitably what's going to happen is that there are things that you did not plan for and you're going no worries the architecture supports this well enough keep going. No worries the architecture supports it well enough. Keep going. But when you do this over time for multiple years, you have enough scenarios where you go, the architecture did support it well enough, but in aggregate, we got some stuff going on now. And now that you see more of those patterns emerge, you go, hm h, now that we know that maybe we should have done this thing a different way, slightly modified or whatever. I would say that is very much uh subconscious tech debt. Um, in terms of your definitions, that would be, um, I would call it arguably good and tolerable tech debt, a mix, right? Um, the reason I say good is because it naturally happened. It allowed your, you know, your application to get to where it is today. Tolerable and that if it's lasted years already, it's been tolerable like almost by definition. But if we switch gears a little bit, that reaches a point of critical mass. Not not all forms of it, but I think things like that can reach a point of critical mass where you're going, we've had this tech debt and it's been tolerable, but now it's getting to the point where it's intolerable. We have enough examples of it where it's slowing us down. Every time we want to go touch something, it's brittle or it's taking us ages to go do it because we designed this thing and now to add one feature, we have to go put it like hooks for it into like 50 different spots in the codebase. That's a nightmare. We always forget one. It's always half broken, whatever. Right? I would say that starts to become intolerable and that would be something that you want to go fix. that could be a very subconscious thing that happened over time. Um, the other sort of flavor of this is like the conscious tech debt and I would say that's where we're looking at something. Let's take that same example that I was just making up where we're like, okay, it's a pain in the butt. We keep breaking stuff and maybe the reality is we're like, we're not even adding any more features like that anymore. Right? The last the last one we did like that that was a total pain in the butt was one year ago. And I admit it is still a pain in the butt if we had to do that. But we're not doing that. We're focused over here now. We're focused over there now. We're not touching that code. And I might say maybe like, you know, we def like consciously defer fixing that tech. Maybe we have to go touch that thing again to go fix a bug. And someone's like, "Okay, Nick, but we said that spot really needs a refactor. It's really gross. We should refactor it or we should rewrite parts of it. Remember how bad it was?" And I might go, I do remember how bad it was, but given how little work that we need to do for this fix and we're not planning to go back there again, like we'll, you know, bad tech debt, we will keep it the way it is. We're not going to address it. There's uh other I don't even know if you'd call this bad tech debt. There's other situations where we might have in an architectural design. We have to architect something that has to go in place for a feature. We might come together as a group and say after going through a design dock, this is the architecture that we'd like to move forward with because it has, you know, out of the pros and cons analysis, it has all the the pros and fewer of the cons and or most of the pros, fewer of the cons. we're going to go ahead with that. But then we're like something comes up and we're like, "Oh man, timeline." Back to Roma's question, right? Timeline. Oh, it's going to take us an extra month than we need. And we just had news like we we really have to get this thing done a month sooner, right? Timeline just got really condensed and we're going, "Oh man." Okay. Well, we had that other architecture that we could do and it is a lot simpler. It's not going to be as extensible future looking, but based on our timelines, like I think that that's our only option to actually get this done because something that people forget seemingly is that in software engineering, we have constraints and it's just reality because you're working for a business. If it's a side project and you can just mess around and build whatever you want, you don't really got as many constraints. But when it's a business, you got more constraints, especially around time. In that situation, you might say, "Let's um you know, I don't know if you call this, I don't know by definition if it's good or bad tech that debt." You make a cons, that's why I call it conscious. Make a conscious decision that we're going to go with that second inline architecture because one of the benefits it had was a shorter time horizon. One of the tradeoffs was that it's not as extensible. And we're kind of biting the bullet on that one for now. and we're gonna have to potentially pay down that debt later. Even better if we can come up with a transition plan between the architectures, that kind of thing. Um, so I don't know if that was a really long-winded way to answer your question, but I I think about them slightly different in terms of um the sort of conscious and subconscious tech. Hopefully that makes sense, though. Yeah, Deon says, "Nougat from orbit. It's the only way to be sure. Every engineer at some point says something like that. Yeah, it's true. It's uh ah that code's really bad. The only way forward is just if we just rewrite all of it. Okay, but remember the legacy code is the code that's paying the bills. Don't forget those are really good questions. Thanks, Jonathan. I hope the answers were uh okay for you though. So, let me know. Um, oh, Devin, I missed your other comment. There's a graph somewhere. One of the Scrum books, I think, that shows that adding engineers only works to a point and then causes the project to implode. Yeah. Um, Andreas, um, yeah, I think I I I forgot to kind of touch on this point specifically that, um, I'm gonna I'm not even going to try. There's a really funny like saying about like, you know, you're trying to there's like a baby making a baby kind of analogy, right? Like you can't just like add more I don't can't remember what it is, but you can't make a baby in like less than nine months by adding more people or whatever. Like that kind of thing. Um, mythical man month. Yeah, that is that the name of the book? Mythical man month. Yeah. [Music] Um, yeah, it's a book. Check it out. Um, should post a an Amazon affiliate link in the chat. Make sense of commission. I don't think I've read it though. Um, I've heard of that book. That's why like I don't read a lot of uh don't read a lot of books. I like uh writing code more than I like reading. But uh that one sounds familiar. Like I think it's been talked about for ages. So, um I think it's highly regarded. I would I would recommend it based on the amount of people that I've heard talking about it. So, yeah. Um I think the last note from the from the article though honestly is like to switch gears back to engineering manager, right? I I think that if you're the kind of person that is interested in working with people, like if you get enjoyment out of enabling other people to be effective and like I don't know, I look at engineering management as like servant leadership is the is the phrase that I've heard used before. It's very much a support role. I think if you're trying to get into engineering management to like have control over things like pro probably not gonna have a lot of fun or um be disappointed or you're going to be a pretty lousy manager to be honest. Um yes you get input on things. Yes, you have you know veto of some things but like it's very much like a support role. So, um, anytime I've seen engineering managers try to take a lot more control over things, I'm like, h, your team doesn't have autonomy and they all don't like you. So, um, it's pretty obvious when it happens. But I think if you, yeah, if you get enjoyment out of mentoring people, helping them grow, um, for those of you that are in your careers, like multiple years in, and you've had the opportunity to mentor more junior people, um, you know, people that are, they could just be new to the team, right? maybe you haven't been doing it that long, but even new team members and not just more junior people. If that's the kind of thing that you really enjoy and uh you're always kind of like I keep looking for opportunities like this because last time I did it, it was a lot of fun and like I got excited about it. Maybe that might be something interesting for you. Um I always like reflecting on on, you know, two of my closest friends that I used to work with. um two two guys that reported to me at different points in time uh before Microsoft and both of them just like outstanding engineers in all aspects um like absolute I don't know absolute monsters of like you know productivity in terms of uh technical abilities the code they delivered the problems they had to solve but also like really really good with working with people and I remember having conversations ations with them in one-on- ones and being like and separately of course, but these two individuals that reported to me around the same time being like, "Have you ever thought about like moving into engineering management? Like, I think that you would do a really good job at this." Because I could see that they actually really enjoyed helping other people and I was like, "Not for me to decide, right? Like, if they like doing it, like I should try to get them those opportunities." And both of them were like, "Nah." Like, I I like the mentoring part. That's great. It's a feel-good kind of thing, but not for me. Like, I just wanna I want to be able to build the software, that's what I enjoy. Okay. Like, you know, just wanted to check in because, you know, from my observations, I just I see I see something, right? Hey, Hammer 88. Good to see you. And so, that's what I you know, okay, you know, let you kind of go your own way. So, one of the other one of the engineers of the two had moved to a different team and um not long after I guess uh he had been like, "Okay, I think it's time." So, he took an engineering manager role since I and so I worked with him very briefly while I was still at the other company as a peer, which is super cool. Super super cool because he was a kick-ass engineering manager. Like, I knew it. I just didn't know if that was going to be something that he enjoyed, but I kind of figured he would. Since then, what's super awesome is both of those individuals now have director roles at the company that I used to work at. So, uh, in theory, they have technically surpassed me in terms of, uh, my career progression, uh, which I think is super cool. Um, I still have not yet been promoted ever in my life, which is very interesting. Maybe someday that'll happen. But yeah, I've been a, you know, engineering manager, not a senior engineering manager for like almost 13 years now. But those two individuals, right, they they definitely had, you know, an ability to work with other people very well. And um I think that without that, if you don't have an interest in doing that, if you're just like purely focused on the technical part, you don't enjoy the people interactions, I think that you'll really find it difficult uh in engineering management. That is not meant to be gatekeeping. that is meant to try and give you some perspective on it. Because if you're like, I want to do engineering management, great. And if you're the kind of person who doesn't like working with people, I'm just trying to let you know that a lot of that role will be spent working with people. So, I would say if you're like, "Oh crap, well, that's not what I was expecting. I thought I could just like tell all the other engineers to do the work items and then butt out." Nope. Um, a lot of your role will be spent, you know, in one time in oneon ones, you know, career conversations, solving interpersonal conflicts, stuff that you don't see in day-to-day stuff because it's happening in conversations with engineering managers. That kind of stuff will come up a lot. You have to be ready to do that. It takes up a lot of time. So, I'm just letting you know because if that is a path you want to go down, I would say start trying to get some exposure to that kind of stuff. understand what that looks like. Um, you might not like it because you haven't had the time doing it. I say the same thing about public speaking, right? I always use this example because I feel like it's very relevant when I talk to people like this. I am very introverted. I've historically had a fear of public speaking. I've historically said I suck at public speaking. And now that I've been doing YouTube videos for like two and a half years now, I don't say that anymore. I'm still introverted. And I know that because from interacting with people, if I have a day of one-on- ones at work, I need to sleep at the end of the day. Close my laptop. I'm going to sleep. I need a nap. I have to. I have absolutely no energy left. But that's okay. I'm not saying that's like a problem or I'm bad or I'm terrible. just nope. I lose energy from it. That's okay. But I used to say I'm bad at public speaking because I was I didn't do it. And why didn't I do it? Well, because I was bad at it. I was afraid to do it. But it was a vicious cycle, right? So, I think that if you're telling yourself, I don't like something. So, I, you know, I don't like the people side of things. I don't like mentoring. It's a waste of time. like is it have you invested time into doing it because you might feel that way because you've you've not actually spent the time doing it. So just some different perspective to share there. Um yeah, Devin says mentoring is fun, but all the squishy people stuff isn't. Yeah, to be honest, like I I know that like I'll be totally transparent, right? I'm I'm talking about this stuff with all of you because my goal is transparency. Like I don't love a lot of the like the stuff that comes up where I'm like, "Oh man, like got to have a got to have a conversation about this, right?" Like that's that doesn't excite me. But at the end of the day, what when I can reflect on the work that's been done like in terms of my workday, even though there's conversations where I'm like, "Oh man, that's going to suck. That's going to be a hard conversation." or I'm like, "How am I going to prepare for that to have a conversation with someone?" After it's all said and done, when I reflect on it, I'm like, like, hell yeah. Like, I got to be part of like helping make something better. And like, yeah, difficult conversation had to happen. It was uncomfortable or whatever the scenario is. Doesn't mean I'm excited to do it, but when I reflect on it, it's a feel-good thing. So that's my my constant reminder that even when you know those not so great conversations have to happen interpersonal conflict whatever else at the end of it it's it's always feel good. Um yeah bird they say the best managers are the people who say they don't want to be a manager. I have two people that would absolutely work with that stat. So Jonathan says I'm also introverted ironically a teacher. Interesting. plus excited to start making first post on LinkedIn transition. Yes. Very nice. Very nice. Yeah. Um I think the [Music] um it's challenging being introverted and having to work around people. Um, you know, as some as someone that is introverted, the uh I think the reality is like I find I need to like I I think my my HR director before Microsoft uh I should refer to her as a mentor because I think that it's unfair. I I've made videos or I'm like, "Oh, I didn't have mentors." I would call her probably probably my my best mentor. just it wasn't like an official thing that I really established, but I I would say that um she helped guide me through a lot of that stuff. And she would say that like I'm ami ambiverted. I don't even know if that's a real thing or not, but she would say like, you know, I would tell her, "Oh, I'm introverted. I'm introverted." And she's like, "I don't think you are." And I'm like, "No, I am. Like, I don't I lose energy from from being around this kind of stuff." But then she would say, "But look how when you're in a room of people talking with them or when you're working with the other engineers," she's like, "You're able to like turn on your extroverted self." And I think it's interesting cuz like maybe I do do that. Maybe I'm doing that right now. Maybe that's what I do when I'm streaming or I'm vlogging or I'm making YouTube videos or when I am public speaking now. Maybe I do turn on an extroverted me. But I do think that that's a bit of a facade and I think that that's something I had to learn to do. So to give you another example, as someone who's very introverted going into a one-on-one conversation, if there's someone else who's very quiet and introverted, my options are to be quiet and introverted with them, and it's probably going to be a little bit uncomfortable because it's going to be two people like you kind of just want to do your own thing, too. Okay. Yeah. Well, good good talk. Right. So, I have to kind of turn on not like an over-the-top extroverted, but at least enough of an extrovert self to kind of get a conversation flowing and make sure that things are are good, right? So, I have to turn it on. I do think it's a facade, though. And I think it actually takes a It's weird. I talk about energy like I don't know. Is it like I'm spending my my mana to cast spells or something? I don't know. But um but I like I generally feel genuinely feel like exhausted from having to do that kind of thing. So uh I could imagine as a teacher it would be very tiring, right? You'd go teach for the day you're around around kids, right? Students and depending on the age group and stuff, the energy levels. Yeah. Just having to be peopleing all day could be a lot. So um kudos to you and for the other introverted people doing people things because it's a lot of work. But folks, I think that's it. I'm going to probably do my little sign off here. Um, I'm going to read Devon's message first, though. Seems like managers should be super open with people about the the difficult stuff. Yeah, more transparency. We're appropriate. You can give IC's enough info to make a decision. We're data driven personalities. Absolutely. Um, I think for this kind of framing, it's a it's a weird balance, right? because I try to be I try to be as transparent as possible in all things I do because I believe exactly what Devin was saying in his comment. I I think that there's there I don't know there there's so much more like inefficiency in like just trying to like I don't know not be transparent like hiding stuff. the I think where I draw my my line of separation is like it's not about um it's not often for me not about hiding things. It's about not oversharing on every detail and that's because if I overshar it on everything that I was kind of getting through um the fire hose then I would be overwhelming other people. So to to rephrase that, I don't try to hide details from people. I try to be transparent, but I won't go tell them all of the things across all of the work streams, across all of the sources of information because that's also part of my job is to like when I say shield people, it's not to to hide the truth from them. It's to shield them from just the amount of noise coming in. That also means if someone's like, "Hey, I heard about this other thing. Like, could you tell me about that?" Then I'm like, "Hell yeah, I'll tell you about that as long as I'm allowed to kind of thing," which is almost everything except like some security stuff. But like the only reason I didn't talk to you about this is because like it wasn't necessarily relevant to what you were doing, but sure, you want to know more? Here we go. Right. So, I try to be as transparent as possible, but I have to be a little bit more selective just so I'm not like blasting people with information where they're like, "What am I going to do with that?" Um, so that's my take on that. So, if there's more questions in the chat or comments, we'll go through them. Uh, otherwise, I'm going to flip back over to my screen sharing. Sorry for folks on Substack. Um, you can't see it. But the first link that we're going to look at is Oh, it's a live stream. How meta is that? It's literally streaming um on Substack. So, this is where the newsletter is if you want to check that out. Like I said earlier in the um in the stream, no, you don't have to subscribe to get emails. By all means, if you're like, "That's dumb. I don't like emails. It's too spammy." Whatever. Don't do it. Totally cool. But if you enjoyed the live stream, uh if you're watching the recording of this and you're like, "Oh man, I want to catch the next one." Um, weekly.devleader.ca will tell you the topic almost always goes out on Saturdays. So, you can go read it at that link I put in the chat. This is weekly.devleer.ca. And then I'm just clicking into the article. This is the one we went through, right? Got the code commute video there. And then this is the article that I wrote. This one was pretty short this week. Um, okay. Next up, courses. I got courses. I got a spoiler alert. Oh, we did this last time. It's still the sale at the 40% off and the timer is always at four hours. U Okay, I paid attention this time. So, I know I think Devon proved that last time we knew this, but this is the first time I've proven it with my own eyes. So, anyway, um 40% off, which is pretty sweet. So if you're interested in courses, I will put the link here and I will share with you a little spoiler alert um because you guys are on the live stream. So the primary ones that I offer, I think people come to my YouTube channel primarily for Courses. So I have the getting started and deep dive courses on domain. They come as a bundle. They are discounted if you get them in the bundle. There's a couple other C courses as well, but I also have like uh general career and software engineering courses with Ryan Murphy on dome train. Ryan Murphy is an engineering manager at Yelp. So, we partnered up on these ones. So, career management, getting promoted, nailing the behavioral interview, and soft skills. So, those are really fun to make. Um, but they're not C specific, so might be interested in them. Um, the spoiler because you're on the live stream is that I'm going to be getting a couple more courses together. Um, one's a big one. I'm not going to share the details of that, but there's a big one coming. We just got to wait for a timeline for it. But the other ones also don't have a timeline. So, I'm pretty bad at this, aren't I? But, um, they are going to be based on building applications. So, the reason I'm sharing that with folks here on the live stream is because this could go any number of directions, right? There's a million things that I could go build in terms of a course, but it's going to be essentially building things from scratch. Okay? So, in terms of gathering requirements, going through how we're going to scope things out, getting some designs together, and then going and building the thing, it's probably going to be um it's not guaranteed, but probably going to be like um ASP.NET Corebased most likely. It's going to be C for sure, but um it's probably not going to be like a mobile application or something like that, but probably you know, something like a web app or web service. So, I'm going to do probably a few of these and I wanted to share it on the stream because if you're interested in having some input, if you're like, "Oh man, it would be so cool if we had a course where we could go build whatever like X, like let me know because I would be interested in getting a list of these things because I can go find some options. I'm totally fine to do that. But if I know that there's something that more people are interested in, um, I can see if I can prioritize that. And if they're not a good fit for the course, there might be good videos on YouTube. So, let me know. You can share in the comments. You can message me on whatever social media platform you want instead if that's more interesting. But if you want to see stuff built end to end, probably over multiple hours of videos, let me know. But that's courses. Then we got the YouTube channel. Let's get that refreshed. Boom. So, I think most I got to check. Not most people. Twitter Twitter definitely has the most viewers by far on the live stream, but um for folks that aren't familiar with the YouTube channel, I'll put that in the chat as well. Um, does the Twitter I don't think my messages go to Twitter. Maybe that's not helping. Anyway, the um the channel you see on the screen is my YouTube channel. This is where I have uh a couple things going on. Most of my videos are C videos. It's how most people come across my stuff. But I have a podcast where I interview software engineers. Uh, so you can hear about their different journeys in terms of how they got to where they are. I'm also doing resumeé reviews on my Dev Leader channel as well. So if you're watching this and you're interested in having your resume reviewed, watch one of the videos in the resume review series, you don't have to watch the whole thing. I tell you how to submit it in the first minute. I would recommend you watch the whole thing because then you can see what's going to happen with the resume review. But this is something I'm offering. It costs you absolutely nothing. It costs me money because I have to go get it edited and it takes me time to do it. So happy to do it. Send it in, but you got to watch one of the videos to see how it's done. There's that. I'm going to switch over to Code Commute. This is my vlog channel. And I didn't post a video today because I'm silly. I I messed up one of my videos and I forgot to turn the audio on and I knew that. So I like caught it and I restarted the recording and then I almost posted because I uploaded it to YouTube. I almost uploaded the video that had no audio. So when I went to go publish it today, I like gave it a listen and I was like, "Oh crap." Like that's the wrong video. So I'm behind. Sorry. I'll get that fixed. But I got more videos to go up this week. But this is code commute. The style of code commute videos are me basically driving to or from work to or from CrossFit. I take software engineering topics either from Reddit or from stuff that people submit. So like people were doing in the chat today. By the way, thank you so much for asking your questions. Thank you so much for your donations, Jonathan. I do really appreciate that. on code commute. You can either post comments on the videos that I'll go answer or you can send them into dev leader on social media, any platform you want. Send me a message and if it's a software engineering topic, I'll try to make a video about it so I can share it with others. So that's code commute. It's a lot of fun for me to make because I just drive and I talk kind of like what these videos are except I'm not driving right now and there's a chat. I don't have a chat in code commute because I'm not actually live streaming. That would be reckless. And finally, my own thing that I'm building on the side is Brand Ghost. So, I'll put a link to that in the chat. Brand Ghost is what I use for posting all of my social media content. This is what I spend all of my time building. So, if you see me very active on social media and you're like, man, how does this guy have any time to go build this now? This thing that I'm building allows me to go post as much as I post. That's the that's the secret. So, uh, I built this so that I could cross-ost to every platform. I could schedule content perpetually to every platform. So, all of my posts are my own posts. It's my own content, but I've created enough content that I could basically stop producing content, walk away, and my entire content would be automated basically forever. And it would take you in some cases over a year to see repeat content. For example, I post a blog every single day. I post a link to a blog. Okay? I have enough blog articles that you will not see them repeat for a year roughly. I think there's 300 blog articles. So, not quite a year, but it's a lot. There's YouTube videos, right? So, I have almost 600 YouTube videos in total. It's going to take you a long time to see a repeat video. That's 600 across two channels though. I think on my main channel it's only 200 and something I think it is over 300 now. Point is there's enough content that it's all loaded up into brand ghost and it will post every day for me. So um if you're interested in either trying to do content creation, you want to do learning in public, it's absolutely free to use for scheduling and crossosting. Okay, the goal and why we have a free tier is that we want to make sure that people are they're getting started in content creation, they can try it out. They can go, "Hell yeah, this is easy to use. Yes, it works." And if you grow as a content creator, then great. We have a paid for option that gives you more tools. Or maybe you have a business. Maybe you're watching this right now because you're interested in software engineering, but you also have a side business or something. And you're like, "Oh man, you know what? Like marketing is such a pain in the butt. I have to go post on social media about the business and whatever." Brand Ghost is a perfect solution for that. Even if you want to start with the free tier, you can schedule all your posts, go across platform because then you don't have to go like copy and paste and re-upload to every platform. It's such a pain in the butt. Then if you're like, okay, this is working, you can use the paid for tier and basically you create the content once and then we will repost it for you on a cadence. So that means if you have um things like that are informational evergreen type of content for your business that you want to advertise, uh you could turn on promotions and have them get recycle. Like there's a lot of different options. The point is that it takes away from you manually having to post and schedule content across platforms. So if that's of interest, do check out Brand Ghost. Um, I I think the cool thing for people that are watching this, if you're like, "How do we know if it's going to work or whatever?" Like, this is literally what I have to rely on to post my content everywhere. If this stopped working, I would have to give up on content creation. That's how important it is for me because I cannot sustain posting to all the platforms that I do. Brand ghost needs to succeed for my content creation to succeed. So, I will keep building Brando. So hopefully that helps. And I think that's probably all I got for today, folks. So thanks so much for being here. Next Monday, 700 p.m. Pacific, same time, same place, unless you want to come over to a different platform. This is streamed on YouTube, Facebook, LinkedIn, Instagram. Instagram's a vertical video. Sorry. It's on Kick, it's on Twitch, it's on Tik Tok, and it's on Twitter and Substack for folks over here. But again, Substack, I'm sorry. Every time this happens, Substack is not like a first class like streaming thing yet. So, if you're watching on Substack and you were like, "It would have been really nice to see the things you were sharing." Come on over to YouTube. It's just dev leader on YouTube. You can check it out. Um, but thanks folks. Cinco de Mayo, Cinco de Mayo stream was good. Yes. Keep forgetting it's Cinco de Mayo. Cool. Thanks for being here. Hopefully.