Retros & Post Commentary - Principal Software Engineering Manager AMA

let's see okay I think that's probably all of them checking to make sure that stuff's coming through okay I think that's it so I wasn't going to be streaming today I did go on vacation over the weekend which is awesome we went down to Oregon and got to have like a 4 Day long weekend so I thought that I would probably be late hello from Twitter first time here from Mexico awesome um yeah I thought I was going to not be streaming today because I I thought that I'd be getting home pretty late from vacation so turns out we came back early I just saw my sister joined hi Kate this is your brother's live stream don't mess it up no pressure um yeah so I thought we were going to be getting home kind of late so I figured I'd cancel this and then it turns out we got home a lot earlier than I thought so I figured I will do the typical stream so this will be a ma format I moved it up about 30 minutes as well because I figured based on some feedback from LinkedIn people were suggesting that they do want to see me go through some articles and stuff so I'm probably going to pull up Reddit for the second half of this and just start going through posts and giving some commentary on them um and of course if you guys are are on the stream and watching it live not the recorded version if you have stuff that you want me to go over send it over um I got a check on a different screen to make sure it's a safe for work kind of thing but if it's uh you know different posts and stuff that you want feedback on or hear my thoughts I'm happy to go over that so like uh like normal though for these streams please do ask away I am watching chat across three enormous monitors to make sure I can uh see anything that's coming in so I do like making sure on these streams that if you guys have questions that I'm I'm there to answer them so um otherwise you know this is It's YouTube content right so uh I do want to make sure that I can spend the time answering what's top of mind for you so the topic for this week and again you can ask questions about literally anything you want related to software engineering but the topic that I wrote about at the end of last week for my newsletter was about retrospection and I think this is a really important topic and perhaps depending on the teams and and stuff that you're on for for development you might be exposed to this kind of thing because you know your teams have adopted say like air quotes here like an agile approach to software development um sometimes it's not even agile and people uh slap in retrospectives which is good I think retrospectives in general are good so I do want to talk about what retrospection is why I think it's valuable and then in my newsletter I was writing about actionable things that you can do for retrospection on your teams so I'll give you some um examples of how I've leveraged them and and why they've been beneficial and then how you can use retrospection for yourself because uh the concepts are similar right we we were going to talk about how retrospection is good for continuous Improvement on teams but it's not just limited to teams because you can apply these Concepts to your own personal growth so that will be the focus then like I said we'll jump over to Reddit Andor be answering anything you guys want to go over so with that said what is retrospection it's a fancy word kind of sounds like inspection refle and it's a little bit of both so the idea with retrospection is that you're going to reflect on a period of time and do some introspection for that period and kind of think about things critically right so I like trying to describe it is thinking about what went well what didn't go well and trying to drive towards things that you want to experiment with respect to change and in in my personal opinion this is really what dries continuous Improvement it's sort of um it's like an official process that you might put in place um and I'm going to say official process pretty Loosely but it's something that you put in place to be able to work with your team to reflect on a period of time to see how things are going and the important part here is that it's not just about seeing how things went you don't just want to stop and write down notes on like how things went and say good we got the notes let's move on so we can do it again next time right that's not what it's about that's part of it right and it's it's a small part because you want to be able to go over what you did and talk about what went well and what didn't but you don't want to stop there because if you just stop there then you're not doing any better next time right so with retrospection what we want to do is think critically about how things went so that we can start asking questions and challenging our El and seeing what can we do better next time so hopefully that makes sense if uh as I start to go through this especially if you're joining uh as this stream is going on if you're hearing me talk about uh retrospectives and retrospection if you're like I still don't get it could you explain it I'm happy to go back over the definition I think for most people especially if you are already employed as a soft for engineer this concept is probably familiar already but I wanted I want to make sure for new folks um that aren't totally familiar with this that we can spend the time to make sure that you do understand it because you may very well be working at places that don't do retrospectives and it's not for me to say if that's right or wrong but if you're hearing me talk through this and where you work ises not use a retrospection or do some type of retrospective this might be something that you want to propose and say hey like this seems like a cool thing could we try it because that's going to be the basis for continuous Improvement so I've said it a couple times I've been mentioning continuous Improvement right like so what is continuous Improvement Nick's saying it maybe it's a cool thing maybe we do it already maybe we don't do it and we should do it what does it mean so I think most folks are probably familiar with hearing about agile software development so um I have sort of stopped saying uh agile software development and I think it's because it's just like I don't know it's almost becoming like a negative phrase in software engineering used to be like um especially when I was getting started it was like oh waterfall is the worst like we don't say waterfall if you're doing waterfall it's the end of the world and like everything has to be agile so I've been in Industry now for uh 12 years plus another two years on top of that for internships which spanned 5 years so in total like the time that I have been in the workforce spans uh a 17year period so it's been a while and over those 17 years what I've seen is and this is just my experience so this is obviously bias right but I've seen this period where it was like I'm joining the software engineering Workforce when everyone's saying like waterfall is bad you got to do Agile things so that's like primarily scrum is one of the the ways you can do that um canb is another popular one that was you know being discussed a lot when I was doing uh you know development uh extreme programming I had a little bit of exposure this sounds pretty cool right XP extreme programming little bit of exposure to that early on but the idea was just that we want to do Agile software development that way we get a quick feedback loop but this is over that 17-year period what everyone's talking about doing like this is the way to do it waterfall bad agile good hello Steve from Germany on YouTube good to see you here so that's taken in my like from my perspective on social media seeing people talk about this kind of stuff especially over the last year I'm seeing a lot of people saying you know what agile failed agile sucks it's it's no good um and I promise I'm going to bring this back to retrospectives in just a moment but I'm hearing this a lot and when I see people talking about it this way saying agile has failed and then I hear them describe it and I think what personally what I'm hearing a lot of is like the implementation of agile again agile with air quotes at a lot of places is truly just not agile it's like a process heavy which is the opposite of agob by the way it's a process heavy implementation of a way to work and then it's labeled agile and then I would say yeah like I I would totally agree if you're saying this is failing yes that probably does not work well in a lot of places it becomes very prescriptive it's um it's very rigid right and it's kind of it's literally going against the agile Manifesto of saying people over process right that's like one of the the tenants of it so a lot of the time when I'm hearing people say agile has failed then they describe how it's failing I'm going well you're describing something that really isn't agile so instead of just debating this kind of thing and trying to get into the the details and the the Nuance aspects of like what is and what is not agile I go you know what like I actually don't care I don't want to waste my time debating you know which way or which process you follow because I just genuinely don't care and I don't think it matters because like a lot of things I'll talk about in software engineering there's pros and cons to everything right typical it depends right we all say it as software Engineers but it depends so um there isn't one best way to go approach building software but what I like to do and what I think can give us sort of the the best version of all of these things is just framing things as continuous Improvement so instead of saying we do strictly waterfall software design or we you know we are an an agile sof software shop there and we must do can band and here's exactly how can band looks you have to follow our exact can band process I'm just kind of saying this sarcastically right like because if you're following an exact process it's and it's very strict it's really not agile by definition so when we start going down this path I don't like talking about things that way I just like saying continuous Improvement and that means that if you are working on a team that is focused on continuously improving you will over periods of time maybe have something that happens to look more waterfall and as you are continuously improving with the team it might start shifting to be maybe a little bit more agile right you might have to adapt to things and you're like hey look we need to build in um the ability to be a little bit more Dynamic have more feedback so some of the waterfall aspects aren't really working anymore and you keep thinking about how to improve continuously and therefore your goal is not how do we make it more specifically canb or more specifically scrum or anything your goal is not to move specifically towards that your goal is just to get better and the reason I like doing this on software engineering teams is because I have seen that even with a consistent team your ideal state is not fixed I've seen it with a fixed team and you start to shift what the team is building right you fix all the other variables except what the team is building now all of a sudden the way that team operates may need to shift to be more effective and I've seen it the other way where you keep you know in place you fix what the team is working on it's very understandable work it's very known you can actually estimate it very well you keep those things fixed and you change the team members the team will need to adapt their processes how they work to become more optimal because you have variables changing so if no variable is changing ever then sure your team may be able to kind of look at what they're doing and say we can optimize this let's keep moving in some Direction but regardless in all of these kind of generalized examples that I'm giving you the goal is continuous Improvement at the end of the day so if you again like The Meta principle here is that step back instead of saying we must do one of these things can band scrum waterfall there's a million of them right instead of saying we do one of these things I like to say we focus on continuous Improvement now bringing this all back to retrospectives generally in agile software development you have some opportunity depending on the process that you're following and I'm saying process here because that's generally how it gets implemented right some some guiding principles you will have some type of ceremony with the team that's called a retrospective and it allows you to reflect on the period period here can change from Team to team your Implement your implementation of the process that you're following right so if we're talking about Sprints um even in can ban I've seen like doing you know every two weeks or something we still just want to put a line in the in the sand to say in two weeks or one week or three weeks whatever that time frame is we just want to make sure that we can Circle back and reflect on how things are going so again regardless of the process you follow let's put some time frame in place where we can Circle back and say how are things going so this is why I think retrospectives are valuable across any type of software development is because you can put them in place regardless of what you're following and I generally recommend again this is going to change from Team to team I like doing about two weeks to reflect on things if you're Sprint or whatever Cadence you're following happens to be much longer than two weeks in the first place for example my previous team that I was on had one month long Sprints because things moved at that pace we would do our retrospectives every month just as an example I like 2 weeks it's about enough time depending on you know still generalizing here it's about enough time to to try something out get a feel for it and then talk about it next time and sometimes you need more time sometimes you know right away but roughly two weeks is a pretty good fit okay so this is framing up what retrospection is what a retrospective might look like on a team but I want to start going into more detail on that so again if you're just joining the stream please feel free to ask questions about this kind of thing or is if if as I'm talking you're thinking about how your team is using retrospectives and you're like hey what about this what about that drop it in the chat I'm happy to engage and try to to navigate some of that with you but I'm going to start going into how we can leverage retrospectives on teams more specifically and I want to try offering up some actionable advice and when I say actionable advice I don't mean go follow this exactly I mean you should be asking these questions because the advice is kind of think about this and maybe you want to put something in place that does this one way or the other so hopefully that makes sense and I need a sip of water because I don't want to lose my voice from blabbing okay I'm just kind of kind of scroll through my newsletter while I go through this so I actually already talked about one of the first things was setting a Cadence and I think the Cadence is important like I said having uh enough time to try things out right because if you just to give you a couple of examples if the Cadence is too short and in your retrospective you say we want to try doing something different and your Cadence is too short you don't have enough time to really measure the result and every time you meet and talk about the result of what you tried you might go yeah not enough time not enough time and then you kind of give up on it like ah like it's just not really working or we haven't seen a change let's just forget about it right so if it's too short that kind of thing can happen where it feels like running experiments are a waste of time because it's just never enough time to measure it properly now conversely if they're too long um I would I hope that teams don't fall into a trap of saying we're going to try things and we're going to try it for the next three months if you know if you know like a week into it that it's just not good and people on the team are like man this really sucks we should change this please don't wait the entire time like that's a bit of an Ane pattern here so come up with a good Cadence talk about this on the team and what's kind of cool about this is in your retrospectives this can be one of the first things if you're just starting them out you can talk about this this could be one of the first experiments you run and the next time you have a retrospective you can talk about the Cadence again and I'm going to get into some some ways that you can look at doing changes or keeping things as we go through this so the next part is that you want to leverage retrospectives I kind of hinted at this to run experiments on the team and when I say experim experiments I mean this can be like range from all sorts of things right I've done um live streams about and newsletter articles on code review processes so you could have a conversation with your team about hey next time you know over the next Sprint again whatever Cadence whatever you want to label it over the next period of time we want to make sure that anyone who's doing a code review we're going to follow this approach of you know ping in the chat make sure that you can Engage The reviewers just as a nudge and you know we're going to try to close off code reviews this is the second experiment within you know 48 hours all code reviews cannot live longer than 48 hours so we need to make sure we're on top of them right you might try this as an experiment I'm just making these up and that's sort of like a process style experiment you could run this is a little meta but you could run experiments about your retrospective so we'll talk about this a little bit later but the format your retrospective you could try something out in the next retro you might pre-plan some topics to go over you might change literally the format of How It's organized so those are some options you could um you know you could I'm just trying to think of these off the top of my head you could say like Hey we're experiencing a lot of problems with our build infrastructure right so what we're going to do is make sure that we can raise awareness over the next period of time to see if we can get some action taken and this might not be something that your team owns right your team doesn't own the implementation of this change but you're taking an action out of the retrospective to identify a pain point and say we need to go socialize this with the owning team right so you can use the Retro to identify things that maybe your team doesn't own but you need to go take action on so I'm talking about experiments here but this might be something that comes up where you're like hey you know what like this is a pain point for us but we don't really own this like we should go raise awareness see if someone can take care of it but the point is that you're talking about these things and identifying pain points so experiments are really awesome because if we back up from just the Retro specifically I've talked about this a lot other people do as well but we talk about having like an environment that's safe to fail and failure is I mean as as backwards as it sounds like fail is like one of the best ways that we learn we need to be able to have an environment that's safe to fail so that we can try things we can think outside of the box a little bit we can learn from our failures and our mistakes but if we have the exact opposite environment where we're punished if we fail we're too scared to try anything your Innovation becomes completely crippled because no one will take any chances right so if you have an environment where you can try things you want to make sure that you're not just you know uh going overboard and say everything we're going to try and like you're not thinking about you know the The Fallout that can happen from it it's a little extreme right we don't want to go too far that way but you want to make sure you're like hey we should be able to try this and see if it's better here's how we'll know and here's how we'll know very quickly if it's not put some safeguards in place and say let's go try it so I think experimentation is very important that's how we can start to evolve as teams and say like hey you know what that did actually work maybe it worked and you want to you know continue that experiment let's try going a little bit further with it maybe it worked and you're like but if we go any further or maybe even at this point it's a little bit overboard like if we try you know try this going forward but pump the brakes a little bit on it maybe that's a sweet spot but we should talk about it again next time all right so experiments are a critical part of this it's in my opinion one of the best things that you can be getting out of your retrospective is just things to try different another sort of action that I want you to take away from this is again it's not a prescription it's it's something to think about it's a topic so I want you to think if you have retrospectives I want you to think about what that looks like you know what kind of process are you following how is it set up um is if it's virtual like how are people communicating how are you getting your thoughts together how are you following up on ideas ownership sh that way if you're not doing retrospectives right maybe you could be taking a bunch of notes as you're going through this couple of takeaways right like when I'm trying to highlight these actions for you these are things I want you to think about but I want you to think about all these things and then when you when you try to implement a retrospective or if you're trying to think about enhancing it I want you to think about the format and what I mean by The Format is like if every time you go to have a retrospective it just feels like it's a completely different experience because um either whose moderating it is just random or the you know you're getting on a call sometimes or other times it's in person or just you know if it feels very randomized I think that that can be maybe a little bit too disruptive so again you can evolve these things but I I think it's important to set expectations about what that retrospective looks like going in into it and the reason that I think this is important and it's not something that a lot of people think about unless you are I mean some people absolutely are you know have awareness of this type of thing but if you're a team lead or engineering manager kind of thing you do try to think about like people people first and not just like what is this process or event we're doing and what's the outcome of it when you start to think about people first something that a lot of people don't realize is like community communication styles are very very different right so you might have very introverted people and if you put them in a room to go talk about some of these topics they might go I have lots of great ideas but I'm not comfortable just like thinking about them on the spot or I want to you know I want to put them down but unless I have some support I'm too nervous to speak up about it because it's just it's too uncomfortable and it's a shame if you set up a retrospective in a way that doesn't really support these people right because they might have great ideas and you do want to encourage people to have a safe place to share them but I think the format that you take on is important so I I just encourage you to talk with your team and kind of reflect on this part about what format is valuable here so on this topic there's sort of two ways and there's many many ways you can do this but two ways that I've really liked doing like sort of the The General Iz framework for a retrospective and the first one that I'm going to talk about is called like wish wonder and it's very similar to the next one I'll talk about the names are slightly different it's just slightly different framing overall but same idea so with like wish wonder what people are able to do is talk about things from the past period in this reflection this retrospective I like these things right so the experiments that you were trying talk about about those what what did you like about them right write you want to write down the topics of the things that you liked in terms of actual format this follows uh if you were in the office traditionally how this was done was like with sticky notes or Post-it notes people would write like literally I like and then write a little blurb about it and they'd put a Post-It note up on a board somewhere and there's digital tools that can do this you can take the concepts and apply it differently but this is sort of high level view someone might go you might have a moderator that's trying to organize some of these thoughts as are getting put on the board so they can kind of cluster them it makes it a little bit easier to go through as we talk about this but you would literally be saying I like the experiment maybe someone joined the team and you you're kind of feeling some pressure relieved from having their support on the team or something else that was unplanned for came up right maybe something that is just good that has been going on you want to talk about like the positive things I like these things and this is an opportunity again when we go to talk about them as a team these are the things that collectively we like what's going on here so that's the I like the I wish is things generally that aren't you like they're not going so well or you're proposing things to maybe drive some improvements right so you might be experiencing some friction right let's bring up the code riew example again I wish we could close off code reviews within 48 hours I wish that when I put up a poll request that I wasn't getting comments about Whit space right these are generally pain points and sometimes you have to be careful that we don't just sound like we're complaining about these things now when you write it on a Post-It note it maybe it comes across that way but when we go to talk about these things on a team we do want to make sure that we're coming up with Solutions so that's why and then I wonder is generally like more kind of out there experiments like I wonder if we were to go change um what's a good one for canb we tried things like this um like a work in progress limit a weird beeping sound coming from my room somewhere um on Canan if you're not familiar with Canan um you can have this concept of a work in a whip limit WIP work in progress limit and what it might mean is that for the different states that work can exist in you limit how many people can be doing that and to give you a really interesting example if you had five developers on a team so five people that are normally writing code if you set a whip limit to work that could be in the state of like someone developing it you set that to three right you can only have three of those work items in progress at the same time and it could force like by by your process could force Engineers to pair up and work on them so again just to say that again if you have five software developers on a team and your whip limit was set to three for the number of work items that could be in progress to being developed that could get you to literally force people to pair up and work through things because that limit is set in place so one wonder that you might have in the I I like wish Wonder strategy is you can say I wonder if we set our whip limit to this if we would have this type of outcome and that might be an experiment that your team agrees to go try right so the Wonders are really about you know framing up some of these more out there experiments now before I explain the other one that's very similar what you do with these like I said is you put these notes either on a virtual board a physical board organize them talk through them I do highly recommend the people that wrote them discuss them because this is where you can get into a state of being like someone wrote like you know I wish we didn't have such a crappy build system and then it's like oh who wrote that and wants to talk about it and no one puts up their hand like it's kind of just passive aggressive and kind of crappy so like maybe don't do that it's not really um it's not really productive but again you want to make sure there's an environment where people feel like comfortable to be able to talk about these things so you go through them and then you would come up with um I would recommend some actions that you want to take and try out now if you go try running 50 experiments over the next period how do you know what's really working right I don't want to say like the you can only run two experiments or one experiments one experiment singular um but it's something to think about maybe you do want to say literally here's a bunch of experiments we could go try but we're only going to try one at a time that way you know if there's you know fewer variables changing like this thing was good maybe or maybe you're looking at the list of experiments at the end of the conversation you go you know what there's a couple things here that are unrelated we think that we could try these you know in parallel great go do it that's for you to discuss with your team it's a great thing to have a retrospective on try it out try different things but you go you know take some actions and follow on them and hopefully over the next period you've been able to go try these things out the other format aside from like wish wonder that I like is start stop continue it's very very similar start we're going to start some type of experiment we're going to try something out stop is that we have an experiment going or just some way of working something we're doing we want to stop doing this and continue is that we are doing something it's going well we should keep it going this one's a little bit more straightforward in my opinion um again it's something to discuss in the team sometimes I think the like wish Wonder Part gets people to be a little bit more creative but also I've seen people go you know kind of debating well that should be a like or that should be a a wish or that should be a wonder and sometimes you can change your framing of what you're going after to fit into different categories so people sometimes debate that a little bit too much and it's like if you just went with start stop continue it might be a little bit more straightforward so different things you can try there but the concepts are very much the same you want to be trying out different experiments okay hopefully that makes sense but this is something you should discuss with your team to see what works and you can always change it for next time the last thing that I want to mention in the team section is like I think it's an uncomfortable thing and I do recommend that people lean into this because your team is the best group of people you could do this with um I I do think an engineering manager plays a big responsibility in making sure that this can happen effectively but I think it's being able to have heated debates and I think it's important to be able to have conversations with your team where people aren't just violently agreeing right you don't just I'm going to give you an example you don't just have the most senior engineer on the team the staff or the principal there's one of them and everyone else is Junior and you know they speak up and say I think we should do X and all of the juniors are kind of just quiet and like no one says anything and it's like okay I guess guess we're doing X and you just go do it I think you want to create an environment again engineering managers play a big responsibility here but it's not limited to just them anyone through informal leadership can create a good environment for this you want to encourage people to have healthy debates you want to speak up there's no stupid questions right if you have thoughts about something you want to create that environment where people can speak up and a lot of the time you'll like from my experience what I've noticed especially if you have say you have someone who's a little bit more vocal and they're more senior and the rest of the team is more Junior Engineers maybe are less less vocal they don't speak up as much if you can get one or two of the more Junior folks to find their voice in the room you will very quickly find that a lot of the other more Junior Engineers share the same perspective not all the time not on every topic but I have seen many times before where someone is maybe steamrolling conversations because they're more senior they don't mean to do it but they're proposing things no one's really disagreeing with them and it's like I guess we just do it and the interesting thing is I've had many conversations with more Junior folks and they've told me in separate conversations man I wish we didn't do that I wish we could do things differently and I need to coach them in those conversations and say hey like maybe you should you know let's let's see if we can find a way for you to speak up about that or what makes you nervous to talk about that right oh I don't know it's a dumb idea the other person I know they have a different perspective and I need to find ways to encourage them and if you're listening to this and you're a more senior engineer like you should encourage other people if you're hearing this kind of thing encourage people to speak up because like I said I've seen a couple people start to speak up and then you get you know if it's remote um and people are on the call you'll have people unmute to kind of chime in about it or you could look around the room and start to see more of the people nodding and going yeah like we do want to try that so you want to create that safe place where people can bring things up but debate is good debate is good it's totally healthy it's okay to have disagreements but you need to be able to respect each other and I think that's such a cool thing that can come out of conversations and retrospectives where people are debating things you have a difference of opinions you can talk about them you can share your perspective but you're all on the same team you're all trying to drive towards a common goal so when you are disagreeing that's okay make the room to try and understand the other person's perspective right you might say I don't agree with that but we can go try the experiment for this time and measure it if we get a good result coming out of it like maybe my thought process wasn't you know wasn't the right one or maybe we can try that and it works and then we can layer on mine on top of that we can try both out right there's so many opportunities but I I can remember being in retrospectives in like a small room like maybe a little bit bigger than what I'm recording and right now it's pretty small in here and you'd be with the team and you'd leave the room and like the room was like hot right CU people were like really debating things and it's like I said it's uncomfortable but I think you end up building a really strong trust relationship with your team and a lot of respect again when you're making room for other people to talk and share their perspectives and you're genuinely listening not just waiting for them to stop talking so you can be like shut up listen to me you're truly trying to understand I think that you can have such an awesome team Dynamic and it's you start to get into this groove where it feels like nothing can stop your team right because you know that even when you're disagreeing together you're all moving forward as a unit so so just wanted to say healthy debate is good I do encourage it but you need to make room for people to share their perspectives okay it's about 40 minutes so far on Retros and uh the team side of things I'm going to shift gears to talk about how you can leverage retrospectives for personal growth but I want to make sure that there's an opportunity again if you if you have thoughts about how your team does this you can jump in any point and share that or ask questions but I'm going to talk about the individual side kind of going forward here um speaking about hot rooms this room is like a million degrees right now the AC should be on but I feel like in our hallway where the thermostat is it's probably a lot cooler and then there's no thermostat in here and it's all basically sealed off so I don't wake up my wife and it's like a furnace okay individual growth this is going to be a lot of similar things so when we talk about individual growth and how you can leverage a retrospective the framing that I wrote about my article was was really about the first thing is like set a time Horizon to be able to do this now it's interesting for personal growth and not just like shipping software on some Cadence right with personal growth you might have goal polls that are on completely different timelines or time Horizons so I wrote down a couple of different things here just to give you some examples I'll read them out but like you know some thoughts graduating from boot camp or finishing a semester of college or even you know finishing college or university in its entirety like those could be things that are months or years long right so if you were to say like those are a goal and I'm only going to ref reflect on that when it's completely done like maybe not not a great opportunity because you don't have a lot of time going back to what I said earlier you don't have a lot of time to to kind of make changes and adjustments right so you want to make a change based on your retrospective but like you've already graduated um so you want to think about your time Horizons that's an example of something that's very long for a goal um I wrote down like uh build an application that does something right in some programming language so this is one of those things where you're thinking about some uh you know early starter projects just for learning so some application that does X and programming language Y and I want to do that in two weeks cool okay so you could maybe with in a week you could do a retrospective on the first week and then at the end of the second week or maybe you want to do a retrospective at the end of that twoe period when you're all done because you're like I'm going to do this again with another goal for an application in another programming language so how did it go the first time and for my next two weeks when I go to build something how did it look I wrote um complete a refactoring a rewrite of a project by the end of the week right so again maybe it's not enough time for you Midway to try experiments out and do a reflection on it but at the end of that odds are at some other point you're going to have to refactor some code or rewrite some code maybe you want to do a a retrospective on that one week of refact ing what went well you might say oh you know what I should have done like I should have had some more modular commits because uh at the end of it that one week I had a big commit that I still couldn't land so at the end of one week I committed nothing I shipped nothing but instead I'm just giving you an example instead if after you know every day I could just commit working code even if it wasn't done but it was working I could have a snapshot and now at the end of the week I might have had seven commits and it's still not done perfectly but I've done seven incremental changes that moved us in the right direction so maybe that's a retrospection uh discussion you could have with yourself and then you go take an action which is more modular granular commits for next time um I wrote get through three hours of video tutorials this weekend right so this is less of a a practical Hands-On coding thing and maybe you're just want to you want to watch some tutorials but maybe you get through the end of that and you're like I couldn't keep focused or you wanted to get through those tutorials and you wanted to be coding along the way and you didn't write any code either because you were distracted or um maybe you know maybe at the end of that you're like maybe watching video tutorials straight like that just isn't a good way for me to get handson practice I didn't have a good opportunity to code was too busy just watching and it wasn't really sinking in so but you should have these conversations with yourself do a retrospective it doesn't have to be you don't have to go put sticky notes on a board you can do whatever you want but you want to do some critical reflection to see what's working what's not the last example that I want to give you here and there's you know a million of these right I'm just giving you examples but this one's probably relevant for a lot of people especially going for interviews and stuff but um I wrote Because I had to do this for myself right so I wrote practice leak code interview uh sorry practice leak code four interviews one hour every week night over the next month as you're interviewing so when I was applying for Microsoft I did something like this it was actually more more time every day uh between lead code behavioral interview questions and uh you know system design questions but you could do a a retrospection and I'm just going to give you a couple of different flavors of this I wrote um you're doing this every week night over the next month so maybe if a month if you're assuming four weeks in the month maybe every week you want to do a reflection on this how many leak Cod problems did I get through am I being honest with myself was I just looking at the answers was I actually trying to do them is this working what can I change right so you might want to do that maybe if you're interviewing over a month and that first month maybe didn't go so well right that's okay right it's not the end of the world but if you were bombing say you're getting interviews and you're not doing so well on the questions what do you want to change about the questions that you're studying right are you maybe maybe you're kind of like reading through them and kind of cheating because you're looking at the answer and then you write down the answer you're going hey look I got it but you're not like challenging yourself enough and actually writing the code like you have to kind of do this honest conversation with yourself and try to change things over the next period so some to think through but I wrote down that you want to set some clear goals and timelines so hopefully when I was giving you those examples you could see that I was giving you some things to Think Through not all of them did I list a clear goal but if you were thinking through it what is the goal after some period of time and that way it really helps you think if I want to go do some reflection on this right maybe it's something that you're going to repeat overall multiple times and you can do a reflection at the end or maybe it's over a long enough period of time that you can do Reflections in the middle and change up how you're approaching things but you want to think about what your goals are and set a timeline and then like I said for teams the last thing I wrote here was experiment right you want to experiment with things to try differently um I don't remember the exact details of this because unfortunately it's been a long time and every time I think through stuff from University I realize I'm getting old um but I can remember um for myself I'm I I don't like testing I feel like testing is very unnatural uh it's like a contrived situation where you're forced to just recall everything from memory and hope that you can go apply it just feels artificial not real it's my personal stance on it um it's also why when I give people interview questions I try to make it as comfortable as possible with no tricks because I just think it's realistic so I remember in University I had to teach myself how to study in a way that would be effective for me to go write exams and without knowing it like I wasn't totally familiar like with the idea of retrospectives back in University had a little bit of like I did you know worked at places that used agile but just wasn't really like clicking I guess so I kind of did like in formal retrospectives with myself where again I'd go to write an exam and I'm like you know over an exam period because we'd have like these weeks where they'd cram all of our engineering exams together be like man that sucked like that sucked I have to do something better for next time I have to and I would make these micro improvements and by the end of studying in my fifth year of University what I found was a strategy that worked really well for me and if you consider this fact that I said that we had most of our exams put in one week you might have something that spills like one or two that would spill over into the next week let's say but I would say look okay I have exam a b and c you know um Monday Tuesday Wednesday right back to back so what I would do is would study for the one on Monday and I would take I got to a point where I would take breaks so I would study for like roughly like 30 to 40 minutes and I take a break and then I'd study for 30 40 minutes take a break and the breaks would be like 20 minutes long or something might go play a video game might just take a nap might go eat but I found for myself that I needed to take breaks very regularly I needed to because what I would do instead is if I tried to go for too long it just wouldn't be effective I would be at my computer finding anything else I could do but my point here is that I kind of had to use this reflection process again wasn't really formal for me but I did these micro improvements where I could make changes and find a better way so again continuous Improvement this is just an example of how you can go accomplish that so if that makes sense um the the last part that I wrote in my newsletter was just about goals that I set myself for this year um these are kind of like vanity metrics I'm just going to kind of say them quickly because it's kind of interesting um I had a bunch of stuff that a lot of this is for Content creation because spoiler alert that's what I'm doing right now is creating content and I wrote like I wanted to reach 5,000 YouTube subscribers by um this is everything was by the end of June so I managed to achieve that and got a little bit ahead which is great um newsletter subscribers I thought that I was doing some things so again running some experiments and a lot of this was just being a lot more open to collaboration so I figured obviously there's a lot of good things that come from collaborating but I was like hey if I go collaborate be more proactive about it I wonder if that will help Drive newsletter subscribers and it might have but certainly not in like a notable way for me now does that mean I'm going to stop collaborating absolutely absolutely not because I learned so many other valuable things from doing collaborations it's just that it wasn't moving that particular metric that's okay I have to come up with a different strategy if I want to see that improve but collaborations um have been amazing I've been able to interview people on YouTube and stuff um would would not change that for anything it's just that it didn't have a particular effect that I was thinking it might um LinkedIn this is another thing so you might be watching this on LinkedIn um I had a goal that I wanted to reach 15,000 LinkedIn followers I got pretty close fell short of that that's okay um I think that a lot of stuff has changed on LinkedIn in terms of getting engagement so uh I have just over 14,000 people that follow me on LinkedIn sometimes I make posts and the number of Impressions is like 300 people which kind of sucks because it's like the post never gets out to more than 300 people so what am I to do with that so I think a lot of that is just like it's LinkedIn algorithm I'm not saying like it's punishing me it's always about your own content so I need to change how I'm posting content in order to have more engagement and you might say well that's a vanity metric and I would say sure but if you take the stance that I'm trying to create educational content if I'm creating educational content and there's 14,000 people that follow me and only 300 people maybe not even my own followers see that like it's a very very very reduced audience so it's very challenging for me to feel like this is being effective so got to play around with that strategy and then the last thing was that uh courses so I set a goal for myself to deliver two more courses before the end of uh before the end of June managed to do that and what's cool about that is that I'm doing my fourth Dome train course right now currently so I'm excited about that that will be C based I have a follow-up course for immediately after that and I am working on something new in terms of courses so I'll be excited to share that with folks when that's ready but um those are some of my goals and in my newsletter where I wrote about like where maybe it didn't go right and some things are going to be changing to go forward but I won't go into the details of that okay so that's really it for retrospectives um I haven't seen any questions or anything come in on that which is fine as I continue on because I'm going to shift gears a little bit here I am going to go over to to Reddit and we're going to read some articles together and I'm going to give you some commentary on them uh I haven't done this before but this was voted on LinkedIn people were saying they wanted to see it so I'm happy to do that but uh again if you're joining and you want to ask questions about retrospectives or you've been watching and you're like uh like I'm just waiting for a time to ask like literally anytime you want go ahead and type it in the chat I'm watching um I think the chat is working on all platforms because I can see Instagram I can see Tik Tok uh I can see I for sure I can see Twitter and YouTube have come in and I am on the LinkedIn event so I can see the comments if they come in as well so um and I see on Instagram from Dev coder I see thanks right so there's coming through oh so here's a question is there any full stack job um I'm not currently offering any jobs unfortunately um if you're I've told anyone who asked me this if you're interested in working at Microsoft the best thing to do is check the careers page honestly um like I'm not currently hiring and if you want to know who is that is the spot to go even internal transfers go through the careers page I transfer teams at the the beginning of this year and I still went through the careers page there was a job posting internally they interviewed and I interviewed with the team like you go through the careers page so that was for uh a question on Instagram Instagram chat doesn't come through on the common chat by the way and I also realized I'm not showing it that chat is at a date I think but anyway so watching from oh Rosa good to see you watching from Instagram good to hear you yeah thanks Rosa I appreciate it okay I'm going to switch gears then if no one has questions about retrospectives I'm going to jump over to Reddit which is dangerous because Reddit is a scary place but um I'm not posting on Reddit right now I'm going to be reading stuff from Reddit so maybe not so scary so Rosa and other folks on Instagram I apologize because the format of my screen might not look good on on Instagram I'll try to see if I can get it to fit but might be kind of crappy but I'm going to try but I'm going to scan like I'm going to summarize the post and then I'll give my perspective on it we have another question on Instagram that says will AI affect our job uh I think the answer to that is absolutely AI will affect our jobs as software Engineers probably a lot of fields um but I don't think it will replace software Engineers I've talked about this before my stance is that um uh and if I back up I don't think this is specific to AI I think when we have either technology changes or things that can potentially revolutionize how work is done if you decide that seems scary that seems like something I'm not interested whatever it is if you ignore it I think that's basically kind of dangerous territory where you can expect that you'll become obsolete but it has nothing to do with ai ai is just one example of this type of thing where if you're like hey I don't care about it oh I don't want to pay attention to it you can expect that probably other people are going to start leveraging it they're going to use it as a tool that can get them ahead and you'll probably be left in the dust so I don't think it's Unique to AI but I think AI is one of one of these such tools that will help with that so will affect our jobs I don't think it will replace all of us I think it will replace the people who don't want to get on board with leveraging more advanced tools so that's my perspective on that okay I'm going to get shifted over to Reddit we are going to be looking at uh r/ experienced devs which is fun I'm going to switch my screen over it's going to drop me for just a moment but I'm going to keep talking here so hopefully you can see my screen but I got to get my cam back up there I am okay um I'm doing a check on Instagram this looks absolutely awful so I'm sorry Instagram folks it's pretty brutal um I wanted to oh man this refreshed here I wanted to start with this one I was did a quick scan through this one so again sorry on Instagram because this is going to look pretty crappy but I'll read it out um pretty quickly so this one's uh This Thread is called wearing lots of hats and sorry I got to change something on Tik Tok here so wearing lots of hats I'm a team lead air dropped onto a team that was having lots of problems I find myself spending time redesigning the data model the architecture the deploy system basically everything right release processes the PM also leans on me to do the road map that is a lot of things right a road map you're doing a lot of architectural stuff I also need to design components that can be used by other teams so not just within the team but other teams so I need to know what the other teams are doing and where they are likely to be in a year so it seems like you know architectural road map not only for the current team he's on that was having a lot of problems but also supporting all these other teams in addition to that I'm mentoring the other Engineers trying to make sure their roles are align with what they want to be doing and doing tooling to work to clear the roadblocks cross team politics yep that's a lot of stuff going on finally have my own coding Tas so also has to go write code trying to make sure my queries hit uh indices and all that is this normal I feel like I'm jumping between so many levels and not just code abstractions but business levels too I've never felt so tired of this so I don't have context right um I don't know if this person I'm assuming they're working at a startup small company this is what I would gather I'm going to scan through the comments a little bit not normal if it's not sustainable maybe once you get the team stable what does a team lead mean at the company you work for right so this is interesting someone's basically trying to get them to think about level setting expectations I think this is a critical one sounds like you take on the task on your shoulders should you be delegating right so I want you to think about this for situation um where maybe you are feeling overwhelmed you're taking on a role and maybe not doing all these things maybe you're doing these things and more um but what I have highlighted on the screen right now should you be delegating and you can see I this person said I have no idea since I don't know what expectations are being placed on you it comes back to expectations as an engineering manager this is something that I need to be very clear with people and I would say if you were an individual contributor or even an engineering manager any role you want to make sure that you have level set expectations with your manager about what you should be doing so this person's saying should you be delegating right this very well may be an expectation of this person and maybe they're not leaning into it too heavily or as heavily as they should be because to be quite honest it seems like they are doing a lot of stuff and if they could man manage to get all of those things done that would be quite incredible but I think the only way to make this more sustainable is that you cut some of those things out so you put your hand up and say hey look I can't do this so whoever is expecting that of you you say hey look person X I can't do this thing you need to find someone else to do it that could be you talking to your boss about it that could be you telling another team that was expecting you to own you know their their components and stuff that you're creating hey look I cannot do this now what I would recommend and this depends on the Team Dynamics is I would recommend having a conversation with your manager saying hey look I don't think I can balance all of these things I need to start delegating it and then try to get an understanding of where those boundaries are for you to be able to delegate stuff this person says sounds a bit like running a startup that's kind of what I said full of C players which is hard to say I mean based on what we're reading here it does kind of sound like that it almost sounds like no one else is doing anything but we're only hearing one person's perspective right I like giving the benefit of the doubt but truly like I would say if we haven't heard from this person how much they've tried to delegate they might not just be good at it and that's okay but I think they need to start with that is it possible is it possible for you to move some of the team members around if at all possible consider replacing C players with fresh Talent yeah so like this person is talking about more bit more of a restructuring so this is a key point I love this part right here I'm going to highlight this again sorry on Instagram it's not coming through but this is not only is this not sustainable but doing all of this yourself will reduce the their ownership over architecture components and tooling so this is a a super awesome comment I have to coach people on this kind of stuff I've struggled with this myself earlier in my career um because I worked at a startup before Microsoft and for a long time I was putting on all of the hats and trying to do everything myself and you know when you go to help people the common mistake when you're helping people is to give them the answers right I need help with this no problem let me do it for you guess what happens that person comes to you the next time they need help and you get another person that does the same thing the problem does not get reduced you just create more work for yourself because you are solving temporary problems and not solving the root of those problems which is that people need to learn so you need to teach them these things so that they can do it themselves so this person is calling out something excellent here if this one person tries to do all of these things it's also perpetuating the problem this is why I think delegating things is incredibly valuable right this person can take some of their time back to focus on the critical things that they should be owning and delegating the rest and it might not be obvious to them and I'm not saying it should be or it is easily obvious I think they need to be having conversations but finding out what they can delegate um this person has an interesting point here it sounds a bit like your stop gapping lack of resources with your own effort right so kind of taking on too much oh where did that go did I just disappear Oh weird I didn't click that I don't know happened sounds a bit like you're stop gapping lack of resources how is your managing up right sounds like it's time to figure out which outcomes need to be properly resourced versus which efforts need to be Dro so this is another strategy right so delegation one part but um it's it's pretty e this is sounds like a startup problem right A lot of the time at startups everything is a priority I mean we see this at a lot of companies not just startups but if everything's a priority how do you pick the priority thing right everything can't be the same priority it's impossible there are things that take higher priority so if you only have so many resources you need to start having conversations with people that are more in charge and saying look these things cannot get done there is no physical way for them to get done even if you're delegating you might say we've delegated everything we can these things cannot get done or they will get done but they're going to you know it's six months it's a year out they'll get done but that's when they're going to happen you need to be ready to have those conversations and they're hard conversations I'm not saying this like it's a trivial thing but these are conversations that need to happen because if not and someone has the expectation that stuff's going to get done right how is your managing up you need to be having conversation with your manager leadership and being transparent about this stuff it's a very challenging spot to be in I have lived this kind of thing before not necessarily the uh I'll back up I have been I've air dropped myself into the teams that were having lots of problems and I've done that because I thought that it was critical for the business and I have air drop myself into teams that were having problems to try and rectify them because if not I strongly felt like the business would not succeed and when I say not succeed that might be too harsh I don't want to say like it would have crumbled and failed but I feel like it would have been uh very hindered so I have air drop myself from the teams like that and that did mean taking on a little bit too much but ultimately try to tackle it from different angles right what could I delegate what could I help clarify and then managing up to try and have conversations about how to do things differently ultimately in this one particular case um and I'll I'll I'm going to talk about this and I don't want someone to hear what I'm saying if you worked with me before I don't want you to hear this like you were the problem on the team because it was not a person problem just for the record I want to be transparent about that it's a uh fundamentally like an organizational thing with a lot of baggage and history attached to it no single person's fault um one of the outcomes is that I wanted to show that the process and the structure of the team was ineffective and I was able to manage up get resources to spin up another team to show how the work could be done in a different way and we literally carved out a big chunk of work that one of the teams was responsible for and we said if you just do it a different way and we demonstrated it it can be dramatically faster without losing the quality so I had to manage up in that situation and show a different way for things to get done um but this is a hard thing I think delegation incredibly important get your expectations aligned with your manager incredibly important and then manage up talk about what things are going to have to drop and get people to make difficult decisions you can't do everything and basically the outcome of that is that work is going to fall off make sure if people are like it all has to get done it's not going to happen right if truly it can all fit make sure that you understand the priority and you're constantly communicating this is how it's going to work that's a tricky one it's not uncommon though especially in startups cool U I'm going to keep going through a couple of these I plan on going for another 50 minutes on this stream so um by all means if you have questions you want to see other articles and stuff let me know got to keep sipping this water I'm gonna go to work tomorrow and not have any voice pixel pushing causing burnout am I the a-hole let's see okay kind of want to know if I'm the a-hole here um I've been writing software for over 15 years now with much of that in web applications I have a product owner that is a hug hu that is huge on Pixel pushing um oh and they explain what it is I was going to elaborate for folks that don't know literally writing bugs over one pixel here three pixels there to move around UI elements or something like a debal of 500 milliseconds is too slow so when they talk about pixel pushing it's kind of like and this is going to change depending on people's perspectives but the perspective that this person has is that this work is extremely nitpicky and is not offering value for how much effort goes into it and even if it's to move something one pixel it's not a lot of effort right but it's a context switch it's a code commit it might be a a review it might be it might be a build the overhead that goes into it to move something a pixel they're like it's just not worth it it's just not and this person keeps doing it so that's kind of what they're getting at here um they keep talking about it a little bit more we have a designer throwing together figma Pages um and what we right the first time where I was always really close to it I end up having to put the figma image on the web page and spend an hour or so something like a data grid because every pixel on every column has to be 100% exact this is oh this is even worse this is an internal web app internal no external C external oh my goodness no external customer see this you can tell I'm getting heeded about this the product owner is way more concerned with how it looks in ways that a normal person would not even perceive than the actual functionality under the hood which is shown in the absolute slowness she's writing these requirements okay never experienced such tight control I don't oh wow this is this these are really strong words right so let's let's kind of read through these I feel suffocated and I'm now burnt out I don't ever want to be an IC again I'm looking for management positions that I can hopefully hold on for 5 to 10 more years when I decide to retire completely if it wasn't for that I don't know if I can get the same pay and benefits quickly I would quit right now wow that's pretty that's pretty strong words right um yeah that's that's a hard one so I'm gonna I'm going to give you an experience that I had uh working with a ux designer this is a this is a good story by the way as in like positive outcome and so uh nothing I'm about to say is paint hopefully it does not come across like I'm painting this person in a in a bad light because I absolutely love working with her and my team did as well but I want I want to paint a bit of a picture here so I worked on a it started off as a prototype and we said holy crap we got something here and we sat and I don't know if people know this terminology but like we basically made a war room we locked ourselves in a room a couple of us to go work on this prototype and start transforming it into a product because we said like I said holy crap we have something here we need to go move as fast as we possibly can to get this going so not a typical situation it's not always how I'd recommend doing stuff um it worked really well in this case what it meant though is that as the the Prototype we were building was rapidly becoming more mature because we're going to get to a point where we have to ship it it meant that we have to start doing stuff that wasn't just coded as fast as you can and you know review it yourself push it up and break the build 100 times like yeah kind of have to start maturing if it's going to go with the door so we need it because we had other products we needed to make sure that it was branded properly and you know could go into customers hands we were proving very quickly the functionality was there but it's not something that we could put into users hands and have a company be like we made this if you were just a solo Dev being like hey look I built something cool sure who cares but it was really difficult to look at what we built and say yeah like our company is proud of how this looks right or it's following our branding it's like it's following other things we do because it didn't and I remember we had uh the ux I and I can't remember exactly how it was but the ux designer came on board kind of did a bit of a conversation about like what the product does and stuff and I remember getting the first set of UI requirements and we were just like like I like absolutely not like just nope and it was it wasn't like we don't like you in the in the beginning it was very much like what you're asking for like functionally won't work like we were seeing things it was like functionally it just doesn't work this way and it was that led to a very interesting conversation because and she she's so good at her job because she would do like not just like a great eye for user experience but um she was a good user proxy too so she would say well why not right like why doesn't it work that way and it challenged us because we would say well we we built it this other way what what do you mean why does it work this way because it works this other way that's how we built it right so part of it was like it could like in some cases it could have worked the way that she said it could have but it didn't at that point in time and that was a interesting Crossroads to have at the beginning of our working relationship with her on this product because I think it set the stage very well because we were able to say to her look it doesn't work that way right now and we can take some of the pieces that you're talking about and we can start moving in that direction so let's do that right and what we would do with her is start using her UI designs is sort of like a North star that we wanted to work towards and it was awesome because the conversations we had with her were like look here's what we got right now here's the direction we plan to head in as we're building these features out like this should be a good opportunity for us to maybe take advantage of Shifting this over and it worked so well it works so well because well if we go back to just like being agile um and continuous Improvement we were shipping stuff and then customers would try it and there were things literally from the first set of designs that she carried through the entire time and we never did them and it's not like we were saying haha screw you look we're not listening to you we never did them because they truly never became the top of the priority list ever ever and that was okay right so in this situation it's challenging because this individual is not working with the ux designer and they're talking about a PM in this case right different roles kind of talking about similar situation call them like a product owner in this case because in the end this person's signing off on on the requirements we were very fortunate because we communicated with them and they understood this software has got to get out the door that's it it needs to go out and truly they understood the value we need to ship the value to the customers they understood that and then we were able to get them as close as we could with their like to their designs with our own user interface and they were like great that's fine so to me how I would approach this conversation is like it sounds like in a lot of a lot of times when I see something like this conversation that we see with this pixel pushing going back to the Reddit article Reddit post sorry is there is a misunderstanding of what's valuable here and it doesn't mean that the ux designer or the they're calling them a PM in this case it doesn't mean that their opinions are invalid right if it needs to be over a pixel or three pixels or whatever like that might be totally right right might be I don't know or maybe they have a uh they're talking about debouncing as well being too slow or whatever that might be accurate from a ux perspective it might be accurate I have no idea but let's assume best intentions this person knows what they're talking about and what they're saying is right it's not a matter of it being right or wrong though because it's a matter of what's a priority so in this particular case it sounds pretty sketchy because it sounds like the situation I had was we had a ux designer she is not prioritizing our backlog we are also working with a a PM who is a product owner and the ux designer had input into this and we basically you know had conversations with her had her blessing to say like it's good enough keep going right she would sign off as a stakeholder saying I understand where it's at let's move forward sounds like in this case this is their PM that they're talking about is their product owner and they need to be able to convince them of the value for the customer so this is an example where I would say I don't think this product owner is prioritizing the right things now how to go approach this is challenging because I don't know the structure of the team in this case so it makes it really difficult to say what's right or wrong or even what steps you take maybe we should scroll through I want to give you a little bit of my opinion before I scroll too far but some things I'm thinking about are one um within a team it sounds like there is not alignment about what is valued right and I think driving towards alignment and value is important so shipping value to customers is really at the the center of it and is the value in the pixel accuracy like no so I'm like I'm very much in agreement with what this individual is saying and why they're frustrated like I get it so I I would want to try and find ways to explain to this product manager about the value that's being shipped maybe you could do it in a data driven way and again I don't know I'm going to scroll through and see if they they comment and we get some more insights here but something that could be interesting is like if you can't convince them that you know being Pixel Perfect is of the highest value could you use data to prove what is higher value could you do surveys could you do customer satisfaction type of things right could you run experiments where you're spending time you know you're saying okay we can't get these features done right we're we're we're spending the time doing what you said we're moving things getting these pixels more accurate are are is the customer satisfaction dropping because we're not shipping value like fixing bugs adding features could you do the opposite way um so that's one thing is can we get more data driven other thing that I'm interested in here is like I don't like this necessarily because I think it's focused focusing on the wrong thing but like are there ways to improve the process where like you aren't off by a couple pixels here and there or if it's de balancing stuff like can you get those requirements more up front I don't know um or could you have a bit of a contract where it's like um maybe on the pixel thing maybe they're not willing to budge but for the de balancing like maybe can they provide you that information up front and if they change their mind later like you can come up with an agreement like we have to go postpone updating that because you know it's a lower priority thing we did what you said your update to its lower priority it's a change of scope you know put it on the backlog see what happens so I think there's a couple things we could do here but one of the other directions that I'd like to go is like if this conversation's not working well because this individual the product owner or the pm here is not really getting on the same page um again so many assumptions are being made here but if you're having difficulty communicating and trying to get on the same page and saying like how do we get the value delivered I would be curious what their their reporting structure looks like because it might be something you need to escalate it might be something so in Microsoft we have engineering org structure and a PM org structure it might be something where a more parent PM so the you know that that PM's manager or something um you might be able to escalate it and say look we've had some conversations about this I still don't feel comfortable could we talk about this more I don't like that a ton because it feels like you're circumventing but if you've already had conversations and people aren't aligning sometimes escalation is necessary so here's a bunch of ideas let's go scroll through and see if they give any more context maybe I can come up with some better answers so this user is Bobby Jew gaming so this is not normal in any way yeah agreed the PO is wasting money and time for irrelevant minutia and nobody is benefiting from it right so that's why I said that the value is not really understood by this person I think there definitely some UI purely cosmetic sometimes even alignment only issues this person person says it's not a bad thing for this design product person to be so detailed and having such high expectations it's what I said earlier when I said it's not wrong right they might be absolutely correct in saying it needs to be over X pixels or de balance change whatever they might be correct in those statements I have no idea however all involved must understand that such standards can only be sustained at a reasonable cost right there's trade-offs that way you can do some Define once apply everywhere feel more at ease style guides right um oh man oh I realize if I'm clicking you probably can't see my cursor when I'm doing this maybe you can apparently before I clicked on the background and it collapsed on the Reddit page so wasn't expecting that um what's going on for this one so this says this is definitely normal for organizations that value their U iux however for internal apps there's a lot of latitude yeah um I don't know I I think that we really valued our UI and ux where I work before but I think like clearly we didn't value it Paramount to everything else we valued shipping value right like like so our our audience and this is an important thing to understand too our audience was this is for digital forensic so forensic investigators forensic examiners they don't care how pretty something is at the end of the day it's just it is a it's a misalignment in value I don't know enough about where this person's working truly it would be hard for me to believe that they would value one pixel off kind of thing over bug fixes other things it'd be hard for me to believe that but it's possible if it's slowing everything else you need to report to your manager this is what I was talking about the escalation thing but I think before this statement this is where I would and I encourage other people to do this because it I don't know maybe this person has that wrote this but I encourage people to try working with the person that they have problem with and it seems counterintuitive because a lot of the time you're like why do I want to go spend talking or spend time talking with so and so like usually by this point you're so frustrated with this person that like the thought of engaging with them you're like no I don't want to do this right like you'd rather just like not go into work than have to talk to this person but that's because this has gone on for so long and I do highly recommend people start to before you get so far along where you're resenting everything this person does you try to have the difficult conversations early so I would highly recommend even for this person like I have highlighted here if it's slowing everything else you need to report to your manager like before that please try and take the time to have an honest conversation with this person explain what's going on why it's impacting try to get a value alignment and if nothing's changing and you've made an attempt to do that I think escalating is totally fine right there's situations where I've had people on my team come to me and they haven't done what I just recommended first and I don't hold that against them but I always try to give them that opportunity if they're like hey like I they're maybe they don't say it directly but they're kind of escalating something I like to ask hey have you tried talking with that person have you tried you know sorting this out most of the time the answer is no and then I like to give them the chance to say hey look here's why this could be a really good opportunity I think you should try but if you're feeling uncomfortable about it or this isn't a good time for it or you know whatever the reason I can I can go approach this and most of the time I've actually had people go and have these difficult conversations on their own and I would say and I don't have stats on this I don't keep a little log book and record it so it's all anecdotal so I could be making up all my numbers but I would say of the people which is over 50% I would say that go try this on their own right so over 50% of the people I have this conversation with do have the conversation on their own and I would say most so again over 50% of those people probably closer to like 75 to like 80% range they have a very good outcome very good they just take the time to get on the same page as the other person that doesn't mean that it's going to resolve everything but um it it has been quite fascinating to see that people end up resolving problems and they end up having a better working relationship with the person they had a conversation with so I do recommend that as a first step escalate if you need to see if there's anything else in here that's interesting so okay maybe this is the last one we kind of touch on here this is specific to this the situation but kind of uh what I was talking about like are there ways to make this process better can you avoid these challenges and this one says working with difficult product people definitely sucks but figma does display the CSS used to style a page so you don't have to eyeball things the P another person responded this was my thought this coworker sounds insane but figma is really easy to use and we'll even spit out the values so you can copy paste or easily check values in Dev mode it sounds like maybe the Gap is a designer somehow using figma incorrectly or something because you don't need to get out of M you don't need to get out of magnifying glass to compare things so again we got to picked a couple of comments and this kind of seems to cover a lot of what I was saying but this one is an example of maybe we can go back to the process that's being followed can we maybe look at that a little bit see if we can tune it because maybe there's a better way to avoid a lot of these things in the first place right you can save some time you can do things the way the designer wants everyone wins right maybe so that's an option time check another 30 minutes or so thanks for folks for joining on the stream if you joined late I was talking a little bit earlier about retrospectives retrospection if you are interested in that topic and you joined late and you have questions on um how your team's doing retrospectives or why you might want to consider doing them anything related to that topic just add it in the chat happy to to pause going through Reddit articles and and chat about that I'm just trying to look for some interesting articles oh have you worked before without stories board to track progress yes I have um and I've done it the other way too okay let's see just joined a company and their workflow is quite unusual we have hourlong daily meetings yikes okay our manager prefers to set priorties during these dailies and every day we need to demo what we accomplished the previous day based on his requests this approach leads to a lot of contact switching and PRS are starting to pile up can imagine despite this he keeps assigning more tasks on different PRS okay what bothers me the most is a lack of clear requirements which is interesting based on what we're reading here so far right hourong daily meetings priorities are set but there's a lack of clear requirements you have clear priorities with no clear requirements okay if I accidentally Miss asking for a specific requirement he complains the next day even though he didn't specify it this was particularly frustrating especially since I've only been here for two weeks okay so I'm going to pause on this one and talk about this briefly if I accidentally Miss asking for a specific requirement he complains the next day so I mean personal opinion I don't think that I don't think you should go complaining about this kind of stuff um so from this author's perspective sure I don't think that that's a great experience where your managers just like complaining about about that kind of thing um because what I was even talking about earlier not for this uh this post it's like level setting expectations right you need to clarify with people especially new people these are the expectations I expect just to give you an example I expect that you are going to be trying to ask about requirements and you know if we leave this uh this standup meeting and you think of more requirements that you need clarification on that you're messaging me you're asking me we get them clarified because I don't want to have unexpected requirements or gaps the next day right we want to minimize that it should be a very rare occurrence but you set that expectation do I think that's great like not really I'm just I'm just giving you an example for this context right that might be a way that they could go approach this so this it's frustrating for this person because that expectation was not clear now to be fair even if that expectation was clear it probably sucks a little bit but another reason for frustration but I think the level setting of expectations is the gap here and the biggest gap on on what I have highlighted so now they go on to say I suggested using a board to track stories and progress but I was told this is just how they work and not everyone fits in hello Satya um from Germany I believe that's the deuts land I believe believe that translates directly to hello from Germany I think cool um so they're suggesting using a board which is I think an interesting tool for uh the situation they're in but I was told this is just how they work and not everyone fits in don't like that just how they work and not everyone fits in I'm considering resigning and looking for a new job but I wanted to get some opinions here am I being too lazy or is this kind of workflow common for some folks okay I think a couple things to consider I don't know awesome um I don't know this person's situation I don't know enough about the company you know we're we're seeing one person's perspective kind of have to look at it through this lens um there's a lot I don't like in this situation right um the first part was we were getting this sounds like there's not your expectations it's not not a good spot to be in and that can be frustrating for a lot of people right so fair um I I don't like this so someone's coming up with a proposal doesn't mean you have to take the proposal right that's not that's not the bad part I've had to tell many people and I have made proposals where it was the answer is no to that for now that's okay right but it's the the response the this is just how they work and not everyone fits in like that's the part I don't like it might be true that not everyone fits in like clearly right this person is is very much challenged by this way of working so they don't fit into this so I don't like it because it sounds very rigid and not welcoming okay so a couple things I don't know if this manager is it's it kind of sounds like they're micromanaging a little bit again I don't know what's happening in the rest of the day but running an hourlong meeting setting priorities every day and having people demo like like parts of this I understand because there are pieces of this this really ties back into what we were talking about at the beginning the very beginning of the stream for um like a process heavy air quotes agile thing right this seems like someone's taking some agile Concepts you have standups you have demos you get this feedback loop right sounds like these are some agile things that someone just said here's the process now it's agile uh this is the side effect this is why people say they hate agile this is it right it's this is literally it so I'm trying to think of what I would advise this person to do and it's hard because I don't know the manager um and a lot of the other team Dynamics something that I could that I would recommend at least exploring feeling out is you can get if you get okay if you get other people to buy in to some of your ideas or you can at least survey and see if other people feel this way this could be an interesting start so it sounds like it's not going so well with the interactions with the manager to start with okay so we can come back and explore that later it might be interesting to check with some of the other teammates right and instead of going hey don't you think this sucks should we change it like instead of approaching it that way you might be able to reach out to someone and say hey I'm having some difficulties um you know doing this effectively could you give me some advice right like I'd like to learn from you like like I'm new here I want to learn how to do this effectively could you give me some advice and approach a few people in the team and see what their perspectives are because while even as I read this I'm like I don't like a lot of what's going on here maybe it literally does work very I'm benefit of the doubt maybe it works super effectively for their team right maybe I have no idea let's pretend it does okay let's pretend they were an extremely effective team this person's joined and it literally just does not work well for them but it works well for the team maybe there's an opportunity where this individual could learn from the other team members about how to do this type of work effectively and they could try some things out and kind of find their groove working in this way maybe but I think what's more likely yep this is sat you kind of said it in the on the the YouTube chat right this is what I wanted to say is it's probably more likely this other thing that you're going to see the other team members highlighting a bunch of stuff that they're not totally content with right so SATA here saying feels like the manager came up with how it's implemented and he can't cope with the criticism yeah so how much of that is like purely on the manager or not not sure but I think what's going on here is that there was a process put in place maybe it was formed over time whatever for all the the you know right intentions I like to assume best intentions and this kind of stuff and what's happening is that there is no good feedback loop for how these things are operating and I would imagine other people on the team are probably feeling some challenges with this so I do think that you know reaching out kind of learning from the other teammates call it that right we're trying to learn from them you'll probably uncover that there's some challenges now instead of you going back to your manager and saying I want to go change this we should go do this you might be able to get the team to kind of rally behind something you might be able to leverage some more senior people on the team to speak up and again I think that you know teams I manage I like new people being able to speak up and share things but I am not the manager of this team and I want to be careful about the advice I'm giving here so I want to make a safe place in general for everyone on the team and if this manager is not really doing that you might be able to lean on some of the more senior people and kind of seed the idea with them and they might be able to bring it up and that way maybe the manager is like oh even the senior people are kind of saying this maybe we should look into this again not a huge fan of that but in this circumstance it might work I'm going to scroll a little bit lower and see if anything else was was added daily demos yeah no thanks this sounds like the least productive method possible and it's got 40 up votes like yeah um I agree this sounds this is why I said it sounds like someone tried tried to pick you know let's do Agile and they just made a process that sounds like they picked agile things yeah um other people are saying might be time for a new job so this person was saying okay someone was like maybe when you go interview next time like you should do a better job asking this is what I don't like about Reddit I think it's like good advice but um I'm going to read this out because I this is exactly why I don't like Reddit cuz people are pretty crappy on here this person responded and said in a quote I am in literal hell and everything is on fire the devil is poking me in the butt daily is this reasonable for a holiday Resort they say this is what you sound like like I don't know I just like you didn't have to say that like why are you being a butt you don't have to do that seems like a crappy way to deliver a point then they go on to say find a new job and figure out how or what questions to ask for your next round of interviews they're basically saying like it's your fault you ended up here like maybe but like do you really have like I don't know I don't like being talked to like that I wouldn't do that to someone else I don't know why people are like that on the internet I don't know if I'll ever know but here we are um then this the op goes I did I did ask the correct questions my specific question was how is a day as a developer what methodologies do you use do you have a lot of meetings and the answer was simple saying that depends on the the project I would be allocated but most teams use the Casual scrum Canan I guess I just got unlucky I literally bet you that they think they are doing scrum and or can ban by doing this somehow without a board somehow by not actually being agile but I bet you that's what they're thinking H and then this person says big Tech boss says to do this but isn't on Sprint board boss is okay and adds it uh that's not safe for work I'm not going to read that out loud that doesn't sound like big Tech to me at least where I work um I don't know I'm pretty flexible on stuff the feature crew so I have feature Crews which are like teams within teams and we will like I don't impose anything and I've actually had people literally when I joined this team they said we would like to use a like a Sprint board it's a great let's go do that like I'm happy to do that um and I've worked you know on other teams where it's like they just don't need it and it's because of how we're working like the situations are different I don't come in and impose anything the thing that I try to impose is that people make sure that their voice can be heard and that we can make things better but they got to speak up about what they want to change um let's see anything else that's interesting here yeah if someone asked me to do this I'd laugh the fact that this manager even convinced a team of people to do it is actually somewhat impressive daily demos off of verbal instructions this guy invented a new form of torture yeah um yeah interesting this last I'm going to this last one before I go to another topic here any environment where you have to do daily demos is maximally toxic sometimes you'll have to spend an entire day reading documentation have nothing new to demo yeah yeah it's like the I can get behind the ideas of demoing right but you need to I think there's a lot more context that has to be provided to an engineering team to be able to do that effectively and I can see it being a big time sync um like I I think an important thing to to identify is like what is the goal of demoing because if the goal of demoing is to have everyone learn from it like maybe that's Overkill to do that every day if the goal of demoing is to make sure that people are staying on track with the product owner and expectations okay like that might be encouraging you to try and get smaller incremental commits right you are not doing huge long lived features where you know after 3 weeks you go land something and the product owner is like what the heck is this this isn't what we talked about it might be trying to encourage some of that but you don't need a whole team together to do that that should be a conversation between the developers working on the feature and the product owner and yeah like I think personally daily like daily interactions like that might be Overkill although I've worked on really small teams that I've managed context here is like I spent a big chunk of my career managing teams and being the engineer on the team as well so I direct reports but I was also coding and there were times where we would almost daily have demos but it was like it came up naturally like we were excited to show off what we were working on and our product owner was excited to see so like that was just a normal natural thing not like a okay it's whatever o'clock you better show me or else like so a lot of stuff on here not so great um but yeah I kind of offered some of my thoughts a little bit earlier that's how I'd look at that how do I create transparency with regard to missing work performance of colleagues this one could be interesting let's see apparently not okay just completely gone maybe this person got totally flamed on Reddit it can we just read this part and fur the rest I don't know if there's enough context here maybe not okay let's keep going on I don't want to talk about contracts [Music] no this can be interesting how to deal with lack of process causing bugs on large production platform I work on large production platforms let's see uh I work for a big company and until recently I used to work and pretty much manage our internal tool okay life has been quite easy for me we're never too concerned about bugs or general performance uh company didn't want to invest extra resources okay kind of like okay you don't got a lot of resources you're not going to spend time on that stuff is what it sounds like so their team front end and back end always lacked a clear process and usually preferred let's do this for now and if it breaks we'll fix it later favoring faster delivery over quity okay I could you know no one set the precedent sure like nothing nothing wrong with that if that's what the team values right it's it's only wrong if people have different expectations of that so we don't really follow Agile development it's more of a constant stream of tickets and we just try to deliver them fast I mean this sounds agile to me we just try to deliver them fast we barely do any refinement of the Tas so most of them have little like add this feature to this page and the body of the ticket is empty yeah I mean this is this is as agile as it gets now I've been as now I've been assigned to work on another team's product the main customer facing app it's a very solid project and I enjoy both their code and their process however in the past month had a couple of occasions where I deployed breaking changes which resulted in small and fixable issues with some functionalities on the production platform oh oh here's a strong word I blame this on my team's process where for example asking a PM to review the changes means I'm spending five minutes doing Quick Test approving they don't have QA and the same can be said about most people in our team forcing me to put extra effort on figur out all possible scenarios and testing my own code deeply okay question am I expecting too much of my team and instead I should spend more time understanding all possible use cases scenarios I mean this is a bit of an exaggeration and I I it's hard to I don't know what the right way to to say this is but it's hard to say yes to this because I want to say yes you should spend more time understanding more use cases and scenarios but it's there's no no one that understands all possible use cases and scenarios it's just like it's not an achievable thing it just isn't because even if you had your whole team go look through it and you release it I can guarantee you a customer is going to find a different use case and scenario that you guys never thought of so I don't think it's fair to ask this question because no you should you're not going to find all possible use cases and scenarios but should you spend more time yeah and that's going to take time and domain experience for sure so I think you should am I at fault for missing certain use cases and breaking existing functionalities because of that um like yes and no like should you feel bad about it absolutely not absolutely not you shouldn't feel bad about it are you are you air quotes at fault like a little bit but not on your own right like this is the thing your whole team is equally at fault this is and maybe not the way your team is set up which makes this hard to answer but I want to I want to talk through this like if if this were a team that I managed right like I would encourage people to be thinking more about use cases and scenarios for sure if you miss them that's okay it's not just your fault it would be also my fault too right as the manager of the team it's everyone's everyone has a bit of a role here when we when we have gaps or we have regressions and this is the thing like when you I'm saying everyone has a responsibility so everyone has a little bit of blame but it's also what makes it blameless right you would have a reflection on this type of thing and instead of going what's this Poster's name Sor the dog so instead of saying hey sorte you did bad you should feel bad we're going to punish you we would just try to close the gaps so why did we miss that scenario how could we do a better job next time and what experiment are we going to try to make that better what are like the you know repair items what comes out of this that we're going to learn to do better next time if that means like you know for you you you have a little bit more responsibility to spend more uh some more time on stuff great okay are there coded tests that we could be writing on this type of stuff could we have earlier feedback could we have more specialized feedback right there's so many different things you could start to explore here so my response to this person is not you know are you are you solely at fault and you should feel bad for this like absolutely not right we have thousands of clients and often some of them require different implementations okay so I like to avoid these situations where I feel like I messed up not because of quote quality but more due to lack of testing Communications and over relying on other people such as my PM tldr my team doesn't really follow a proper process how can I enforce a better process to prevent the release okay so this part here and the last part how can I push them to use agile practices properly this is probably a good one to end this stream on cuz this is not planned and it's actually bringing stuff back full circle we love when that happens so how can I push them to use agile practices properly and I wouldn't personally I wouldn't and the reason I wouldn't is because I would say how do we get the team to continuously improve see what I did there it's not going to force agile we're not forcing anything we're not pushing anyone any direction except how do we get better and to me that lowers the barrier dramatically right you are a team you all want to do better you are experiencing some friction other people are probably experiencing similar friction cool how do we do this better what can we try and this is where I would say I don't know what other processes you have if you don't have a retrospective in this case we're talking about some incidents from things breaking something similar to a retrospective in general for your processes that are in place or a post incident review postmortem in some cases it'll go by that name you have a review process to talk about things that you may want to change start with that do it informally do something right start making a habit of introducing this thing where you can reflect and start incrementally driving little experiments hey we didn't like how that went what can we try doing next time what's a little thing that we could try adjusting and you build momentum this way so I would try to rally behind that try to get some Buy in from other team members so again circulating kind of asking like if other people you know learn from them how are you getting through this how are you avoiding some of these things seek to understand because you will learn a lot of stuff from other people on the team and you might learn where their challenges are too and then you can start to say hey like you know on this thing that we did it seemed like this was a common challenge do you think we could try things this way right and you start to just introduce little experiments if you can get your whole team bought into doing something that is focused on continuous Improvement so you leverage a retrospection post incident reviews you get in the habit of identifying things that you want to try to make things better try them out and then you reflect again and say if it was better or not that's what I would recommend here not pushing a team to go use you know agile practices I don't know maybe agile's not even a good fit for this team like I just don't know it's not for me to say I think probably it could work well without knowing much about it I think in in a lot of situations agile can work very well but I think the big thing here is that there isn't a like no one is working together on refining this process so do we blame it on the teams process I don't blame it on the teams this so I'm going to highlight this sorry again Instagram folks you can't see what I'm highlighting because it's a little bit off the screen I think but I don't blame it on the team's process directly I blame it on the team not improving their process and refining it is how I would look at that so I have been in situations where um so they're saying they don't have QA I've been in situations where and I'm going to walk you through this briefly and kind of wrap up this stream but going back to um even the Prototype product I was talking about earlier when that started to become more real um one of my one of my very good friends and so former colleague from this team he was a he was a test strategist that we had hired on hello Andreas from Greece thank you I am wrapping up soon though so I apologize um I should mention before I finish my thought on this I am going to try to stream in the morning and last time I said this I slept in because I couldn't do it and I I streamed at night I'm going to try to stream at 7 a.m. PST I'm going to try to it's going to be it's going to be in the morning tomorrow hopefully 7 a.m. PST um and I'm going to be going through code tomorrow so that'll be different okay but my to wrap this one up on that prototype uh product that was becoming more real we had a test strategist that was on our team and one of the common things that a lot of testers were doing because our organization had developers and testers it was very common for developers to go make something and then pass it over to the tester and say now you go test it I'm going to go work on the next thing and we knew that this was a crappy way to develop software at least for us so I don't want to say if it's working for you that it's wrong it was crappy for us and it was crappy because there was so much context switching it was just ridiculous because what would happen like 95% of the time is you would be all done done say hey tester go test this and in like a second the first thing they do it was broken and they're like well why am I going to go test the rest of this if it's already broken or let me start clicking through and immediately it's like this common theme of this stuff being broken and you're like okay like forget it I'm going to go back and change this so it was just ridiculously ineffective and we got in the habit of finding ways where we could do a bit of the development together so almost like not quite but almost like a bit of PA programming around as we're building the feature how are we planning to test it like what are the scenarios we want to go walk through and the evolution of this that I thought was so cool was that we got into a habit of writing coded tests for almost everything we could to the point or I could work with this individual on my team and the other developers were doing the same thing we talk about what we wanted to have tested in terms of use cases and stuff and I could go to him and say here are all the tests you can check it in the code riew here are all the tests for all the things we talked about they all work I can walk you through and he learned some of the code over time and the testing scenari so this got easier and easier but I can walk you through what these test du so that you have confidence that those things we talked about are test they're covered we should feel good about them and this is by the way when you hear me talk about the purpose of test is to build confidence this is where it all comes from so we would work together this way and what started to happen was that there was so much confidence from both sides where he would start to look at the test and go oh you forgot to add this one we talked about or now that I'm looking through this I wonder do we have a test that covers this other situation and the other thing that we layered on to this was getting him builds very early so they wouldn't even be done but if we had something that was compiling that he could start to use when he had some downtime he could start to click and try things out and just start to think like if I go to use this feature I know these things aren't done yet is there anything else I can think of so we layered these things on together but it ended up making it such that we could write tests for so much stuff and instead of having testers manually go click things they ended up having a lot of confidence in what we were building up front now this did involve an evolution of how we were testing stuff so I I'm PL I'm I haven't decided for sure I'm going to be flying to this is kind of cool actually I'm going to be flying to Dallas on the 23rd of uh of July so this month 23rd I'm going to fly to Dallas and I'm going to give a talk and I think I'm going to do it on this topic it's between testing and plugins um but I want to talk about testing because we evolved how we test how we write code to be testable to literally being able to test user interfaces in code headless and being able to communicate that to our testers because we built up Confidence from their testing role and our development role to be able to handle this hello rambling geek good to see you back I'm sorry that I'm just wrapping up my stream but I was just letting people know that I'm going to be back on in the morning hopefully 7 a.m. PST that's my goal it'll be coding but to wrap this up on the on the quality side of things the testing side of things like I just bring it back to in the example I just gave you regardless if you're like I don't want to go do things that way that's fine I'm not telling you you have to go approach things that way you might have a different team setup that's totally fine the thing that I'm trying to encourage you to do to bring It full circle is work with your team and continuously try to improve you need to reflect try things out and do different experiments measure them see what works see what doesn't and keep on going so I hope that helps I'm kind of glad that we came across this one at the end to kind of wrap things up but that's why I think retrospectives are so important so thank you folks that's a pretty long one for today I got to sleep I got to stream in the morning right um I do appreciate it if you uh if you have any thoughts or questions please let me know send me a message uh you probably notice that I'm basically on every platform so what ever you're comfortable being on send me a message if you want to see other topics covered um I do want to start I haven't figured out a good format for this I want to be able to start doing code reviews I might do it specifically for Discord community members and that way it's a little bit easier to manage so if you want to join the Discord Community you can check out my website um what's a good way to do this one sec it is a paid for Community by the way this is how I give Priority Access to people so this is a bit of a a plug um but on the code reviews I'm thinking I want to get people from the Discord Community I'm just putting it in the chat um I will get Discord community members if they want to share code I can talk with them about what they're comfortable sharing and that kind of stuff and then that way I can review it live and my goal with that is that I don't want to like have people submit code and then we're like roasting the code like that's not uh productive at all and I quite frankly think that would be kind of gross to do I'm not a fan of that I would love to be able to have uh Discord community members submit code and then I could review it like I was reviewing code at work right so I could might you know if I'm streaming it if they're on the stream I could go ask them like hey like what does this mean like could we talk about it I want to be able to go through code offer some advice and then demonstrate how to approach doing code reviews so that's something else I want to kick off on some streams but tomorrow morning will be code will be in C I'm probably going to do some WPF stuff been doing a couple WPF videos it's funny I've been getting direct feedback um about the WPF videos people really like them they're like thank you so much for doing this but my views on them are abysmal like my channel is like tanking putting WPF videos up so it's kind of kind of crappy but I still want to do some because I think they're valuable and with that said I have I think another three WPF videos already recorded they should be going up over the next week in a bit hello there on Twitch I'm just signing off so sorry about that I will be back on in another eight hours or so and no one likes process whether necessary or not hard sell yeah it's uh It's Tricky It's Tricky but I think one of the ways that I lean into that is one of the ways I lean into that is having the team come up with the process right I don't like enforcing it all right folks I will be back on in another 8 hours or so and I'll be coding so hope to see you there thanks for tuning in and I'll see you next time or in the morning or evening depending where you are see you