In today's episode, we pick back up with our guest, Suzek Teller. In the first part of our discussion, we began the conversation on what the differentiators are between a senior engineer and a non-senior engineer. You may think that you're a senior engineer based on your title, but in these two episodes, we'll talk about that mindset shift. So I've also created seniormindset.com. We talk a little bit about that in today's episode as well. Thanks so much for listening to Developer Tea. Let's get straight into our discussion with Suzek Teller. This is incredible. I was just going to say, it's incredible how these fundamental things, I think when I was a younger engineer, I thought, okay, the hard part is in the algorithms or the hard part is in some kind of design. Design, the specifics of the way that I'm dealing with this stuff. The data stuff is all easy. We just throw it in there and then fetch it out. But all of the other things are the hard part. But amazingly, the system design problems tend to be where the biggest opportunities are for seniors. Yeah, because especially with modern computers, algorithms just aren't that important anymore. Because compute is very... Very, very cheap. And at least in web programming, we use languages that are so slow that it gets overshadowed by the slowness of the web as a platform. Like a really cool example I like to use is when people have a function that makes three API calls and then does some data manipulation or an algorithm with an array of a thousand elements. And they will spend... So much time with all complexity and looking at that algorithm for a thousand elements and obsessing over it and figuring out how to make it perfect. And it's like, yo, you're spending half a second on making three API calls. Wouldn't you want to look at that instead? That's going to be much more effective use of your time, right? Exactly, yeah. Yeah, it's, you know, I think about complexity a lot. But I don't... I think about it a lot because I'm dealing with it in an algorithmic sense. I think about it more as a mental model. And so for that reason, I'm excited when I hear that people have, you know, some kind of formal understanding of that because we can have that common language. But rarely is it because the code that we're writing is, you know, we need to go from linear to log or whatever. That's not the point of that particular skill. It's more of a thinking tool. It's more of a thinking tool than it is actually practically useful. Totally. Yeah, and it's good to at least think about so you don't have accidental complexity or super complex algorithms. But I think the other important skill for a senior is prioritization. And that's something we see a lot of seniors fail in interviews is because they don't know how to use their time effectively. Like one of my favorite interviews to give is a refactoring exercise that's specifically designed to be... to take too long for an interview if you want to do everything. And we tell this to interviewees. We say, you don't have time to do everything. Even if you think you do, we promise you that you don't. So we want to see how you prioritize. What is it that you go fix first? And it's very... It's one of the most... Next to system design, I think that's one of the most revealing interviews for whether someone is ready to actually be a senior or if they just have the title. One of the things that I look for, especially in senior applications, because most of the time we have a small exercise and I haven't done it in my current role, but I've done it in previous roles. Mm-hmm. The exercise... What I'm looking for most of the time is exactly what you're talking about, the ability to prioritize. We explicitly will provide some kind of small window. And we do this for a couple of reasons. The first one is we genuinely don't want you to spend a ton of time on this because it's not... The ROI is not there for anybody, right? We're really just trying to assess how you approach problem solving. You know, as a secondary part of that, we cap it well under what it would take to actually do everything to the degree that, you know, feels complete. The possible features you could build far extend beyond the time window. Yep. And so what we want to see is what do you choose to do first? What do you choose to do, you know, in the initial parts of this? Yep. Because... The requirements are very clearly laid out. And the kind of nice-to-haves are very clearly laid out. Did you put in a nice-to-have and skip over the requirements? Right? That would be... That would indicate a problem with prioritization. And then also, most of the seniors... This isn't... And I bet you, you have something like about this in your set of opinions about seniors. Most of the great developers that we hire, that I've hired in the past, will have such a clear way of writing what their decision-making process was, but also what they would do next. Why did they prioritize this way? Why specifically did they cut this out, but put this in? That has been a consistent factor in virtually every senior engineer that I've ever hired. Yeah. It's almost like looking for whether they have a consistent consistent or, yeah, if they have a consistent philosophy of software engineering, if they have an approach that they like to take. Even if it's an approach I don't agree with or that we have disagreements on, it should exist for a senior. A senior should have seen enough code in their life that they have strong opinions. Hopefully weakly held, but at least strong opinions. And the reason that's important isn't just because it shows that you have clarity of thought and clarity of mind, but it's super important for the mentoring portion of the senior role. Because if you're able to help the rest of your team come to decisions and design things and also explain why you made that decision or how you made it, they're not going to have to ask you next time. They're going to be able to make it themselves. And that's how you can actually grow the rest of the team around you. Otherwise you end up being one of those seniors that's just, bogged down in messages all day, every day, and they can't do anything. And you become a single point of failure for anything getting done on your team. Whereas if you can explain every decision, you can be making fewer and fewer of them as time goes on and people are empowered to step into those roles. Yes, this is absolutely one of the biggest multiplier factors. Not only because you don't want to be a bottleneck, but because you may not, be there all the time. You could be out on vacation, you could be, you could go to another team. And it's a part of the kind of life cycle of work for you to be absent. And a great senior engineer knows that their absence shouldn't mean that the team falls apart. Another thing I think about with this is when you have a great senior engineer, they don't always rush to be the person who solves the problem. And I've noticed this, especially with staff level. This is like the senior, senior engineers. They almost hold back from solving the problem because they want to make sure that the, I guess, atmosphere on the team is that anybody can always, you know, have their own problems that are happening on the team. It doesn't always have to be, even the important problems. It doesn't always have to be the senior engineers. We want everybody to be involved with this. I found this very striking because I think as a younger engineer, you think that your role as a senior is to be that super powered 10X developer, whatever that incorrect picture is. But really your role is to try to shape, a more, a useful environment almost, right? It's environment shaping and platform shaping to the degree that other people can be incredibly productive. Yeah. Like one of my favorite things to do in this area is to, like on my team, we have the concept of almost like distributed ownership where anyone on the team can own a story. And that means you own it. You actually own the outcome of that story and you're responsible for it. And one of my favorite things to do is to take on that ownership role for a story and not actually be involved in any of the implementation directly. What I do is review PRs, answer questions and create an environment where I'm not actually creating the solutions. My input to the final solution is more in asking questions and being like, okay, so you've solved this. Awesome. Have you thought about this edge case? Or have you thought about that thing? What about if this happens? And through those questions, helping the team come up with a really great solution that then ends up being reliable and robust. And because they've come up with the solution, they can, they then also have that lesson for next time so that they will think about it before somebody asks them. Yeah. It is really about kind of creating this, this portfolio of solutions or models for solutions. And then taking advantage of that as a team together, I think is hugely valuable. I'm curious, you know, this is kind of shifting gears just a little bit. If I am a, let's say a junior engineer, or maybe I'm right on the verge of maybe have that title. I have that senior title, but really I'm looking to become truly a senior engineer. Maybe the company that I work for calls it a staff engineer or an architect or something like that. What are the most common misconceptions that I might have about what it takes to become a senior engineer? And how do I fix those? I think the most common misconception is that people think they need to become more and more senior engineers. They need to become more and more senior engineers. They need to become more technical or better at technical solutions. Like learn a new language, learn a new framework or any number of those things that everyone on the internet is always telling us we should do like go learn Rust, go learn Haskell or whatever. I don't think any of that will actually have as much of an impact as, as it would to shift your mindset, to be more involved with the problem solving part of it, not the implementation part. You know, the, what I said earlier, going from being a better and better hammerer to being really good at using a hammer to solve business problems, because that's what fundamentally gets measured in companies is who's solving the business problems, who is bringing in essentially like who's bringing in the money. Like, you know, in lawyers have this concept of bringing in clients and that's how you get promoted. In engineering, I think it's taking on responsibility, not the implementation, but the responsibility of bigger and bigger projects being successful. So like as you get more involved with the, with your product managers and talking more to them, that will propagate throughout the company. And you then, what I think is really staff and staff and above level is when you can own the technical aspect of, of company wide initiatives and objectives. And the, like, it's kind of hard to, hard to fully put into words. But I think what happens is that as you think, as you start thinking more in those ways and being vocal about the business problems and having that hunch for what is important to solve and what isn't important and focusing on the important stuff that gets noticed in the organization, and responsibility kind of just starts sticking to you, like, like you're made of glue or something like that. And as you get more of that responsibility, you then, that's, that's where those promotions come out of. But I've never been a manager, so I don't actually know what it is that if that's true, if that's what managers look for, but that's what I've noticed. Managers have been pushing me towards and what's been noticed more the most in, in the organization. Like, um, to give you an example, writing better JavaScript or splitting things into microservices or introducing TypeScript. That's great. My manager notices that and he says, this is really awesome. Let's keep, let's keep going. But what gets my head of engineering to come to Slack me and say, yo, we have this really important business objective coming up. I want you to lead the implementation of it. You have free pass to talk to the VPs of the vendors to choose which vendors to talk to. Which vendors want to use, get anything you need. We want this to happen because it's critical to the business. I think that came out of showing the results and being like, Hey, we focused on the important stuff. I was leading the project. We shipped it, it shipped on time. It got the results. It really had a big impact on business metrics. And that's what gives you that trust from the, from leadership to go. We want you specifically to own this project. We want you to lead this project because we've noticed that when you do that, they go better than when somebody else does it. Hmm. Yeah. Yeah. That, if you put yourself in the position of a manager or a leader, head of engineering, all of those positions have different, uh, I guess kind of, uh, motivations, right. And as a manager, I'm looking for your performance over time. I'm looking for how you're affecting the team as a head of engineering. Uh, I might be looking for you to be a key part of a strategic initiative. And a head of engineering might be, uh, less concerned with, let's say for example, uh, you investing in your immediate teammates, whereas your manager is much more concerned with that. Uh, and I think there's, there's a good balance here, right? It's important for the senior mindset engineer to recognize that there's, there's, there are going to be, and for what it's worth, there's going to be competing incentives that are trying to pull you in multiple directions. And part of your job as a senior engineer is to once again, to be able to prioritize that, right. To, to know, okay, where, when, when is it, uh, the most critical thing for me to do to go and be a part of this outside strategic initiative that doesn't necessarily involve my team directly, versus when is it time to spend time with my team reviewing their code, right? These feel like very different, um, exercises, both with perfectly good reasoning as to why you would choose to do them. Yeah, exactly. And a lot of those external, like leading core core initiatives comes down to the bushwhacking I was mentioning earlier. If you're there in those early conversations and you have the lay of the land, when you get to the, the super sliced agile story, user stories, you are the one who has that broad cons, a broad lay of the land and can help guide your team to a solution. That's not going to fall apart by the time you get to problem number five, because you have that longterm view of it. Yeah. Yeah, this is, I think, I hope that we've helped some people change the way they think about becoming a senior engineer. You know, what does that job look like? And hopefully we've actually helped some people feel like it's more accessible because especially if you thought, well, I have to learn like six more languages or like, you know, I've got to have these three certifications before I can be, you know, a senior in, in almost every case I've ever seen. That's not true. And, uh, what is true is exactly what, so as what you've been talking about, which is aligning yourself with that value that you have, that you're trying to achieve, that you're trying to achieve, that you're trying to achieve, that you're trying to achieve, that you're trying to achieve, that value stream in the business and enabling that, um, both through your own contributions and helping others enable that through their contributions. I think that is really the key to becoming a senior engineer, not only just becoming a senior engineer, but actually helping the business succeed. Um, that's actually how businesses operate. Uh, and it seems kind of foreign, uh, in some ways to an engineer to, to, to say, well, the code is not really necessarily the thing that makes the, the business operate. Well, that's actually true. And you have an opportunity to step into that value stream. That's how you're going to grow in your career. Probably the fastest. We'll be right back with our discussion with Swiss teller. Right. If we talk about today's sponsor. We'll be right back. We'll be right back. We'll be right back. I think at, especially at higher leadership levels, the only thing that's really visible is that we are the business metrics going in the right direction. and who is most likely to get them to go in the right direction and who just isn't a problem to work with at the, at a fundamental level. It's like, if we take you, the project is going to get done. It's going to get done on time or mostly on, or, at least there's going to be a very good reason why it's not done on time, but it's still going to get done eventually. And we can just trust you that if we give you a problem, it's just going to get resolved. You're going to keep us updated on, on like progress. We're not going to have to follow up 10 times to make sure it got done. You know, it's like when you hire a plumber, you want a plumber who comes in and you say, toilet's broken and they fix the toilet and you don't even know what happened, but the toilet now works better. Or do you want the plumber who comes in and is like, well, what do you want? Do you want me to change that pipe? Or do you want me to close that faucet? Or I don't know, you're the expert, just fix my toilet. And that's kind of how the higher, the higher and higher you go in leadership, that's more and more how they think about it. It's like, I don't know how you do it. Just fix it. Yeah. Yeah. And if you were to think about, you know, being in a leadership position and trying to solve a bunch of problems, do you want to have to tell each person how they're going to solve the problem and not be able to, and it really comes down to delegation of responsibility. It's not delegation of tasks. It's delegation of responsibility. Exactly. Because whoever is, is, you know, giving you that position, let's say they're the head of engineering. They don't really care how it gets done. I mean, to some degree, maybe they have some principles that inform them. They care that you're not doing harm in order to accomplish your goals. And they probably don't want you spending an exorbitant amount of money, but they're probably ready to spend some money, right? Otherwise they wouldn't hire engineers. And they're also probably ready to not have to think about all of the details. Once again, why they've hired engineers, right? So if they can delegate responsibility, your capacity to take responsibility for something is highly correlated to your capacity to be promoted. Yep, exactly. And that's where also then the autonomy that everyone's dreaming about comes from is if they can delegate responsibility to you, that automatically also gives you, a lot of the autonomy that so many engineers want. But let's be honest, most engineers aren't actually ready for as much autonomy as they want. Right. Because most engineers want the autonomy to go and do the thing to the spec. Yeah. Right. But they're not ready for the autonomy of making the decision and carrying the responsibility, whether it fails or succeeds. Exactly. So it's heavy. It's not an easy thing, right? No. I think that's another important message that at least I want to get across, and I'm sure you do too. Mm-hmm. That it doesn't, just because maybe this is more accessible than the folks listening might have thought originally coming into this episode, it does not mean that it's emotionally easy. Mm-hmm. It doesn't mean that it's intellectually easy or relationally easy. Yeah. None of this is necessarily an easy thing, but it definitely has a more natural path than maybe most engineers might intuitively expect. Yeah. Yeah. And I think the hardest part of autonomy and probably the thing that makes it most likely that you're going to get more autonomy and more responsibility is when it goes wrong. Mm-hmm. It's very hard, but- Yeah. ... you really have to do is say, I messed up. It went wrong. Here's why it went wrong. Here's how it's not going to go wrong next time, and this is what I'm doing to fix it. Mm-hmm. And that's how you get more responsibility next time. But it's really hard to do that. Yeah. That is, I mean, one of the most important things that you can do when looking for a role- Mm-hmm. ... for folks who are looking for their next job is ask what happens when things go wrong here. Mm-hmm. If the culture supports that opportunity to say, yeah, sometimes things do go wrong, like that just is par for the course. It's going to happen. Mm-hmm. What we expect when things go wrong is that you learn from it, that you apply your learning in some way, that you actually have a plan for how you're going to respond to the failure. Those are the things that you look for. Mm-hmm. And if you have cultures of fear or of blame or those other pieces that make that incredibly uncomfortable, you get to experience failure and that kind of rebound or response to failure, that is a huge growth opportunity. Yeah. And to your point, that's where you learn to have that autonomy that is actually useful. Mm-hmm. Yeah. Because it's easy to show ownership when everything is sparkling gold and going awesomely. But the real ownership is what do you do when shit hits the fan. Mm-hmm. Yep. Absolutely. Thank you for joining me to discuss this. I have a couple of other questions, but before we get into those, I want to ask you, for engineers who are listening to this and they just want a lot of information, what are some things that you would like to see in the future? I know you just want a lot more of this discussion because we haven't covered all of the points that we could. Where should they go? What can they learn from you more on this subject? Yeah. So I have a tiny little website called seniormindset.com where you can get a series of emails or essays that I've written about this over the last couple of years as I've been learning about it. And it's essentially a collection of my most impactful essays on the mindset of a senior engineer. And they're currently also being packaged as an ebook. And probably by the time you listen to this, the ebook is going to be out and you can binge read the whole thing. Because apparently the essays are good enough that the most feedback I've gotten were people saying, yo, can I stop waiting for the next essay to come in email? Can I just binge read this whole thing? So that's how the ebook happened. Yeah. So that's on seniormindset.com. Excellent. And you can also go to swizzes.com, which is my blog where it's a little bit more off topic and more technical and mindset kind of all mixed together. Perfect. So seniormindset.com. That will be likely in the show notes, assuming I remembered to write them correctly. Yeah. That should be in the show notes. I do have two questions I like to ask guests who come on this show. And we'll start with the first one. What do you wish more people would ask you about? Oh, that is a really good question. What do I wish more people ask me about? Wow. Nobody has asked me that before. I think one thing is that I keep harping people on is how to think more in probabilities and statistics and making bets rather than looking for perfect answers to everything. You're on the right show. We could talk about that for a whole nother episode, I think. Tell me more about your thinking on this. Yeah. So a lot of this has been brewing for a while and then it really solidified when I read Thinking in Bets by I think Annie Duke. Yes. Annie was actually on this show talking about thinking in bets. Oh, she was? Yeah. Nice. Yeah. So I found that book to be really impactful. I really liked it. And it's basically, you can never really make the perfect decision, but you can look at the odds of the different options. You have and make the best possible decision and then go with that. And where I've really applied that in engineering is being able to say, this is not worth fixing because it doesn't have a big enough impact, doesn't have a big enough expected value. Let's fix this other thing or just evaluating different options of how to implement something and just taking a bet and choosing one of them and being very comfortable with that because I know I'm not going to be able to do it. I know I'm not going to regret the decision because just because the outcome is bad doesn't mean the decision was good and vice versa. Just because the outcome is good doesn't mean that the decision was a bad outcome doesn't mean it was necessarily a bad decision and a good outcome doesn't necessarily mean it was a good decision. So thinking about it that way has really helped me make decisions faster and be able to be that person on the team who... Who can almost like parachute into a technical meeting and five people are discussing something and they can decide how to solve the problem. You can listen to everyone's input and just make a decision because you're comfortable making those bets and say, let's go. Let's take this way because X, Y, and Z. And then if it doesn't work, I'm going to take the heat because I made the decision. It's... It's amazing how many of these pathways are... They're worth exploring more in depth. Certainly, the book is worth reading as well. Something that you mentioned is that... Well, two things I want to touch on. One is it has been fairly easy for me when I talk to people about this subject that a bad outcome doesn't necessarily mean a bad decision. Most people can kind of get there. Like I said, I'm not a big fan of bad decisions. They may not have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have taken the plunge, they may have a good decision. Intuitively, we think that it's impossible to have a good outcome with a bad decision. And that's not true. Right? Yeah. Like you can run a red light and you don't crash, but running a red light is still not a good decision. Right. And even more extreme things like you could have a very successful startup as a result of a series of, you know, strokes of luck, basically. And even if you make a bunch of bad decisions, it doesn't necessarily mean that, you know, that those, those positive outcomes that you're enjoying are because of those decisions that you made. Yeah. It's like they say in a sale in a business sales covers all sins. Yeah, that's a good, that's good. Oh, and I've seen, you know, the, the results of previous games, you know, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, good decisions that end in good, uh, you know, good outcomes could absolutely be kind of influencing what you're thinking is a more localized decision, which was a bad one, having a good outcome. It's actually because the good outcome is still trailing from that previous decision. Right. An example of this is if you've built a really great brand, uh, and you're in, you're selling products and you come out with a really bad product, but it's carrying that really great brand. Uh, it's still may have a decent sales quarter because it has that brand. Yeah. Yeah. Yeah. You see that a lot in very big companies where they would have to mess up so many decisions in a row for the money printing machine to stop that it's almost impossible to tell. Yeah. Yeah. Which, yeah, this is a whole other, uh, uh, I guess, class of problems to solve. Certainly. Uh, but I, I like what you're, what you're saying here at the more atomic level that because you have these tools of reasoning where you can apply this kind of statistical thinking, you can come into a meeting where you didn't really have a lot of context and assuming that you can ask the right questions and get accurate info from the questions that you've asked, you can help make decisions. You can kind of be the, uh, the operator in the room that helps wade through. Some of, some of, you know, what other people are having trouble wading through. Exactly. And that's another way to force multiply your team is to help unblock them on those things. Yeah, absolutely. I've also noticed, uh, with this, with this idea of being an, an, a, a statistical unblocker that a lot of people have somewhat of a way of saying, oh, this is more likely to succeed. than this other thing or given two options that they can't really tell the difference between them. They're just going to go with the one they like. And another kind of statistical thinking that I've tried to help introduce to my teams is the second order thinking. In other words, okay, yes, you may have two equal options on their face, but what are the downstream effects? Or is one of those options easier to reverse the decision on? Yes. And if they're otherwise equal, then the one that's easier to reverse is probably a better option, right? Yes. It's whatever that second step is. And I think a lot of people intuitively don't think about the second step, um, as kind of a core part of the decision. Yeah. Or like when you're writing code or designing solutions, thinking about what is this going to encourage? What kind of behavior is this going to encourage in the rest of the team? At the same time, you may have these evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution it's a relatively short one. If you could spend just 30 seconds giving advice to engineers of any background and experience level, what would you tell them? I would tell everyone to read How to Win Friends and Influence People and read The Goal. I think those two books will have a bigger impact on your career than all of the technical books you could read, assuming you already know how to code. Wow, yeah. So you're pointing folks to these two books. So the first one was How to Win Friends and Influence People. Most people have probably heard of that one. The second one, I don't know that I've heard of. What was the name of the book? The Goal. It's from something Goldratt and it's about the theory of constraints. It's actually a management book talking about manufacturing and it deals a lot with how to have smoother manufacturing processes. What is the actual goal of manufacturing? So that's where a lot of my ideas earlier come from, where why do you even do engineering? Well, it's because the business wants to achieve some goal and that's actually the goal of engineering. It's not the coding itself. And then if you want to dig deeper into that stuff, there's kind of spiritual successors to the goal are the Phoenix Project and the Unicorn Project, where it's more specifically theory of constraints applied to software engineering and IT systems. And that's also where the whole DevOps movement comes out of, et cetera. Absolutely. Excellent. That's kind of a cheat code, because you're giving 30 seconds of advice to go and read for a couple of hours of that info. So that's great. Thank you so much again. And if you'd ever love to come back or ever would like to come back on the show, we would love to have you come back. But otherwise, once again, if you want to hear more from Suez, head over to the Senior Mindset. That's seniormindset.com. Not the Senior Mindset, but seniormindset.com. And what else can we share with listeners about where they can find you online? Yeah, seniormindset.com or suizets.com. Or probably if you just put Suizet Stellar into Google, you'll find a lot of places where you can go from there. Excellent. So thank you again for joining me on Developer Team. Thanks for having me. It was fun. Thanks so much for listening to today's episode of Developer Team. Thank you again to today's sponsor, LaunchDarkly. You can get started with feature flags that won't break on you and will help you deliver faster and more frequently to your users with much more confidence. Thanks so much for listening to this episode. Thank you again to Suiz for joining me once again at Suizet on Twitter and seniormindset.com. Go and check out everything he is creating there. If you'd like to discuss this episode or anything about your career or your life as an engineer, you can join other engineers who have that same, same desire. Head over to developertea.com slash discord. That community is totally free. And it always will be for listeners of this show. Thanks so much for listening. And until next time, enjoy your tea.