Who The Hell Wrote This Code?! - Principal Software Engineering Manager AMA

one sec we'll go live there should be good to go I think I'm live everywhere welcome uh for folks that are joining uh just a heads up if you don't mind send a message in the chat that way I know that it's working because I have done streams where the chat's not working and I have to make sure that I'm following along for questions and stuff on other tabs and and things like that that I have open so uh please uh let me know if you're you're tuning in uh where you're tuning in from again just helps me know that the chat's working and would love to hear from you so uh if you haven't been on my streams before they're very much an AMA style regardless of the topic so uh definitely feel free to jump in at any point write a comment ask a question I don't care if it's unrelated to the the conversation which is going to be about uh getting into a team or a code base and then asking questions regarding like you know who wrote this code like why are things in the state that they're in so I'm going to provide some history around that um frame it up I see uh my un Jane on LinkedIn uh from Seattle awesome so you're not too far away from me I'm uh I'm in the Seattle area as well good to see you here thanks for joining um so again yeah leave any questions comments as we're going through this I want it to be interactive I always let people know if I just wanted to get in front of a camera I would be recording YouTube videos so I prefer if I can be spending time answering the things that you want to talk about so these live streams so for me it is a Monday night it's uh just just past 9:00 p.m. and I do these streams focused on General software engineering topics career um career growth management perspective that kind of thing and what I been trying to do and it hasn't been working out too well recently just because of my schedule is the next morning at 7:00 a.m. I'm trying to do a live stream where I code the coding ones get a lot more traction I realize that people like to see code being written they like to talk through it that kind of stuff so um I'm trying to get back into the swing of that but I wanted to do it this week and I ended up swapping an on call rotation with someone so that means that uh not only can I not do the live stream in the morning because it'll conflict with my on call uh that would be a very terrible thing to to have overlap I also can't go to the gym every morning this week so uh kind of a bummer uh because the on call shifts are 12 hours long 6 to 6 so um I will try my best to resume next week for the live coding in the morning so again these ones every Monday 9900 p.m. PST for General s for engineering Concepts so I'm going to like usual kind of walk through my most recent newslet letter article so if you're ever curious what I'm going to be talking about for the most part during these streams it is on my newsletter I'm just going to drop a link in the chat if you're on Instagram or you're on Tik Tok um you are not going to see the chat uh from the other platform so I apologize but it's just weekly. deev leader.com check it out and not get it delivered to your inbox if you want to see what I'm going to talk about um infected FPS good to see you back can I use your morning stand as an excuse just skip stand up yeah your morning stream that's right yeah um I I'm not going to advocate for that or advise I'm cool with it but I'm not going to I'm not going to rubber stamp that because I don't want to get in trouble from anyone so uh great to see you back though thanks for thanks for tuning in I appreciate you being here okay so I put the link uh to the newsletter article which is the topic for today and it's titled who wrote this trash so I wanted to talk about this because I think it's a really important topic I think that a lot of people uh either if you are newer and you haven't really experienced this you might be the person saying this kind of thing and for other folks if you've been around for long enough you've probably been in areas where people have onboarded whether they're new to the company or new to the team and they say this kind of thing about about the code base as well it doesn't just have to be the code base I realize as software Engineers we usually talking about code so I get it but this could be the build system it could be uh your onboarding process it could be any part of the business right so it's just more relevant I think in this case because we are software engineers and we talk about code a lot so the context behind this and why I'm sort of I don't know if I can say passionate about this because it's I haven't really explain the topic necessarily but I I think it's important to talk about this thing because I have experienced it at a startup being someone who was around for a long period of time and we talk about people like this like almost like historians of the code right they've been around the product and the code base for a long time um doesn't mean they're the best or anything like that it just means that they've seen a lot of the code and how things have evolved they're a historian for the code base so I got to be this kind of position uh like obviously it's like an informal type of thing uh Hey on Instagram good to see you uh I don't know how to pronounce your entire username there but I I do see you there um so when you're in this type of position where you have people onboarding and they're talking about things I experienced this a lot at the startup I worked at called magnet forensics and this is just prior to Microsoft and I worked there for eight years uh I was roughly around employee number eight I don't actually know but it was something roughly like that and it was uh uh over you know 250 people by the time I left so um I got to see this happen a whole bunch so and oh from Turkey awesome on Instagram so welcome it's awesome to see people Tune In from from different parts of the world so at one point in time uh I decided uh at the last place I was working magnet forensics that I was going to start giving a talk about this and that's when I say like I'm passionate about it I just think that it's important to talk about because it's different perspective um and then uh yeah infected FPS is saying in the chat I used to ask who wrote this crap on a daily basis in my last position I was the only contributor to the repost yeah so I do want to call out for this context because there's another framing for this which is exactly what infected FPS said we're always going to be growing from the code that we've written right we're going to write something today and we're going to think it's amazing and if if you're really Junior you might find in a week you're like holy crap I can't believe I wrote something so terrible how could I the more uh Advanced you get and and more skilled you get hopefully the longer the periods of time are before you go holy cow I can't believe I ever wrote something so bad but I've been programming for 21 years and I still come across code and I'm like oh man what was I thinking so yes there is going to be this observation about our own code and I don't want to dismiss that it's just a different topic than what I want to focus on today and instead of thinking about our own personal growth and how we get better as programmers which does kind of factor into this I want to think about this more from uh growth of a company and growth of a codebase growth of teams okay so that's going to be the framing here so at a startup if you're trying to keep a company alive you're moving pretty fast generally so moving fast does not mean okay let's not care about anything let's just rush through let's deliver a crappy code let's just do whatever we want that's I think some people hear like what I'm trying to say and then associate it with like you're just writing garbage code you shouldn't write garbage code it's not what I'm saying what I am saying though is that when we are engineering software engineering is all about pros and cons and tradeoffs that we have to make so when we're talking about keeping a startup alive we need to be and this is not just true for startups for businesses you need to deliver value to customers this is your goal at a bigger company you can take more risks because generally you have things that are a little bit more distributed in nature you don't just have one product necessarily or one feature that's going to keep the whole company afloat at smaller companies everything's a little bit more risky because if you don't deliver that software and you don't get the next client that kind of thing you can literally be in positions where your company will not survive now that might might sound like an exaggeration and fortunately for us it wasn't quite so bad uh we did have uh you know I want to say the luxury we did have paying customers even early on so that was good but truly you need to be focused on delivering value so what does that mean right you have to work with your teams to understand this but that might mean that uh if you have a bug in the software you've written something that does need to be refactored you might be asking yourself the question like do we really need to go rewrite this part of the code right now like is that actually going to help us with the next stage or should we be focusing on delivering value to the next area of the product this part we're acknowledging maybe Isn't So Clean you know air quotes clean I don't really like saying that because it's very subjective but maybe it doesn't have great unit test coverage on it or we've experienced a couple of bugs there that we've had to patch up and looking at the code we're like yeah that would probably be worth redesigning but we ask ourselves like is it worth redesigning right now because if we could be delivering more value and that code is currently not broken maybe it's worth just continuing on in another area of the product so the whole point of this I'm just trying to frame some of this up is that we are constantly moving forward we're constantly taking steps and even as things start to stabilize at a company so even as we are uh growing and it's feeling less and less like we're just trying to fight to stay alive yeah we are still going to encounter situations where we are making decisions with the best information that we have at hand sorry with the information we have at hand to make the best decisions possible I kind of butchered that sorry so the whole point is that we are constantly in these scenarios trying to understand the information around us making a decision for our future and then going forward and then we repeat this right so we have to make more decisions okay what's the information we have at hand what can we try to predict let's do a best effort do it and move forward rinse repeat so what ends up happening over time is that when someone comes in and they don't have the context of everything along the way it's very easy to be in a situation where you look at something and you might truly say like why is this so bad and it might like genuinely be code that is bad it might be poorly designed it might be brittle it might be slow it might be all of these things objectively it might be bad but the problem with this is that when you walk into somewhere and you say something along the lines of like who wrote this trash who wrote this crappy code um how could anyone have ever done this anything along the lines like that you're failing to acknowledge that someone wrote that at the time with their best intention they used the information they had they made the best decision they could given the context and then went ahead with it so I always like to say when I talk about this and this is going to be some additional framing here is that I do think that it's important to join teams to join companies and to ask questions I think it's extremely important to be doing that but I think that there's two primary ways that we do this one is the one that I was just talking about where you have someone who is kind of being factious right they're sarcastic in nature they're seeing something they think holy crap this is terrible oh my God they're rolling their eyes at it um you know they almost like feel embarrassed that someone could have done it uh they're making fun of it and the reality is they're looking at it like I got I got to get rid of this garbage I got to move on from it whatever it happens to be but the problem is that they are not acknowledging the context in which that code or that process was created okay so this is the one way and this is sort of the negative way if it wasn't obvious the other way is to come into this situation and to be genuinely curious so yes when I go to frame this it's going to sound very different but I'm still asking about what the code is right so if you were to turn to someone on your team and say why did we write the code this way I'm just trying to understand it more clearly or who wrote this so I can talk to them about it so that I can understand what it's doing and why we needed to do it right if you're genuinely curious you are seeking to understand why the code is the way that it is I think that that's awesome now you might still fundamentally disagree with why the code is written that way like I said it could be objectively bad right it it could be literally objectively bad it's not even your opinion and I think it's still important to be curious because the whole point of being curious is getting the context you are acknowledging that someone probably had the best intentions right they were trying to do a good job and at that point in time if you have the context and understand why it makes it a little bit more obvious why they might have made that decision so um hopefully that makes sense I was going to say I'll pause for a second but I don't see any questions rolling in on the chat uh if you before I continue on to some examp I see more people have joined I'll just repeat that please at any point in time in the live stream uh feel free to ask questions in the chat as I'm talking I am literally watching the different Windows to make sure that if people are sending messages I can stop and address you I just like to finish my sentence usually but happy to answer any questions whether or not they're related to this topic if you just want to talk about software engineering career advice C perspective from a manager whatever it happens to be please just leave a comment uh in the chat and I and I'll get to you so thank you okay so kind of talked about the two framings here right and the I'm going to before I get into the examples on the negative side uh because I like to do some storytelling around this on on the being curious side I do think that it's important to do this and I think that uh even like regardless of your experience level because you might be more Junior listening to this or watching it and saying well you know feel kind of like I'm not in the right position to be able to you know to challenge these things or to ask about them I'm not the expert you might have people that are watching this who are more senior um maybe they feel like hey I don't want to step on anyone's Toes by asking this kind of stuff or maybe they feel like they they know better anyway so why should I bother asking I think that being curious and asking questions can like almost be a superpower if you're doing it genuinely and the reason I say this is because I've had to try and live this as a manager so when I worked at the startup that I was describing uh I worked there as a technical manager uh Willow on on Instagram I am doing good today I hope you're doing well um so in that previous role my technical management position meant that I was writing code and managing teams at the same time I lost my train of thought that's so embarrassing uh um on the genuinely asking question part there we go I knew it would come back so I had the luxury of understanding how these things were built over time working in these different product areas and like I said being a historian for the lifetime that I worked there now when I came to Microsoft I had no such luxury I I was coming into completely new domain I had no historical context I had no domain knowledge I just had experience working in C so I could relate to the developers at least and um and then I could basically focus on managing people right so I had you know a background in software engineering I had a background in the language that was being used but I knew how to manage people so um I make sure that when I come into a new area I am genuinely asking questions and and I do see a couple questions I'll get to you in just a moment um for me asking questions is not only so can learn so people should be doing this so they can truly learn genuinely and when you're asking questions you might not realize this but you can actually be helping other people who do have the knowledge think through things again so before I come back to that thought I'm just going to answer a couple questions in chat um on Instagram I do stream to Twitch so if you just look for Dev leader on Twitch I stream there as well uh I'm currently streaming to LinkedIn Tik Tok twitch YouTube Twitter Instagram Facebook kick I've never even used kick so I I have seen people from kick tune in so yeah on all the platforms it's just Dev leader uh my young in uh in the chat here from LinkedIn asking for a student what if I contributed to building native product I got laid off because the product was stable enough is part of the prod uh reduction of Workforce um so I'm not sure uh what the what you're sort of asking about for this question so asking for student contributed to building a native product got laid off because the product was stable enough as part um are you asking about how to talk about this when applying for a new role are you talking about how to uh interpret how you should feel about this um just let me know if you can clarify the question a little bit I understand the context but I don't understand and the goal of the question so uh if you can add a little bit more I'm happy to answer uh and Willow on Instagram every Monday at 900 p.m. PST is this stream for me and it's been a little bit less consistent but I try to do the next morning at 7 a.m. PST is live coding so this week because I'm on call for work I will not be able to do that but hopefully next week I'll be back to doing that in the morning so yeah Myan if you can uh clarify your question I'm happy to try and answer a little bit more clearly sorry okay so this idea of asking questions right you're coming into a team you're new to it you're asking questions I had mentioned that it can get other people to be thinking about things in a different way and to give you an example um you might come into a team and someone say let's say you're for me I I started at Microsoft and I had a principal engineer uh on my team and tremendous he had been around for a long time uh and he had all of the domain knowledge he was truly the historian in this space and there were times where I'm asking him questions because I'm just trying to learn and understand the system and he might say something uh along the lines of like hey like you know we do X or Y and I go oh well well why like can you explain why because to me I want to understand it because on the surface it's not really making sense why we might do that right so kind of pequs my curiosity and I go well okay well I see the the point of this but I don't necessarily understand why you would do that so can you enlighten me and then he would explain things and then from there I might say oh have we ever considered this or that or you know just trying to understand a little bit more about the context and the framing and a lot of the times but what happened is it's yep you know we we considered things like that at the time we were uh you know considered these these couple of options and we went ahead with this one here's why okay makes sense but there are occasions when I can recall several of them with this individual specifically so this is just one person when I'm on boarding to a team where they're saying oh you know what once upon a time we did talk about that and at the time didn't really seem like it was going to work or it it didn't it wasn't a good fit but now that you've mentioned it these other things have changed and it might be a good opportunity to revisit this so your curiosity just from asking questions and trying to learn can end up having other people that you're working with start thinking about things in different ways they can start to reconsider things so that's why I say it can be a superpower if you lean into it you can not only help yourself learn and understand get all the context because people are happy to help you learn this stuff but you might get people thinking about things in different ways um I don't know if my uh my friend and former colleague gr Harvey coined this term I like giving him credit for it because uh I heard it from him but maybe it's not him as the original uh author of it but um he calls it like ignorance as a service so truly as a manager I come into a space I am ignorant to things because I have not experienced them before and just by being curious right like here my ignorance I don't understand this please help me understand that provides a service to the team um checking on the chat uh I do have someone who does uh editing and stuff so I appreciate that I have no other funds for art I do appreciate the offer but I will uh politely decline that uh my okay so reading your question goals to navigate better uh continue the goal to navigate the job interviews okay understand the pros and cons from interview point of view okay perfect y so um I think something that's important to address um like when we're talking about interviews in general uh my my perspective on interviews is that the interviewer has a goal and that's to basically try to extract as much valuable information from you as the interviewee that aligns to the job so instead of and this isn't true for every single interviewer unfortunately it feels kind of weird to say that but um the goal should be to like to not be gatekeeper they're not they shouldn't be trying to prevent you from getting the job they should be trying to work with you to extract as much information as possible right because it's a waste of their time if you're sitting there and you can't give them valuable information like they don't want that they want to make sure that they can learn that information from you so I like putting that perspective out there now to this question in particular if cont uh contributed to building a product and got laid off because the product was stable enough and there was a reduction in the workforce so what you don't want to have to worry about as an interviewee is the last part of that so laid off because the product was stable and there's a reduction in the workforce there are going to be situations in businesses and I'm not a fan of layoffs um I really don't like the idea of it they do happen so if there was a business decision that we don't need to invest further into this product and and I'm not trying to justify this so please don't uh misinterpret what I'm saying if the business happens to decide no longer investing into that product area they're unable to move people around to different areas and they end up doing a layoff I don't want candidates to be concerned that like that automatically looks like they were not valuable right there is a separation between the product area the business area and the individuals and I think that it's a huge Miss to try and not keep the individuals if you have great people like people are one of the most expensive things for software development right we want to make sure that we're spending the time and the money to get good people because it's costly to go through more people so I think we should do whatever we can but if you haven't seen other people posting about this kind of thing over the past few years in particular there are plenty of people who had like you know literally 15 20 20 25 year careers at big companies uh had that have done tremendously well that got laid off and it's just because the the business unit was like no longer going to be something that was contributing so again I'm not trying to defend that perspective or anything I'm just trying to say that you want to be able to try and separate yourself from the layoff part so if you had been contributing to a product area right and you were laid off I think that you just like you don't have to make that the focus so if you are working in a product area use that experience to talk about it right you can you can literally think about this as what would that situation look like just omitting the layoff part like it it's almost not relevant to the interviewer and I mean that as someone who's doing like I am currently interviewing for different teams uh and I have been interviewing over the past 12 years like if you were laid off that doesn't change my perspective about like about the thing that you were doing because that's not in your control if the company's making a business decision about the area so I think the way that I would approach that is again if you um so I'm going to do a little bit of a Shameless plug here but Ryan Murphy and I have a course that's coming out on behavioral interviews uh you'll notice that Ryan and I are talking about Behavioral interviews a little bit more leading up to this course and we'll have more and more content coming out sort of from the manager's perspective Ryan already posts a lot of content like that which is great but again the goal here is that when we're talking about behavioral interviews this is something we talk about in our course a lot you want to be thinking about what the goal of the question is so if someone's asking you in an interview like tell me about a time where you had a conflict with a teammate tell me about a time you were leading a project tell me me about a time like tell me about a project that you really enjoyed working on and what you did enjoy like all of these things you want to be trying to understand what the goal of the question is the goal of the question is probably never to put you on the spot to make you feel awkward about a layoff it's just not a goal so if it's not a goal don't focus on it it's not relevant so my I'm not sure if that helps um but I think that um you know when you're trying to navigate that or I know you said asking for a student so if the student in this case is like they're concerned hey look I worked in the spot got laid off can I still talk about this project like yeah absolutely um if it wasn't a good project to talk about though like if they didn't have meaningful experiences that translate well to behavioral interview questions then I wouldn't but it has nothing to do with the layoff part so I I hope that helps from at least my perspective let me know if you want me to clarify that anymore and I'm happy to do so um Omar um I'm a programmer 3 years of experience in net in an effort to improve my skills I try to learn about best practices patterns architectures yep uh but sometimes I feel like it's too much and in the end I don't apply or internalize it yes okay so um Omar this is um something that kind of sounds like tutorial hell and the the term tutorial hell is I'm using that just because it's more catchy and people talk about it more but you could you could leave out the tutorial part and just say like I only I don't even do tutorials I just read books on this stuff right just read posts or just watch videos right like yeah it's it's it's the same thing um what ends up happening and this is the same for any skill so Omar I want to give you a completely different example that's not programming related because I think it will sound funny and make my point more more obvious okay so I Nick centino I want to to get good at basketball so what are my options to get good at basketball well I don't know a whole lot about basketball like the rules and everything like I got I know a little bit um I know that I'm probably not going to be super great at it because I'm super short but you know what I still want to learn I want to get good at it so what I'm going to do is I'm going to buy a couple of books on Amazon about uh how to play basketball I want to get Basketball for Dummies I'm going to read that front to back I'm going to start watching some YouTube videos about the most popular basketball players and see what they have to say about basketball and then I'm going to start reading some of the articles that the people like basketball coaches are posting online because I want to get in tune with that and you know I'm going to do this for a few months and I I think I should be good at basketball by the end of that and I'm using this example because it probably sounds ridiculous because I'm not going to be good at basketball even if I wasn't super short I'm still not going to be good at basketball just by doing those things I might learn some things which is great I'm not saying that those things are not okay to do those are great things to do but the way that I'm going to get better at basketball is by playing basketball you can take this example which I tried to make a little bit funny sorry if it my humor sucks but um you can take this example and give any skill that you want to get better at and you can literally apply the same uh framework if you're not practicing it you ultimately will not get better at it you will never build the expertise and Mastery unless you're doing it so another more relatable example so we're talking about programming programming is done in a programming language uh often with you know text stacks and Frameworks if you are someone so um I I only speak English when I was in elementary school and stuff we had to learn French in Canada and so I remember having french I think from grade 4 through grade n and I think after grade nine we were able to stop now that's grade four five 6 7 8 n six years a French and I even in grade n like as soon as grade n was finished I could not speak any french at all at all and the reason that I couldn't speak any french and that I still can't speak any french is I don't practice it so uh Omar I'm I'm not trying to be factious at all here I'm just trying to give you a couple of examples right so uh I think it's absolutely awesome that you're trying to learn and get better at these things uh I think that what you're doing and you know trying to read things and learn about different concepts what however you're doing that I think is awesome I think it's good and I don't want you to necessarily stop doing that the problem or the challenge that I think you're facing is that you're not when you say I don't apply or internalize it that's the thing if you flip everything around and you say Okay I want to start building things I need to start applying what I'm learning right I need to I just need to start programming and Building Things if you do that you will often find that it will very much direct your learning as well so in order to do this I highly recommend if you don't have ideas for projects and stuff my uh sort of recommendation is to list down a couple of hobbies that you have uh if I do that example for myself I like cars I like video games um I'm trying to think like I I just started playing elen ring a little bit later than probably everyone else who played Elden ring um and what else I like to program um I like dogs I like cats like so let me pick a couple of things like that and then I would say What types applications are you interested in building and then I would just say go build an app related to one of those things that you're interested in and it can do the most basic thing ever I could go make an Elden ring armor index I could go make a Pokemon index Pokemon index would be sweet to go build um and you want to make a mobile app because you want to learn about mobile development cool like go do that um the point is trying to pick something that's align with your interest will make that learning experience feel a lot nicer you're not going to be saying I don't even like weather applications if you're a doet developer you'll know what I mean um like if you don't care about it you're not going to want to build it more when you're stuck but if you're like man I really love Pokemon and I'm I really want to see like how I can make this uh Pokemon database work like when you get stuck you might be like okay like I want to go learn about this I'm going to go research it it just kind of keeps you going for me personally I used a role playing game that I was building I started doing this 20 years ago it's still not complete it will never be complete but I use that as something that kept me motivated because it was super interesting to do so Omar I highly encourage you try to work on something you could work on a handful of small things there's lots of options but that's what I would recommend doing then using tutorials to unblock yourself um infected FPS I'm just catching up on your message here also good to focus on one thing at a time yep trying to learn everything all at once you lose some of the details uh in in the jumbo yep example focus on design patterns and getting those down before diving into DDD or something else yeah and this this ends up happening when you're like I don't have something to go apply so let me just jump to the next topic right if you put the project first you'll notice like I'm getting stuck on X okay go like you're playing around with it you're stuck on it go read about it go watch videos on it get unstuck the getting stuck part is unfortunately like the best way that we learn get stuck get unstuck I'm not the first person to talk about this and I won't be the last uh if you know who the primagen is uh he is a huge creator online uh he's talked about this a few times over the past like few months I've seen content where he's literally telling people he's a huge streamer um he's telling people on his stream like you need to get stuck you can't take shortcuts get stuck and learn so uh hopefully that helps Omar uh Razer sharp Fang we've had layoffs but Regional management wants more centralized engineering uh I don't sorry I might have missed the context for that one if you want to elaborate anymore if you had a question I'm happy to to jump onto that but interesting so it sounds like um they're at least the company where you're at they're trying to get people closer kind of reminds me of this this Amazon situation that was uh just today that's uh pretty pretty interesting about the return to office 5 days a week uh and I see Buran uh thanks for tuning in from Facebook and I I can't tell but it looks like you just tagged a bunch of people so I I do super appreciate that uh I do appreciate all your support okay I got through the questions so far thank you keep them coming if you have them um the next part of my newsletter that I want to talk about back to this idea of you know who wrote this trash is I wanted to talk about these funny I'm going to call them funny scenarios but these real scenarios that would happen at the place that I used to work and the idea was that when I I so I mentioned this earlier in the Stream you might have just joined uh I apologize if you're watching the recording of this and you're like why does this dude always repeat himself it's because there's other people joining so um the the idea that that I had at the last place I worked was that I kept having these situations where people were saying you know I could literally hear them in the office like oh man like this code is so dumb who would do this and you know like I had written a lot of the original code so like I could put up my hand and say like probably me and like let let me walk you through it um but I realized like if it if people were talking about me this way I'm like I don't I don't care I've heard it enough it's I feel like it's unfortunate but like it's okay um I have I have enough confidence in what I'm doing to like not be totally bothered by that but what I really didn't like is I noticed when it was happening to other people I was like that's actually not okay right like I need to make sure that I can step up and you know speak for people that are are being kind of hurt by this and I will mention that when people do this kind of thing and they're like mocking the code or the processes and stuff their intention is still not to like hurt people right that's not their intention in fact they're usually trying to get a rise out of people like right like we all think this is crappy right like haha it's funny but unfortunately it comes across in a way that's just truly not positive so I started realizing this was happening more and more which you might expect as a company is growing more and more and you're going to have people that are newer and don't have context so I had decided I'm going to make sure that um I'm going to start talking about this so I don't only given the talk two maybe three times and wanted to keep evolving it over time um but the idea was that I would periodically give this talk and that way when there were new people at the company they could hear it and hear about some of these things so in the talk I picked a couple of uh sort of things that I could walk through and they might be relevant I tried to find things that were outside of uh the development process as well so those might not resonate here so I'll leave them parked but you can apply these this type of Storytelling to things truly outside of code just as a heads up and what I would do is I would would explain like the current scenario of things so I would say okay like you see how things currently are but here's what they used to look like and then I would keep going back in time until I could explain to people here's how they started and what that would generally do is paint a picture for people where they would understand like look this has come a very long way and the other side of that is that sometimes we don't realize that everything else around some area is getting improved lots and this other area is kind of just left behind but at one point in time it might have been very good so I'm going to start going through these examples there's a couple of them uh I think I'm going to try to go through three of them in my newsletter I combined two of them into one and I'll try to separate them out and I just got to it might be a little bit rough because I'm going to try to to jog my memory as I go through these but again this came up recently because when I was talking to my manager at Microsoft one of the things that he said because we have a lot of new people on the team over the past couple of years he he made the comment he wants to make sure that people coming into the team feel comfortable and I like I really appreciate this kind of perspective right he wants to make sure people feel comfortable that they're not coming in going oh well someone else wrote It's kind of it's almost the opposite like someone else wrote this like I shouldn't question it I I should kind of like you know shy away from it they know what's up like I'll kind of just like start my own thing over in this other area um because I'm not the expert so he's very like cognizant of this and he wants to make sure that we can do everything we can to let people know like ask questions dive into the code like if you like ask the subject matter expert get them to pair with you like you're part of the team now like you get to be part part of this with us so I had mentioned that I used to give this talk and then that gave me the idea for the newsletter so that's just the the little bit of background here so um two examples that I want to give they're both related to things taking too long uh one was our build system okay so um where I work right now the builds take a little bit longer so this would be a great story to tell people uh if they had seen what we had before and what we have where I currently work but completely different scenarios but where I used to work the builds might take uh on the order of a couple of hours tops right which is not I think we were able to do them every hour on the hour but let's let's say that we went over so that's why I'm kind of rounding up here so for some people they might say this is ridiculous like I can see what we're building here and in fact we would have some parts of the code where it's almost like we had a lot of resources like projects and DS and stuff and we' have to go build a whole thing just to get a part of it like back out as a like a subproduct and people would come in and they're like well this seems ridiculous like why does this have to take so long right like and you know I I feel like I'm of the mindset where I want developers to have agility I don't want builds to take a long time so I get it but they're basically they're frustrated with it and instead of trying to understand things they're just like cursing at it right so um what they didn't realize is like our build system had gone through a huge Evolution I'm not going to go through all of the details cuz it's not relevant but we were using Jenkins to build things and uh we had a bunch of different products at this point in time having to build through Jenkins now if we were to back up from before Jenkins and this is what a lot of people didn't realize is that before Jenkins and before we had a whole team that was dedicated to like build an infrastructure there were two of us there were two of us at the company that were trying to put together it was called bamboo for jira I don't even know if it exists anymore probably not because I think they bought uh bit bucket and there's probably some type of actions thing there but bamboo was this jira build system and there were two of us that on the side tried to stand this thing up and were the builds faster at that time yeah maybe they might have been faster they probably were but did they run all of the time like absolutely not so like going from what we had with bamboo to Jenkins was an enormous step forward and there's absolutely no way we could have made at least with the two of us bamboo keep up with all of the awesome things that our build and infrastructure team was delivering we simply just would have not survived now before we had bamboo cuz two of us decided we're going to make bamboo work it's going to happen before we had that we had an internship project that was our build system sounds a little scary and it's because it is and hindsight probably not the best thing to do not because we don't like interns in fact we worked with tons of interns I hired interns every single like not quarter but like a period of the year what do we call that a what do you what's a not a every third whatever that word is um so every four months we would have interns come in it wasn't just in the summer so I worked with interns nonstop tons of amazing people we hired lots of interns full-time so it's not the fault of the intern we had a build system that was an intern project and be between every intern they would try to hand it off and then the next one would spend a couple of months ramping up on it there's basically no continuity but you know what it was working it was just pretty rough so that's why we went to bamboo Bamboo was a huge improvement over the intern project no offense to the interns it was just that we had consistency and then moving to Jenkins was a huge improvement over that now you might be thinking well yeah okay the people that were complaining about the intern project they're totally right you know it's not fair that would be a really crappy setup to have an intern project like that for your build system but I an even better one for you because before that intern project Not only was it not a project there was no automation the build system was an intern the build system was the intern's desktop and when we needed to release software he opened up visual studio and he pressed build and then he copied the files from his desktop to a file share build system that's how we started so to think about that for a moment because I talked about multiple stages of evolution and you could absolutely imagine that at any point in time someone coming in could say holy crap why would you do this but they don't understand the context that came before they don't understand that these were all incremental improvements we were always trying to make things better and sure even at the end of that it wasn't perfect but at least it was moving things in the right direction so uh I'm going to pause on that one when I go back to chat and check some things out um oh infected FPS I remember installing that on a VPS at one point was a nightmare yeah it's weird I haven't I just feel like I haven't heard of bamboo like ever aside from that period of time so pretty incredible but uh it like at the time it worked well for us it I think our biggest struggle was that we couldn't um we couldn't really share the load with the team so instead of it being a central thing that we could train other people up on we made it a central thing and then kind of failed to train other people on it there was no one really dedicated to doing it so kind of just fell apart oh I think it became bitbucket pipelines yeah maybe that would make a lot of sense then um because that's why I was like bitbucket seem to be the thing that came after but uh and on YouTube uh D Garcia good to see you hello hello um I always like calling out like where people are representing from and so fascinating to me that LinkedIn used to be a ton of people that's where most of my following is on social media and then it was like YouTube because that was next and some on Twitch and then out of nowhere out of nowhere all of the people on Twitter like way more people on Twitter are tuned into this so Twitter people represent I know infected FPS you're you've been you've been joining regularly so I appreciate you joining in from from twitch so just wanted to say that the the Twitter folks they're do doing a good job okay let's talk about another similar example to the build one and that's going to be tests now this is the one I kind of Blended in in the newsletter because I talked about build systems and testing kind of similar but they have a different Evolution and when I used to give this talk I would talk about them separately but um it's been a little bit of time so I might kind of butcher this but okay so we had tests that we would run and if you were to have joined the company around the time that I left we had a lot of these automated UI tests that would run things end to end so that seems pretty wild so it would literally click through a desktop application uh it we had basically had a search engine for digital forensics we click through that um we had um sort of a separate program that would let you view the results so you'd interact and go through all these results so we had user interface tests it would work end to end on that and then we had these other tests that would scan through hard drives and technically devices um and basically compare results of those searches and those could take ages right so if you're not familiar with digital forensics I don't suspect a lot of people watching this are um being able to scan you know multiple uh terabytes of data and especially the more samples that you have this is something that takes a long time and unfortunately given resources it's probably not something that you can afford to do every single time you have a build so that meant that we would have these scenarios that we might run every build and other scenarios we might run every week and of course because there's not a perfect overlap and it's not a perfect system because nothing's perfect you might miss things so we had these UI tests that could take a long time to go run we had these other like search engine type tests that could not only take a long time to run but they weren't always being run on every build and people didn't like that like why can't we go run everything all the time why can't we go invest into doing this right why are these user interface tests taking so long like can't someone improve these do we really need these things so that would be something you probably would have experienced if you joined right around the time I left now let's take a step back from those two things because what did it look like before okay so before we had the UI test we basically had we had some coded like we were getting better at unit test so that was good um but we had a lot of Legacy code that was not really unit testable in its current format and I'm using unit test and like functional test like a coded test to kind of be the same thing here so the code was very difficult to test in a lot of spots so what we had done to make it not such a pain was that we put in these UI tests especially over the areas of code that did not have unit tests and why did we do that because if you had the UI test you could at least try to go refactor things and make sure that you weren't breaking what the users were expecting to do we couldn't even add like highlevel functional tests the code is very very brittle unit test sorry coded tests on the UI were basically all the we could do so there was that um and then we also didn't have the luxury of doing these tests on these hard drives or images so like copies of the hard drive but I'm going to going to park that one for a second so that's kind of where that that trail ends but I want to talk more about these tests so we started adding these UI tests and so that people could go refactor things and why did we do that well we did that because before we had those in place what used to happen is that testers we had testers and developers that was kind of how we composed our teams we would have testers manually click through things for multiple days to release something and I'm not saying there's anything wrong with manual testing but I don't think manual testing this way is the right thing to do did it help catch bugs absolutely there is no doubt that it helped catch bugs but what I'm saying people were complaining about the UI tests taking 30 minutes an hour to go run I'm saying this used to take humans multiple days to go do a verification of a build days and that meant that if they found a bug guess what odds are they weren't just going to go test that one spot again they would want to repeat a lot of their tests cuz when that bug fix how do they know it didn't break other things so this process was incredibly heavy and this is exactly why we introduced some of those UI tests because people would say look we need to go write coded tests on this stuff and then they were like well how do we know it's not going to break right then because it was basically guaranteed to break something so we had to come up with this compromise put the UI tests in place that way ideally you shouldn't need to keep the UI test there for forever ideally because there's better ways to test these things more effectively but I think what happened over time is they became a bit of a crutch but that's a different story okay so we have we're at this point where we have testers doing like a build verification test on every release and if you came in at that point in time in the company history like I remember saying this and I was there from the right from the beginning and I was like man why are we doing this but it was for a reason like it's for a reason and that's because when we didn't have this we only had a couple of coded tests in some areas we had all this brittle code right because we're we're trying to move fast we're just trying to get things done and there was code that just became more and more brittle over time so what would happen well we would go have coded test in some spots and then we would be adding features to another and then we would go ship the software and it would be busted so that's why we put the build verification tests in place but if we go back even before putting some of these coded tests in place we truly did start off by having no tests and when I say no tests I literally mean there wasn't the concept of a unit test anywhere to be found in the codebase so how did we test things well we would make changes for a couple of weeks and then the CTO would take a build from the intern's computer and then he would would go test it himself so he kind of did a build verification test as one person it go through the product and he he did have a lot of knowledge in it like without a doubt so we could trust that but it's just not a consistent way to do it so of course if we go look at this moving forward right going from the earliest point in time we had the CTO running tests on the build before releasing seems like not a great strategy so then we had that plus we added the unit test in so we could catch some bugs along the way okay still not perfect so we started adding in build verification tests okay still not perfect because that was really painful to go through so we started adding in things like UI tests and we had tests on running on these these images that we could scan so of course people did not think that was perfect still but it was a huge improvement from the beginning so those are two huge examples that I think hopefully that helps illustrate what I'm trying to say that when you come into an org at any point along that timeline it would be very easy to say like what the hell are you thinking doing this but it's because it was an improvement already I'm going to talk about one more um so this one I thought was really fascinating I can't remember the exact details of it so I apologize for kind of making it kind of lightweight but I want to talk talk about this situation like purely in code and the idea behind this one is that we have a search engine for digital forensics and we obviously want to make sure that our search engine is reliable of course so it should be consistent with the results it produces but we want it to be fast speed is always a goal that we want to have not at the expense of accuracy but we want to make sure that it's fast okay so I can recall that when we were trying to optimize the search engine I remember there being a point where someone had found part of the code and realized that it was a huge bottleneck to everything that was going on with it and what that had to do is how we were scheduling work items to get run so it's a multi-threaded application the way that something was getting queued up uh someone had looked at this and they were like oh man like this is literally going to give us like a 30% performance boost I can't remember the details but it was like this is the spot like we did an analysis across the code base for different places to optimize this spot right here absolute biggest bottleneck which I thought was super interesting because when I heard that I had remembered that I got to jump all the way to the beginning of the application we're skipping a step in the very beginning this application used to technically be written in VB6 before all of us started there when I had started it was just converted it over to C but it used to be in VB6 VB6 is not a multi-threaded application for those of you that don't know if you want to have multiple threads you're using multiple processes but it does not have multi-threading at least it didn't I don't know if vb.net does but VB6 certainly didn't so it meant that at one point in time our application was single threaded you weren't running your search in a multi-threaded fashion so we moved did over to net and then even while it was in net it was still not multi-threaded but we said you know what the biggest performance boost that we could possibly get out of this thing right now is we are going to make this a multi-threaded search engine and truly when that was landed that was the biggest performance benefit that we had ever got out of that application up to that point and here's what I want you to realize the way that we were queuing up that work to be done in a multi-threaded way that code didn't change so that was at one point the biggest performance boost that we had in our application and over time everything else around it was evolving getting faster things like uh when you're doing a an index of uh when you're checking for Strings uh you want to use like ordinal instead of like uh you know the the default right if we used ordinal we could speed up all of our index ofes um we didn't have the luxury of using spans and stuff like that so that would have been a huge performance gain mentioning some C and net Concepts but um the point is that everything else around it was improving over time that code never changed and the reason I think this one's so fascinating is because not only at one point in time was that the biggest performance boost that we ever had in our application but the same code in the future was also now the biggest bottleneck so someone looking at that code it might be obvious to them where they're like why would you ever schedule stuff this way this is not a smart way to do it how could you ever consider this all right who the hell wrote this code but if you have the context you might understand that that same exact code gave us the most performance we had ever seen at that point in time so that's going to be it for the scenarios I hope that that was helpful um I just wanted to give you some context for how you approach these types of things so to kind of circle back to the beginning I do think that it's important to be asking questions I think it's important that you're curious I think that can not only help you learn your new domain it can help you get comfortable but it can also help other people you get them thinking about things right they have to explain stuff to you it might be something where they're like oh yeah we haven't considered this in a while it might be something they haven't thought of before there are plenty of great opportunities that can come out of you asking questions so I do highly encourage you to do this okay so then the other flip side is that if you're coming into an area and you're seeing code that looks like crap I do urge you to resist that to to not kind of say out loud or message someone on the team and say like who wrote this this sucks this looks ridiculous um instead I I just urge you to to try and be curious instead um some of us have thicker skin right you can make fun of our code and we're like I know it's bad whatever I wrote that I wrote that eight years ago I know it's bad whatever um other people don't and especially if you're new to a team and in general for your teammates you just don't want to be putting yourself in a position where you're making other people feel like crap it's very easy to kind of uh to tear down I guess right and it's funny because for some of us we we see this a lot and I think that I'm not saying that as a manager this is the only time you see it but I I have spent a lot of my career working with individuals who just have like low self-esteem they lack confidence they have impostor syndrome and then when you layer on something like oh my God whoever wrote this is a total idiot like how do you you think that makes that person feel right like they were clearly doing their best they didn't write that code with the intention of like oh I can't wait for that senior engineer that's going to join later to read this and it's going to ruin his day or her day no one's thinking that so instead of making people feel like crap even if it's unintentionally I'm just trying to give you the reminder try to be curious instead cuz I think it will go a lot further so that's going to be all for this topic so thank you if there are more questions and stuff uh definitely happy to take them in the chat there is a delay in the chat versus me rambling on here so uh what I'm going to do because I got to get better at this but it's always awkward for me I'm going to do a bit of a sales pitch so bear with me folks I do appreciate you being here um just for heads up if you joined late this this is where my newsletter is it's on substack and this is the article yes I use these silly YouTube thumbnail style pictures uh but you can check it out at Dev leader weekly so it's weekly. dead.can plug I got a whole bunch of Shameless plugs to go through here there is a bunch of courses on dome train I will also put these in here if you're interested so if you're interested in net development all of my courses on doome train currently are foret but Ryan Murphy and I are hopefully well we are launching I'm hoping it's in the next couple of weeks we are launching our behavioral interview course that's going to also be available on dome train Ryan and I will be delivering more courses from this perspective to dome train as well so the behavioral interview one is just the start and we're very excited to be doing more and kind of branching out the Dome train brand it's by the way not my brand Nick chaps runs Dome train yes we have similarish names he's Nick chapis I am nick centino uh we both talk about net but this is his website and Ryan and I are going to have our choruses up here uh should also mention and I should have said flashbang warning I apologize but uh I do have a podcast as well so if you want to listen to the software engineering interviews I do uh instead of watching them on YouTube if it's your preferred platform you want to listen to them while you're you're Pumping Iron at the gym going for a walk or driving to work um sitting on a plane whatever uh you can check out the dev leader podcast it's on Spotify it's on Apple music it's on YouTube it's everywhere um so check that out I do have another YouTube channel that I'm just going to point out to you in case you're curious if you like this kind of style so instead of just my YouTube videos where I have uh sort of like rehearsed uh tutorials or rehears content you can hopefully tell this live stream is like I mean obviously it's live and it's kind of off the cuff a little bit but um if you want a very sort of natural conversation from me yes it's One Direction uh it's not live uh but I've been trying to do vlogging from my my car when I'm commuting to work so uh if you want to check out this channel it's just called code commute I will put that into the chat as well in case you're curious uh it's I've been I was mentioning this to a couple people that this Channel with 50 or it's got 55 subscribers now wow um it's getting more views than some of the views on my my primary Channel with over 7,000 subscribers so uh kind of funny how that's working um and then the very last thing I'm just going to kind of make a little bit of a pitch here uh if you are interested in either creating content so if you see how I'm creating content online and that intrigues you you're like I would like to try learning in public public or I've been thinking about talking about software engineering or anything that you're interested in brand GH is the tool that I'm developing and it's literally the system that I've been using to post content for the last however long now it's been 21 months so I use the same system but brand ghost is the software that's I'm I'm kind of transforming it into now if you're not a content creator and you're like I don't care about this kind of stuff I will frame it a different way if you are someone who has a a small business um and you don't want to spend time on social media and you're like man I know we want to attract people through social media but I just don't have the time to be posting every day I highly recommend you check this out uh I have someone who is on boarding his real estate company and his roofing company to this because he understands that when he's posting to social media he is getting clients but he does not have time to be living on social media this is the exact same situation for me so every piece of content like 99% of what I post is done through brand ghost uh my comments are not uh however we are building commenting functionality and later so if you're curious about getting your content more streamlined do check out brand ghost um this is what I'm personally building on the side so that is all of my sales pitching I do want to say thanks to everyone for tuning in I'm not going to go over to Reddit today uh to go read through articles and this is purely just because I'm on call so I don't want to stay up too late because I start at 6:00 a.m. and I want to make sure that I'm rested so uh I don't see any other questions or anything that came in so this is just your last chance as I'm kind of wrapping up here if you have anything else you want to ask let me know but folks I do these streams 900 p.m. PST on Monday days and I try to do them for 2 hours usually uh if I'm not on call or have other things going on and uh the second half I usually go over to Reddit and we go through some posts together so that's usually what it looks like and generally just not recently I've been trying to do coding live streams at 7 a.m. PST on Tuesdays so if you wanted to hang out with me like tonight and then the next morning you want to come online and through some code with me that's what it's all about so uh those ones I will hopefully be resuming next Tuesday so with all that said I don't see any further questions thanks so much folks I do appreciate you jumping into the chat and asking questions and and offering your perspective as well so I will see you all