In today's episode, we pick back up with our guest, Swizec 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. Susette was also created senior mindset.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. Swizec Teller. Yeah, this is incredible. I was just going to say this. It's incredible how these fundamental things, you know, I think when I was a younger engineer, I thought, okay, the hard part is in the algorithms or the hard part is, you know, in some kind of design specific, you know, 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 kind of opportunities are for seniors. Yeah, because especially with modern computers, algorithms just aren't that important anymore because compute is very, very cheap. And at least on the 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 it 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. It's like, you're spending half a second on making three API calls. Yeah. Like, 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 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 some kind of formal understanding of that because I can, 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 the log or whatever. Yeah. That's not the point of that particular skill. 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, the other important skill for a senior is prioritization. And that's something we, we see a lot of seniors failing 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, if you want to do everything and we tell this to, to interview is 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, right? 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. 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. I mean, 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, on this because it's not, the ROI is not there for, for anybody, right? We're really just trying to assess how you approach problem solving. As a secondary part of that, we cap it well under what it would take to actually do everything to the degree that feels complete, right? The possible features you could build far extend beyond the time window. And so what we want to see is, what do you choose to do first? What do you choose to do in the initial parts of this? Because the requirements are very clearly laid out and the kind of nice to have are very clearly laid out. Did you put in a nice to have and skip over the requirements? That would indicate a problem with prioritization. And then also most of the seniors, this isn't anything. I bet you you have something like about this in your set of opinions about seniors. Most of the great Developer 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 or 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 this agreement on, it should exist for a senior should have seen enough code in their life that they have strong opinions. Hopefully weekly help, but at least strong opinions. And the reason that 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 make 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 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 atmosphere on the team is that anybody can 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've found this very striking because I think as a younger engineer, you think that your role as a senior engineer is to be that super powered 10X developer, whatever that incorrect picture is. But really your role is to try to shape a more useful environment almost. It's environment shaping and platform shaping to the degree that other people can be incredibly productive. One of my favorite things to do in this area is to, on my team, we have the concept of almost distributed ownership where anyone on the team can own a story. That means you own it. You actually own the outcome of that story and you're responsible for it. 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 to those questions, helping the team come up with a really great solution that then ends up being reliable and robust. Because they've come up with the solution, they then also have that lesson for next time so that they will think about it before somebody asks them. It is really about creating this portfolio of solutions or models for solutions and then taking advantage of that as a team together, I think it's hugely valuable. I'm curious, this is shifting gears just a little bit. If I am a, let's say, a junior engineer or maybe I'm right on the verge, maybe I 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 technical or better at technical solutions. 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 it would to shift your minds as to be more involved with the problem solving part of it, not the implementation part. What I said earlier going from being a better and better hammer 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? 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. As you get more involved 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 above level is when you can own the technical aspect of company wide initiatives and objectives. It's kind of hard to fully put into words but I think what happens is that 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 you're made of glue or something like that. As you get more of that responsibility you then 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 the most in the organization. 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 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 three paths to talk to the VPs of the vendors to choose which vendors want to use yet 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 shifted it shipped on time it got the results it's really had a big impact on business metrics and that's what gives you that trust from the from leadership to go we want to use specifically to own this project and to lead this project because we've noticed that when you do that they go better than when somebody else does it. 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 I guess kind of 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 I might be looking for you to be a key part of a strategic initiative and a head of engineering might be less concerned with let's say for example you investing in your immediate teammates whereas your manager is much more concerned with that 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 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 know okay when when is it 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 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 super sliced agile story user stories you are the one who has that broad cons 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 long term 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 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 what is true is exactly what so as what you've been talking about which is aligning yourself with that value stream in the business and enabling that 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 that's actually how businesses operate and it seems kind of foreign in some ways to an engineer 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 rather than we talk about today's sponsor this episode of Developer Tea is proudly supported by launch darkly launch darkly is feature management for the modern enterprise fundamentally changing how you deliver software than here's how it works launch darkly enables development and operations teams deploy code at any time even if a feature isn't ready to be released to users wrapping your code with feature flags gives you the safety to test new features and infrastructure in your production environments without impacting the wrong end users when you're ready to release more widely it's as simple as updating the flag status and the changes are made instantaneously by the real time streaming architecture you don't need to waste your time building the system that does the feature flags in fact it's pretty hard and error prone instead focus on delivering value to your customers head over to launch darkly dot com and get started today with launch darkly you'll innovate faster deploy fearlessly and make each release a masterpiece thanks again to launch darkly for sponsoring today's episode of Developer Teaexactly it's like 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 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 it 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 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 tall is 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'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 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 you know 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 your capacity to take responsibility for something is highly correlated to your capacity to be promoted yeah exactly and that's where also then the autonomy that everyone's dreaming about comes from is if 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 it's heavy it's it's not an easy thing right it's that's I think that's the important another important message that at least I want to get across and I'm sure you do too that it doesn't just because you know maybe this is more accessible than than the folks listening might have thought originally coming into this episode it does not mean that it's you know emotionally easy doesn't mean that it's intellectually easy or relationally easy none of this is is necessarily an easy thing but it definitely has a more natural path than maybe you know 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 and it's very hard but what 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 and that's how you get more responsibility next time but it's really hard to do that yeah that's that is I mean one of the most important things that you can do when looking for a role for folks who are looking for their next job is ask what happens when things go wrong here if the culture supports that opportunity to say yeah sometimes things do go wrong like that just is part for the course it's going to happen 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 and instead of you know cultures of fear or blame or those other pieces that are 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 and to your point that's where you learn to have that autonomy that is actually useful yeah because you know it's easy to show ownership when everything is sparkling gold and going awesomely the real ownership is where what do you do when when shit hits the fan yep absolutely well so 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 you know a lot more of this discussion because we haven't covered all the points that we could where should they go what can they learn from you more on this subject yeah so I have a final 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 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 binge read the whole thing because apparently the essays are good enough that my the best feedback the most feedback I've got and where people saying yo can I stop waiting for the next essay to come in the email can I just binge read this whole thing so that's how the ebook happened yeah so that's what's your mindset.com and you can also go to swizzes.com which is my blog where it's a little bit more off topic and more technical that mindset kind of all next together. Perfect so seniormindset.com that will be likely in the show notes assuming I remembered to write them correctly that should be in the show notes. I do have two questions I like to ask guests who come on the show and we'll 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 we wish more people ask me about? Wow nobody has asked me that before. I think one 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. Actually we could talk about that for a whole nother episode I think. Tell me more about your thinking on this. Yes so a lot of this has been brewing for a while and then it's really solidified when I read thinking in bed by I think Annie Duke. Yes so Annie was actually on this show. Talk to us. Oh she was thinking in bed. Yeah nice. Yeah so that's I found that both 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. It doesn't have a big enough expected value. Let's fix this other thing or just you know 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 regret the decision because just if 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 that has really 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't 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 amazing how many of these pathways are there 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 the subject that a bad outcome doesn't necessarily mean a bad decision. Most people can kind of get there like oh okay yeah I can understand how you wouldn't be able to know what the outcome was and you know sometimes good decisions go wrong right that's okay sometimes really great you know quarterbacks or whatever sports you follow sometimes they lose games the best teams lose games too right. The other is much harder to get people to to accept which is a good outcome doesn't necessarily mean 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 not 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 sale in business sales covers all things. Yeah that's a good one's good and I've seen you know the the results of previous good decisions that end in good 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 yeah an example of this is if you've built a really great brand and you're in your selling products and you come out with a really bad product but it's carrying that really great brand yeah it still might have a decent sales quarter because it has that brand. 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 I guess class of problems to solve certainly but 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 there are questions and get accurate info from the questions that you've asked you can help make decisions you can kind of be the the operator in the room that helps wade through some of some of you know what other people are having trouble wading through. That's another way to force multiply your team is to help unblock them on those things. Yeah absolutely. I've also noticed with this with this idea of being and a statistical unblocker that a lot of people have have somewhat of a way of saying oh this is more likely to succeed than this other thing mm hmm. 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. Mm hmm. And another kind of statistical thinking that I've tried to help introduce to my teams is the second order thinking in other words. mm hmm. 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. Mm hmm. I think a lot of people intuitively don't think about the second step as kind of a core part of the decision. Yeah we're 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. Can I write this code so that it's not just this code that's good but so that also others who are following these patterns by accident almost by accident write good code as well. Mm hmm. Yeah yes. Yeah I'm trying to follow good practices as a modeling step rather than just for this specific problem. Yep. So as thank you again for taking the time. I have one final question for you and hopefully 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 you're pointing folks to and these two books so the first one was how to win friends and influence people. Most people 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 is from something goldrat and it's about the theory of constraints. It's a it's actually a management book talking about manufacturing and it it deals a lot with how to 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. I mean if you want to dig deeper into more of that 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 then DevOps movement comes out of etc. Absolutely. Excellent. This is that's that's kind of a cheat code because you're giving 30 seconds of advice to go and read you know for a couple of hours. That's a bad 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 Swaz head over to the senior mindset that's seniormindset.com not the seniormind but seniormindset.com and what else can we share with listeners about where they can find you online? Yeah seniormindset.com or swizzets.com or probably if you just put swizzets teller into Google you'll find a lot of places where you can go from there. Excellent. So let's thank you again for joining me on Developer Tea. Thanks for having me. That was fun. Thanks so much for listening to today's episode of Developer Tea. THING. You again to today's sponsor launch darkly. 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 Swaz for joining me once again at Swazek on Twitter and seniormindset.com go and check out everything he is 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 desire. At 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.