Success From Software Engineering Failures - Interview With Alex Lau

stop, right? Like, I made it, did the thing. Okay, we're done here. But you kept going. Okay. >> Yeah. And the reason was because >> what if you had a way to take all of your past failures and mistakes and transform that into something positive? Hi, my name is Nick Cantino and I'm a principal software engineering manager at Microsoft. In this video, I got to sit down with Alex Laauo, who is doing exactly that. Alex has written a book that will be out July 16th, 2024, and that focuses on a lot of his learnings based on his past failures and mistakes. In this interview with Alex, he explained how he's been able to take his past failures and make them transformative and for himself going forward. He also shared with me how public speaking was an amazing skill set that he was able to learn, not the way that you might expect, and how that transferred into his software engineering abilities. I think this is another awesome interview. So, sit back, enjoy, and let me know in the comments if you want to see more stuff like this. Thanks, and I'll see you next time. where you started, how you got here because I think people are always interested in this kind of thing because everyone's journey is truly it's different and unique, >> right? Yeah. It's funny you mentioned that it's unique specifically because typically when I describe it to people, I say like, oh, I'm from a traditional computer science background where I got like a computer science bachelor's degree, but I don't think that that's like traditional at all anymore. Right. As you mentioned, people have just like totally different walks of life that they come from. And whereas I think that that used to be the status quo, I think it's really good that it's changed since then because I've worked with people that have come right out of boot camps and they've been really great developers and it's amazing to see how quickly they can come up to proficiency. Um, but as for my background >> specifically, like I said, I got a computer science degree and went to college. And then right out of college, I worked at a large company for about five years or so between internships and working there full-time. And that was in Minneapolis, Minnesota. And between it being very cold there and wanting to just start a new chapter in my software journey, I really wanted to work at the complete opposite end of the spectrum in terms of companies. So I really wanted to see what working at a startup was like, just how that would flex my skill set differently. And I had in particular become really enamored with Ruby on Rails and like watching some videos on YouTube and seeing just how quickly they could get up to speed with certain projects and prototype things really quickly. >> Between all those different factors, I found that moving to Austin, Texas would be a really good fit for what I was looking for. And so almost 12 years ago now, I moved to Austin. And since then, I've worked at a handful of different companies, a lot of different startups, some medium-sized companies, and it's been a really good journey to just have that diversity in my career as well because I got to wear so many different hats and try so many different things. >> And particularly during the last couple of roles that I've been, I have found that I very much align with the mission of the edtech space. So, the last few companies I've worked at have been in edtech, and I I really like that. >> Awesome. Well, and I'm curious because you have uh this mix of experience. I think a lot of people, and I say a lot, I don't know, I don't have stats or anything to prove it. Anecdotally, I hear a lot of people uh as they're up and coming in their software journey, it's like, well, the it seems like the goal is I must work at big tech. And for me, even like that was never the ultimate goal or anything like that. This is something that's transpired throughout my career. But, um I hear a lot of people just set on like, well, I must work at Fang, right? and you have startup experience and I I'm curious like how did you find the the learning or the uh I don't know the engagement like the different aspects of being at a very small company versus something that was significantly larger. >> Yeah, it's a good question. One big difference that comes to mind is typically at a bigger company you can afford a lot more specialization. So if you really want like dig super deeply into like the nuances of Reddus or something and like really optimize that and have that be your role. A big company is a good place to do that. When you're at a startup, the depending on, you know, your situation and the company and their funding and how much runway they have, you almost certainly don't have that flexibility because there's the reality of it is that you only have so much time and resources that you can dedicate to a given problem at a given time, which >> right >> is is neither better nor worse, right? It's just different. But it forces you to make a little bit more judicious decisions in terms of where you allocate your time and your resources. So engineering wise, you probably can't just go to the, you know, absolute pinnacle of optimizing, right? Asus, you're probably more worried about like how do we build the next step in this product that get us to the point where we need to be in terms of like trying to find that product market fit. And I think that there's like certainly more hats that you wear from an engineering perspective. You're probably >> having to do a bit more of like product management adjacent kind of work or like working really closely with product managers as well as working really closely with you know QA folks whereas at a big company you might have entire teams or certainly resources that are dedicating dedicated to doing those things specifically. But before we move on, this is just a reminder that I do have courses available on dome train if you want to level up in your C programming. If you head over to dome train, you can see that I have a course bundle that has my getting started and deep dive courses on C. Between the two of these, that's 11 hours of programming in the C language, taking you from absolutely no programming experience to being able to build basic applications. You'll learn everything about variables, loops, a bit of async programming, and object-oriented programming as well. Make sure to check it out. Yeah, that that definitely checks out with my experience as well. Uh I actually had a conversation with uh John Vanir of Laterally IO and he actually has stats on, you know, the fact that you were talking about specialization at bigger companies, right? Like big companies can afford to have the specialization. Like it's it's literally part of it whereas at the smaller companies, yeah, you kind of need to wear all the hats. Um that's been my experience as well. Um I find it very interesting like when I think about engineering I think about uh like problem solving but I think about problem solving with constraints and the constraints part is very interesting to me because >> like >> I'm not saying that there aren't constraints in big tech or something like that but you feel >> there's always constraints right but you I feel like uh from my experience the constraints are felt a lot more in a startup because it's kind of like hey look if we don't get this writer. We don't work within these bounds. Like we either can't afford it, like we could basically this whole project could fail. If this project fails, the company could fail, like we have to pivot. It just feels like there's more constraints. And when you're trying to engineer solutions through that, like the creativity really shines. Again, I'm not saying in big tech there is no creativity or something, but that forced like constraints on problem solving in startups is uh I always thought that was like very uh very interesting. >> Yeah, for sure. That actually reminds me of a conversation I was having at the CTO of one of the companies I was working at where we were really small and I was mentioning to him like, oh, I wish we could do like X, Y, and Z kind of like refactoring sorts of tasks. and he agreed with me, but he had a quote that I thought was very insightful, which was that our goal in like a startup isn't to solve good problems or like problems that are useful or like implement ideas that are useful because there's an infinite amount of those useful good ideas. It's to solve like the right problems given what we are as a company, which I thought was kind of mind-blowing at the time. And I've like really grown to appreciate that sentiment because yeah, you're right. It's like in in a world with infinite resources. Sure. Yeah. Let's go for like trying to solve every problem we can, but that's never the reality of it, right? We're trying to work within the context that we have at a given moment. >> Yeah. your prior you mentioned the interactions with you know product or uh you know parallels to product but that idea of you know we got to work on the next thing that's going to allow us to take the next step versus just like and I talk about refactoring code and stuff a lot and I think my perspective on that comes from being in a startup where I'm like I wore an EM hat at the same time as a software engineer hat and I had to sit there and I would look at code I wrote and I'm like man we got to refactor this. And I'm like, okay, but like >> but what do we actually need to do? Like customers don't care about that. So like are we going to be working in this space of code again? Like or is it currently broken? Like we have to look at is it holding us back from making progress and we can't deliver the customer expectations or if it's not the case like let's just go work on where we need to deliver value to customers and eventually if it comes up again we will come back and refactor this and there were times where code would live like that for years like four years and then someone would be like oh man who the who the heck wrote this and I would be like oh yeah that was me like and I know it's terrible. But here we are now. Ready? If we're good to refactor it now, let's go. >> Right. Yeah, that actually brings up another good point that I meant to mention earlier, which is like when you're at a startup or an early stage company, you're typically getting to work on more green field types of applications. like the trying to make those kinds of architectural decisions and seeing the repercussions of those directly down the road is a lot different skill set than working on an existing legacy codebase that's been around for you know five plus years and just the experience that you get from that I think is a lot different as well because >> sometimes sometimes if not many times it's like oh yeah I actually worked on this right and this is now a pain point that I can very much appreciate. Uh even though I didn't fully understand that problem at the time, >> but did this myself. >> Yeah, exactly. I've also heard of um this notion called like the prime directive of coding which is um basically that like considering this idea that whoever is working on a given piece of code at a certain time was trying their best with the information that they had. Right? It's really easy in hindsight to say like, oh yeah, like why did we do this this way when like the reality is, you know, the domain has these other rules that would have made it so much easier if we had implemented another solution. But you don't always have that information at the time, right? And it's really hard to kind of contextualize and empathize with where somebody was when they made that decision or like what constraints their team had. maybe they were like trying to do 10 other things or like get this, you know, demo ready for a pitch for investors or like something else that had higher priority. And I know it's it's hard to do and I've kind of like grown to appreciate it over the years, but I I really try not to blame anyone, including myself, when I see code that's like suboptimal or like decisions that were made in the past because you just don't know what somebody was working with at the time. >> Yeah. like that really resonates with me where I used to work before Microsoft I was there for about 8 years and basically since the beginning of it so I got to write a lot of the original code that was you know people say like this is terrible and uh I actually I had a a talk that I used to do that I was pretty proud of that um and I like especially at that time like public speaking like could not probably today I could do it and be reasonably comfortable but then no but I still felt it was so important to have this conversation periodically because we were growing so rapidly and having engineers come on and they'd be introduced to the code base and they would be like literally you'd have this kind of thing coming up all the time where it's like who the heck wrote this like this is trash and whatever and part of the talk that I would give basically walked through these different areas of code like so it was a kind of a technical talk but at the same time I was like look if we didn't do this none of you would be in this room I had said it a little bit more politely but you We did this and this allowed us to basically survive and ship like conscious decision did it or or it wasn't but it let us or I I should still say it's probably conscious it let us move faster and as a result we could get to the next step and it would be things that you know after a couple of years it would finally be like okay it's time to go back and then we might go touch it but the point of the conversation was basically to let people know like it it's exactly what you said we were making decisions based on what we knew at the time and and to say like hey this is a this was the wrong decision to make. It's like it might not be the most optimal code in hindsight but literally like we are here today sitting all together in this room listening to this talk because of the code because we made these decisions and we got us here. Yeah, I love that point and like thinking about it that way and kind of like recognizing like the legacy that got you to the point where you are today, right? >> Yeah. I also >> I realized when I said that I didn't want it to sound like I was being a a total buttthead, but the the way that I presented it I feel was less like you owe us something and more like um it's not that you owe us something, but it's more like we should I think it's totally great to question why. Right? If you're genuinely curious about asking why, that's awesome. But if you're like saying why because you're basically trying to indicate that someone's dumb, like that's where I'm like that's not okay because you don't have the full context. >> Yeah. Yeah. That underlying intent is certainly important, I would say. >> Right. >> Um I also I kind of wonder if it's like there's something behind the nature of just having code that stands out because like in hindsight it is suboptimal or like doesn't fit the problem as well anymore. Whereas like do people really it's it's almost harder to appreciate adequate or even good code, right? Like it's it's much less likely that somebody is going to be like, "Oh, what a what a great abstraction we use here. What a great pattern." Because I I almost wonder if it's because like when stuff works well, you almost don't notice it, right? Like when an abstraction is really clear, it's just like easy to read and you don't think twice about it. It's only when stuff is harder to read that you're like, "Oh, yeah, let me like kind of wrestle with this more or bring it up more." >> Yeah, that's it's a really good point. Um, there's probably some psychological uh explanation for that kind of thing, but uh being able to I'm trying to there's another parallel I wanted to draw here, but you're totally I feel like you're totally right in saying like we notice when things are bad and good things we wouldn't notice unless uh like they they basically go silently for a good abstraction. you might be in a situation in the future and this is actually a pretty rare thing even though we do a lot of abstractions but like hey we're going to switch out the database completely and go to something else and it's like oh thank goodness someone put this level of abstraction there it's like and now it's saving us like I feel like it's a a more rare thing to happen but the the parallel I wanted to make here is even like the different types of teams that you can be working on this has come up before in the teams that I've been on where um like a platform team sometimes Sometimes it feels like a very thankless job because you're doing all this awesome work and basically people it's like the expectation is just like these things work and they do well and you only hear when people are upset like >> it's an interesting paradigm right and I'm glad you brought that up because there was another similar one I was thinking of in like the security realm right where you can do a hundred different things and prevent a hundred different attack vectors but if just one of them gets through when somebody's trying to do like a pen test or you know um is just being malicious like that. It's just a really lopsided paradigm where it's like so many things have to go right but only one thing has to go wrong. >> Yeah, totally. Yeah. And it's that's it's funny I mentioned the the platform thing. I was thinking about the deployment team I was just on before and the security part that you're talking about now is literally like one of the teams I'm on right now. So that's very like that's a very relevant example for for me. But uh >> yeah it's it's challenging right because and you know as software engineers and I'll bring in my em kind of perspective here. I need to make sure that people understand the value of what they're doing, especially in situations like that where it's like we do all of this work and like it feels thankless, right? And we're only hearing from leadership or other teams when things go wrong and it's like I need to make sure that we try to balance that so that people are motivated and engaged to do all of the things that are valuable that allow us to to hear the bad things less frequently. >> Sure. Yeah, that's one thing I try to be conscious of on the teams that I work on is finding that right balance of celebrating others, >> right? >> Because you don't want to be doing it like every single day and saying like, "Oh, so and so wrote such great code and like I'm really glad that they did this even though you might actually think that." But I think that there's like a balance to be struck for kind of like more publicly acknowledging when something works really well. like maybe your team is just on like a big refactor. It's gone really smoothly. Like I think that that's like a good opportunity to kind of thank the people in the room that have made that happen because >> yeah, >> like we've been talking about, there's a lot that goes on kind of behind the scenes if you don't get to like hear behind the curtain and see what's going on. So like having a project that you can tie it to is like a really good way to kind of celebrate that. >> Yeah, absolutely. No, I think that makes a lot of sense. I was I was curious though because I know you shared with me that along your journey one thing that you kind of discovered for yourself was this this idea of public speaking being valuable. >> Yes. And uh I often talk about uh sort of just a general set of this whether it's not necessarily just public speaking right but this idea that in software engineering soft skills and things like communication are so valuable and it seems like you've had a very good discovery for yourself and a lot of learnings and I wanted to kind of ask you about you know your journey with public speaking how all that's kind of helped shape who you are. >> Yeah. Yeah. I would almost argue that public speaking has been one of, if not the most important skills that I've fostered throughout my software career. I obviously there is a technical side of writing code itself. But in order to complement all that, I think that it's been a really impactful journey to get into public speaking. The the way I got into it was very unexpected. Actually, I had a friend call me up around the holidays back in gosh 2015 or so and we were just chatting and catching up and I knew he was engaged and about to get married over the next year and I thought he was going to ask me to be one of the groomsmen in his wedding. So, I was really excited about that and instead he asked me if I would officiate his wedding, which was a much different ask. And when he asked me that, I had like this flashback of like all of the different times that I've done public speaking and it's gone really terribly because there had been so so many times whether it was in class or even for a job one time. I remember that I was invited to go speak at a college campus and I just did like this abysmal job where I was like tripping over my words and stuttering a bunch. And so when he asked me, I I literally couldn't even answer him on that phone call. I was like, "Uh, maybe maybe let me call you back in a few days and think about this." >> Interesting. Okay. >> Yeah. So, I took a few days to think about it. And the thing that I realized was that it was an honor to be involved in one of the most important days in my friend's life. And I shouldn't let this fear overcome like the benefit of that. And I like wanted to be part of it. and I wanted to, you know, again, I was honored to be involved in it. And so I had I'd heard of Toast Masters before. I'm curious if you've had any experience with it or if you've heard of it. >> Not personally to use it, but I have heard of people using it and having like awesome success. And when I say success, uh the way that I'm gauging success here is that they feel very confident after in public speaking. I'm not I'm not the person like to sit back and like grade someone's public speaking ability. So I don't I'm not saying success based on my observation, but success based on how comfortable they feel after going through it. Um from the people I've talked to, they were like, "Yep, like that was the thing that did it for me." >> Right. Yeah, that that's certainly been my experience. And so I I had heard a public of Toast Masters and I basically just knew it was like public speaking club which sounded absolutely terrifying to me. But again, it was in service of getting prepared for officiating this wedding. And I knew if I didn't go to this, no matter how painful it was going to be to go to it, I knew that the alternative of not doing it was going to be even more painful and even more scary. So, I started going to a Toastmasters club here in Austin and I just really committed to making it. They they met every week, so I would commit to going every single week. And then they have all kinds of different roles that you can do, like different capacities in which you can help out with the meeting. Some of them are really small roles where you're just kind of giving a quick intro, like talking for 30 seconds at the beginning of the meeting or something like that. And then they have more involved roles as well where you can have a prepared speech ahead of time where you're getting ready and kind of working on crafting your message and then getting out and presenting it to the whole club. And my club was one of the bigger ones. It was about 40 people which I think was one of the biggest ones in Austin. So it was really good practice to kind of just build that skill set >> and it kept going week after week. It was really difficult in the beginning and like again it was kind of like pulling teeth. But the thing that motivated me was just keeping this ultimate goal in the back of my mind. And by the time I started going for a couple months and giving those first few speeches, it was kind of like what you were describing where it became this really transformational uh experience I was going through because I just noticed that as I went more frequently, my skill set was getting consistently better and better and I was growing to be more comfortable being in front of people. And so eventually my friend's wedding came and it went really great. One of the most like memorable parts of it was the father of the bride coming up to me afterwards just showering me with praise which I really appreciated. He was saying like I I appreciate how you have like a good balance of humor and you incorporated the story how they met. And so that just meant a ton to me. And again, it was like such an honor to be part of my friend's big day. Uh, but the thing that I didn't expect was that I would keep going after the wedding. I thought I would just go and then try to be done. But I >> I did it and then you stop, right? Like I made it, did the thing, okay, we're done here. But you kept going. Okay. >> Yeah. And the reason was because I felt like it was just a good community to be involved in. like it was nice to be in this community that was there just for people to get better at and had like it fostered a lot of improvement and encouragement between all its members. Um but also because I felt like at work I could notice a huge difference in terms of how just I was able to communicate and better work with others on my team. And during that time, I actually went from being like a senior developer to like a team lead and then had a very brief stint as an engineering manager. Um, that only ended because I ended up going to a different company shortly thereafter. But it was kind of incredible to see like within this year and a half time frame like how much just growth had happened for me personally. Um, and so like you were talking about before, I think that it's easy to just kind of think of our roles as software developers as you sit there and you write code and you kind of work in isolation, but anybody who's been doing it long enough knows that the opposite is true. You're like ultimately having to work a lot with others, craft solutions together, advocate for certain tradeoffs, or like better understand what somebody is trying to convey to you. And I think like right public speaking has helped me in every single one of those domains. >> That's awesome. I think the like a good takeaway from just this portion, right, is like that and I I want to sorry there's a bunch of thoughts going through my mind. I wanted to to mention like the the fact that you have a very clear example of like how some type of soft skill that's not just like hey I got better at JavaScript or C. I know these design patterns like nothing to do with that stuff which is not that it's not important it's just we park that on the side here's some soft skills we're talking about public speaking in particular and then that directly translating in your ability to do your job better and the reason that I was pausing and kind of I had this other thought coming into mind which was earlier you mentioned like this idea of like traditional route for being a software developer I did you know same thing and I I always say like I guess this is the traditional in a way cuz that's what we've said traditionally. Uh I've been talking to more and more people that uh not only are they doing like say a boot camp route but they might be switching careers what they would call later in life right they're like hey look when I was six I didn't know I wanted to be a software engineer so you know I decided later and later is very subjective some people it's like hey it was in my mid20s some people 30s4s but where I'm going with all this cuz I know it sounds like a bit of a tangent is that all of those skills that people were acquiring that had nothing to do with writing code. There are so many other skills that you can bring into software engineering. So people might have been great at doing public speaking or they might have been great at working with customers cuz they were doing sales. You have all of these things that aren't just writing code and you can bring those into your software development and excel tremendously because communication ends up being such a big part of it when you're working in teams. >> Absolutely. Like I think that that's so true in so many ways and like almost in the same way that I'm skeptical of companies that only want to hire roles for a given like experience in a given language. Although there is a time and a place for that depending on what the position needs. But like in general if a company just has like a policy of like we only hire people that know Elixir or whatever language, right? and like they have like a hard and fast rule about that. Um, like I'm kind of skeptical if they're looking for the right things, right? Like languages can be taught, especially if you know other languages. It's like very easy to get up to speed quickly a lot of the time. Um, and I think that in general there's like this parallel of like we tend to overexaggerate the pure writing code side of the skill set and underexaggerate all the rest of the role that comes or all the rest of the qualities that come along with the role of being a software developer. >> Absolutely. And like you were saying with the language and like other skills, right? Like your ability and willingness to learn other things is like in and of itself a skill, right? I've been at Microsoft uh almost four years now and every and I I think I can say this that it's statistically accurate. Every single person that's been hired under me uh and not on the team already, but every new person that's come on board has not known C and that's what we use. >> So that means that every single person uh at Microsoft where C is the language we use, right? They came on board and they were like, "Yeah, I don't know this language. and they're at Microsoft. That's what were you like, you know what I mean? Like >> I'm trying to >> I don't know how it could be any more uh obvious to say like the language itself like it's if someone knew C#, yeah, that's great, >> but it's it's not going to be the thing that holds you back. You know, if you know Java, you basically just put the curly braces on the next line and capitalize some other letters. You're done. But you know if you know a lot of these concepts are so transferable that if you have other experiences like yeah I will spend you know the first couple weeks might feel like you're I don't know like your fingers are numb because you don't know the right things to press on your keyboard and then basically right after that you're like oh yeah it's the same as everything else like it's fine right so yeah I think these other skills your willingness to learn I think that programming language example is a great one when it came This is a really interesting thing. One of the notes that you had sent me about public speaking though is because it sounds backwards when I go to say this. Your ability to public speak better or a better ability to public speak has allowed you to be a better listener. So, can you kind of explain like your observation and how that's happened? Because listening is incredibly important. If you're just sitting there and I already noticed in this conversation, there was one point where I went to go speak and I basically in my mind I was like, just wait for your your time to speak. And I had to tell myself, no, like you need to shut up and listen. Like, so what's that been like for you with your public speaking and your listening ability? Yeah, I I think part of it is just the way that um Toast Masters in particular uh is organized and the way that they run their meetings. I had mentioned before that one of the sections of the meeting is to give like a prepared speech where you're talking for like 5 to 10 minutes on something. But later on in that meeting, there's actually a portion for evaluations. So if I'm giving a speech that's like one of the prepared speeches and you're my evaluator in the meeting, you would be taking notes during that time and then gathering those notes, preparing them, kind of synthesizing it over the course of I don't know 20 to 30 minutes and then at the end of the meeting you get up and you give me an evaluation. So you're going through and talking about the things that went well and areas for improvement. And I think seeing that and hearing that and just seeing it over and over again across a lot of different speeches kind of just started to make me become very introspective about the way that >> I not only presented the points that I was trying to make in other speeches in the future, but really just hearing what somebody was trying to say or ways that they could improve saying that. And I think the overall like the overarching lesson that I got from that was being able to in in during a Toastmasters meeting, it's hard because you're like having two different one-way conversations. Somebody is sure >> just presenting and then the evaluator is also just presenting after that. But when it's in a work environment, for example, you can have a lot of follow-up questions. And so rather than having like this one-way dialogue that the evaluator would have in a Toastmasters meeting, you can have this real-time feedback where you're trying to like dig in and find like this underlying message for what somebody is saying at work or like helping to clarify the point that they're trying to make. >> Interesting. That's that's really cool. So I think uh yeah there's I I've noticed maybe a pattern if I can call it that um that especially as more software engineers become more senior uh one thing is that you know we lean on a lot of our experiences it's easy for us to say hey I've seen it this way and we can sometimes get in our own heads about it like hey like just trust me like I' I know I've seen this just like we're going this way we're taking this design path and it's dangerous right like there's a you want to be ble to lean on your experiences, but I think that there's going like thinking about listening here when you have other people talking to you about things like instead of just waiting to go interrupt them as a software engineer to be like, "No, like I've seen this before. We're definitely using this technology or this design pattern here, like just giving someone the floor and just being like >> you you can you can have your own opinions and experience is great, but just like shut up and listen, interpret what they're saying. like try to understand because if you don't, you will miss other details. Um, and sometimes those details, yeah, you might have done it before, but now that someone's telling you this again, you're like, we did it before. That was 3 years ago. Actually, maybe this has changed a little bit. Maybe this is the time for it. >> But if the whole time you were like, no, no, no, no. Like, just be quiet. Like, I'm here to speak. You're going to miss all that stuff. So, listening is critical. It sounds funny. Uh, I guess because it's it almost seems like it's a passive thing, right? You just sit there and you listen. How hard could it be? But like it's a skill. >> Yeah. Um, one thing that I've tried to do in more recent years is if I'm like submitting a PR for code review or working on some kind of bigger feature is I really try to align the the breadth of that feature with like how much feedback I like purposely go and seek out from teammates. So what I mean by that is like if I'm working on something where it's like a very very isolated change where I'm just like adding one new field to a report or something like that like that that doesn't signal any like alarm bells in my head. But if I'm like working on, you know, a new API schema or some kind of like overarching like architectural change for something, I purposely go and try to get multiple opinions on something because I want the solution that we come up with to be well-rounded and like well thought out. Uh, and I think that just like acknowledging that you're not going to have all of that context and seeking that out from other developers is a great service you can do to your team and like to help kind of future proof and get ahead of a lot of the pitfalls that you would see otherwise. >> Yeah, I love that. And like one of the best things that happens during that is you're talking to people, you're listening to what they have to say. And if someone gives you some perspective that you hadn't thought of, like you're like, "Oh man, like like you basically feel so thankful that you went around and you were taking the time to listen to people cuz otherwise you would have gone ahead and there would have been a, you know, a glaring hole in whatever you were doing that someone was like that's why we need to go do it this way." >> That's really cool. Um, >> yeah, there there's this like mental shift that I've had from like I I used to always try to kind of protect my code in code review and like defend it from feedback. And that I mean certainly wasn't effective uh like in a lot of the things I've worked on in the past, but like it also just kind of in some ways defeated the purpose of being on a team. Like I the the in more recent years is to rather than thinking about like oh this is a solution that I'm creating and I'm proposing to the team like I instead I think about it as like well how we have like other team members with a lot of valuable experience and perspective like how can we as a team come up with the best solution for this and if I'm the one writing the code great but if I'm not that's great too or like if I'm helping implement other ideas that people have that are going to result in a better solution like that to me is the goal not just me being right about everything because I know I'm certainly not right about everything. >> That's such a such a good learning. Um so thank you for sharing that. It's yeah it's like you know we work in teams with a common goal like as soon as you start making it all about yourself that's like yeah it gets kind of dangerous. It's a slippery slope. >> Um I wanted to make sure we could start diving into your book because you do have a book. I think this is awesome. You have a book. Um, do you want to kind of give us a bit of a an overview of what that is? And I know I I asked you ahead of time like, "Hey, look, I want to see if you have some lessons that you can kind of share with us uh from your book that would be good takeaways for folks, but you want to start us off by what's the book about? Why'd you write it?" And go into it. >> Sure. Yeah. I actually, it was almost surprising to me that I ended up writing a book. I never really pictured myself as the type of person who would write it because I always put book authors on this pedestal of like oh only like the best top tier like person who's like the best rubious would ever be able to write a book about Ruby or anything like that. And I've always had this interest in doing technical writing. And so I've had a lot of false starts with different blogs over the years. And I a couple years ago I was starting to just kind of think about like oh if I did a blog series like what would it be about? And I started gathering a lot of thoughts around that and lessons around that. And eventually I stumbled upon this theme of having different mistakes that I've made in the past and how I could avoid those mistakes. And a lot of those mistakes I realized weren't in the code specifically that I was writing, but rather in the approach I was taking, the mental models that I had or thinking about certain problems. Kind of like what we were just talking about in terms of working on a team versus like me presenting the solution. Like once I made that connection, it really changed the way that I approach software. And so my book is all about the soft skills and mental models that have helped me throughout my career. And the way that I present those is all through different mistakes that I've made because I've seen that pain directly. And so I think it's nice to be able to tie the lesson that you learn to a mistake that you've made in the past. And so yeah, the book again and I will have an upcoming blog series as well. It's all focused about mistakes that we as software developers make because I wanted to have a safe space for other software developers to kind of share the lessons that they learned too because I think >> there's this natural inclination for us to want to avoid talking about mistakes because it makes us feel I don't know if like weak is the right word but like yeah it's it's hard to acknowledge that right like in some ways why would you go about just talking about your mistakes and like broadcasting that to the world. But at the same time, I think that those are really the lessons that are best seared into our memory because we learn directly from them. >> Yeah, that's uh so many good things there. The I love the idea of, you know, having a focus around failures, right? And you're totally right. People don't like to talk about it. Um I think the word weak is a good description of probably how people feel. I would say especially in like a a field where we're all intellectuals as software engineers, right? And having a failure makes it feel like you must be suboptimal, right? Like you must not be worthy if you make mistakes. It's like a direct attack on your intelligence. Like how could you be around your peers ever? But the reality is like yeah, like we learn most effectively. And actually I don't have science to back this, but I'm pretty sure it's probably backed by science somewhere. Um, but when we have our failures, like that's how we're truly learning. So, I always find it fascinating when people will reach out to me and I'm I'm sure you get this. I'm sure lots of people who have been in industry for a while get this where it's like, can you just tell me like what the best X is to use here or like what's the most efficient way to do this? And it's like, first of all, there's context to all these things that people are missing. that what they're trying to do, and I don't blame them, is they're trying to shortcut all of the painful things, like all of the failures. Like, hey, >> you're 10, 20 years into this. Let me just jump to there. And it's like, look, it just I wish it worked that way and it literally doesn't. You have to go mess up a bunch. >> Yes, that's such an incredibly important point to learn and one that I I do cover in the book as well. like talk about how it's it's really easy to have this mindset that I was describing before of like when you're submitting code for code review, you're wanting to protect it. You're wanting it to just be perfect the first time around. And it's just not the way that it works. Like in some ways, code is subjective. And in other ways, there's just like uh again with this theme of like if you had infinite resources, you could um kind of optimize everything, but you don't. So like you can always make code more performant or you know have like a super super secure version of what you're writing that's like really robust and like fault tolerant and all these things but like is that the right thing that you need at the moment? Probably not. and just getting comfortable with the idea of getting kind of those those reps in, having a lot of repetition in terms of like getting code out there and getting feedback and trying to do that I think is so much more valuable than if you take like a longer period of time to attempt to make everything perfect. Like in either case, you're still going to end up with feedback on your code review, right? So, like why not go for the much faster route where you've still given it a good effort and you can get that feedback a lot quicker and have that feedback loop really pay like um dividends going forward because you're just doing it so much more and like building that skill set so much quicker. >> Yeah, the the feedback part is tremendous, right? And I think uh again I'm checking out notes here, but I think is just you refer to this as like the fear of failure pitfall, right? Like basically if you sit there and just avoid failing like this is actually not the spot to be in like uh >> but actually I guess maybe this is worth asking to based on your experience. Um, I think being able to like if we're failing at things, we're able to learn and have these takeaways, but have you can you think about the environments you've worked in and like were they safe places to fail? And what did that look like? Right? Like uh what did it look like if you were in an environment where you were like, I actually don't think I can take any risks here. I feel like if I mess up I like I could be fired or something versus jobs you were at where you were like obviously no one's encouraging you like go mess this up but you feel like hey if this isn't perfect like I'm supported. >> Yeah. I think to even take a step back like I think that there's acknowledgement that's worth making in terms of like the domain itself and the things that you're working on where you can afford um more or less leniency in terms of having things perfect that first time around. Like if you're writing code that's going to be, you know, used in launching a rocket, like that warrants a very different level of caution than it does for like most web applications that people are working on, right? And I think that we get really caught up in thinking that things are the former even when they're actually the latter. Like we tend to like one thing that I've noticed that I personally have done on teams before is really conflate like the sprint deadline with like an actual deadline where it's like we really want to get this thing done and we need to get done by the end of spring. But is that actually the case or is it just something that we decided in like an estimation meeting ahead of time? Right. And so I think we're talking about like signals for when it's harder to fail or it's harder to um overcome that failure is when you kind of just have those guide rails incorrect in the first place or you don't even have that alignment of like what a true failure is. Like the way that I think about failure is like again if it's really just only one chance that you have at something it's like you're trying to get a demo ready for investors and there's like literally just one chance for it. Yes, that's a time that warrants like extra caution and attention that you pay to things, but that's such a rare case. And like 99.9% of my job is the opposite where it's like things aren't going to be dire if we don't get this perfect the first time around. But it's much more important to have like iteration and measuring the results and having like if again if you're making like a a big architectural decision taking time to invest in that because the ramifications of getting that wrong are going to be a lot different down the road than if it's just like this oneoff page that only one internal employee sees, right? like trying to align the attention and time that you put into something with the actual like problem at hand and the severity of that I think is really important when we talk about like what failure is because if there's a bug on this page that only one person internally sees like who cares like we can patch it up we can fix that like we shouldn't get too bent out of shape and like treat those things the same as like when something truly is dire. Yeah, absolutely. And it's I think depending on the scale of your application or system, it's easy to say when it's small, like when you have one thing, you're like, well, it's a it seems like it's a big issue. But the more that these things grow, >> I mean, even the line with if something's a bug or not, like that could it might be like it's just someone has a different opinion on usability and stuff, right? Like >> it just gets a little bit more complicated. And if the entire time you're kind of like, you know, in your environment that you're in is such that it feels like everything must be perfect all of the time. It's like I I've told I was coaching someone who's doing a bit of software consulting and was trying to basically let them know like you know one thing about the plan that you're putting in place like I think it's a good plan. The only thing I can tell you with 100% confidence is that all of these steps are not going to be what you think, right? Like it's it's going to be wrong. And instead of saying like, you know, oh, I tried doing this and like I'm not getting this step perfect. I'm like, don't worry. That's not your goal is not to get your plan perfect because I'm telling you already it's wrong. And I'm not saying it's a bad plan. I just mean it's not going to be 100% right. It's impossible. >> So, just accept that you're going to have to make these changes. And if you think about things that way, then it's not like you're constantly failing because you're not hitting a 100% of what exactly what you planned. You're just using it as feedback to say, "Okay, how do we get closer to the goalpost next time and just keep doing it, >> right?" Yeah. I think that there's like an interesting parallel between like trying to be perfect in everything and having like this high sense of um importance that you associate with every single task. Um and having like a high sense of priority and urgency that you assign to every task is being like well by doing it this way and by being too absolutist you actually like lose the focus of like where priority actually lies. Like if you treat everything as like a T0 critical must be done issue then really nothing has property right and I think that it's kind of the same thing in terms of like >> how much time and attention you give to different solutions and software. >> Yep. And that reminds me like I mean earlier in the conversation right this idea of like sometimes being at startups exposes you to some of these things around what priorities actually look like when it comes to getting value to customers. And you know for some people I would say that's why like startups can feel very frustrating for some individuals where it's like look the I have not done the code cuz it's not perfect yet or like we need to go back and do this tech debt because I don't like the way this code looks and it's like look we just it's just not how it is like we need to keep moving right. So yeah that >> chasing perfection thing is kind of kind of dangerous. Um there was a another pitfall you mentioned and I don't think that I had um seen it I guess like labeled this way but I think it's really good. You called it the halfmeasure pitfall and then talk about basically like having plans for integration and transitioning between systems and stuff. Can you walk us through what that is, why it's so important and kind of how like I don't know if there was an example of failure where you were like this is why this is so important. >> Oh there absolutely is. Yeah. >> Excellent. Yeah, I heard in the book actually. Um the example that I think of when I think of this pitfall is we were I was working at a company and we were rewriting our entire front end of our stack in React and it was a Ruby on Rails application prior to that. And so what we did was for all of like the core functionality we just wrote that purely in React. And then we had like a handful of lingering pages that were only used by admins of our system. So like out of our full user base, you know, if it was like a couple thousand people at each of our clients, like only one or two were the admins. So like that of course had a little bit lower priority. And what I was in charge of was architecting the transition phase to get us to React on the front end. And what I did for those admin pages was I just tried to find the fastest solution possible which was having like some of the page render in the traditional Rails view and then like we sprinkled a little bit of React on top of that going forward. >> Yeah. like our the result was by the time our migration was done was that we had like 99% of it in React and then like this 1% these admin pages that still lived in this like weird hybrid mashup kind of going forward and I thought it was a great compromise at the time. And I was like, we focused on what's important and now we're able to like still deliver value to our customers. And well, >> okay, >> that was true to an extent. What I began to see over the next couple months and even years after was our our plan was like, "Oh yeah, we have these pages. They're in this weird hybrid state now. We'll eventually get off of those." But that that day never came, at least not when I was at that company. And like, who knows if it's still like that today, however many years later. And so we incurred like a context switch every time anybody had to work on those pages because they were like oh this isn't just fully react this is like also using this other technology so you have to like learn how that works and there's like the maintenance aspect of that too and the onboarding aspect and like there's all these little other things that we don't think about and the the most ridiculous part of this all is that it probably would have taken us like another week just to like convert everything else and like put more resources towards that and instead we had instead of taking that full measure solution, we took the half measure of kind of like having one foot on each side of the fence for this. And uh I guess like my main point with this chapter is that this is a pattern I've seen over and over again at different companies where it's like if you're uh like trying to introduce a new pattern into a system and the team generally agrees that it's like a good better way of doing it. Like it's not enough just to introduce that and have that live alongside of the old pattern. like part of the proposal should also be that transition phase because otherwise you end up in this exact scenario that I'm talking about where you have like all these kind of like lingering little nuisances that live on in the system when in a lot of cases that I personally have seen like if you just put time and effort to try to convert that over as quickly as possible you can do that probably quicker than you think and you can avoid all these other um annoyances that you encounter along the way. >> I like that. That's uh it reminds me of something that someone at Microsoft who's a he's been at Microsoft for a while. He's a very very brilliant person uh someone on my previous team actually uh introduced me to this phrase which is not new to anyone but I don't think I had heard it apply this way and it's tax and he would describe different things. I know we talk about tech debt and stuff like that, but when he would call things attacks, it really helped frame things for me and I'm thinking about your example here, right? So, um certainly agree that when you have like two patterns or multiple patterns being introduced and this is pretty common like you said, you've seen this many times, right? Things don't stay static generally in software engineering, right? you're going to have a code base and if it manages to survive and live on, there's going to be a point where people are like, "Look, we've been doing X a certain way and like we know there's a better pattern for that now. Let's start adopting it or we're using a different tech. Let's start adopting it." And there is usually a transition period. I totally agree that you want to, you know, do that as fast as possible or have at least plans for what that's going to look like. Um, >> I wanted to bring up the tax part because it sounds like if I'm using the this individual's kind of mental model here in this case, my assumption based on what you described is that it would have seemed like perhaps the tax would be very low to pay uh in those areas, but perhaps it was not as low as you thought. And I wanted to ask you this, like if those couple of pages or whatever it happened to be, that 1%, if that was code that truly was going to be touched like once every five years, would would you feel like this was such a bad thing or was it still it was touched so infrequently and was still that much overhead? >> Yeah, that's a good question. Um, I'm going to give every software developer's favorite answer of it depends, right? I think the thing that I would maybe use as like a way to like like a major factor in that decision is like how painful is it during that time when you have to modify it. Like is this a sure we're we're touching it like once every couple of months, but when we do it's like a you know it takes a developer out of their normal sprint workflow and like they have to like go back and relearn all this code and it takes them like two or three days to even like build up their mental model to make that decision. Um that's like kind of an extreme example, right? Um, if if the skill set on your team is like everybody is a Rails developer and they also know React and making that context switch is pretty low, maybe you make a judicious decision to not switch that over because, >> right, >> you're right, it just doesn't like warrant the change. I I do think it's possible to go too far in the other direction and try to kind of too eagerly implement the tactic that I am advocating for in the book of taking full measures. Like I think it's it's possible to say like, "Oh, we have this new reporting framework and it's better in these two ways. Let's just convert everything immediately." Like I think that there's a a balance that you need to strike in terms of fleshing out a new solution and being confident in it. And then once you're at that point of confidence, then fully committing to the transition phase is kind of more the way that I look at that problem. That's a I like that example because there's uh sort of an extension of that exact challenge, right, that I've kind of been living through for a couple years at Microsoft where there's a technology that we're trying to leverage across a lot of services and uh you know decision was made and it's you know I'm not against the decision. And I think it's a great piece of technology we're trying to leverage in all these places. But if you imagine the code base like we're talking hundreds of teams like hundreds of services um like thousands of people, right? So uh saying okay we're mandating that we're going to be using this technology. One of the things that comes up is that there's actually places where we're not even yet using the basis of what this technology is replacing. So there's like a checklist to go through to make sure that this is all complete that says 100% of all of the services use it. And it's like look, you're act people might not realize this, but again, given the scale of things, you're telling us that we have to go into some of these services that might be basically in maintenance. No one's really touching them. They're just working. And now we need to go introduce a technology basically just to check a box even though it's it truly won't offer any net new value there because we're not even using what it was replacing. Like it was that concept was never even there. So uh again to your point like would we be in this halfway part like yeah maybe but like I was saying the tax in that case is like what I've been telling people is >> maybe the better approach is when we say hey we need to go leverage this thing for the first time in this service let's just introduce it at that point. >> Sure. >> It's slightly different from your original example because we don't have two things at the same time. we have nothing versus we should go introduce the thing. So maybe that's a slight difference too. >> Yeah, I I love hearing that perspective and like obviously Microsoft is such a huge company that when you're at that scale versus like a small startup where you have you know 20 or fewer engineers like the way that you make those decisions is going to be a lot different. Like the ramifications that you have to think about is also going to be a lot different. >> Yeah. the um like you know it's very your answer of it depends earlier right like the context is everything for these types of things and um I think it's so easy to start making arguments about stuff like here's the right way and here's why and it's like sure but if you omit parts of the context it can dramatically change so I think it's important for people to you know I think it's great you have these examples to walk through they can provide you a framework and what's cool about that is that what you're not doing is saying like simply follow these, you know, three steps and it will solve every problem. It's like here's framing for you. >> Apply the framing to your situation. If it doesn't fit, adapt it, right? But here's a basis to get started, >> right? Yeah. That's one of the lessons that I'm really hoping that people will come away with after reading the book is that it's important to be thoughtful about software development and not just be really dogmatic about things. And as an author, it's actually kind of tough to strike that right balance because you want to acknowledge both sides of like the topics that you're covering, but you don't want to water down your like original point. You want to still have a strong stance on that, but not like totally contradict yourself when you're talking about like the pros and cons of it. So, I'm hoping that I've struck that balance correctly. >> Yeah, that's a it's a very interesting point, right? It's like you're trying to offer a perspective, but it can almost be completely watered down if you say, "But in this case, but in that case," and then 400 pages of a book later, you're like, "I think I might have covered everything," right? And someone's like, "Dude, what were you even trying to say at this point?" >> Yeah. Yeah. And part of it, too, is how people prefer to receive advice. Like, I actually really like when there's this this discussion and nuance behind things rather than somebody only promoting one thing and only thinking about it one way. even though there is like merit to have like each approach and I think it's just different for the reader. >> Yeah. No, that's super cool. Well, Alex, I wanted to say thank you so much for making the time to to chat with me. I wanted to make sure, you know, I'll follow up with you offline to get links and stuff, but can you let people know where they can find you, uh, where they can check out your book and give us the details? I'll have links and stuff below, but if you want to let us know. >> Sure. >> Yeah. The easiest place to find me is just on the books website keepmandcodon.com based on the title and that has a section for contact which has both an email that you can reach me at or LinkedIn and I I'd love to hear from any of the future readers or even people that are just interested in the book or talking about software development mistakes that they've made in the past. Like I'm super open to connecting with people. >> That's great. And thank you so much for for for putting this book together and being someone that can lead by example with sharing like sharing fails, right? Like here's the lessons learned. Uh I think we would all be in such a better place if we saw more of this kind of stuff and not trying to avoid admitting to failures and like hiding from them. There's just so much to learn. So thank you. >> Yeah, I'm glad you appreciate that and I'm I'm just genuinely hoping that it helps others avoid the same mistakes that I made in my career. Awesome. Okay. Thanks, Alex. We'll chat soon. >> Yeah, sounds good. See you later.