Senior Engineers Spend Less Time Coding - Principal Engineering Manager AMA

Okay, we're getting the stream going here. I am a minute or two late. My apologies. Usually I got this down, but it was kind of rainy on the drive home from work, so I apologize. I just want to get couple things set up here. Um, if this is your first time here, though, welcome. Uh, these are very much an interactive. What's the goal? They're an interactive live stream. It's an AMA format. So, uh, I have a topic as usual, but I do encourage anyone and everyone if you got questions, just jump in the chat. Happy to try my best to answer. Can't promise that I got good answers for everything. But that's my goal at least. So, one sec. I want to get Instagram going, too. For some reason, it's kind of a pain in the butt, but Substack, like I do these every Monday, and Substack has uh decided they're changing something about their site and it completely breaks live streams. [laughter] So, they're like, "We don't have permission to use your camera." And I'm like, "You don't need my camera because I don't actually stream directly on your site." But I gave it permission and it still doesn't work. So, I can't stream to Substack anymore because they broke the ability to stream to their platform, which is super silly. Um, but anyway, I'm just going to get the last little thing set up here. Got to get Instagram going because last week we were coding and we're not going to code today. Um, by the way, if you have things you want me to code on stream, like, let me know. I'm happy to try. coding live is uh definitely a pain in the butt, but it's uh it's definitely something like I think it's I think it's good. I think people are, but you also get to see like it's not perfect. [laughter] It's definitely not um like a a polished YouTube video kind of thing, right? And I think if people are okay with that, then that's how she goes. I just What? Instagram's not working. Oh, no, it's working. There we go. Finally. Okay, I'm just pulling up my newsletter. By the way, if uh you want to know what the live stream topics are going to be, it's almost always whatever is on my newsletter, which is at weekly.devleer.ca. No, you don't have to subscribe to the newsletter if you don't want an email newsletter. I don't blame you. That's totally cool. But that's usually where the topics are. Topics for the newsletters come from Code Commute, which is one of my YouTube channels where I do Q&A style videos. So people submit questions, try my best to answer them things on software engineering. But today's topic is going to be senior software engineers spend less time coding. And this actually is originally from Reddit. There was a thread on this. Someone wanted some perspective on it. And um when I don't have uh a stack of questions to go through on Code Compute, I go over to experienced devs on subreddit. Wow, [laughter] it's been a long day. Uh I go to the experienced devs subreddit on Reddit. Words are hard. And uh look for topics that I think that I can speak to. Um so yeah, that's my my kind of pattern. So, this one is regarding this person's original post on this and they were saying um in their role it kind of feels like they're they're almost doing no coding and they're at a senior level and I thought that was interesting because I don't know maybe for people that are more senior it's not a surprise like you do other things that aren't just coding right and like that picks up more when you become more senior so especially when you're more junior, you know, you're going to be spending more time like reading stuff, trying to learn, and then coding obviously, and then you keep ramping up the coding because you're getting more productive at it. You're getting more independent at it, right? You're taking things that are um you know, each each time like a little bit more complex, a little bit more ambiguous. You're working through them and you keep doing this and then when you become senior, it's not like that just goes away, right? like you still should be coding a bunch but as Devon says in the chat [laughter] meetings meetings and more meetings yeah it depends where you work right um but there's other types of interactions that you will be doing as a senior software engineer and beyond right um so and terminology and levels and stuff is kind of weird because it's not super consistent before Microsoft I worked at a place at the time we had developer and like senior developer That was it. Like there you you weren't getting to level three because there wasn't a level three. It just we didn't have it. Um I think since then they've done like you know they have like a staff role and perhaps like other things going on but we simply didn't have more levels. So not every place is the same, right? And like at Microsoft now we'll have like we have a principal level engineer. We don't have staff though. at least not I don't know if that's the case for all of Microsoft but certainly in Office 365 we don't have that um whereas like at other big tech companies or other tech companies in general you might have staff you might have staff and principal and like what's what right but the point is that as you're getting more and more senior there are things that are going to be less about code good to see you bra thanks for joining yes it has been a little while it's always great to people coming back. And I know like everyone's got life, right? Like you can't, as much as I want you all to be here every single Monday, 7:00 p.m. Pacific, you got to be in, got to show up, uh, I get it. So, I do appreciate, you know, when people can make the time to come hang out. I think it's super cool. Um, but like I understand people got lives. You can always watch the recording, but it's better when it's live. Uh, yeah. So, I wanted to talk about this because I talked about it on Code Commute. I thought it'd be a good one to go through because I think it's applicable to a lot of people. But like I said, the reason this one was more interesting for me is not um I feel like this usually comes up in the sense where people are like, you know, people that are newer to the industry are like, "Oh, I didn't realize, you know, that happens. I didn't realize there's more things outside of coding. I thought it was maybe more deeper involved problems kind of stuff with code." Uh, and that's like, you know, you can debunk that pretty early, but this was almost the opposite. It was like all that I do is this other stuff. I don't code. And I think that's a little bit misleading. So, um, kind of already I'm just, by the way, if you're again, if you're new to these, I usually kind of scroll through my newsletter, kind of pick up the topics and and and go through. I'm not sharing my screen. Sometimes I'll switch over to it. Um, Brax Saint says, "I'm transitioning into the architect consulting role, but I always thought you needed to go senior first." Depends, right? Um, I think it helps. Um, I think from an architecture perspective, it helps a lot to have more experience. And the reason for that, again, uh, these are like guidelines and suggestions, not rules carved in stone. What is an architect responsible for? right? Like systems thinking, big building blocks. Usually it's about like um it might even be systems coming together. It might be uh a lot more forward-looking. It doesn't mean that you cannot do architecture if you are not senior. Um but it certainly helps to have more and more experience for this kind of stuff. And the reason for that, in my opinion, is that if you haven't lived through some of the the stuff that's a pain in the butt or the things that have worked really well, you have fewer experiences to draw on. And that can make it challenging if someone's like, "Okay, we're looking for input on the direction we should go with this software." Right? You might be able to sit there and go, "Okay, based on your requirements, I think that you will need a SQL database. I don't think you need microservices for this and you know good programming language let's pick one C big surprise right um and so like or you have an existing system and you want to expand it and like you could make suggestions based on the requirements but um I think one of the challenges is that like without some of the lived experiences things might look good on paper and you have blind spots that's all um you know we do you'll go for interviews and places will give you like system design questions that kind of stuff I think has a lot of like architecture involved in it but it's not I think one of the problems is a lot of architecture is not it's not really like that like it's like that would be the the perfect world architecture is someone gives you a set of requirements and they say design this system like draw me the picture for it But what you actually have is like real time constraints. You have real resource constraints. You have existing systems that are already in place. You have um things you have to migrate. You have live systems where there's users and you can't just like turn it off to go build the other thing. Um you know customers are paying money for existing things. So the sets of constraints can become ridiculous. And again on paper you might say well your perfect system is you know it's an object database and uh it is micro service but like do you know that based on you know like how do you transition to that? So it's not that it's impossible but I think it helps a lot to have more experience. Um Bra says okay true. Uh I could definitely see that I'm in my first senior role now but I've been learning a lot through some system design course and I'm able to connect a lot that to my prior experience. Yeah. Um to give you another example like I had an internship like this is I'm not even working full-time professionally. This was my fifth out of like I had six internships. So this is internship [snorts] number five. So, I had worked for I had 16 months of like work experience at this point, but not full-time. And so, uh, you know, month what 17, 18, 19, 20 at this place, uh, I was on an architecture team and that architecture team was actually the role that I had was prototyping. So what was interesting about that was that I got to like the architecture team my my management would tell me like you know we want to experiment with these types of things like we're there's more asks for these types of features like we want to see if we can prototype X. So I would go build it and then it was kind of to prove the viability and then as architects they were able to say cool like we now that we've seen some of these things come together and they were doing their own prototypes as well. They could kind of see like with a quick iteration like what's kind of feasible and can we start pushing things in certain directions. So this you know this can look different at different places but high level that's my that's sort of my rationale for why being more senior helps with architecture roles. Um it's kind of like your responsibilities versus how effectively you might be able to do them. Not impossible though. Okay. Um so kind of started talking about this but when you are gaining experience as a as a software developer right and becoming more senior it's not just code right you will be coding you will keep coming back to this there is code to write but you'll have other sorts of responsibilities I think one big one that comes up a lot is uh mentoring um you know you don't you don't even have to be more senior necessarily to do this you I've seen this some of the, you know, some of the junior engineers that I've worked with have done an outstanding job where they're still junior and there might be someone even more senior than them that's just new to the space and then they they work with them and they kind of do some it's like it's not mentorship in the sense of like guiding people through their career, but it's like helping them on board and navigate things like that. So, I've seen this kind of thing start to to surface with people even like super early in their career. Um, and it only builds from there, right? Like you can you can tell when people really lean into this because they see the value in helping others, but that starts to become more of an expectation of you when you're becoming more senior. So, there's time dedicated to that. Also, I should mention a little bit of a tangent. I'm very good at tangents, but um that can seem or truly become more of a time sync. Not because um it's bad to go mentor and develop other people. Not the case, but it can become more of a time sync because you are trying to help. And if you don't have experience doing it, you can do it in ineffective ways. So, for example, um you're trying to help the more junior person on the team and your idea of helping them is giving them answers, right? Like you're you're helping unblock them, you get time back quicker. It's a win-win, right? But like the reality is that over time, that person becomes a little bit more dependent on you because you're just giving them answers instead of helping them learn. And then over time you get more and more people like this and all of a sudden you're like why am I why does it feel like I'm doing five jobs and it's because you are [laughter] um you know so you end up spending an inordinate an inord what's what's words are so hard today a disproportionate that's a better word a disproportionate amount of time uh mentoring and helping other people just because it's an inefficiency so it's a skill to learn right but it's part of the expectations Um there is you know more aligning on architectural decisions. So a great you know great kind of a re segue back to what Brax was talking about but this this does come up more and more right when you're more junior and you're working on stuff that is less ambiguous less less complicated. um you you probably don't have to focus much on like architectural decisions, right? It's usually because someone's like, "We've we've thought about this or we are thinking about it and like I'll help steer you in the direction." But over time, you have more experience and you're able to kind of see those patterns. You can kind of see the direction of the code. You'll form opinions about that. So with experience, you will be able to to start participating in those decisions more and more. Wow, we already got spammers. I don't even know why I streamed to kick to be honest. Um, it sucks. Bra says, "Yeah, it's always been better to provide some guidance over direct answers. That's what I tend to do in my new role." And that's uh from remembering how it felt just getting answers as a junior. Yeah. Right. It's like it can seem nice in the moment cuz you're like cool like I can keep going but like what really that the feeling that really sucks is when like someone gives you an answer and like you didn't learn but you keep going and then it happens again [laughter] and you're like oh I got to go back to the same person and ask the same thing and it's like feels bad. Um and it feels bad for that person when it keeps happening right because they're like I'm trying to help. why does this person like why aren't they learning because it's just not an effective way for people to learn. But um you'll do more cross team work uh that you know you might even as a junior you might be doing some of that um but the coordination and management of those types of projects that might be more handled by someone who is a little bit more senior. So, as you kind of fill into that role, um you know, you you'll have more of that exposure and um that expectation on you and the the whole list of things I'm talking through here are things that like aren't just code. So, yeah, you might be doing code reviews and discussing code and stuff like that with people on different teams. That's part of it, but you'll also be like in conversations with them because if you know your team or their team, if there's dependencies one way or the other, you'll probably be participating in meetings, all that kind of stuff, getting status updates, understanding where things are at, like this just becomes part of trying to work on more complex projects. You will start to do the things that people were doing more for you. So, what does that mean? uh if we're I mentioned am ambiguity and complexity a couple times already right when you're more junior things will be a little and this I'm speaking in uh the general sense here by the way um I think some folks that watch a lot of code commute they'll know that hopefully that I don't have to say it every time but I feel like I always need a little disclaimer where I'm like by the way I don't like talking with sweeping generalizations but sometimes it just makes a conversation easier so my disclaimer is like I don't mean to do that. So if you're like, "Oh, I have there's an exception to that." Like I understand and and I'm sorry. I don't mean to assign everyone the same thing. But um generally when you are more junior, you work on things that are less ambiguous. And when things do come up, so say someone's given you a task and you're more junior and someone's like, "Oh, like it's, you know, it's XYZ and like that's how you go approach it." and you start work on it and you're like, but that's not really working out. And there actually is more ambiguity to it or more complexity, usually you go to the more senior people on the team and you get that guidance from them, right? Like, hey, I know we talked about this, but I need to get this clarified. So, you actually start to do that more because you're building up subject matter expertise. So, you start to become the person that can do that for others. You can do it for yourself, of course, it's part of building up some independence, but you can start to do that for other people. And that means you'll have people coming to you and that takes time. Designing systems before they exist is one of the things I wrote down here that's very similar to like, you know, architectural decisions. Um, and then dock writing. And dock writing is basically the one from the original Reddit post that this is sort of in response to. This person was saying they'd spend like almost all of their time writing docs. Like I I understand that you have to spend more time writing docs, but to do no coding and just write docs, like oh my goodness, that's not probably not a good balance. But that's just sort of my take on things. But yeah, I think there is an opportunity to kind of catch if you find that you're going down this path, right? And I don't mean like specifically like, oh no, like now you're writing only docs all the time. Like it doesn't have to look like that, but I think I think that there's ways that you can like try to catch on to this stuff. So I feel like at least my opinion is that when you are coding a lot less it's going to feel like inefficient. It's going to feel like you're not getting things done because like um probably and I don't know this for sure but the expectations that have been put on you as a more senior software engineer are some of these things we just talked to but also like hey you have these features that you're expected to go deliver. So, you probably will start to feel like, oh man, like I'm not getting anything done. And it's because you're not coding. Like you're not [laughter] you're not actually moving the needle on some of this stuff. So, I think a good um indicator is going to be like when you start to feel like things are not efficient, right? So, what can we what can we start to look at? We'll go through a few of these. Um Bra says, "Oh, yeah. I remember this guy who was a technical writer at my first job. Was that his role to be a technical writer or was that um was that what he started doing because he was spending too much time writing docs and [laughter] and not uh not building software? I don't know. Okay. Um let's see. Just looking for some some points that I want to focus on. Oh yeah. I mean technical writer is is definitely is a role. Um we had a technical writer where I used to work um that would actually do like like writing for um like products uh what's a good way like like support documentation I guess like how users could really dive in deep to use the product and that kind of stuff. So, okay. Um, I think if we're reflecting on like when what's a good way to say this? When you're feeling like, okay, something's a little bit off and like things are getting inefficient, like I think a good opportunity is to to kind of reflect on like where things are coming from, right? So, we have to kind of step back and go like what's what's sort of the root cause of this? And it doesn't have to be the root, but that's where we want to get to. Dominique says, "Inspired coding came before vibe coding." Yes. [laughter] Um, okay. So, I think you can get some of this like ridiculousness when you don't have um early alignment on things. So, you can run into situations like if you're like, I'm always writing docs. Like, why does that happen? Well, if you don't have early alignment on things, you could be in situations where like instead of you putting together what should be like a small dock, like now you're getting um people debating on things, right? like people truly aren't aligned on what the goals are and all of a sudden something that seems simple and you might have experienced this if you if you know if you've if you've spent more time doing dockw writing or working on more complex things you might have a conversation with someone you kind of feel like you're on the same page you're like okay cool so you start putting a dock together could be a one-pager kind of doc it could be a more of a larger architectural doc it could be whatever something just to convey you know, um I put together like almost like proposal ideas, like super high level, but like this is why we want to go do something. And you might feel like, cool, I had a little bit of input early on. I feel like this is on the right page. And then what happens is when you start to bring together other people to go discuss this, you just quickly find out like, oh crap, like everyone's got different opinions here. And then you can have a lot of back and forth. And if you're doing this asynchronously, you could have people leaving comments on stuff and it's just like the cycle keeps going and going. Um, it's good if you get this kind of feedback early, right? So, if you start this kind of thing off and you find out early that people aren't aligned, cool. Not a lot of time wasted. Hash things out, get it written down. But it's much worse if you've put something together and then much later on someone's like, "Whoa." like what's going on here? We got to revisit this whole thing. But that's kind of the going into the next point that I want to talk about which is like especially with dock writing because the focus of this part by the way is around dock writing because this person said that's all that they do. And I think if you like I've seen this happen a lot with writing documents where this happens on code reviews. So you can think about that too if you haven't written many uh like design docs. If you have multiple people that need to review and everyone's kind of going at their own cadence and there's not like a timeline like we must review the dock by X date. If you don't have things like that in place, here's what could happen, right? Let's use a hypothetical situation. You are a senior software developer and you are responsible for this architectural document. You've had a couple of side conversations early on to get a little bit of feedback, test some ideas out. Cool. I'm going to start writing this thing. So, you start doing it. You get it to a spot and you're like, "Okay, like it's not it's not 100% done, but like I need to it's far enough along like I want starting I want to start getting people to review this and get some feedback coming in." Okay. And so, you might go, "Cool, I got to go talk to one of the other senior developers." And like you might have like staff or principal engineers, that kind of thing. And you're like, "I should pull in a few of those people, get their input." Uh, you know, product manager, your engineering manager, whoever, right? there's might be an architect. You start pulling in some people to have these conversations, right? Maybe it's an asynchronous review. People are leaving comments in a doc and you're going back and forth. So again, you think about this with code reviews. It's not like everyone signs in 10 minutes after you notify them that you have a doc and they start leaving comments right away for 20 minutes and then they go away. So we have like a 30 minute turnaround on you at everyone's feedback. Doesn't work like that. Right? Most people are doing their own thing, rightfully so. They they have their own tasks, too. So, some people are like, "Cool. I'm going to try to address that right away. I want to unblock this person." Maybe it's in their best interest to provide feedback early on, too. So, they jump onto it pretty quick, right? Maybe they wrap up the review they're doing, finish up their code, get it a little check-in, and then they're on your dock. But maybe the next person they're uh they're out of office for two days. So next next next sorry next time that they can leave comments is three days from now. Maybe someone else is on call and they're totally swamped on call. They're on call for a week. Maybe someone that you have to engage with is just like I don't know like tied up in their own work, not really paying attention and they're also a week out. So what happens is like you get feedback from someone early on. You're waiting for the other people. So you're like, I'm going to address this person's feedback, start writing it in the dock, making your updates. Maybe you have enough time to meet with them and chat about it. Week comes around now, you get this other feedback, and then people are like, "No, I don't agree with that. Like, we should go do this other path." You're like, I just I just talked to Joe about this and like we got on the same page and I just made changes to this dog and now now Sally wants a different direction and then Steve wants a whole other direction or he agrees with Joe and like well what do we do now? You've just lost a whole week of time and now you're at a point where people don't even agree. So, I think that this kind of thing can be a huge time sync. I don't think I have a perfect solution for it. I think trying to set some timelines is helpful, but there's always going to be this kind of stuff that comes up. And I think what we want to do is um like minimize the amount of delays with this kind of thing and then find ways to to work around it where possible without ignoring feedback, right? You don't want to say like I wrote this design doc and you know reviewers couldn't do it in 15 minutes. So like that's just the way we're going. Like it's it's not going to work like that. But you want to make sure that you can at least try to minimize this kind of stuff. But like I said, there's a parallel to code reviews here. So, if you haven't done a lot of design docs or run into this with design docs, I'm sure you can think about a pull request or a code review where you put it up and maybe someone gives you early feedback and you're like, "Oh, yes, like I I'm using a pattern that I shouldn't." So, you respond to the comment and you're like, "Cool." You start addressing it locally, get it all fixed up. Uh maybe it's a bigger design change and someone's like, "Hey, like this is the wrong way. Like, you should go down this path." and you get, you know, rework some of your stuff and push it up. Next reviewer comes on, right? Because there's a delay in the time to review two days after you put it up and you had enough time to go make the changes and they're like, "This isn't the right pattern either." First person might have been fine with it. Second person's like, "Nope." So, back to the drawing board, right? Got to change the code again. And like just these time delays can make a huge difference. So when this person who wrote this Reddit post is like I spend so much time writing documentation. This might be one of the reasons why meta point is like I don't know that for this person or for you. This is an exercise you got to go do to see like why why am I spending time on it. Um, and then I I wrote down like over documentation too. And I have different thoughts on this. And I think that I have like a a bias towards um it's not that I don't think documentation is helpful. I'm using um documentation here to describe like lots of things like wiki pages, uh one pages for things, whole architectural design docs for things, whole variety of things. And I think I think my like my perspective coming from like startups and small companies even though I work at Microsoft now I think I'm personally a lot more aligned with like the approach that I I lived for my time before Microsoft and that means like less process and documenting things and one pages and design docs and stuff like that is more process. process. I don't think it's outright bad. So, it's not my intention. I realize it's very easy to like say things and have them be uh misconveyed. Um, so I'm not saying that documentation is bad. I'm not saying wiki pages or design docs are bad. What I am saying is like I feel like I have seen leaning into this kind of stuff like almost to an extreme be kind of a pain in the butt. And it's like if every decision you need to make needs like a formal dock and the dock process is similar to what we were just talking about where it's like the turnaround time is so long. You know by the time you get to code something you might be a couple weeks into it and it's like did that change really need a couple of weeks? You probably could have pushed up the first version of it depending on your environment or whatever. You could have been out in production in a week and you could still get feedback on it and redo it a whole different way and push it up and still finish in the exact same amount of time. Um, so I don't know. I I feel like I don't think that it's bad, but I've definitely seen like some patterns with like overdocumenting things and I I don't know. I think there's a balance, right? I want to acknowledge that like I have a bias and other people might lean the other way on it. So, um we'll keep going. So, I do think that I do think coding for um for IC's is incredibly important. Uh I do I think that it's important for like for managers uh personally no but I need to qualify that. [laughter] So I let me start with IC's. I think that you know as part of being an individual contributor as a software engineer is that there is an expectation that you're delivering things and I think that some of the other expectations that are put on you as you become more senior it is still very helpful to remain hands-on a lot relatively speaking it will drop because you have other things to do that you didn't have responsibilities over when you were more junior. We've already talked about that. But I do think that having your hands in the code, working with the systems, that kind of stuff helps. It helps you as an individual contributor make better decisions about the systems you're working with. It helps make sure that you can make better technical decisions. Right? To give you an example, as an engineering manager for my teams, I don't there isn't an expectation on me for this and I certainly would not operate this way. But if someone was like, hey, we need a technical decision made for like one of the the product areas I own. Am I in a position where I could make a decision about that? Yes. depends on like how detailed it needs to go. But could I make a decision? Yes, I think the answer is yes. And I could say that comfortably for most things. Does that mean that I am the right person to make a technical decision for that? And I would say most of the time the answer is no. And most of the time the answer is no because there is someone on my teams that is much more technical than me. they understand those things much better. I would love to work with them to get their opinion or several people's opinions and go hey like we should discuss the technical solution for this. So it's not about can I do it as someone who's not writing code at work. It's not can I am I the best person for this. So in a pinch yes or if there's people say I have two engineers that can't agree on things I'm happy to work with both of them to arrive at a common solution right like I end up playing a different role in those types of things so to the other part of the that statement around should managers code I think that like that wildly depends on the scale of the team that you're working with and I've talked about this many times but you know Like before Microsoft, I managed teams and I was a software developer at the same time. [snorts] I managed teams of like up to 15 people, I think. And that was early on, too. It was not [laughter] not a good move to be a new manager, managing, you know, like 10 to 15 people and then coding at the same time. Um, but here we are. And I think by the end of that it was like probably 10 to 12 people across two teams. Sure, please. I I'll Yeah. Uh Patrick, I will answer your question in just a moment. Um, so you know, I I did that and I was coding and managing teams, but I was also working a ton. And I think that when the teams are small, there's almost like there's almost like no excuse to not be participating in the building of software hands-on, right? If I were managing teams of like, you know, two, three, four, five people, like six starts to be where it gets a little bit like you might you might be better used other places or at least your hands are coming out of the code a lot more. And then beyond that, it's more and more and more hands-off. It doesn't mean that you should never code. uh doesn't mean that uh you don't need any technical skills or anything like that but I would say in my experience that when you start managing more people and you keep your hands in the code because you're trying to deliver on features I don't think you're focused on the things that are important for your role personally and I do think that if you're trying to work on things you can become a bottleneck very quickly So, it's not that you can never do that or it never makes sense or anything. I don't like extremes like that, but I do think the situations where that makes sense are fewer and farther between, right? I want to give you an example and I don't want because I'm going to use my own manager. I don't want this to make it sound like I'm setting him up to talk ill of him because I'm not. My manager is extremely technical and he knows the area uh that you know more than what I manage but especially what I manage. He knows those areas extremely well. And if there was a really urgent issue and he needed to jump into the code, he's been in that code base for years. He absolutely could go jump in and make fixes or make changes comfortably because he has worked in there for years and years and years. Do I think personally, and I would tell him this to his face, so if I'm not like scared about saying this, do I think that it would be a good use of his time to be coding instead of doing all of the other things that are expected of him in his role, like on the job? And the answer is no. I don't think that's a good use of his time. I simply don't because there are so many other things that he needs to to be responsible for. Is it great in a situation where we're like, "Oh crap, we really need some help with this." Of course. I just would not expect him to do that normally. So, uh, Patrick has a question in the chat. Says, "Sir, please, is learning coding really important because of AI?" Yeah. Um, I think so. >> [laughter] >> Um, so Patrick, this this question comes up a lot, right? And I if if you're comfortable, I would love to hear more about your concerns on this because this question does come up so much and it does get brought up in a very general way. One of the things that I tell people is that like general questions or you know general questions get general answers. So if you say is coding really important I would say yeah if you want to be a software developer I think coding is very important but that probably doesn't seem like a helpful answer right and I I realize you said because of AI and I understand like that's a lot of the reason why people are asking this right now so I want to I would like to give you a helpful answer and I have to kind of make assumptions about the things you would like me to talk about without more context. So, I'll talk a little bit more, but while I'm talking, if you don't mind adding in a little bit more about what you're curious about or what you want to hear about, I have to kind of guess for now. Okay. So, um I do think that like AI does not mean you don't have to code if you want to be a software developer. I do think that people who have no experience coding, the barrier to jumping into having something written with code is lower, which is great, right? I am all about trying to help people get started, right? I you know made tons of posts over the last even when I was write I'm sure when I was writing stuff in 2013 still like my opinion on this has not changed but a lot of people are like I don't want or I'm not I'm not smart enough to be a software developer. I don't know math. I'm not good at math. I don't like math. And I'm like dude I don't like doing math either. I love to code. I don't like doing math. So, like I've spent a lot of time talking to people that are like, "Oh, I'd love to program, but like I'm just not smart enough." And I'm like, "Have you tried?" Like, is this just something you've told yourself that you're not smart and you can't? So, um, the fact that AI, I think, has reduced the barrier for people to jump in, I think, is awesome. Now, does that mean that I don't think there are trade-offs? I think there's tons of trade-offs and I think there's lots of benefits, but I I do think because I haven't seen evidence to prove this otherwise. I do think if you want to be a software developer, there are lots of reasons that you should be learning to program still understanding how things work, understanding how to debug things. And the reason for that is that even if you are at sort of at the uh new wave of software developers coming through, how do you expect to be able to interact with an LLM effectively? I would say like just to give you another example, this is going to be a bit of an extreme in comparison, but we probably will get there is like do I think that it's important that software developers understand how to communicate with product managers? Like could you get by doing a very poor job of that? Absolutely. You could probably write great code and not be good at talking to product managers, but do I think that it would be helpful in your role? 100%. So I think knowing the intricacies and all the crazy nuances of a programming language or you know all these super nitty-gritty details I think they will always be helpful but I think that you will be able to get by without those more and more. I don't think the need to to know how to program and be a software developer de developer I don't think the need to know how to program goes away. I think it will always be a benefit. So, Patrick, I don't know if that answers your question, but if you want more detail on a certain part of that, please just ask in the chat. Happy to try and answer. Devin says, "My manager does some coding, but he's got a good sense of what's lowhanging fruit." Uh, that won't get in the way. It's always something I'm glad I didn't have to do. Yeah. And so, interestingly, Devon, I was, you know, I've been saying like at Microsoft, I don't code. Um, and that's just because I have a lot of other things to do and that's not an expectation of me. Now, what's really cool is that there's a lot of AI tools now and I do know how to code. I code all of the time outside of work and we happen like not our entire stack, but we have a lot of C code and I happen to love programming in C. I also happen to use AI agents a lot outside of work. So, to Devon's point around lowhanging fruit, there's a lot of stuff where I'm like, if I can get an AI agent to do some like package migration or to to do like mundane work that I don't want my team to do, like that would be great if I can go like babysit some agents doing some some boring stuff. Right now, I've seen a counterpoint to this because I don't know if it was on Reddit or somewhere else, but someone was saying, "Hey, I do this for my team, but to the whole whole um theme of this this talk, right, in this newsletter article, it's like this person was saying they're spending a lot of time doing it." It's like, hold on. Like that does that doesn't make sense because it's probably not the best use of your time if you're leading a team to be spending all of your time babysitting agents that are doing mundane, boring, crappy work that no one wants to do, right? It's nice. It's helpful. And in like low volumes, it's great. Especially if you're not spending a ton of time on it. Things are chipping away. Great. Like that's helpful. But like why not teach that to the person who's more junior? They can babysit the agents, right? Like it's all about like is that the best use of your time? So I do think that it's it's cool to be able to do it. I think that's a great thing to be able to lean into helps everyone, but if it's a disproportionate amount of your time compared to what's expected in your role, I don't think it's a good fit. So, uh, anyway, Devin, I think that was, uh, I just wanted to relate that to my own experience and then something I heard more recently and I was like, "Yeah, it's a fair point. I'm I'm certainly not there, but I wonder, right, it's like I'm spending six hours a day babysitting agents doing code changes no one else wants to do." And I'm like, should shouldn't I be doing the other parts of my job? Um, Bra says, "I feel like it would be okay for managers to code in more of a proto prototyp prototypal way. Oh, like doing prototypes. Okay. Yeah. For example, experimenting with a new technology before it comes into play on the team. Yeah. Um, you know, and again, I think that depends a lot on the experience of the team too, right? I don't disagree with that. Um, but that might also be an opportunity depending on the size of the team, the experience of the team. That might be a good opportunity to give to someone who's more senior to be like, "Hey, this is an ambiguous thing that we need someone to go investigate. like you're in charge, like go explore it. Um, but you know, if the team's smaller or they don't have experience in an area, like that might be a great thing for a manager to go do. All right, it it depends on a lot of things. So, um, I think it's an interesting idea for sure. Kenneth, welcome. Hello. Thanks for joining from LinkedIn. I appreciate you being here. Brex says, "The core fundamentals of coding should be learned because those don't change and not knowing some of those concepts can really mess you up if you're air quotes vibe coder." Yeah. And so like I had this conversation with someone recently and I think it's on a podcast I haven't uploaded yet, which is a good reminder. Um because it goes to this, if you're on the YouTube channel, it goes to this YouTube channel. By the way, this is the podcast channel. So, I 100% agree with what Brax Saint said. For the record, and when I was talking to this guest on my podcast, I was saying I'm really curious about this because we don't know. We know we don't have a crystal ball. Okay? And I I don't I don't I don't want to say I don't want to believe it. I have a hard time believing this is possible, but hear me out because I think it's an interesting outcome. I genuinely wonder if we have a wave of developers that come through and they're like, I started vibe coding because that's what everyone was talking about. Like I just vibe, right? I don't really I don't really know exactly what's going on, but I take the code and like I can now I can see the issues are coming up. it's not compiling or it's doing weird things when it's running. And I wonder if this next wave of software engineers coming through, they become so effective with the tools and the feedback loops that they learn things as they're going. They learn enough of the air quotes fundamentals as they're going, but they're so efficient at being able to prompt and work with the LLMs that they actually just move faster in the end anyway. I don't know. Like I find that like I said, I think that's a that's a really difficult thing for me to believe, but we don't have data, right? we need to wait 5 to 10 years or something to see like are people just like LLM wizards because I'll give you a maybe a bad comparison but like I think some dep I don't know my my target audience watching this right now or watching the recording but I used a computer from a pretty early age. I didn't get a cell phone until I was like I don't know was I like 13 maybe for maybe it was in high school. I think I might have been 14 going into high school. I think I got a cell phone and it was like a Motorola Razor. So like it wasn't even a smartphone like that that didn't exist. And my niece and nephew like they've been growing up with an iPad. So they have like a decade of experience more using devices like that. I just wonder if when you get introduced to these things at an earlier age or like an earlier time in your learning like LLMs if if that just becomes a way of thinking that is ends up being more effective. I don't know. I think it's a crazy thought. It's not going to affect me anyway. Like [laughter] I've already learned how to program. It's not going to change anything for me. But I'm really curious to see in five to 10 years if like we look back on this and we're like, "Oh crap." Like I know we said you got to learn the fundamentals. And it's I'm sure it's not like fundamentals would be useless. I just don't know if the people that skip over that are still ahead because that's how it works. We'll see. Uh Deon says, "We might have the data already." Okay. Uh think about how many Access or Excel monsters there are out there built uh by entirely non-technical people. Yeah. Yeah. It's that's a good point. [laughter] Um I I I got to get him on my on my podcast still, but uh depending on how early people have watched some of my my content. Um I have a a friend of mine who I can I can call him a friend of mine. Before I probably would have said the brother of a friend of mine because I I you know his brother was my age in high school and oh still my age, [laughter] you know, we were in the same grade in high school and then we went to the same university. We were roommates and stuff. And so his younger brother, his name is Jamal. And when I started making videos on YouTube, like right in the beginning, Jamal reached out to me and was like, "Hey, like I noticed you're putting up like, you know, helpful programming videos." And he's like, "I don't know if you're monetizing this stuff or like what your plan is, but he's like, "Hey, if you want help with editing your videos, like, let me know." And I was like, "Oh, like, yeah, I'm not monetizing anything. I can't like pay you or anything. I don't I'm not making money from it." And he was like, "No, like I'll just do them. And I was like, that's such a nice offer. And so where this is going, because I'm really good at tangents, Jamal is someone who was trying to dabble in building some things. And he would tell you he if I could call Jamal right now and say, Jamal, do you consider yourself a programmer? He would say, absolutely not. No. Because he doesn't like he doesn't think of himself that way. And but Jamal is very smart. And I think Jamal uh doesn't give himself credit, but Jamal is not your typical or maybe it's closer to your typical developer now. He didn't go to school for programming. He was never interested in it, but he's I think he's very good at connecting things. Like he's very good at understanding different things and going this thing talks this way, this thing talks another way. He's a good communicator and he understands systems. he wouldn't think of himself as a programmer, but he's been able to put together some awesome stuff. And now that we have more and more AI tooling over the past couple of years, he's really leaned into that. I still don't think that he would call himself a programmer because I'm sure he's written code using AI tools and he's like, I I can probably tell you what it does, but he's probably like, this is it's probably garbage, like whatever. like and I think over time from talking with him I think he's able to pick up a lot better now when he thinks code is bad and it's he he doesn't he doesn't know what he's doing but like he's been vibe coding stuff and and and learning that way and truly has built software. He has he has sold software like he got paid to build software on like a contract basis and I have never done that in my life and I had to remind him I was like Jamal like you said that you're not good at programming you're not a programmer. I'm like you've done something I've never done before. I have never done that in my life and I've been programming for like 23 years or 24 years or something at this point. I've never done that. You got to give yourself some credit, right? Um but I I do think that, you know, that's a possible outcome of all this stuff. Kind of interesting. Okay. Um we are approaching time here, but uh I do like to kind of wrap up. Maybe I'll just show on my screen. One sec. Gonna zoom in on it, but did I get this? Oh no, there I am. I'm back. Uh [laughter] I I kind of wrote down like, you know, I like I said, generalizations I don't not a fan of, but there's some ranges to think about. Um in terms of like how you spend your time, but there's a lot of like caveats here. And like of course if you try to add these numbers up, if you take all the minimums, you're like that doesn't add up to 100. Like I get it. you know, the minimums don't add up, the maximums are way over. I understand, but somewhere in this range, I think, is probably a pretty good mix. Now, this could change, and I think that it will change. And I think that anyone who maybe lines up somewhere in here, you know, two weeks from now, that might change, too. Like, nothing's fixed perfectly. But I do think as a senior software developer, there is still a good chunk of your time coding. Is it over 50% of the time? I would, you know, at a senior level, I would push for that, I think. And if you're going past senior, I could see that that's dropping. Something else to think about though is like especially if we're looking at these other pieces here, even with the coding, the the type of impact you have and the sort of the the amount of impact. I don't know the right way to say that, like the [laughter] the significance of the impact and the blast radius of the impact. I don't know what the right qualifying word is here. The amount of impact you have though is probably also greater, right? So you don't actually need to spend as much time coding things proportionally to still code high impact things and then to have impact across these other areas. If you think about it, some of this work where you can unblock teams, get people aligned faster. Some of this work where you're working with other people on the team to enable them to do work more effectively. Some of this work where you're designing larger, more complex systems and having other people partner with you to build those things. Some of these things can be significantly more impact than just you sitting at your desk trying to code as fast as you can or yelling at co-pilot to do it. Uh Kenneth says, "Can you briefly state what this mix would look like for a junior?" I think a lot more um coding and uh I would say depends where you work terms of design and documentation this number would be way down. So um maybe this is something like I don't know five to 15% for this. This is the majority coding by the way. Uh, I say five to 15 here, but like if you have a process where everything you do has to be documented, that just by definition has to go up. Um, and what's not listed here though, like I would still do reviews, I guess, and I kind of included that in coding maybe. So, um, you still pro maybe like another 5 to 10% on reviews, but this part, the mentorship and collaboration like looks very different because you're probably spending. So Bra says 80% coding 10 collab 10 reviews something like this like it's it's disproportionately more coding but I think even what's kind of mixing or missing in Braz's layout and it's not really listed here is like just like learning and like that could be reading code reading documentation like uh maybe it's mixed in with collaboration and the the uh the opposite of mentorship like getting mentored having people explain things to you like there's a a bucket of time that's not really accounted for uh on here and that's like the learning part and for me that that number I would expect is certainly non zero and I think it would start it kind of tapers off but I think someone who's brand new on the team so imagine someone who's you know early in career they've just graduated college or they're uh you career switcher uh or finished a boot camp and they're hired. You know, to say 80% of their time coding, probably not because 80% of their time is probably just like reading, trying to understand what's going on, reading things. Um and then that tapers off. The rate that tapers off depends on how fast they onboard, how complex the system is, the support they have. There's a lot of factors, right? Um, when I joined Microsoft, my first manager at Microsoft told me, "Expect that it will take over a year for you to feel comfortable in this space." Over a year. [laughter] That's a long time to, you know, to be reading about stuff and catching up on things, right? So, hopefully it doesn't take a year to on board. But I I do think that there's, you know, something not called out here, which is sort of that um that dedicated time for like reading and learning and understanding. But that you could capture that a little bit in collaboration and uh the inverse of mentorship for getting help from people to understand stuff. Um but yeah, I think like Bra put in the chat, I think that's pretty close, right? Bra doesn't have sliding windows on there, but I think that's the idea. Something close to that is what I would expect more for juniors. And the reason for that is because you like I don't mean this in a insulting or condescending way. This is sort of just reality. Most juniors are not as effective at coding, right? Like simply put and so you might have more proportionally your time the expectations of you is more on coding but also you're less effective at it and that just ends up kind of consuming more of your time. Then what happens is you become more and more effective at coding. you get uh you know ramped up in the area and the domain and the code base. So you're more effective at coding. You're spending less time having to go learn things because you've learned them. There's always some amount of learning, right? But you can probably see how that becomes more and more coding. Then what happens is you start to get these other responsibilities more and more. So this bucket shifts from somewhere near 80%. Let's say again these are I hope everyone understands these are not like numbers carved in stone but this goes from somewhere near 80% to like the that time has to start going into some of these other things more and more as well just because these become more and more of an expectation. So I hope that helps. Um but let me know if that's not totally clear. Um maybe it's too hand wavy but abstract percentages. Yes, that is that is the way to call it. But yeah, Kenneth, let me know if you have any more thoughts on that. Uh, or anyone else if you are kind of curious. Um, I think we're at 8 Pacific. I'm gonna probably wrap it up there. I do have a bunch of homework I got to do for for work, so I might kind of start signing off here, but that means I get to do the fun thing where I talk about all the other things that I got going on. Thanks, Brax. I appreciate that. Um, so where do we start? Let's go to YouTube. Um, this is I'm not sharing my screen yet. Sorry. My main YouTube channel is called Dev Leader. That's me talking. Um, this is where I do my programming tutorials primarily in C. I do a lot of AI tutorials and stuff now. So, um, these more recent videos are me kind of, uh, using like real examples from my own development where, um, I've been, you know, using AI agents and in particular these three, um, how I'm trying to put more guard rails in place for keeping agents on track. And I have two more videos coming out this week. Um, I I don't know. I think it's it's kind of interesting uh for me because I show you literally how I am using AI to build some of the features that I put into brand ghost. Uh I'll talk about brand ghost right at the end of all this but kind of like hey I had uh a user that requested something and like okay I'm not totally familiar with this. I poked around a little bit to understand and I was like, "Okay, concept seems very similar to something else we have." Okay. Looked at the the API docs and I'm like, "Oh, this is a huge page of API docs. Probably something on here." And I said, "Okay, time to go to GitHub Copilot." Sent it the docs. I said, "I'm pretty sure what's being asked for is something like this other thing we have in the codebase. You can see the whole codebase. Tell me what you think." So, the first video kind of shows you this back and forth with Copilot to put together a GitHub issue and then the second video we review what Copilot did and spoiler alert did a pretty good job. Um, [laughter] it's it's awesome. So, I was able to kind of knock that feature out for a user that requested it very fast. And pro tip, uh, at least in my opinion, I think one of the best things that helps with users is not that you have to get everything perfect, but that you show that you're listening and that you care. And I have seen this time and time again. I saw this. It's one of the core lessons when I worked at that digital forensics company before uh Microsoft. you know users they have a high bar. It's digital forensics. We have to be very accurate. But people really cared or really it meant a lot to them that we cared about listening to them. You know, people had requests or they had issues they wanted things addressed and we would do it and that was a huge uh huge upside for them. So um trying to trying to live that out with some of the brand go stuff I do. So, uh, next one is where's my podcast channel? YouTube, come on. That's over here. So, this is where the live stream's happening on YouTube right now because I switched channels to do this, but the podcast channel, I interview other software developers and I love it. It's a lot of fun. And the one of the things I try to get every guest to do is talk about uh their career journey. So, every single person that comes on, doesn't matter if uh like so Samantha Samantha has I I'm going to keep bringing up Samantha every time I do one of these because uh it was the biggest roller coaster [laughter] of like um career switch moves. And super cool because every time she was switching careers, it was, you know, something that she said, "I'm trying this because I love to do this and maybe that could be a career for me." and she ended up, you know, getting uh towards software development at the end of that. Um there is one with uh with Rita Iglacius kind of behind my head on this one here, but uh she was talking about how she was an actress, right? So she was uh doing I can't remember exactly how it worked, but they were organizing like uh plays and stuff like that. And so they were always trying to put this stuff together and then she switched over to software development. And it's like it's such a cool Cool story to hear everyone's different journeys, but um there's Ethan Evans who is a VP at Amazon. Oh, my face looks pretty fat there. Holy nice solid hair, too. Um who else we got? We got uh Dan from Code Wrinkles. We got Derek Martin of Code Opinion. Lots of awesome people. Scott Hansselman. This was like one of the coolest ones for me. Scott's like a Do people know who Scott Hansselman is? I feel like I feel like when I told my wife I was like I'm going to interview Scott Hansselman. She's like I literally don't know who that is. And I'm like that makes sense. And I was like he's like the Taylor Swift of like you know Microsoft developers and she's like that doesn't make sense. Um but it was really cool. Uh Scott's an awesome guy. But all of these every single person talks about their career journey and then we get into you know something that's a little bit more specific for them and something they want to talk about. So, I really enjoy that. I have a resume review channel if you want to check that out. It's dev leader path to tech. I do have résumés to catch up on. I've just been swamped. What else we got going on? There is code commute. Can't forget code commute. Let's pull that one up. Love seeing folks from Code Commute come over to the live stream. My computer's chugging along here. This is uh me wearing an eye patch, not to be a pirate, but because [laughter] my eye was totally messed up. It was disgusting and I'm like, I need to film videos. [laughter] I'm like, I have to cover it up. So, yeah. Anyway, um not a pirate, but that's a code commute video. Um code commute is my channel where I do Q&As's basically. Um, and so the way that works is people leave questions as comments on videos, they send them into me, uh, or they go to codeccommute.com and they can submit questions anonymously there. But the the idea is like if you have a question about software engineering or your career like write to me and I will make a video about it. And I started Code Commute because I don't like doing nothing when I'm driving and I wanted to be productive and I figured why not, you know, try to get some content made. And it's turned out to be like in terms of content creation, one of my favorite ways to make content. Looks like we've gone over 400 videos on Code Commute now. Um, hello Om, welcome. And so, yeah, making code videos is a lot of fun for me because I know that when someone asks the question, it doesn't matter if I'm reading it off Reddit, I'm like, "Someone asked this question, they're looking for an answer." So, I I know that it will help at least one person who watches it. So, that's uh one of the reasons it's nice. And to be honest, the topics on Code Commute are a lot more um a lot closer to like the stuff that I want to focus on as a content creator, which is why I use them as uh newsletter articles. It's why I use them as my my live stream topics. I love programming in C, but I don't I don't want my identity as a content creator to be like the C guy because I think I offer a lot more than just C. I've been an engineering manager for for 13 years now and like I've seen some stuff but I would [laughter] rather help folks out. It's like what I do in my career. So, um would be happy to help that way. What else we got? Um that's code commute. Uh courses. Yeah, I got courses. We should talk about courses. Um this is the part where I got to sell people on my courses. I know. Um but this is dome train. It's not my platform. This is by Nick Chapsis. Um, where are my courses? Can we go by author? What? There's a lot of courses now on domain, which is sweet. Um, but I have the getting started car one. So, I want to learn about car and.net. Oh, I guess that's going to be basically everything. Can we just ask it? Um, no. That's just a search. Um, what do we call it? There's deep dive. Oh, I'm not even on here. Come on, man. So, do train pro. I think a bunch of my courses removed to do train pro. Um, there is a sale. Nick Chapsis is almost always running sales, but um, all the dome train courses are by industry professionals, which is really nice. dome train pro. Uh, one thing to consider is if you're like, I don't have money for that, like totally get it. Um, your employer might something to think about. Uh, if your employer can pay for it, that's great. With Dome Train Pro, you get access to all the courses, which is super cool because if I scroll, there's lots of them. Hey, there's mine. Um, can I move this over? It's probably going to be a pain in the butt. Oh, it's going to do weird stuff. and my codes behind here. But you can see right these two are mine. I got more on there, but there's the getting started and deep dive C# courses that I am very proud of. And I do have another one that I'm going to be putting together. I've given hints on the live stream of what it's about, but I have not revealed it yet. And finally, I will show folks my pride and joy. Brand ghost. Uh, Brand Ghost is the social media content posting and scheduling platform that I build. So, if you see my content posted online, it is posted by Brand Ghost. Um, so Brando lets me create content and then I just add it to Brand Ghost and it will go publish it on a cadence for me and then I never have to worry about posting to social media myself. And so you'll see in some of my dev leader YouTube videos, I actually I use Brand Ghost as an example a lot because if there's interesting problems I'm solving, I generally make videos about them. I also blog all the Twitch people and the kick people that try to spam my chat. There we go. Get rid of that. And so yeah, if you're someone who's interested in getting into content creation, Brand Ghost is 100% free to use for getting started. Uh you can cross post and schedule content with unlimited accounts. Uh we will make exceptions to that. I've had people, no joke, uh we had someone try to add 370 Facebook accounts. 370 Facebook accounts. And we said nope. Like there's no [laughter] there just isn't a legitimate use case for that. So it's not a spamming platform. It is a content posting platform, but like I have probably close to like 50 social media accounts, but I'm also doing it across three brands. So, um, that's not unheard of, but if you're not interested in doing content creation, totally cool, too. If you have a small business or you know someone that does, this might be a great fit. We've actually had um like non uh not forprofits sign up and stuff. So, uh churches, we've had uh like fundraiser uh you know, type organizations register because it's free. Um and if they have funding and they you know, they want to spend the you know, for the first tier and get some recurring content, that kind of stuff, then they can. The reason that this is helpful and people may not realize because you're like, I don't think I have this problem. You might not, but if you're trying to run a business and you are like, how do I market? I don't have I don't have time for posting on social media. What we try to encourage people to do because this is how I make content and this is what Brand Ghost excels at. If you make content and you're not trying to chase being viral, you can do a lot. So, uh, Om, no, this project is not open source. This is a project that I sell. Uh, I it's free for people to to leverage. Uh, but if you want the more advanced features, this is a a business of mine. So, um I do like talk about the code and stuff in videos, but um the code is not for for public use. So, if you're trying to market and you're like, well, I don't have time for posting on social media. If you make content that's aimed at being helpful, um aimed at I don't know, like we call it evergreen content. And the idea with evergreen content is that it's valuable today, it's valuable yesterday, it's valuable last year, it's valuable next year. You make content that's still valuable and relevant and you add it to Brand Ghost. This way in the future, every piece of content you put into Brand Ghost is sort of like an investment. Um, yes, Kenneth, Brando is written in C. uh the the front end is in uh is in React well next.js JS, TypeScript front end and then uh the whole back end which is the part that I work on primarily is uh is all C. But if you think about creating content this way because if if you're like I don't you know I can't think of creative ideas every week. Um I can tell you I do not write posts every day. I would die. I am not creative enough for doing that. I cannot think of like viral ideas to go try and, you know, film skits for and stuff like that. I I'm not that person. I never will be that person ever. And that's okay. It's like it's not for me. But I still post every single day to like how how many platforms is that? That's 11 platforms. Um 11 platforms every single day, multiple times per day. videos, text posts, short text posts, long text posts, pictures, like you name it, I post everything. And the reason that I'm able to do that is because I've created a bunch of content and a lot of it gets recycled. And there's nothing wrong with that. People are discovering my content that is 2 years old, tutorials, and they're like, I like, thank you. Like, haven't seen this video before. And I'm like, that's great. It's 2 years old. watch it. Um, same with my technical articles, right? Creating content that's repurposed uh and repostable is very valuable. And I think if you're a small business, if you have content like this, what's really good is that you have a pipeline of content that you can reuse, then from there you can focus on other parts of your business or you have more time to periodically try doing a, you know, a viral trendy thing, right? But if you're trying to chase a viral trendy thing and post every day, good luck. Unless you want to do that full-time. Some people do, not for me though. So, if you're interested, let me know. Just reach out, ask about brand ghost. I'm happy to help. We can onboard. We can import posts from LinkedIn. We can import post from Twitter. Um, if you got content somewhere else and you need help with it, I'm happy to try and work with you. I can try to build an importer, can try to do stuff in bulk for you. We can upload bulk pictures and videos, but uh text posts, you know, we can get a CSV or something of it. we can import that. But happy to help you out. So, if you're like, "This seems cool, but how would I get my content?" We'll find a way and we will get you going. And of course, if um if that does sound interesting, but you're like, "I don't know how to post. I don't know what to post about." I don't talk about that stuff, you know, as like aside from the ends of these live streams like right now. But that's something that I'm happy to help people with. And I probably will uh for brand ghost in particular, I'll probably start doing um more video content in particular. So I will probably do probably in the new year even like a podcast where I will get people on that create content of all different kinds, interview them, see what tools they're using, stuff like that. Talk about content creation. And again, I'm telling you this because it doesn't it doesn't mean you need to be a content creator, influencer, like if you want to learn in public, like what types of like how how can you go show people that content? You have a small business. How could you leverage this? Right? It's part of me is like sure like I would love to sell you on this and take all of your money, but it's also free to use for the basic use case and if that means I can help you get going on this stuff, then I would love to do that. because I can't survive content creation without Brand Ghost. That's why I built it. So, um I will leave you with my Brand Ghost content calendar. This is my new favorite thing to show people. So, one sec. Let me pull that up because it's fun. Okay, this is my social media calendar. So, this is what December looks like. Yes, I'm on a 74. Oh, I'm not sharing my screen. Ah, there we go. This is my content calendar for December on my 74 year trial. Um, and if I pick a day, I'm going to have to move some stuff around so you can see this. Sorry, don't look at the code behind. I got Visual Studio up. Um, if I pick a day like this one, right? Post for December 17th. These are, you see this scroll bar? These are different posts that are going to go out on all these platforms. Don't worry about that, Alex. 74 year trials are just for the the pros. Um, this is like, look at this one. This is a short form video. So, every day at 9:00 a.m. Pacific, I post short form videos. This goes out to one, two, three, four, five, 6, 7, 8, 9, 10, 11, 12 platforms every day at 9:00 a.m. automatically. That's one of the posts I make every day. Okay, but here's the best part about this. Oh, thanks for joining. [laughter] Uh, you may want to watch the recap. I appreciate you being here. We're just at the end, so I'm sorry. The best part about this, in my opinion, though, is not that I have like a day like this. It's that I have every single month perpetually is scheduled like this, right? This is April 2026, May, June, July. This content's already scheduled, right? July 28th, right? Another short form video going out 9:00 a.m. already scheduled. All that I have to do is add content into Brandos. It keeps it fresh. Otherwise, it just recycles stuff. And I have hundreds of short form videos. I have hundreds of blog articles. I have uh I have how many memes do I have? I have over 200 memes. So, there's enough memes. This is also another one I should show sometime. I have enough memes to post on software engineering that if I post four times a week, because I post them on Wednesdays, Friday, Saturday, Sundays, if I post a meme those four days, you won't see the same meme repeat for over a year. Which is sweet because as a content creator, it means I can take a break. I'm telling you this right now so you can pay attention. I am taking a week off over Christmas. taking the week off. My content will still be going out. I will periodically check in and I'll be commenting on stuff because that's the other whole thing. Um, you didn't see it on my screen maybe, but we have this uh this feed view. We're going to going to redesign the UX for it a little bit. But the feed view, you can see I have it says 27. I have 27 comments I have to go respond to on the platforms that let me respond to comments. LinkedIn is not one of those platforms because LinkedIn sucks, unfortunately. Um, but we have like a one-stop shop where you can get all of your comments to go respond to. And so I need to respond to comments because on platforms that makes a big difference. But yeah, July [laughter] July 28 spoilers. That's right. You got to I hope everyone memorized what those those posts were because you'll see them coming out. But anyway, that's Brand Ghost. That's what I build. Um, that's what my my time and energy goes into outside of work because that's what drives all my content creation. So, thank you so much for watching, folks. Um, what's next Monday? Am I around? Yes, I'm still around. I'm not not taking time off yet. So, I will see hopefully we'll see you all on the 15th. Same time I'll be here. And if you want to know what the topic is for next week's live stream, where do you go? The newsletter weekly.devleer.ca. So, thanks so much for watching. I will see you next time. Take care and have an awesome week.