Building Software Outside of Work - Principal Engineering Manager AMA

All right, we're getting things going here. Get the stream chat reream's doing a weird thing here and I can't seem to turn on my chat to display which is kind of annoying. Feel like there's move to top. Yes, it's not working. I don't know. Uh, sorry folks. That means I can't show the chat. Um, the chat is indeed working though. But I just wish uh I could kind of show it a little better. So, I'll read stuff out. I'll try to do a better job of that. I apologize. Would be nice if uh things just worked, but that's not always the case. So, welcome to the live stream if uh you're new to the live streams. They're in AMA format. What's going on? My Instagram's not working either. Okay, nothing nothing's going to work today. Live streams are in AMA format though, so you can uh jump in, ask questions. I always have a topic that I'll be going over. So, if you are available on Substack down here, hello Substack folks. I still don't have any support for like a month now from Substack on getting their live streaming working on the computer. I'll try to watch in the chat. Otherwise, Substack folks, if you want a better experience, I would just recommend going to YouTube. It's a Dev Leader podcast or if you uh if you're on LinkedIn, you can probably see that I'm uh like doing a LinkedIn live as well on Twitter. Try to do it everywhere. But the topic today is going to be about building software outside of work. And this is a topic from Code Commute. It's a thing that comes up a lot too. Hey Devin, again, can't see the chat. Devon says, "Howdy. Wish uh wish this would work." Um but yeah, a topic that comes up a lot. Um and I would say different people have different perspectives on this. I think that when people talk about this, it can kind of feel I don't know like polarizing, right? Some people will say like, you know, they have this expectation that that people have to if you want to be a good software developer, you have to be spending time outside of work, you know? um coding and then I will talk about things from the perspective of like you know if you're trying to get into the into the industry that I I think that if you need more practice and more experience like that's a good opportunity to do it but there's not like I don't want to go into this conversation saying like this is the right answer right like you need to be doing this or you should never do this and it's it's completely black and white sort of thing because I don't think that's fair I don't think that's accurate and I don't think that's the case for a lot of things we do in life. But what I did want this conversation to be about is um why you might want to consider it if you're able to. Okay, so that's kind of the framing. Give me one sec. I'm just positioning this so that I have a reference to go by. And this is going to be the the day where nothing technical works. Come on, Windows. Please dock the window. Thank you. I got to talk to someone about that. Um, yeah, the newsletter that I publish on the weekend has the topic for today. So, I'm just going to put that in the chat. It's at weekly.devleer.ca. Uh, Substack folks, you're already there. And, um, you know, if you're on a different platform, uh, it's at weekly.devleer.ca. The latest one is called Building Software Outside of Work, which is uh coincidentally the title of this live stream. And I always remind folks like the newsletter is if you don't want email, like don't subscribe. That's totally cool. I'm not here to push that. But if you like the live streams, right, if you're watching this one, you're hanging out and you want to come to the next one or one in the future, if you're interested in knowing the topic, it's usually what I end up sharing uh in the newsletter so you can get a preview. Okay. So, building software outside of your working hours. Um, I think that primarily um like I have a few different angles for the things I want to talk about today, but to start I think the most important part is like is kind of getting your own why. And that kind of seems I don't know maybe woo woo like handwavy like okay well what does that mean Nick? Um I talk about this a lot in on code commute. I talk about this a lot you know for dev leader in general but um I think a lot of things we do we need to make conscious decisions about them and so the reason I say that and maybe it's very obvious but right just to elaborate is that there's so much information whether that's online on social media from your colleagues people you've worked with whatever there's so much information sometimes it's very conflicting and this isn't unique to software engineering right I've given examples before like in the fitness industry like you know for dieting and what works and what doesn't like no keto is the best diet no intermittent fasting no you need to be vegetarian no you need to be paleo like and then you'll have examples of each of these individ like carnivore diet you'll have individuals all these examples where like it works and then it doesn't for you or it doesn't for someone else and it's because it's not just like one sizefits-all one solution ution for everything. And so let me ban this person. Ryan, I'll come to your question in just a moment. Um, so the framing that I want to have with all this kind of stuff is like I think if you come up with your reason why, then you can use that to guide you. Okay? So I'm not going to use this conversation to convince you or try to convince you because I don't think that's relevant or necessary that you need to be going to build stuff outside of work. So, if you're like, I don't have time, or whatever other excuse that you might have for yourself, whatever, um, that's great. I'm not here to to to convince you otherwise. I'm just here to give you some examples. And I think if you pick why and you understand why for yourself, then that will direct what kind of software you plan to build and how you might approach that. Okay. Um, Ryan is asking in the chat, which no one can see because reream. Um, he says, "I'm not sure if you're going to cover it or not, but I would be curious how to avoid overlapping your work software building versus your outside of work software building." Yeah. Um, that's a great question. And Devin has responded on YouTube saying, "My last job, uh, my last job I got mad about them not letting me work on a project, so I built it on my own time and put it on a GitHub. My coworker found it. We ended up using it anyway." Nice. That's awesome. Um, yes, I think, um, I would be curious to how to avoid overlapping your work software building versus your outside of work software building. Um, yeah, it's a good question because like I didn't write about it, but I think it's a a good thing to consider in that. Okay, couple different ideas come to mind here. So, if you're if you're interested in the stuff that you're doing at work, like let's use Devon's example, right? If if Devon um in his example, he's saying uh there's a project he wanted to work on, so he built it on his own, put it on GitHub, and then they ended up using it. If that was something that was maybe more generic, right? Or maybe it was for a specific problem, but that's not like the company's like core thing that they're doing. Just going to make up an example, right? So Devon is building software for I'm literally making this up for um for medical purposes. Okay. And so the company has a very medical focused mission. And at some point Devon's like, I really want to make a PDF rendering library. Again, this is as random as I can make it. If they were like, no, we're not doing that. Um and Devon's like, I really want to do it, so I'm going to go build it on my own. if like a PDF rendering library is so completely outside the realm of like what the the business is doing probably fine right go build stuff now your employment contract might have some wild stuff in it and they might say I don't know how they ever would enforce this but not for me to figure out um hey anything you're building while working for us like we have rights to it or something like that you'll want to figure that out but so you got to navigate that and if you're not sure, like, go ask. Okay, ask your manager. If someone came to me at work and said, "Hey, I'm doing this. Like, is there an issue?" I actually don't know a definitive answer. Like, if I can sign off, I can give them a what I feel like is a pretty good guess. Like, unless you're building routing technology, um, you're probably okay. Um, but if I needed to, I would have to probably go ask someone in HR and get that figured out. Um, and I would expect any manager that doesn't have sort of the authority or the the exact answer to go follow up on that. Ryan's also adding and overlapping as in what you're coding building in your job overlaps or conflicts with software you you are wanting to build outside of or conflict of interest kind of thing. Yeah. Okay. So, I think I'm answering um what Ryan's kind of after this. So, I think if you don't know like ask, right? There should be some I mean there's a million different examples we could go come up together with as a group, right? Like if I were at Microsoft building Microsoft Word and I was like, I want to go build a video game for I don't know the Switch, Nintendo Switch, like it it's probably not remotely close to overlapping, right? And I think if you're getting in the territory where you're like, I don't know. Um, like even the example that Devon gave, I don't know what he built and I would say like, you know, I think Devon has pretty good judgment, but if he was concerned and was like, I don't know if this is too close, then he should ask, right? Devon Devon knows that. Um, and really, like, I think once you get an answer like that, you kind of have to respect it. um unless you want to potentially risk what that looks like with your workplace. Um I think that there's subcategories of stuff. So the example I was giving with like doing a PDF rendering thing, there might be elements of what you're working on like in the domain that you're working in where you are like hey we need this feature built or we need a library to do whatever. um it might be really interesting to you and it might literally just not be a core business priority and so if it was something you wanted to go build because you're curious I think that's fine. Um again ask for clarity. I think the other thing to look at here too is like um if you were building stuff that was literally completely workrelated. Okay. So, um, in my example, like I work on the routing plane for Microsoft 365. If someone on their own time wanted to go build routing technology and do it on their work computer like after hours on their work computer to to go learn about it and it's not being published and they're not like putting it outside of work, like I mean that's that's fine. I'm not going to encourage someone to go do that because I don't necessarily want them like to me that's too close to work. Uh not from a privacy compliance kind of thing, more like are you going to burn yourself out from just like literally doing more work things or you know work adjacent things. So I would try to balance that out with people. But um Brian, let me know if that answers your question. Um I think it's a really good one and people should be aware of that. Um, Muhammad, I am not ex uh there's a question from Muhammad says, "What language are you explaining about?" I'm not uh currently talking about any specific languages. The question from Ryan, which unfortunately I can't show on the screen because my streaming tools aren't working properly. Um the question was about if you are working on side projects, uh how do you kind of uh avoid conflict of interest with work? Okay. So, my example like um I've had a couple, right? When I joined Microsoft, I was building something called Meal Coach at the time uh outside of work. And so, at some places they'll say like when you're when you're signing your employment agreement, it's like a moonlighting clause kind of thing. And so, they might ask like, "Hey, what are you currently working on?" And that way you you can kind of separate or if someone needs to figure out like how to navigate something from the start then you can um and otherwise like I work on brand ghost now which is completely unrelated to what I do at work or Microsoft products. Um I do obviously I do content creation and stuff like that. So just as an example content creation itself is kind of like a a side project right. So, I need to make sure that if I'm talking about work things, I'm making them very generic, right? Um, what I don't do is I don't go on video and I say like so and like this specific person from my team or my specific colleague uh does this, this, this, and whatever make it awkward. Exceptions are for like sometimes I'll praise people that I've worked with because I think there's a interesting scenario to talk about, but it's not work specific. Like the fact that it's at work is a detail that can be omitted completely. So hope that helps. Um to keep moving along here. Um so we want to start with the why. We want to figure out our own motivation because if basically if you're doing things just because other people tell you like hey like you need to be building stuff outside of worker you need to build web applications you need to go use Rust like you don't need to do anything right like you don't need to now what are your goals figure out your why and then move in that direction okay so the buckets that I've kind categorize. I have like four major buckets that I group things into. First one is like skilling up in an area that you're not really focused on at work. Okay, so you're doing web development at work in the front end and you're not getting an opportunity to work in backend stuff or you're not getting an opportunity to do mobile development because you're curious about that or um you name it, right? You're not getting that opportunity. Okay, like if that's an area that you want to skill up in, whatever your motivation is, then go build stuff outside of work to do that, right? You can kind of create your own learning and experience from doing that. So, that's bucket number one. Um, bucket number two, I would say, is uh especially common with more junior developers, and it's because people like me and others will push this a lot, but that's like resume and portfolio experience. So, this may resonate with some of you that are uh watching live or watching the recording, but if you are new to the industry, you're trying to break into the industry. If um if you do not have, you know, professional work experience, if you don't have that and you're trying, you're like, "Okay, well, I have to compete with these other people applying for the same jobs and they they do have some work experience." One thing you can do is create your own experience. And it's, you know, it's not the exact same as professional working experience, but you can go work on projects outside of work to go create that experience for yourself, right? You've never worked in C and you've never used Postgress and you've never seen ASP.NET Core, okay? Like if you want to be able to showcase that on a resume because you don't have the professional experience for it, build things with it, practice it, learn it, right? then you can start building a portfolio and kind of your goal here is to to enhance your resume for things to show. Hey Baron Bites, good to see you back. Welcome. Welcome. Appreciate you being here. The third bucket um this I think sometimes happens for you know for new developers um maybe for I don't want to call it the wrong motivation but um but it's like entrepreneurship right so I think sometimes people are like maybe they are entrepreneurial and then they go I want to go build something I think we're seeing a lot more of this with AI where it's like you know I don't work in the developer space but I would really love to see this app idea come to life, whatever that is. So, they find themselves kind of moving in that direction. You might have um folks that are uh more senior, right? They've been building stuff for a long time and maybe they started off with some of these hobby projects. Maybe it was uh to enhance their resume at one point or something they were just curious about and then it ends up turning into like, hey, may maybe I can maybe I can monetize this. Maybe there's a business here. So that might be another reason that people go in this direction. And the fourth bucket I have um is really around um I don't know I don't know I don't have stats on this to know but like you do it for fun. And so it's kind of interesting because I think that uh if I reflect on my own experience, I think I got a little bit lucky that some of this for me fell into the the fourth category like building stuff for fun. Um you know, like pretty I'm a pretty nerdy introverted guy and I can remember being younger and being like I like writing code. Like it's just fun. and I feel like I'm building Lego with, you know, like bricks of any shape and unlimited count of them. So, I really just enjoy doing it. And then over time, what's really cool about that fourth bucket of just building stuff for fun is that you go, "Wait a second." Like, you know, I'm been building this and like maybe I need to enhance my resume. this could be a cool portfolio project or I'm building thing X for fun and like hm you know what I haven't had an opportunity to go learn about mobile development maybe there's this this thing related that I can go build and you kind of can touch the other buckets that I was talking about and it feels easier and it feels easier because you're just doing it for fun in the first place sometimes your for fun ideas can turn into businesses as well um Baron Bites do you still do resume reviews. Yes. Um I do I have not been keeping up. I think I have a couple that have been sent in and I have to do them. Um so yeah, send it in. Go. Uh what's the what's the YouTube channel? Path to Tech. Let me just link it in here. Sorry, you can't see Baron Bites is asking, "Do you still do resume reviews? I started a backend internship last week. By the way, congrats. like to volunteer as tribute towards uh as tribute towards April. Cool. It's um it's this I think that should go to YouTube, but it's dev leader path to tech. If you go there in one of the videos, um I explain how to submit it. If you watch like 60 seconds of the video, you'll see. So, um check it out and send it in there and I will try to get to it. I've just been definitely been slacking on the resume review videos because I've been doing other stuff. So, please do submit. I will try my best to get to it. Okay. So, we went over a handful of like different reasons or motivators why people might want to consider building stuff outside of work. And um again, I'm not my goal with it is not to tell you like therefore go do it. You have to. um not for me to decide. If that aligns with you, then by all means investigate. But um the other thing I wanted to talk about regarding this is like I call it I didn't like coin the term but like activation energy and I think people can see this with different types of tasks. Okay. So again, it's not unique to software engineering, but we're talking about like doing extra stuff. And like when you have to do extra stuff, if you're not in that fourth bucket where it's for fun, like if you're like me, extra stuff is like, "Oh, I don't really want to do that." And you'll procrastinate, you'll put it off. And I think that this is especially challenging for folks that um they're trying, like they they know that they want more experience. uh when they're applying to jobs. Uh maybe someone who's been laid off who's like, I need to skill up. Maybe if you like in the layoff scenario, it might it might be a little bit easier because there's a forcing function versus um you know, maybe someone who's interested in switching jobs, but they're currently employed. It's like if there's a little bit more like comfort, it's harder to like make yourself go do something, I find at least. So, I'm going to talk about activation energy here. And not only is there like activation energy to just get yourself started, right? That's the whole idea of activation energy is how much effort is going to go in so that you can even begin, right? So this is this is a thing. If you're like me, you procrastinate a lot and then finally like you get the activation energy. It happens and you're like kind of think to yourself like why didn't I start this sooner? Like it's really not that bad once you're going. But I think when we talk about um like maintaining that activation energy, you've activated, right? You've started the project. How do you keep it going? And there's a a pattern that I um that I've noticed like in my own learning or when I talk to some other people and it's that if you understand like the you know sort of basic idea behind this activation energy idea where you you'll procrastinate and like you just want to kind of get yourself started and then it makes it easier. If you understand that and you you've experienced that, the other thing we don't want to have happen is that we get overwhelmed because then what happens is you've kind of hit this wall after sustaining that activation energy. Now you hit this wall and you're like okay like for me to go progress in any one of these directions like now you feel this activation energy again like you get stuck and you're like I don't know like I can't move left because uh I don't understand this about Postgress and like it's really frustrating and like I can't go straight ahead because like there's this weird C thing that I don't really understand and I can't turn to the right because like I you know I'm deploying to Azure and like I really don't get Azure and then I can't like go down like I'm just picking random directions, right? But you keep getting stuck in every direction and then it's suddenly like it just feels overwhelming. So you're like well this project's kind of kind of screwed then I can't make any progress. Now, for some people, you can kind of push through and you end up making progress in one of those things and then kind of unblock yourself and keep going. But my point here is that if you want to try and minimize that, my recommendation to you is to not try and do everything completely new all the time for your side projects. Okay? So if you're someone who is very junior, it's likely that any side project you do is going to have a bunch of new things. So like it's true, you're going to feel that activation energy like probably more than other groups of people because like everything's kind of new. It's just more effort for you to kind of to do things and that's okay, right? So I I get it. I hear you. Um, if you can, that's why doing smaller projects are are handy to kind of build some momentum. If you are someone that is more senior and you're like, well, I want to learn I'm just going to make something up, right? Like, I want to go learn uh Postgress. Okay. Well, if you know Java and and you know uh I don't know like Microsoft SQL Server and you want to go learn Postgress, what I wouldn't recommend is you go okay well I'll do a new app and like I'll pick Postgress because that's the thing I want to learn about and then I'm going to go pick I don't know I don't know Rust yet either. So like I might as well like pick up Rust at the same time and then like I've never deployed to AWS just Azure. So, let me go deploy this to AWS and then hm like and then you start adding in all these things that you've just never done. It might seem like on the surface like hey look I'm going to learn all these things at once and I don't know you might be the kind of person that can certainly not. And it's for this reason I just explained which is when you get stuck on any of these paths, it's like you don't have any momentum to kind of carry you through. Okay. So my recommendation is that you try to uh fix as many variables as possible and then have only one or two kind of new things that you're going to try to learn about. That way you can keep the momentum because like for me if I wanted to go learn Postgress in this example I'm making up. If I wanted to learn about Postgress I'm like I know C very well like I should probably keep C in the mix and then build something in C that connects to Postgress and then maybe it's still ASP.NET Core because I know that pretty well. Um, but maybe I could do like I don't know as much with Blazer and that's close to ASP.NET Core like obviously tons of overlap there. So maybe I could do C, Blazer and Postgress, right? But I'm not going to go completely off the rails and pick all new variables for it because it's going to be a pain in the butt. That's been my experience. That's what I would recommend to people is fix as many variables as possible. The other thing that I want to mention around activation energy is like we did a stream I feel like it's probably like a year ago now. Um I've definitely talked about this before. Um but it's it's worth rementioning. I think that if you can find projects, if you have convinced yourself, okay, I'm going to go, you know, spend some time building stuff outside of work. If you can find stuff that you're genuinely interested in, I think it makes things so much easier. Okay? And for those of you that like can remember like, you know, if you if you depending on your age and stuff, if you've gone to high school, if you went to college or university or whatever, can you remember taking courses or having classes where there were projects and you were like, "This project sucks. Like I have no interest in whatever this is. Like it could have been for me it could have been something you know using C which I like but I'm like this project is stupid. I don't like it. I'm not interested. For me that would really cause me to again procrastinate. I'm not going to be engaged with it. If I encounter a problem while doing it, instead of being like interested and excited to go solve the problem, I'm like, "No, I'm frustrated." Like, I don't I don't want to be doing this. Again, I'm things I'm talking about here might be a lot of like kind of me problems, but I think that other people go through this kind of stuff because I have talked to people where this has resonated. So, um, finding ways to align your projects with your interests are very helpful. So for me, this worked really well early on because I like vid I still love video games, but playing video games as a kid and then being like, cool, like I can I want to try and make my own video game. So you realize there's a lot going on in video games very quickly, but um it made it fun, right? I was hitting problems all the time. I have no idea what I'm doing when I'm starting out, but it was really fun and exciting. So even when I ran into issues, I wasn't like, well, guess I'll never program again. I hate this. It was like, no, like how how do I find the answer to this? Like this is like sure it's frustrating in the moment, but like I'm excited to find the answer. Um, what's another I was just thinking about something as I was blabbing away there, but um I was filming YouTube videos earlier today and um I was uh filming a video on some of the work that I was doing over the weekend for I have uh this what's a good way to explain this for nonet people? Um I have a dependency injection nougat package. It's a you know a library that you can download and it's nothing special. uh uses reflection to go find plugins in assemblies. I use it. It's just based on patterns that I've been using for a long time. So I made it a package and this weekend um we had a long weekend here in the US. And so this weekend I spent some time with co-pilot and Claude and I said it's time to make this thing go from reflection to source generation. I'm going to do it. And I was thinking about this while I recorded um the YouTube video that like I had some frustrating points on the weekend where like the way some of the AI had like refactored the code and like some of the architecture. I remember being like oh like I don't like that. Um and I'm sitting there looking at the code being like I I don't have a good solution to this. But instead of being like, "Well, screw it." Like, you know, this is a dumb project anyway. Like, AI is dumb and everything's dumb. Instead of like being totally demotivated that way, um, it's a project that I am excited about. I find that kind of stuff super interesting. I wanted to learn about source generators. I wanted to see this kind of thing come together. So, it was really cool um to try and think through these problems instead of it being a big demotivator. So my recommendation is if you're building stuff and you're trying to learn especially try to align it with uh things that you're interested in, you might find it a little bit easier to stick with if there's some external motivators coming in. So for example, if you're, you know, you have a project and it's generating money for you, like you might be able to kind of put up with some a bit more crap because you're like, I got to do this cuz it's making money. That could be a good reason. But you need to find your reasons. Um those are some for me. So, uh I wrote down a couple notes in the newsletter to say like, you know, I gave you an example of games as interest, but like you know, if you're into fitness, like could you make a a calorie counting app or an exercise list app? If you're into cooking, what about like a recipe app or something? It doesn't have to be something that like no one's ever done before. Just build stuff, right? um music like can you do something that's going to go look up artist information or discoraphy or maybe you want to track like where your favorite bands are touring. I don't know like there's a million things that you could go build in in these categories but try to align them to your interests. I think it'll help. Um Baron Bites says at what scale do you think optimizing SQL queries matter? I'm tasked with using Postgress for the first time. Not sure if optimizing would matter for under thousand users advice. Um yeah, I mean like what are the what are the what are the requirements right? I think that's what it comes down to. Um just I'll give you an idea, right? So like if you're tasked for optimizing or sorry you're tasked to work with Postgress and let's say there are a thousand users if these are a thousand paying customers and if you're thinking about um the latency right because the query takes a long time if how that's fitting in to your waterfall of latencies if that means that your query is the thing that's taking you know I'm going to make up numbers it's 4 seconds to run this query and as a result like the user experience in a web app or something is is very bad. Like I would say the number of users doesn't isn't the factor here, right? They're paying users. Like if you had if I had one paying user and it was a really terrible experience, I would probably try to make that better for them. Um if your company I'm just going to give you a different flavor of this. If your company had, I don't know, 10 million users and you're talking about a new prototype thing that like people are baiting and they're not even paying money for it and there's a thousand users and it's a little slow for latency like yeah maybe you don't care but we have to talk about business requirements if we're working at places right so you as an engineer you might go and this varies from person to person right you might say like I really care if if if I haven't spent time optimizing this. Like, personally, I really care. Others might go, I don't care at all. Like, it gets the right data. I don't care how long it takes. And like, those are sort of the wrong um the wrong answers because they're not they're not addressing the the real question, which is like what what does the business need to deliver for the users? Yeah. Deon says measure first, optimize second, or don't. Yeah. Right. So, um, and then, you know, to add more context into Devon's comment, measure first, optimize second or don't. It's like you need to understand, and sorry, Baron, when I say you need to understand, I'm not trying to I hope you understand what I'm saying. It's not to like point at you. Um, this is a very general statement. As developers, we need to understand what the the functional and non-functional requirements are for our product. And if you don't know and no one's told you, it's a really good conversation to have with a team, right? Including a product owner on that because the reality is again the latency for your query. Say the query takes 10 seconds, okay? And like that seems pretty crappy because you're like, "Oh man, I know if we had some some indices on here, we could make it go faster and like we don't even have those." But like, is that a 10-second query on a I don't know, a workflow that takes three hours to run and it's run once? Maybe it doesn't matter, but it's not for me to say, right? That's a that is a question that you should go figure out sort of in terms of the value to the business because it will change. This is why context um there's uh Derk Martin from code opinion. Anytime I'm about to say context is king, like I have to shout him out for it. He does such a good job. For folks, if you're watching my stuff, if you don't know who Derek Co Martin is, please go look up Derek. Um he's like uh his handle is code opinion, but Derek does such a good job explaining why like when people talk in absolutes or like it's always, you know, one way or another, he does such a good job explaining like situationally why it may or may not apply. And it's like you can change the context and it will dramatically change what sort of the air quotes right answer is. So I do really recommend um you know kind of take the context into account. Baron bite says I think I understand what Devon wrote. See if there's a problem measure before spending time refactoring for something only um only optimize if confirmed to be a problem. Exactly. And then you know whether or not it's a problem is going to be based on you know the expectations the requirements of your product or your service or whatever. And that's going to be very contextual. So I think it's a really really good question but like the the way that we answer questions like this ends up being like this is why we joke in software engineering like oh it depends because it does it depends on many things though and it's I don't want to leave it at it depends I want to give you examples and kind of walk through why it depends and what it depends on. So Baron Bites, I hope that helps answer. Um, please feel obviously you know how to use the chat. Keep asking if it's uh if you want more clarity or a different view on it, but and thanks Devin for your comment as well. Okay, so you're thinking about building stuff outside of work and it's not an activation energy problem for you. You're like, I am ready. I got a million ideas. You're over ready, right? You got ideas oozing out of your fingertips. You are ready to go, you know, code it yourself to go learn about, jump into claw code or co-pilot or whatever you want to use cursor. There's other things. You're ready, right? The ideas can't be contained in your fingertips any longer. You have to tell the LLMs what you're trying to build. But where do you start? You got so many ideas which what's going to be the right one? What's going to be the best one for your resume? What's going to be the best business idea? What's going to be the best learning opportunity? You have a million ideas. How do you where do you start? And so my oversimplified answer here is that like you need to just pick one. I don't care if you end up working on multiple, but if you're not starting because you have multiple ideas and you're trying to pick the best, there isn't a best. They're all the best and all the worst, right? Like they're all equal. It's not not necessarily true. Some may or may not be better than others, but what I want you to take away from this is like doing nothing is the worst of the options that you have. So instead of being paralyzed not doing anything, I highly recommend you get started on at least something right. Make sure that it's aligned with some of the goals you were setting. Not again, not because you know Nick said you need something for your resume. You're like, I don't care about my resume. I want to go learn Erlang. Like great, go learn Erlang. That's that's your goal. That's cool. There's nothing wrong with Erlang. Um, if that's your goal, like stick to it. Don't just do it because someone said and then if you're not able to start because you're trying to pick the best option. The more time you spend doing nothing, trying to debate what's the best, the less time you've spent actually building things. So, I've seen this kind of pattern come up so often and that's why I have to talk about it, right? It's like the the most common version of this that I see is that um I feel like and maybe it's in a for a good reason changing over the past year or so. But the most common thing that I see or that I get asked or have been asked in the past is like, "Hey, I'm just getting started. Like, what programming language should I use?" And I've made like LinkedIn posts and stuff on this and like and written blogs and stuff on it. Like there isn't a best, right? You people can make arguments all they want about like this one's the most performant or there's this or there's that. Um yeah, and Baron Bice says paralysis by analysis, right? It's it's all it is. There isn't a best. Programming languages are different tools for different things, right? Like I I personally stick to C a lot these days. Not because I'm like in my head, oh, you know, C is the best language that's ever been created. There is no fault. Everyone should use C and buy my courses because it's just the best. Like, that's not that's not it. I like C, but for a lot of the things I'm doing, it makes sense for me to use C. For example, if I am trying to build brand ghost on the side and it's a business, it makes sense for me to use something that I can build with very effectively. It also happens to be a very good general purpose language. It has enough performance. It has enough community support. It's modern and I can program in it effectively. Seems like a pretty good reason for me to use it. Someone might come along and say, "But you know, Rust, Rust would be the safest because we're saying that now Rust is the safest and it's faster based on these benchmarks for the app you haven't even built yet, but it's faster. So, you should go build your business using Rust. And I would say that's great, but I would actually like to make sure that I can release software and get some paying users because if I need to go learn Rust from scratch and try to build things at the same rate that I'm able to with C, it's not going to fly. But that's the context for some of the goals I have. Many of the goals I have end up working out pretty well to use C. Now, if I wanted to set a goal for myself to go learn a new tech stack or to program on a different platform or as a goal to go learn a different language, then of course that I should go explore something outside of C. Of course. But that has not been a goal for me for most of the time. So your goals will change the different variables that you want to focus on. Devin Devin says, you can't see his message because the chat's not showing unless you're on YouTube, but Devin says, "Is this a bad forum to say that you shouldn't pick what opinionated streamers like to talk about?" No, it's the perfect forum for it. So thank you. I know Devon's joking, but but it's also a true statement, right? Um, it's it's very true. Like you when you're seeing stuff on social media, including people streaming and stuff like that, you get a very like narrow view of what's being represented, right? This is it's not unique to software engineering. It's been a big theme on this stream so far, right? Like this is why I was saying, you know, use I like using fitness examples a lot cuz uh you know, the gym's been a big part of my life, but I think we see it like it's so much more visible on social media, right? It's like most people can think in their head like, well, you know, someone who goes to the gym a lot, I know what they I have a visual in my head of what they look like. It's like you don't because what you have a visual of in your head is like something that social media has been kind of feeding to us over and over and over and it's like you're actually seeing people that are like the top end of the people that go to the gym a lot. It's the same thing with beauty standards and all these other things, right? People's uh standard of living. Like, you know, if you were an average person, you're probably not the person going, "Oh, like, let me show off my lifestyle." It's the people that are at the higher end that are trying to show it off. Like, we get a very skewed view of all of these things from social media. It's just sort of how it is. And that's the same thing when you have people, you know, that are popular on social media talking about programming or software engineering topics. By like most measures, I am not a popular person on the internet for this kind of stuff. Been trying hard to make progress towards that. But um if one day I am a, you know, a very popular YouTuber or content creator, I really want to make sure that I can say, "Hey, there are things that I like. I like C. I happen to like the Microsoft tech stack long before working at Microsoft. has nothing to do with the fact I work at Microsoft actually. And like I don't want people to think that that is the best thing. It's the thing that I happen to like because it solves most of my issues and I'm comfortable with it. Doesn't make it the best, right? So that's something I want to make sure kind of comes through in in all my content. So Devon, I think it's I I very much welcome that. Um, cool. What else we got on here? Um, I think, yeah, it's kind of like a sign off from the article, but like it's just to kind of bring it back to like whatever your goal is that you're setting for building software outside of work, like match what you're doing to that goal. Okay, that's what I want to leave you with on on this part of the of the topic is match what you're doing to your goal because what can happen along the way especially if you're dabbling is like I think a lot of people go oh I want to go I want to monetize this I need to get users right um this is one of the most common things I see for resume projects is like people are saying well this app that I'm building like I don't have paying users and like or I don't have a user base and like that means it's not a good project because employers aren't going to care that I don't have like a thousand monthly active users and I'm like hi like I I I know I'm only one person but as a hiring manager and I've done it for 13 years I have never cared and never cared how many users your app has. I'm not hiring you for your app's users. I don't care. I think it's great for you. I'm very proud of you for getting users. That's awesome. But I do not care in terms of hiring you for that. Excellent for you. If you're proud of that, I want to be proud of you as well. But it's the wrong thing for me. Doesn't it's not a it's not a penalty. I just I just don't care. Right? So, if you're going, "Oh, I need to build a resume portfolio, right? I need the experience for my resume. I want to build a portfolio for this stuff." and then you go, "Oh, I need to go get users." I'm like, "Unless you want to talk through resume experience about how you were doing like um user requirements gathering and going back and forth and like you want to talk about that stuff." I think that's great. You probably need some users. You don't need tons, but that would let you practice that, but like what is your goal, right? The same thing can happen where people are like, "I'm not making money from it." So now you're you're learning opport maybe let's take the resume part out of it. You're like I want to go learn Rust. So you go build a project in Rust and then someone's like yeah but like how are we going to monetize this? And it's like dude you're trying to learn Rust. You don't you don't need to monetize everything you touch. If you can that's I mean power to you. That's amazing. Um but I don't think it's realistic and I think it's a distraction from what your goal is. So my sort of closing note on the building software outside of work thing is like keep your goals in mind. Your goals can shift but be honest about them because if you're doing stuff that is not sort of pushing the direction of your goal like do you need to re-evaluate your goals or do you need to re-evaluate what you're doing? Okay. So overall um what's going on? My chat saying it needs to connect. Am I still here? I hope I'm still here. Um, overall, I think for building stuff outside of work, I'm a really big fan of it. Um, let me switch over to this this screen. I'll put my little There I am. Um, chat still doesn't come back. Yeah, I'm a big fan of building stuff outside of work. I've been doing it. Um, you know, I'm I'm biased in the sense that I've always been the kind of person interesting interested in building stuff outside of work, but I realize it's not for everyone. Some people are happy to do their software development at work and they go, "G cool." Like, I'm I'm done my day job and that's it. And there's nothing wrong with that. I just happen to also like it outside of work, too. Uh, I love building stuff. So, um, that's mostly it for the stream today, folks. I'm recovering from a a flu and I think I'm almost in the clear. My nose is still not great. Um, but this is the newsletter article. So, it's at weekly.devleer.ca. I'm just going to put it into the chat again. Substack folks, you're already there. So, I'm just sharing the newsletter article for folks that want to see it. I mentioned at the beginning of the stream that the live streams are generally based on the newsletter articles, unless folks have different requests they want me to write about uh or do live streams about and I, you know, we'll separate them, that's fine. But you don't need to subscribe to it. If you like the live stream, you like the format, you like hanging out here asking questions and or answering people's questions, check out the newsletter so you can see it's it's if you go to the site, it's like a blog post, right? So, you can just read it there and see what the topic is. Um, otherwise, let's go through some stuff. I'm just going to refresh a couple of these. I got some other tabs to pull over. I just got to refresh them all. Cool. Give me one sec here. You can tell I'm not a pro streamer. Okay, cool. Let's pull this back. So, um, this is my main YouTube channel, Dev Leader. Um, I think most folks that know me probably know me either from my YouTube channel or from LinkedIn. Uh, but Dev Leader has uh C programming tutorials, a lot of .NET stuff. And then I am trying to layer in a bunch of, you know, building with AI so you can see how I'm, you know, writing software. So if there's AI related tutorials that you would like to see, please feel free to ask. I'm trying to do a better job this year playing with more tools. So um, this weekend, um, I was using Claude Code. I've used Claude Code before. Actually, one of my most popular videos on YouTube is using, uh, Claude Code. Um, and so I was using cloud code and then I my limits ran out and I was already kind of in this flow of like building in the command line in the terminal. So I got the co-pilot command line and so that was my first experience this weekend with the co-pilot command line. And if I'm very transparent with you, the very beginning I was like this is terrible. And then I realized it's the models. I was picking models that were just not delivering. Um, once I got past like these GPT codeex models and just went back to Opus, I think GPT 5.1 usually works pretty well for me, but with Opus uh 4.5, I was uh back to flying. Um, and so yeah, I'll I'll publish those videos when my editor gets them done. Um, but made uh made a lot of good progress uh this past weekend and got to learn about Co-Pilot CLI. I really liked using it. Um feel like the out of the box the features are less than Claude in terms of extensibility. I'm not actually sure. I think obviously Claude has a lot of momentum behind it, but um I'm not really like a terminal kind of developer at all, but it was really handy for going back and forth kind of in like a pseudo planning mode. But that video or that there's three videos, they'll come out on this channel. Uh Dev Leader, I have another one, Dev Leader Path to Tech. So Baron Bites is asking about ré reviews. Devleer path to tech is where I do my resume reviews. I have to catch up on some of them. Um, yeah, this past week was not good for recording anything because uh I had the flu. And then Dev leader podcast is where some of you are watching this from. I split my podcast out from my main channel to help the algorithm. Um, I don't know how long that's been now. Um, I would say the result has been uh absolutely no difference. So, lots of extra work for uh zero benefit. But hey, that's social media for you. Um, so I interview other software engineers on this channel and then the live stream and then code commute. I have a lot of fun on code commute. Um, code commute. Put that in the chat as well. Sorry Substack folks. This is why I said until Substack fixes their live streaming on the browser, I can't do anything. Um, so if you want a better experience until they fix it, head over to YouTube and you can see the stream. Uh, but code commute, I know there's a bunch of people that come over uh to the live stream from code commute and I appreciate you being here. Code commute topics generally are what I write about um in the newsletter. So the live streams as a side effect end up becoming topics that come from code commute. So, um, you can see this one here. How and why to code more outside of your day job. This was a submitted question, I think, and, um, came the newsletter. Oh, it's a live stream. And I think before last week, we did Fang interview reality check. Um, so we walk through what big tech interviews look like. And that's it, folks. The last thing I have to show off is, of course, brand ghost, which is what I build outside of work. This is my outside of work coding project. This is the one I've been working on for few years now as I build out all of my social media. Um we had a pretty cool announcement at the beginning of the week. Um we partnered with Monty Mater who is a um social media influencer and so we are doing um with her social media team. They're using brand go. So, we'll be uh partnering with them, getting their feedback, enabling them to to post all of our social media content, which is super cool for us. We're super excited. Uh I even got to sneak my own face on here. We got John Vanir. Uh he's also a tech creator. You'll see him on LinkedIn and uh he's a big on Tik Tok, posts a lot on LinkedIn. He's posts a lot on a lot of platforms because brand goes. Um so, John's pretty awesome. And then, uh Teeoken. Um he's an awesome guy as well. Uh he is I don't know he started content creation not too long ago and like really the it's been awesome to see him grow because uh I think he's someone who took it to heart where we were like hey like you just got to be consistent man just like it doesn't happen overnight unless you have some weird viral Tik Tok and you're like the I don't know overnight social media sensation like it doesn't happen to people though. So, keep showing up, keep making content. Teemo's done an awesome job of that. Uh, so we got a few people highlighted at the top. But yeah, Brandos is what I build. It's in C, of course. Um, so the whole back end is innet. We have a TypeScript front end, which is why I don't touch the front end because it's not C. Just kidding. Um, runs in Azure. Yeah, it's a lot of fun. and I have um you know I work with co-pilot to build a lot of features. It's really helping me um get stuff done. So um yeah, this is what I build. It is um we've changed up our pricing and tiers and stuff. It's still free to use. Um so it's like a instead of having a timelimited trial, we just made it like a permanent trial. It's just you have a limited number of feature uses every month. Uh, but it's free, so you can just check it out if you want to post stuff on social media. Because one of the questions I had over the past week was, "Hey, if I work in tech and I want to start posting stuff online, do you have any advice?" They mentioned that they were considering doing it as a side hustle. So, I tried to share some perspective on that. That'll be on code commute because that's where it was asked. And then, of course, I mentioned brand ghost as part of that. So, thank you so much for being here, folks. Um, I got to schedule all my code commute videos for the week. I got a full week coming up. And then I'll get my videos for Dev Leader sent over to the editor and should be a good one. So, I hope to see you all next Monday, 700 p.m. Pacific, same time, same place. And we finish right on time. Look at that. It's crazy. Okay, folks. See you later. Have an awesome week.