Actionable Code Review Culture Tips - Principal Software Engineering Manager AMA

of course I can't see this stuff okay cool LinkedIn is live and just got to go live on Instagram and we should be set okay if you're joining let me know in the chat so I know that I can see the messages coming through that would be super helpful thank you so much this is going to be a talk on code riew and we're not going to go through code reviews and poll requests we're going to talk about code reviews poll requests and sort of that culture that you can have on your team for these things so I did write a newsletter article on this I will put that in the chat if you are on a platform where that chat is not coming through I'm going to try it on Instagram I have no idea if that's going to work um but if you're on a platform where that chat is not coming through it is at weekly. deev leer.com that's where you can find my newsletter I'm not telling you to sign up for it but if you want to stay in touch with what a lot of these live streams are about for Monday nights here in Seattle then that's what they're about but like all live streams I do highly encourage you to uh participate um please ask questions as I go along I don't care if it's unrelated uh I would much rather you know pause what I'm doing to answer questions that you have because that's why I'm live uh if it's just me reciting things and I could go make a YouTube video about that and I would much rather get a better use of your time so please do ask in the chat I will be watching uh across the different platforms they're across all my screens right now um if you've seen pictures of my setup then you know that I have a lot of screens to watch as I'm talking to all of you so um with that said you know ask questions I will leave some time at the end as well so usually these streams are about an hour and I will try to make sure that leave time at the end and that way uh you know if you were kind of waiting for an opportunity cuz you didn't want to jump in and you know ask something unrelated then you can jump in at the end so hopefully that sounds cool like I said let me know uh I'm going to refresh my chat because I don't see it's saying that only some of them are coming through and I don't trust that okay now it's saying all six of six and let me get my chat turned on so you guys can see what's coming through too in case people start getting noisy okay so to start things off poll requests code reviews well what are those why do we do them right so this is something that is not necessarily enforced at all companies but um most companies have some type of you know pull request or code review process in place and the idea in general is that you are getting more eyes on the code that you're putting out there so that people can make sure that it is uh safe to commit that it is following architectural patterns that you've put tests in place all sorts of things right and that's what's kind of cool because depending on the team your organization there are different things that you value and different reasons why you might be doing code uh code reviews and po pull requests that's going to be I just realize how the confusing that's going to be to keep saying that I'm going to probably say code requests and pull reviews um get ready for it because I can already feel it's going to happen so yeah we we do these for a lot of different reasons I listed some of them but it's one way that we can get some of that feedback right it's not the only way but it's one way and generally how these things are set up are that um you are making changes in your local environment as a software developer and then you can commit those changes so most commonly people are using get these days for Source control there are other source control tools um I I don't know anyone today that's using anything other than git I feel like it's kind of one out in the source control race if that was ever a thing um so yeah most people are using git so you would make a commit locally and then you would push that up and this is where things get very different right so um if you have no um code review process in place and no gating system there you might just be able to push to a destination uh so a remote branch the code lands voila right if you have a build system it might kick off but generally what we try to do is have a gaing uh pull request or code review system so that when that code goes up then you can add people to go review that on some platform and there are lots of different platforms I'm not going to go into the details of those especially because if you're watching this you're probably working as a software developer and you know what the heck I'm talking about I like to overe explain things because this is recorded there will be other people that join and they might not know so try to explain filezilla baby the OG yeah um that's right um some people did things before Source control and a lot of us especially early on when we're developing software right like um you know you might have found yourself writing code before you knew how to use G or like I started with subversion and we were making copies of our code folder right like here's a snapshot like it's working like don't touch that one I'm going to go copy it over here and start messing it up and then when that works that becomes my good copy but we have Source control for that now fortunately um so filezilla you can you can do it I'm I'm proud of you if you moved on from it though so yeah we we do have these uh code review tools and like I said there's many of them that exist and then these allow us generally to collaborate and look at code together um some are more fancy than others for sure um but the idea is that you can have your peers join in look at your code and give you feedback so probably doesn't sound very surprising to a lot of you you're going yep I know been doing that good stuff um there are situations where you may not have gating code reviews um and just checking chat here we know Tech uh we now technically call that the last known good that's right so if you're taking snapshots of your code folder that's the last known good so there are situations where uh code reviews and poll requests are not necessarily gating and that might just be because in the you know the team setup you have um you don't have that kind of stuff configured yet I would say it's probably easy enough these days where most people you know even at small startups and stuff it's something you do early on but I've definitely scene where that's not the case um and I will come back to this later because I want to go through a lot of these different ideas about like code review culture and revisit this idea and I want to seat it early because for people that are joining or you might be watching this I want you to stick around and kind of think about what this might mean but what would it mean to be in a situation where you don't need code reviews and pull requests sounds sounds maybe kind of crazy right um how could we possibly do that wouldn't that be defying all things but remember what I said the very very beginning of this sorry if you just joined but I did say at the beginning that these tools enable a bunch of things for us but they're only one such tool that enables those things so keep that in mind maybe have a a a think through that as we go along here okay let's talk about code review culture so the reason I wanted to write about this is because I've worked in both uh startups and in big Tech now at Microsoft worked at a couple of different teams at Microsoft certainly not someone who's been at Microsoft for 20 plus years and seen like you know a lot of the evolution of Microsoft so from Microsoft perspective I'm still very very new to Microsoft so uh when I do talk about Microsoft I don't want to make it sound like I'm trying to to claim like I know all of how all the different teams operate and things like that I'm just going to share some insights from from my experiences and uh similarly I I've worked at startups but I can't obviously speak on behalf of all startups so I do want you to keep that in mind as I talk there will be a lot of generalizations I will try to call those out but I need you to know that uh my goal is not to to overly generalize and then have you think like this is the way that it must be right um for everything it's just not the case just doing a double check my audio is coming through on Tik Tok talk I did one of these live streams and Tik Tok was like Hey it looks like there's no activity we're going to shut you down I was like what the heck's going on and then I realized my my audio wasn't turned on for Tik Tok so that must have been probably uh one of the worst streams ever um but that's okay so code review culture why do we do it talked about a few reasons but code review culture can have a really big effect on the productivity of a team and when I think about startups and big Tech there's again generalization here but there's usually this situation where I feel like at uh startups we're I don't want to say we're rushing but like we're we're moving generally at a faster Pace right the we're moving at a faster Pace shipping code faster we're creating bugs faster like there's a lot more rapid iteration generally and that will mean that maybe how we approach doing code reviews and poll requests those that those systems those processes for us might look different and my experience at Microsoft has been that um it's slower uh arguably more methodical if I can say that uh maybe it's not maybe it's just slower because things are moving slower in general um you know how we might deploy changes and how how things are moving is slower on purpose because it's more cautious a bunch of different things going on there but I would say that these things look different now you could be at a small company as well and maybe these things are moving slower so I like I said I wanted to put this together to talk about some different aspects about pull requests code reviews to get you thinking like hey I'm working on a team right now maybe parts of your development life cycle are going well maybe some other parts aren't and that's okay right if you are able to kind of identify what challenges you're facing like hey I'm just going to give you an example hey I'm putting up code and find like I can make it through my code changes pretty quick but um it takes me like a week to get feedback to get things through or two weeks and you're like trying to do other work at the same time and the context switching is really heavy so we'll talk through some of that maybe you're finding like I'm getting uh code reviews and poll requests from everyone um you know the last team I was on even as a manager I was because of how our our owner ship was set up in different repositories like I would get added to tons of poll requests just by default right like the team would get added so like that became noise for me so I would ignore those until someone said hey Nick could you please look at it right so that became the culture that became the norm these are things that you can think about as we go through this and say hey if I like that how do I encourage it and if I don't like it can I explain why I don't like it and maybe propose an alternative that's ultimately the goal here here just to get you thinking through some stuff okay so this was a shorter newsletter for me um we finally had some nice weather here in Seattle I feel like I I've been saying like oh like finally Summer's here and I'm like wait a second it's like almost the end of June like are are we about to miss summer going to get one weekend or something and it's nice finally not raining but it was a quicker newsletter for me generally go through these things pretty quick um but sorry I said that wrong I don't go through these things pretty quick this one I went through quickly this is what happens when I try to read and talk at the same time so this one I did do a little bit quicker but I I figured I'd get it together as like a list and try to make it more actionable and that way you don't have to listen to my my droning on in in my newsletter you can just say cool give me a list of stuff to think through so the um the things I kind of listed off here um I'm just going to go through some of the benefits again just in case I missed any uh but oh so I wrote down things like sharing knowledge right so doing code reviews even if you're not thinking about the code itself and trying to critique it and look at the design and the architecture and the test cases I'll touch on these in a moment even if you're not doing that there is a benefit that you could be literally just being exposed to more parts of the code base exposed to the changes that are coming through so you're more cognizant of what's going on so there is a benefit to that you can have more Junior p people get pulled on to code reviews for context so they can start to learn about the changes coming through there's a lot of great knowledge sharing that can occur because of this so that is one benefit reminder it's not the only way to get this benefit but that is one benefit um this one I think is probably a little bit more obvious and I mentioned it earlier but like it's like really critiquing the code right so feedback on the patterns the practices the approach that you're taking and something that's nice about this is that and if you're not familiar and maybe you're maybe you're someone who's more Junior kind of coming into industry but a lot of code bases are not they're not great um and it's not because someone sat there and said I'm purposefully going to write terrible code it's because someone said it with best intentions and over time things evolve and the fact that you're still working in a code base that's been around for 5 10 years is like is remarkable that that code has lived on that long so it's there's going to be parts of it that don't look great so what you'll often find is that there are inconsistencies in the patterns right because someone might have said hey this is the new way after we've learned after a couple years we're going to move in that direction and you might be working in an older spot and you might start copying and pasting some of the patterns and on a code riew someone will go hey no like we don't do that way anymore that's that's two patterns ago like you're you're missing it um and you can get feedback on that to say hey you should try this other way out this is the the new established way and you know here's why um a thing that I have really enjoyed uh if you have testing in mind and it it is a bit of a culture thing on a team is that you get exposure to people thinking through test cases looking at what you've put there and being able to say like hey I noticed you added coded tests in this area I'm saying coded test by the way not specifically unit integration functional because it doesn't matter um it's not for me to say there are some of coded tests or they might say hey there are no tests why is that the case right how did you validate this how are you going to make sure that we're covered for regression right all these sorts of things so you have people that can have an extra set of eyes looking for that um I've kind of this one is already kind of included in some of the things I mentioned but basically having situations where you might not be the subject matter in an area sorry subject matter expert I missed a word you might not be the subject matter expert in an and you might be making changes there and the subject matter expert can say hey like by the way like this might be an edge case or something else we have to think about as we're designing this here's why so you can have those people put on to give you more of that insight and um the last thing I wrote in this little list here was that when you have more people on a code review right more of your teammates and stuff um I talk about tech that a lot and I think it's because it's just a natural part of software development and some people are very very much like you know no Tech debt ever like you can't ever have Tech debt we have to do everything to stop it um I just say it's going to happen so uh learn to adapt and live with it and uh prioritize the tech debt that needs to be paid down so one of the things I like to call out is that if you have other people that are looking at the tech de that's coming along right you might be making a conscious decision and saying we are introducing um Tech de here on purpose to be able to accomplish this goal so you have more people having awareness of hey this is the bad pattern but we understand why for this case um you might have people that are saying hey look like you're introducing Tech de here and no one's acknowledged this yet right like you're you're kind of going around the established pattern or you're taking what we might consider a shortcut architecturally like I'm putting my hand up to say hey there's Tech debt here um or you know I perceive that you're about to create some tech debt have thought through this so um all of those things I think are and and there's more right so if you're in the chat and you're like well Nick you didn't say this like please like share I will gladly read it out and we can chat through it but those are a handful of different things that you can get from having PLL requests and code reviews um so Rick here from Twitter so yes get comfortable with how and why to use Tech that great great advice well thank you so much for confirming my bias um no but I I think it's important right um I again like I I don't want to say other people are wrong like I think there's a lot of different ways to write software but at the end of the day when I'm creating software with teams I want to prioritize shipping value to customers because they're the ones who pay the bills that's it and customers people hate hearing this but like customers they don't care about your code they don't care about your infrastructure they don't care about your test cases they literally care that you are solving their problems and that it's a good value for them now the side effects that they will feel from you having crappy code from you having terrible flaky test that never run and give you no confidence from have like all these bad things that you want to address the side effect is that they generally end up getting features slower over time broken features that are lower quality over time but those are the side effects right they will feel those so if you're in a position and you're like why do we never prioritize Tech debt they don't let me write the clean code we just have garbage spaghetti code everywhere and it's really upsetting to you because no one's prioritizing it I think you just need to change your messaging and work on communicating and I realize that I'm oversimplifying that I talk about this a lot by the way so I'm not going to I'm not going to stay my soap box here for too long going go going off the rails on it but I genuinely think that most of the time this comes down to a communication problem between Engineers who are very passionate about having cleaner code that's easier to navigate more testable all of these good characteristics we have a gap between those individuals and the people that are working on prioritizing things for the users now it takes communication from both sides so even if you are doing an excellent job communicating that as an engineer the person who might be call them your product owner just for generalization here they might not be they might not be understanding it right so you might have to do a uh an alternative I don't want to say a better way to communicate but like an alternative way to communicate so they can understand and the flip side right you might be the engineer who's not doing a good job communicating it I have been on both sides of this I before Microsoft I was a software engineer and an engineering manager for years in parallel so I got to work with my team and live the tech debt the pain and also be on the side of like the product owner like working with our product manager and kind of having a product owner role and just working with the team to be like you know let's let's make a good business case for this Tech debt or paying down the tech debt right if you're going to introduce it or you're going to clean it up so all important stuff but again pull requests and code reviews I think give you that opportunity to kind of come together together and say like we're acknowledging this as a thing and if we're missing it let's make sure we we are acknowledging it okay so I think code reviews and pull requests have a lot of these awesome benefits but I think depending on your culture when I say your culture I mean like the the culture of your team I don't mean like your individual culture so let me clarify that that's uh that's dangerous um based on your team's culture and how approach PLL requests code reviews that kind of thing I think that they can dramatically improve the productivity of a team or I think that they can have sort of a negative effect and slow a whole team down even if you're offering some of these great benefits that we just talked through I think that based on how you approach these things you might find that your productivity actually drops so as we go through this next little set like different things to think about I don't want to say like I'm not suggesting to you like this is the way to do it I just want to give you a bunch of different things to Think Through um and I I'm gonna answer Andy young here from Twitter hey Nick what's one thing your senior direct reports understood about management um you uh can you clarify that a little bit I'll try to answer but as I'm answering if you want to clarify because you might see that I'm not answering you accurately I'd like to do a good job up here so uh what's one thing your senior direct reports understood about management um so I would say okay so I I think more of my my senior direct reports understand some of the business decisions a little bit better um and it's just because they've been exposed to those types of things a little bit more so for example um I I'm trying to think I'm going to make up I'm going to make up a hypothetical situation but kind of explain why I think that this this pans out um say if we have to Pivot on a project right we've been working on it and some new priorities come up from from leadership or uh at startups it would be a lot less about like leadership uh you know from a corporate structure having different priorities and more about like some urgent customer thing coming up um I found that generally my my more senior direct reports are able to understand why a pivot is beneficial um not always and I think like that's on me as a engineering manager to make sure that I can convey the why accurately I think that's extremely important I was doing a lot of that today actually in my 101s was uh going through some stuff and I'm like Hey we're not changing what we're doing but here's here's a new why we should do it so I think my my more senior Engineers seem to get that a little bit more which is nice um and the more Junior folks it's I feel like it's because it's almost like uh this I don't I don't mean for this to sound insulting or condescending but like lack of exposure to to business right they've been say they're fresh out of uh college or university maybe they're a boot camp grad or this is kind of their first job um they they might not have seen like hey look we need to ship value to customers that's how we get paid as a company like that's how the company makes money they might go we write code and we get a paycheck right they they don't have that connection to like we need to do the thing for the customer so I would say the business value part and uh shifting priorities I think they they seem to get a lot better uh Andy let me know if that is an example that made sense or if you want to hear something else but like I said if uh if that's not a if that's not an answer you kind of looking for the right direction just uh if you add a little bit more context I'm happy to try and pivot my answer there oh it took me over a decade to make that connection yeah um I I'll take a little bit of a a tangent here too just on this note from Andy so I don't know I I've seen Andy on Twitter and stuff so the the face is familiar um but I don't know Andy's background for coding right um one thing that when people are saying like hey like you know I want to go they you know they're uh new software developers hey I want to get into big Tech I'd love to work at Microsoft or you know refer me whatever it happens to be and there's a lot of people that are chasing big Tech which I'm not saying right or wrong see a lot of it of course um like I didn't start in big Tech and to be quite honest that was never I never set out as that for that to be a goal of mine just wasn't really on my mind as like must end up there but I would say without a doubt working at startups absolutely allowed me to make that connection that and's talking about in the chat that I was just talking through about this like we need to ship value to customers and the the I think the best example of that was when I was working uh before Microsoft the company was called magnet forensics and when I joined it was like eight people and we were the underdog digital forensics company and it was like look we're we're in an accelerator Center so we basically had like three offices with the walls knocked down like the sliding uh what do you call them it's like a sliding wall that you can kind of open up um partition that's the word it's a computer science thing too um so we had these partitions open up but there was eight of us in this office and like we didn't have investors and the company did have uh customers so they were profitable they could pay but it was like look like we need to make this work like there we need to make it work and I think extremely early on developing with that company there was this strong like understanding of like it's us and when I say us I mean everyone in the company not just the engineers the sales the marketing team although the engineers were like it's all us like that's how we think um but you know it was it was all of us there we need to make this work so it was like yeah as programmers writing stuff and we're like oh this is gross like we we'd love to do it a different way but we're like take note of it and we'll come back to it if we need to because there might not be a comeback to it if we don't get this shipped and there was in the beginning I'm not like I'm not trying to dance around it there was a ton of these situations in the beginning where we're like like that's definitely cutting corners or like we' go look at the code like from last week and we like oh my God how did we do that so the amount of pack at a crural in the beginning was nuts absolutely nuts and I did a lot of it and I'm sorry but I had to do it and um spoiler alert that company ended up doing very successful they ended up going public um so moral of the story is you can put a ton of tech debt into a product it can still work you can come back and revisit things if they make sense and they're a priority like you got to keep shipping value to customers but I think the startup situation really help with that to reinforce it but that's it not your Tech de anymore yeah I said I'm out of here guys see you later I I started off uh not every single product uh certainly not the original one but most of the code base I had started off the original projects and stuff so by the end of my time there it was kind of I've told people this where it felt like I would start my day and I would just be jumping from Team to team trying to be like they'd be like hey we want to go in this Direction like I know you kind of dabbled in this like what are your thoughts and I would be like Oh no you're about to go touch that part of the code and then would kind of like you know um back them away from the cliff and then would run to the next team and they would tell me a similar story and I'm like oh no um yeah it was kind of like a not not an actual nightmare but like metaphorically it was like this nightmare where I'm like oh no all this code that I created and I'm so sorry uh but yeah no was good times but definitely startups I think can give you some of that Insight okay PO requests code reviews so one thing and this is my first thing that I do actually highly recommend there are always exceptions I don't like saying it's a rule but a very strong guideline I would like to encourage small modular uh commits so the poll request you're going to be dealing with the review you're looking at is small and modular now you might say hey I had to refactor a bunch of code I had to do a big rewrite and there was no way to do it small and modular I would say yeah there's I bet you there was a way I'm not saying it's going to be easy it might have felt very artificial and cumbersome to try and break it up so I get it there's exceptions but it's always doable it's just how much work you want to put into it because there's a trade-off but the reason I like saying small and modular commits is multiple reasons um but from the perspective of a Cod riew it's the sort of like the the tax or the burden that you're going to put on the reviewers to go understand your code right so if you think about if you've been working in industry for a while I am sure you've seen the code reviews that come in and there's 50 files touched 100 files touched and you're like okay you want me to sign off on this and you click through a couple and you're like okay I see the pattern like are you telling me that you're going to go sit there and go through a 100 files to go see you know a typo fixed and like or even worse like that one's actually not bad you go through a 100 files and you're like there is no pattern like you've just touched a 100 files in you know 10,000 different ways like what do you like what do you want from me here so I think when uh your your commits are small and modular they're a lot easier to digest for people and then you can get more meaningful context and comments in your discussions for your code review so that is something I do highly recommend um I would say if you're unable to in the in the situation that you're in like I said there's always exceptions is try to communicate upfront so whether that's a a brief call whether that's a bit of a write up for your your review to give people the context like hey look these are the major patterns I want you to be thinking about this is how I did like approach things and that way people aren't just like trying to figure out what they need to be paying attention to if the the pole request is bigger so couple thoughts there something else I wrote here is early and often can be your friend now this and if you think through these as I'm talking about them you'll you'll maybe have different perspectives where you're like I can see that working well or I can see that being like a a total pain in the butt early and often one I think is one of those double-edged swords where I say early and often because small and modular commits allow you to push more code earlier and do it often because they're smaller now you might say well Nick that's going to give someone on the team like 50 code reviews a day to go review like how are they ever going to do that and then they go yeah like there's there's the tradeoff right these are things you want to talk about with your team but if you had a lot of small modular ones they might take you almost no time at all and you go yeah checks out like I can understand this makes sense you know you have a typo cool like fix it great move on um but the early and often thing I like not only for having the small bite siiz uh pull requests but also the feedback like we talk I know some there's going to be someone watching this I'm going to say the word agile and they're going to lose their mind doesn't work forget agile like we let's talk about feedback loops sorry if I triggered anyone let's talk about feedback loops ideally we have shorter feedback loops so that we can understand if we're on the right track so I would say for code reviews one way to help prevent having an enormous pull request is to get the feedback early right you don't want to have that enormous PLL request and someone goes dude that's not you did the wrong thing and you're like I just spent two weeks writing this code I touched a, files and now you're telling me it's wrong right so doing getting some feedback early uh something I've seen work really well as using drafts so you could have a draft pull request to kind of show the idea making some of the changes in one spots I he like hey here's the idea I'm thinking about it's not just written down you can see some of the code changes and get that feedback and go what do you think about this is this is just looking good because if it's not I'm not going to go waste like two more weeks making the changes um so I'm just Andy I see your question I'm going to read this one from uh from Instagram someone told me PLL requests could be too dirty with too many commits and this is why I'm saying yeah it's definitely a balance so thanks Hector um it's definitely a balance I think you want to think about this with your team because you know if you take it to an extreme and you have you know say you have seven Engineers on a team and everyone's doing 10 requests a day 10 commits a day right like what's going on um now the other thing too um and for I don't have the full context from Hector in this comment but someone told me poll requests could be too dirty with too many commits if it's a single poll request with too many commits in the poll request yeah so I would say like you you you don't want to be just tacking on tons of changes and sometimes it might be an indicator that if you've done tons and tons of revisions on something we might have started in the wrong spot so yeah Hector I know there's might be a couple different ways to approach answering that but um hopefully that kind of helps I I do think that if you have too many changes in one poll request it's overwhelming and if you have too many tiny tiny tiny changes um it can be overwhelming for a team so a balance there um Andy asks are you on an incident manager rotation currently or your ic's on call how are you they handling that yeah so um inant manager at Microsoft is like a special role um and I am not an instant manager so a little bit of context um we do have on call rotations and I say we as in the individuals within Office 365 and I will be referring to that as substrate because substrate is the infrastructure for Office 365 um within substrate there are incident managers incident managers work sort of at a higher level across the teams that are operating on call and they can help with incidents so it's kind of like a cross functional on call uh with with more Authority um so it would be like very uh you know props to the people that are doing it because I can imagine how stressful that would be um I'm the kind of person if I don't feel like an expert in an area like I get a lot of anxiety um I've been kind of open about this before that like putting myself in new situations I'm like oh I don't want to do that um but then people force me into a new situation feels uncomfortable for a bit and I feel great um so yeah maybe someday incident manager for me but not today is not that day um on call so interestingly I switched teams earlier this year I have my first on call rotation coming up on this team uh which I've been on call uh prior to this team like for 3 years I had on call rotations I'm super nervous to do this one because I haven't done it for the team but it's like uh when we talk about impostor syndrome right like I know that I'm capable of doing it I need to remind myself like you know the whole world isn't coming after me if something's wrong like I have a whole team to support me so I have to keep reminding myself that but um yeah there's anxiety leading up to it uh I I find it challenging as a engineering manager because I'm not I'm not in the code I'm not in uh operating with the services like the like the engineers are um you know when I was on deployment prior to the team that I'm on now um in order for engineers to get their changes out on my team they have to deploy them and we were the deployment team too so even going through the process of making changes they're exercising all of our infrastructure and getting more and more familiar with it but I'm not doing that so my my familiarity came with being on call and then working close to the engineers and understanding what's going on so it's a tricky thing for me because it's infrequent and then it's wildly uncomfortable and my team um I think I don't want to say like it's easier for them like as in like it's not they don't have to put in any effort like yeah like they they put in a ton of effort and they do an awesome job um I think that they're able to probably jump into situations with more cont text faster uh than I am because they're closer to that stuff but they the the rotations are periodic um it depends on the team what it looks like but uh we're very fortunate that we work uh cross geography too so we have support with uh other geographies coming online when we're you know um it's in our evening time and stuff like that so it's not so bad yeah and so yeah hope you have good run books and support for team absolutely so we have a lot of documentation and stuff in place that's super helpful it's uh sort of like the backbone of being on call is having a lot of these resources you can go to and um definitely like uh my previous team and this current team the engineers are so awesome that like you're you might feel like even if it's late or something you're like oh no like I'm alone and I have to solve this but there's always people that are willing to help and the fact that we are cross Geo just really helps with that too so um and then I think Harrison on Twitch I'm a current data engineering intern at Tennessee Valley Authority TVA do you have any advice for tips to prepare for Post University life um so with data engineering I can't comment on that specifically but my general advice is like um couple things I guess one is if you're able to during school internships or anything like that um you know if you can continue doing that because I see you're like you said uh data engineering intern currently if you can keep up with internships one of the best things that you can do just having that work experience as you're going along is like I feel like nothing beats that because that's the thing that a lot of people say they're missing when they graduate they're like I don't have any experience and like yeah well you do um I was very fortunate I had uh I went to a an honors uh Co-op program at waterl so I had six internships I had two full years of work experience but that time I graduated and it was super helpful and in fact I probably would not have stayed in University in what I was in if it weren't for the internships because I did not like school um so my advice yeah stick with internships if you can um find ways uh internships or not to be able to practice the things that you would be doing at work so for data engineering like I said I can't comment on that specifically for software Engineers I say build software uh it's not just grind Elite code like go build things now for interviewing grind Elite code because you're probably going to get some stuff like that in your interviews but uh for data engineering I would say like if there are things that you're doing it work like working with different platforms technology like I would say like try doing some of that on the side so you can be practicing and experimenting and just getting familiar because it's all about getting uh use a gym anal ology like getting your reps in right you want to be practicing stuff that's my best recommendation and second to that some might argue like same kind of uh uh same level of importance but I would say Network don't uh don't wait to do it start building your network early it's uh I don't I feel like it's never been easier to network with people you are literally talking to me right now there's people in the chat you could be talking to you can go on LinkedIn and start saying hi to people and engaging with them on their posts it's never been easier so do recommend it let me know if that helps you have other questions I'm happy to try and answer okay um something back on code review culture comments I realized I have more I might go over time so I hope you guys are okay going a little later um comments on code reviews something that is very common and uh I'm sure a bunch of you have seen this before you're on a code riew and someone leaves you a comment and they've done a little write up for you and you're reading through it and you're going okay I think I see what they're saying not totally sure but like let me let me write back and I'll clarify so you write a little a little story back to them and then they read yours and they write you another story and they're going no no no like here's here's what you're missing and then you're going ah no man like you're missing it so you write another one back and now you're probably five six seven comments in and you're starting to get frustrated because Jim on the other team is just not understanding what you're talking about and you're pretty confident you're right but you're also like I know Jim's a smart guy why can't Jim why can't he get this there's a thing that you can do here and it's to stop writing comments written communication I know we're programmers and we write code and that is a form of written communication written communication is absolutely Rous at conveying things that we mean right I would say if you are able to talk in person you're in the same office poke your head around the corner and say hey Jim we should talk about this if you can't hey J send him a message hey Jim you got time for a call like let's chat through these comments you will find almost all of the time Jim is not mean Jim actually mostly understands what you're saying you mostly understand what Jim is saying there's a little bit of discrepancy you talk it through and you go oh why did we spend a full day almost passive aggressively sending each other these novels back and forth and comments just to have a call that took 3 minutes and 42 seconds to realize we're saying literally the same thing so I honestly it comes up so often and I I do recommend that uh you talk about this with your team like what's a good threshold if we're not getting on the same page how do people like to be communicated with outside of you know leaving comments and stuff what's a good way to do this how can we get on the same page faster so it's not that you can't leave comments I just think that when they start going back and forth try to find a different way to communicate uh I can't pronounce your last name so I apologize on YouTube Anthony um hi Nick how do you maintain a consistent code style across a team documentation editor config Visual Studio rules automated in some way during your code reviews yeah so this is a great one um I am not actually I'm I don't want to say I'm not a fan I'm almost like against uh some a lot of stylistic things in code reviews and I'm against it because I feel like it's it's such a dist okay let me back up readability and code is important let me start with that I want to put that I want to put that out so I don't have people coming with pitchforks for me readability and code is important I think having standards is important but I find that as humans who are great at thinking through things critical thinking being creative spending time on a code rview trying to critique wh space is like it's the biggest waste of time ever and you might say well no Nick it's important to have the consistency and I say sure if that if if you value that so much if you value it so much should you be spending your time on it or should you have that in an automated way that literally no one ever has to think about it ever again because if you really value it to Anthony's question here is it automated in some way I would say if you value it like you don't want to spend time on it you make it automatic so no one has to think about it you're never wasting time on it again because that's how much you value it prioritize it right think about how often you're spending uh time in code reviews just going back and fixing indentation or stupid stuff where you're like like there are literally tools that can do this for you um you can write uh we were talking today about writing Roslin rules not even for um like you know indentation and style type things but for patterns so again if you're not from c space and net space um there I'm sure there's other types of static analysis things like this I don't know your your JavaScript and typescript ways but in CP and.net we have Roslin which allows us to to write static analysis rules that look at the expressions in the language and then so you can write static analysis rules that say Hey like don't do these types of things and actually analyze the the language it's been written so um we were talking about hey like this is a potentially dangerous pattern it can have dangerous side effects it shouldn't we shouldn't leave it to someone um to avoid coding it to know all the time we shouldn't leave it to all the reviewers to have to go chase it down all the time why don't we just prevent it from being typed in the first place so I think that's a huge strategy that you can lean into um yeah like the visual studio rules editor config and stuff I would say like when you get into this kind of thing you want to just make sure that you can keep it synchronized between your local Dev environment and the build system because I think these types of tools can be very powerful but when there is a discrepancy between your local Dev environment and your builds especially if your build systems can take more time one thing that gets really problematic is you go hey great it works you push it up it goes to build and it fails and you check an hour later you're busy doing stuff right you go back and you're like what it didn't Why didn't it pass you're like oh it's you know you can't have an extra blank line here like oh my God okay so you go take the extra blank line out commit it again push it up only to find that there's another blank line or some other silly thing later like you want to make sure that they're consistent between your your Dev environments and your build system uh but I think they're super powerful um and what about more General consistency themes on not only syntax like one developer likes functional yeah so um this is kind of a part of your first question right how do you maintain consistent code style across the team so I know like I was talking more about like style in terms of uh like how pretty code looks uh but in terms of patterns and stuff this is a tricky one because I think that like a a strategy that helps is for things to be mostly consistent but the problem is that as patterns need to evolve right we find better ways to do things let's walk through a little exercise you have a code base start it off and I'm not I don't I don't know how many files or how many classes we want to get into here but you start it off you start with these patterns and you start going this these these patterns feel good we like using them okay so you start continuing to develop building up the code base then something happens in the future it might be hey look a new language features available it might be we've updated uh a package that we're using it might be that you found that there's a there's actually a critical flaw and the pattern that you've been leveraging and if people aren't aware of something they can introduce something dangerous so you go okay we have this pattern everywhere and it's been really helpful but we we need to start changing like there is a we've figured out there's a better way to do this now you have a couple of options one is that you press pause you stop delivering code and you say I and the team or maybe just you solo whoever I'm going to go change all these things I have to go through all of the code and change them now if there's not many places and it's quick it's not hard maybe you do that right you bite the bullet you say we're changing this pattern we're going to get it out of there but um that one doesn't scale so well because um I'll give you an example um in substrate if we were changing our testing infrastructure or even we're changing net versions how many projects do you think there are there's more than I ever more than I ever could have dreamed was physically possible so it's not it's like one of those things that at some scale it might work well and at other scales it doesn't so all these things have context so um if you need to have some type of um pattern change generally what I suggest is that people get on the same page as a team right you communicate it out hey this is the pattern here's the new way we're doing it if you have things that you can put in place for static analysis to prevent it great right that's that's extra work but maybe depending on your code base you want to prevent new uh introductions of this pattern you could do that uh you have the option to go change it all like I said it doesn't scale but what I would generally recommend is communication a bit of documentation around it and then you start to introduce this pattern going forward and then you take on the mindset like this is where people will say hey if you're going back make you know touching an area of code make it better than when you left it and I'm on the fence about this one but I would say this might be if you're like touching an area and you have to go overhaul It Anyway introduce the new pattern don't just reuse the old one now if you were fixing the world's tiniest bug and you say oh also we happen to be using this pattern nearby I should I should go change it because I was already in this file that's where I say not so fast if you are going to do that at least make it a separate commit but um it might it might just not be a priority you might literally be introducing risk and you're not even aware of it but I think those are conversations you want to have with your team so I hope that helps I I am the kind of person who I would rather be in a code base with more patterns moving in a direction that we're happy about some people will disagree with that and say it becomes too much of a nightmare to navigate that's fine but I think this is something you want to talk about with your team um I my personal belief is that code is always evolving and it's never going to be perfect so basically continue introducing new patterns if they make sense communicating out as you need to make changes about them and and then if you're like hey it's getting too crazy we have too many patterns so you put your hand up for the tech debt and you say hey we're reaching a point where it's getting very hard to develop could we carve out some time to go clean this up and then we come full circle back to what we talked about with Andy and folks earlier which is schedule that Tech debt make a business case for it and if you can predict before it gets Two Nuts to try and maintain then um you can address it I hope that helps Anthony let me know if that makes sense moving along here um I think another thing that I added was uh understanding of who needs to sign off on poll requests which might sound funny um there are situations I've seen where you know you might put up a poll request and it automatically adds a couple reviewers or maybe you add someone manually or add two people and there might be that implicit expectation that whoever you add they're going to sign off but there are situations where someone's like hey like I know I know so so and so was working in this space and maybe a couple other people it would be really good if they had visibility on this maybe the new intern or the new Junior engineer like it would be really good if they could see this so they could read through it and understand it but maybe in those cases you don't actually care if they sign off on the poll request you're not genuinely looking for their feedback in their input maybe they have it and that's great but maybe you're not trying to block the review on their input because again double-edged sword here you might want to add people for visibility but the tradeoff is that now your gate the gatee keepers you have 10 Gatekeepers is that actually what you want maybe in some cases but probably not in all like you don't need like an army of people that need to sign off on your pull request it's pretty rare that that's a thing that you need so I think um Cod review culture wise having clear expectations about who needs to be reviewing things if you're adding reviewers on just to to check them out um maybe different code review Systems have different roles like maybe there's like a reviewer and just like a spectator or something I don't know um but treat them like that right you might want to say this person's here just for visibility and that way the person who owns the review they're not waiting for or like chasing people down to sign off on things they're just like okay like Jimmy has you know he's just watching this thing for input because he's trying to learn about it but I'm not waiting for him right you might say hey anyone who's on here by default if you're on here even if you're not reviewing like you you can sign off as like a you know approve but needs others uh input like depending on the code riew system there's options like that but my point is that you want to have a clear expectation with your team on this because this can be a huge source of friction where people were say it takes me a week to chase people down and they don't even have input I don't know like do something about it talk to your team about what's happening right like you can work together on this and improve it okay um another one and this one is again an double-edged sword um I wrote try to encourage team members to prioritize getting poll requests reviewed and moved along now pull requests like other things can be something that's disruptive all right you're working on code you're developing software and you get a email notification someone pings you on slack teams Discord whatever you're using not zoom um and they're going hey I'm waiting for my your review you're like oh crap okay and like now context switch right so you lose 20 20 minutes in your context switch for overhead now you got to go do the review and then you know you start getting back into your coding and someone else pings you again right so it's it's a tricky thing to say like prioritize it because I don't mean drop everything you're doing all the time all at once to go review code but I do mean that as a team if you can try to think about like I want to help unblock other people if you have that like as a a cultural belief on the team that's something you value I think that it can help dramat ically speed up Effectiveness and it's because we spend so much time spend so much time having code sitting in review state I got eyelashes in my eye I can't see what's going on but I hope that makes sense right so how do you how do you do a better job of that well you can you can block out time right you might say instead of me getting pinged every you know 5 minutes to jump on reviews and I can't get my work done let me carve out a block of time where I'm not going to code but I'm going to sit down and go through my reviews and I'll make a case for it and that's when I'm going to do them and you can dedicate time to it so you're not contact switching back and forth there's no one right way to do this but this is a thing of balance I I just think it's important that if you if you think pull requests and code reviews are valuable how can you make sure that the context switching effort is low try to prioritize them get them through because that's how you ship value okay what else we got here um I wrote the next thing I wrote was about batching your time okay um I did say this one because this is uh maybe something that comes from more Junior perspective uh you know younger engineers and stuff I said don't just add a buddy that blindly signs off on your poll requests we've all done it don't don't uh don't sit there listening to me going no i' never never wouldn't even think about that you've done it it's okay I've done it you want to get your stuff through you want it you want to ship the value to the customer what's the best way to do it get the person who's going to give you a thumbs up maybe your code review system allows you to approve your own stuff don't I mean don't but like maybe right like it's in our nature that we want to move things along so especially and this why I want to talk about this is that there are situations on teams where sure maybe most of your team is very cooperative and you're happy to work with them and getting stuff up for review but I think many of us have been in teams where there's one or more individuals where you almost dread getting them on a code review and you dread it because you know that as soon as they get onto that Cod rview and they start commenting well first of all you know they're going to comment and you know that once they start commenting that you have more work to do so instead of going down that path you go well Jimmy always leaves tons of comments Jimmy always makes more work for me I'm just gonna add Steve or Sally let me pick Sally so I have a mix of names here so Jimmy sucks Sally's in I'm never putting Jimmy on another review right we avoid the problem and then we go for the goal of trying to get the stuff through quicker and that might feel good but we're avoiding a problem and the problem is that and I almost said Jimmy sucks at communicating but what's a better way to say this it's that we have poor communication with Jimmy it's two ways right so if Jimmy is the person who's always leaving you comments on your review and you're like I just feel like I can't get work done with Jimmy guess what you should have a conversation with Jimmy about how you want to make sure that you can live up to the code riew expectations you can say hey look I notice I get a lot of comments I just want to make sure that I can understand where you're coming from on some of these things right not everyone's that agreeable maybe Jimmy is a jerk in which case maybe it's a good opportunity to bring some visibility about that um hopefully not though I don't like thinking that people are malicious most of the time they're not Tik Tok is trying to shut me down again I don't think so there we go um so I I think that you should try to not avoid people on poll requests i' I'm saying that as someone who has done it before I absolutely know the feeling it sucks because you're like I just want to get my work done and I know Jimmy is going to make another whole week of work for me but instead of avoiding it try to get ahead of it if you know Jimmy's going to have a bunch of stuff for you to go do and fix up why don't you talk to Jimmy sooner about your designs why like why why not get it done sooner get the feedback right like it's easier to said than done I know but I just want you to think about this kind of stuff so that you can stop avoiding it because big surprise um there's always going to be people like that so you can keep trying to run away from them but they're always going to be there so you might as well try to find a way to work with them collaboratively okay next thing as a reviewer make your feedback actionable that doesn't mean that you can't say like hey this is a nitpick or like a small thing like you can do that kind of stuff be clear about it right if something's a nitpick you're like I like I don't not going to block your review on this but by the way like that's actually a compound word so you want to capitalize the second part this like not a big deal sure like you might say nitpick whatever but my point is that when you leave feedback make it actionable doing something like this is if you say this is the wrong pattern leaving a comment that just says test question mark or this won't work period wrong design pattern didn't we talk about this question mark like um that kind of stuff is it's just not helpful and again I don't like to think that people are malicious I don't think that someone's sitting at their desk and being like oh man I can't wait to lay into this guy like you know they put their jerk hat on and they're like oh I hate my whole team like I don't think I don't think people do that it's ridiculous because you're on the same team they want their code base to be good they want to value to customers you all want the same thing so it's not that people are malicious generally but I think that the way people communicate it's not that effective most of the time so if you can be cognizant of this and you're maybe you are that person sorry if you can be cognizant of the feedback that you're giving like what are you hoping to see in terms of changes because if someone has to write a comment back to you to be like like you said patterns wrong and they're like well what should I use like you could have saved that whole step and said hey uh this is one of the patterns that we actually retired a couple years back and we've moved uh over to this one you can actually find a reference to it in this file over here here's why we use it right like here's what's wrong with it or we could improve here's where you go see an example of it here's why great test question mark and then they don't you don't say anything like what you're trying to say is like hey look I would love to to assume that you have validated these changes I would also love to assume that you have some regression coverage somewhere I happen to not see it I happen to not see it so like uh could you walk me through some of the scenarios that you've thought about for testing on this how are we making sure it's validated and how do we have regression coverage like it's a simple thing but kind of lead people in the direction don't just like be a jerk about it you might not notice you're being a jerk but when you're super short with comments and advice and it doesn't feel actionable people people don't know what action to take so again it it's it takes a little bit of training and introspection to realize if you're just being really short in what you're asking for or stating on a review people may not know and then you might get frustrated with them when they go make a change and you're like dude that's still not the right thing like how could you not get it and it's because you're not telling them what you're expecting to see so try to be a little bit more aware of that I think that's very important and that can make a big change okay next thing try not to take things on reviews personally this is probably um the easiest thing to say and the hardest thing to do uh I have talked to people especially I know a couple of exchanges on Twitter where people were saying I don't own the code I have no attachment to it I don't take anything personally and I go that's super cool that's not how it's not what I'm like at all um I very much feel like code is an expression of how I think right I'm taking logic that's up here I like to think there's logic up here somewhere and I'm taking the logic and I'm putting it down into the code and then someone comes along and they're like this is wrong and I'm sitting there going excuse me you're like you're basically just telling me that my brain is wrong like how dare you I'm exaggerating a little bit right but like that's kind of the feeling that we get when people start critiquing our code I think for a lot of people like it's it's very easy for it to feel personal we layer in a couple more things I mentioned earlier that written communication is absolutely terrible it's very it's a poor mechanism for communicating things right I could say the same things with different uh tones you know volume in my voice and I might sound very happy versus very angry you can see my facial expressions as I'm talking to you so you can tell if I'm smiling and I'm talking to you like this versus if I'm like I can't make a mad face I'm going to laugh at myself but if I would if I was looking angry at you and changed the tone of my voice and I was shouting even though I'm saying the same words you go oh this guy's this guy's angry right like we don't get that that a lot of the time in codee reviews and it's very easy to start basically inventing how other people sound when they're talking to you so you might have this experience where you're like someone's basically making me feel like I'm stupid because they're challenging how I think and it sounds like they're angry at me who who does this Jimmy guy think he is and then you start to resent them and then you go to that spot where you're like I'm never adding Jimmy onto the Cod riew again right but you you need to do some work on your part to not take things so personally it's very difficult to do but I've had um I've had a couple people offer a similar suggestion around this and I don't want to butcher it but like they basically said imagine that your best friend so you're not best friends with Jimmy right but imagine in this in this case this example Jimmy was leaving you Cod riew comments you're feeling kind of resentful of Jimmy but imagine it was your best friend Sally and imagine Sally was leaving you those comments would you change your mind about how you feel about the comments it's it's a really interesting exercise right you might go yeah like well Sally wants me to do good things like Sally means well so you start to look at the comments in a different context so I think it's a really helpful exercise try to practice it because I know if you're watching this I can guar guarantee if you put up a code review before you have had someone that's reviewed it and you're like I wish they didn't cuz they made you feel not good but try to imagine your best friend is the one giving you the feedback and see how that changes things okay the last one I'm going to mention here and then we're going to go back to the thing I said at the beginning because I hope you were thinking about it if you joined late in the Stream shame on you first of all no I'm just kidding um but I mentioned earlier in the Stream what does it look like or why like what what's the world that we would live in where maybe pull requests and code reviews don't make sense so we're going to wrap up with that one so last part here try to communicate goals and expectations around timelines for poll requests this goes back to something I was saying earlier about delivering value to customers right if we are spending a tremendous amount of time on a code review where the impact of that thing actually has a time sensitive or time critical aspect to it are you like are should you be debating about the white space and delaying delivering the feature that the customer needs Yesterday by another two weeks because the white space is off little bit of an exaggeration right but like is is that a valuable use of time I think it's really important to have context about what you're delivering because you know time is a constraint that exists in real life and I think sometimes when we're developing software we like to think that it doesn't because if we don't have a time constraint we can go make things perfect another spoiler alert no such thing so uh we we use up a lot of time trying to make things the best that they can be but there is a point of diminishing returns so I think being able to communicate in some capacity some expectation around when this needs to go out right for us in substrate we are always we follow safe deployment practices right so things will roll out purposefully not at light speed we purposefully roll the mode at a slower speed that we feel comfortable with we have flighting tools on top of those roll outs as well so that even though binaries are being delivered we can turn off off and on features so we have all of these things and you might be in a position where you're like I need to have my change saturated out across the world by a deadline like that's the goal that we've set and I know that I have these mechanisms to turn things off and on like like basically what I'm getting at is like you should have a conversation about what your plan is for this going further and make sure that people understand because every little bit helps there it might save you some frustration of people not reviewing their stuff because they think that your change doesn't have to be out for another two weeks anyway so who cares they don't know that the VP was talking to your manager and they said if this thing doesn't go out yesterday you know there's fire under your butt you better move faster like that kind of thing like if you can have conversations you can save a lot of frustration so it's a simple piece of advice okay now before I have to do this because I don't do a good job of it so I apologize and advance but before I go back to the question that I had at the very beginning of this about what is a world without PO requests and code reviews I do need to mention that I have courses available that's my my opportunity to sell you things no I just want to mention them briefly I'm not even going to switch my screen to show you them but I have courses on dome training if you want to learn about C I have one that takes you from no experience at all it's about 5 hours long gets you to the the very basics of basically no programming to working in C and then a follow up on that that's 6 and a half hours and that gets you to building basic applications hopefully with a bit of confidence so together there's a bundle it's 11 and 1 half hours long it's a 20% discount to get them together so that's a dome train and maybe I will just put that in the chat so you can check it out if you're interested there is a refactoring course that's available so if you are building stuff oh awesome so rambling rambling geek on Twitch is saying I found you on YouTube twitch from Dome train perfect that's what we're talking about um there's a refactoring course if you want to learn about refactoring so that's a bunch of my experiences from startup world that I mentioned earlier on the stream about how to navigate code bases and try to clean them up because again spoiler alert code that lives for a long time is probably going to look pretty messy by the end of it and I wanted to announce that I am working on my fourth course for Dome train I have another one uh planned basically immediately after that so hopefully I'll have five of them out in total by the end of this year and another surprise course that I'll be working on I can't reveal anything on that but if you're interested if you like my courses my style of teaching please do follow along because I'll be talking about that be talking about them it's hard to say uh as they get announced and then the last thing I wanted to mention before I go back to the refact or my goodness before I go back to the code riew question of the evening is that if you are interested in creating content because I've been doing this now consistently for about 18 months uh thank you for all of you that have been following along and kind of seeing my journey still very early in the journey um I have a a Content strategy I guess that I've kind of I don't want to say I invented it because that wouldn't be fair to say but a Content strategy that I follow and I decided I'm going to put my energy into making that something that is useful for others so I created something called brand ghost it's not yet launch but one sec I will put that in the chat as well if you want to see it I did see the question about WPF as well so I will answer that in just a moment so brand ghost I will put in the chat if you are in interested in creating content if you like how I've been approaching it uh this is the strategy that I use so you can check that out in the chat the goal the entire goal of that platform is that you can either scale up your content creation to allow you to create more or you can do the opposite you can put yourself into a situation where you've created content and you can take a step back and not feel like you're perpetually trying to create more content I've seen both sides of this as a Creator where you're like I need to do more I don't have time this uh I basically literally follow this exact content strategy but I'm building an application for it and people have said to me how do you produce so much content and I basically in the back of my mind I've been thinking if I wasn't putting this content strategy together I'd be making even more content but I have to go build this thing at the same time on top of my 9 to5 job so um the goal of that is just to help you get more steady with creating content and then once you are very steady with it uh I will be taking a vacation this week coming up so Friday Saturday Sunday and Monday not going to be not going to be around and I will still have content going out because I put in the work ahead of time over the past 18 months to make sure that I can take vacation so that's what brand ghost will help with I'm hoping that it will help other people that want to start off with their creation for content and uh yeah hopefully hopefully you find that interesting are you going to be continuing WPF application work yes I will be actually I should mention this too I'm going to be I'm going to try to live stream uh tomorrow morning um I guess based on uh rambling geek based on the fact that you said good morning it's probably the evening for you when I go to stream I'm going to try to stream oh it's going to be early um I I can't promise I want to be online it's 7 a.m. PST tomorrow so that will be Tuesday for me 7: a.m. um fingers crossed I'm going to be going through some WPF stuff I want to get some some videos recorded sent out to my editor so I can get them back and have them queued up for Friday and Monday and hopefully Wednesday next week because I won't be here so some things brand ghost will not replace brand ghost will not replace me creating YouTube videos but brand ghost will AB absolutely help me with getting my content put out there especially when I'm not around so we'll be trying to do that and then yeah I'll have WPF videos going out WPF for me I spent years years and years and years building in WPF my entire job before Microsoft for eight years was Wind forms and then moving over to WPF for eight years right so um and before that I built Wind forms since I was ever like learned to program so it's just been a while for me so I've lost the muscle memory and I'm trying to get all that stuff back so um if you watch my stream tomorrow when I'm coding you'll be like dude have you ever worked in WPF um it'll come back I promise um but I'm hoping to to try and show some some some different patterns that I leveraged in WPF and it kind of feels like you're fighting against the framework sometimes but I have found that they help with testability and extensibility so I like sharing those so hopefully you can make it if not it will be recorded so um that's the thing too but folks it's almost 11:00 p.m. it is my bedtime so thank you so much for joining thanks for all the the chat questions if uh I guess next week because I will be on vacation I will not be doing the stream so I apologize but the week after and hopefully every Monday 9:30 p.m. PST I will be having streams just like this one and I look forward to hearing from you and being able to answer your questions uh makes me feel good to be able to help so thank you okay folks