What exactly doesn't mean to be a senior engineer? We don't mean necessarily how much as a senior engineer paid or what is the title. Really, we're talking about the responsibilities, the intuitions, the mindset. How do you become a senior engineer? Today's guest argues that it starts with that mindset. Today we're joined by Swizec Teller. Swiz is a senior engineer at TIA. He also authored the serverless handbook, which you can find at serverlesshandbook.dev. And most importantly for today's episode, he created seniormindset.com. Go and check that out that seniormindset.com. Let's get straight into the discussion with Swizec Teller. Swiz, welcome to the show. Hi. I'm excited to have you on. This topic is, I'm sure, top of mind for a lot of engineers. And if it's not top of mind this year, it might be next year. And I'm really excited to discuss this with you. But first, I'd love to give you the 30-second window here to give a pitch for who you are, what kind of work do you do, and then we'll get into our discussion. Yeah. So hi, I'm Swiz. I'm a software engineer at TIA, which is a health tech company. I've been in Silicon Valley now for, wow, seven years. I'm getting old. And lately I've kind of been exploring what it is that I've done in the last couple of years that has really unlocked my career from being a really good solid technologist to being more someone who can take on bigger challenges and do some team leading stuff and cool things like that. And I'm sure that the people who are listening right now, if they're in that phase of their career where they're trying to say, you're trying to figure out, how do I go from just writing code to, you know, being in some kind of higher level position, the higher level thinking, you know, maybe they want to employ a different kind of thinking pattern and get out of some of that day to day, you know, just coding is all they do. I'd love for us to kind of dive into this, but I want to start with a framing question here. If you had to sum up, what it means to be a senior engineer, what is the biggest differentiator? If you had to just pick one, what is the biggest differentiator between a senior engineer and let's say someone who isn't a senior? It's hard to decide what the name of that is, but a non-senior engineer. Yeah, so it's funny that you have a hard time coming up with that because I think a lot of people who aren't really seniors quite yet do have the title of senior engineer. And this is something we see especially in fast growing startups. You know, if you just stick around for three, five years, you're going to get that senior title, but it doesn't necessarily mean that you're actually a senior, senior engineer. I think the biggest difference that I've seen in my career and in team members' careers and just in general is that you kind of switch from thinking about focusing on just the code and thinking about the code into more about thinking of using the code as a tool to solve some problem. So to kind of expand on that, I think the biggest difference is going from give me the spec, tell me what to do and I'm going to implement it and I will make sure that it's perfect and amazing and the code is beautiful, readable, everyone else can understand it on the team and stuff like that. I don't really care about the code. Tell me what's the problem we're solving and I'm going to be a really solid partner to my product owner or my PM and work with them to figure out what is the smallest, quickest way we can get this to fit in the rest of the project so that we can solve the problem rather than focusing so much on the code. Yeah, it's like one way I like to sum it up is that at least in the last couple of years I've gone from being a really good hammerer to being someone who's really good at solving problems with a hammer. Yeah, that's a good way to think about it. You're a craftsman or you're kind of getting above that, you know, just whatever that kind of mechanistic action is and thinking more about how does that action support some larger goal? Exactly. Yeah, like what is the actual business objective we're trying to solve and one interesting thing that I've noticed as I started talking more about this and being more vocal with the PM, they come up with really good ideas but they don't always have the best ideas. That's why they need engineers otherwise they could just go and code themselves. And as I started talking more about, you know, if we if we change this requirement a little bit and we do it this other way, it's going to be much quicker and it's still going to solve the actual problem that you're solving. The more of that that I did, I found myself naturally getting involved earlier and earlier in the cycle because the product owners and the leadership team on my companies was like, oh, hey, this guy is actually thinking about this stuff. Why don't we just go ask him before we even come up with a solution and just be like, hey, we're solving this problem, come help us solve it. And then through those conversations, you suddenly find yourself being able to kind of steer the whole technical direction of the company and think more further ahead. Yes. So I've noticed this with senior engineers. Often the ones who tend to be the most successful, I've noticed two things. And that statement that you made, which probably is it may feel controversial to some engineers who are listening to this that I don't care about the code, which there's a lot of context to that. I'm sure we'll get into it. And then the other thing that I've noticed about successful senior engineers is that they tend to have a very tight relationship with product managers or product owners or whatever that role is on your team. It's essentially the person who is responsible for driving whatever that business outcome is. And those two things kind of go hand in hand. The context for, I don't care about the code is I care less about the code than I do about it working to solve this problem. I can come in and care very much about the code because especially over the long run, let's say we have 10 problems that are stacked back to back. If we continue to write poor code, then it's harder to solve problem number five, six, seven, nine, ten. And so we care about the code as a senior engineer, you care about the code because of that. Not just for the intrinsic value necessarily of the code itself. And then, oh, go ahead. Yeah, exactly. It's like you still care about the code being good enough, but you don't care about it being perfect because as long as it's good enough and it's maintainable enough. That's what you care about because you're solving the problem. And like you said, you're still care, you still care about solving the fifth and sixth problem. So you're more thinking about how the code sets you up for that rather than the initial like the initial of perfection or textbook perfection. I like to call it right now. The marker of a kind of junior engineer is the inability to get past an argument about, you know, what particular tool between two very close tools. And then, you know, what are we going to pick the marker of a senior engineer is someone who leaves their vote on the table sometimes and says that actually this is not where we need to spend our time or potentially even says we don't need to write this. Maybe they say actually this problem is the wrong problem altogether. We don't need to write this code in the first place. The amount of time you can save by not writing code is ridiculous. That's why that's also why I like being involved in the earlier stages of something or of a new project is because I can. So one of the things I start to do is my manager calls it bushwhacking is where instead of being in like I'm getting less and less involved in the day today's print work because I'm spending so much time looking ahead and working with product to get the whole project to a point so that we don't even get tangled in the bushes or in the weeds because I already tried to clear them out because I know we're going to get there eventually. You can either do that by changing what you're building, making sure you're building the right thing or by having those contacts with your product owners to look ahead and we like oh I know we're going to be building that we're going to be solving problem number five in three sprints. If we take that into account a little bit right now it's going to be a lot easier. This all brings up a lot of both personal experience memories and stories that I've heard about interactions with product owners and I'm curious. When you start taking on this role of being more connected to the product or looking kind of upstream of some of the specifications do you find yourself in conflict or otherwise feeling like you know you're in some ways stepping out of your role and into more of a product role. And if so how does that resolve with with a good product manager. So I wouldn't say I'm stepping out of the product role because at least how it works in silicon in more silicon valley style companies not necessarily companies that are physically here is that you have this model of empowered teams so instead of getting orders from up top that then get trickle down to the engineers it's more like your whole team gets an OKR business objective and then you work together and to solve that business to achieve. That business to achieve that business objective and the PM is considered to be part of your team they're not your boss they're not someone external they are part of the product team and you're a product engineer because you work closely on a product that has an outcome for some type of user. So I don't think you're actually you're not so much stepping out of the role of engineering and into product it's more about being a good partner and a good backup to product because they're more they're better at dealing with organizational complexity and coming up with ideas for features or things to try and then measuring them and figuring out if they were if they actually solve the problem or didn't. And they they do a lot of glue work between business and design and engineer engineering and all of that and I think what they really need is an engineer who is able to speak their language and who understands product has like a little bit of a business mind as well but you still need to be very deep in the code and the code base to know to be able to tell them hey this isn't possible or hey this is going to take too long and it's probably not worth it. But also to be the person who says hey there are three different ways to solve this they have these different pros and cons and then the product owner makes the call on what gets done. Yeah. Yeah. That makes sense. So you're just teaming up with them in a way and trying to give them kind of surface more information for them to make decisions but also kind of helping them see that you know what the ramifications of their decisions if you go this way it's you know 20% more expensive than if you were to go the other way for example. Exactly, I think it's similar to what I imagine a relationship between a golfer and their caddy looks like or I watch f1 between the driver and their engineer where the caddy is saying hey this is what the wind looks like this is this is what the stats are or the engineer is saying hey your tires are going to last another 20 laps if you do this if you do that. But then the driver or the golfer gets the final say in whether they're going to go for the swing or not. Yeah, that makes sense. So you're not necessarily kind of getting out of your role this this happens to be what the senior engineer role is is this kind of you know higher level thinking and problem solving not necessarily the decision making side of things but. Yeah, helping a surface the correct options for a given decision. Exactly and then when it's a purely technical decision I think it's best if you make it together with the whole team but what I've noticed ends up happening a lot is that the team uses you as if you're comfortable making those calls they let you make them it's like yeah right we're going to go to swiss or whoever and we're going to give them these two options. And they're going to make the call between them because they're the kind of person who is also going to take ownership if the call was wrong is going to say I messed up and if the call was right they're going to say the team did an amazing job. I think that's also an important part of it. Yeah, well will definitely dig into how does how does the senior engineer dynamic support and champion the team. Because it does go beyond just looking at the problem or just working with the PM there's other engineers are around too how do they respond to this and you know how what are those dynamics. I do want to ask one quick question while we're at it because I think this is a common scenario it's one that I've recently faced when you have a an emerging need on the product side. And it's it's fairly clear that there is a business case in that in that need. That is at odds in some ways with what you would consider to be what's a clean engineering. That's kind of a kind of a weird term but we'll stick with that the best practices engineering is at odds with whatever this business need is. What is the role of the senior engineer to try to either find which direction to go or finding common ground between those things. Oh yes. So we could probably do a whole episode on this but I would say that technical debt is a tool that especially in startups should be used as much as possible. And I have a really great experience to share on that the current startup I'm at. They got to the point of being on the verge of hockey sticking with a jQuery app and then they decided this jQuery is getting out of hand we need to rewrite the whole app. What we also have users banging on our door and we can't you know our like our biggest problem is that we have so much user demand that we can't keep up with the technology that we have. And then the hiring me as the first person as the first react person and the victim was basically take our jQuery app and rewrite it to react. Oh and by the way the business is not slowing down for this so figure it out. We ended up so they just raised a series a which I don't know how big it was but they use that to fund more time better more experts that could come in and work on a code base that wasn't that great because they proved that the business case is there. So they had the essentially prototype and not was time to make it more serious and over the next year we rewrote the whole app in react from scratch. We hire the entire react team taught everyone who didn't know react yet react and we were able to at the same time grow the company enough to then raise a hundred million dollar series B. So that's my story of leveraging technical debt and it is okay and you should totally do it. Yeah yeah it you know I think it is definitely an art form right to know when is that technical debt being leveraged versus when are we you know just kind of. Writing it out and I guess you know some of that comes down to again we're going back to team dynamics here the quality of life even just for the engineers who are who are having to work on on that on those problems. We'll get right back to our interview with Swiss right after we talk about today's sponsor. Celebrity is proudly supported by court. Court is the messaging tool that gives you direct access to hiring teams inside technology companies in London Europe and New York. It is the new way to find your next job. Court enables what is currently not possible assemble conversation with someone who wants to hire you with court engineers find work through these conversations rather than applications. And replies are meaningful fast direct and relevant in the impact of the conversations that you have could change not only your career but also the world around you. There are hiring teams inside the world's most advanced technology companies who use court to hire including recent white commentator alumni and publicly listed technology companies and everything in between. Entire engineering teams are built on court that wouldn't otherwise exist inside companies whose innovative work is enabling vaccines tackling climate change and powering the next wave of autonomous vehicles. Learn more today by going to court.co slash T. A. That's C. O. R. D. C. O slash T. A. Thanks again to court for sponsoring today's episode of Developer Tea. How does the senior engineer will start kind of at a big or high level what are the senior engineers responsibilities when it comes to the team morale and specifically I'm thinking about you know between kind of the difference between the senior engineer versus engineering manager. Are they would you say that that's kind of a team those those two kind of team up to think about morale together or where you see those responsibilities. I think they do they team up to an extent. I think the manager has the actual manager has a lot more time to work on team morale and. Good managers usually spend a lot more time talking to the team one on one than a senior would because as a senior still an I see and you're varying the weeds you don't necessarily have time for all of those one and once. I think it's a partnership in that the manager is kind of setting the tone and the senior engineer is a you know because you're more in the weeds you can you maybe not just can but you should be loud about things that are bugging the team like we keep dealing with this stupid thing that's in our way all the time. So you fix it. And I think senior engineers especially are encouraged to whenever you find something annoying. Just at least put it on the backlog somewhere even better create some time maybe take an hour. Twice a week and work on those little annoying things and fix them to make the whole rest of the team faster kind of like working as a force multiplier where a lot more of your work is focused on. Making life easier and faster for the rest of the team then on actual exact implementations because you know if you spend an hour implementing something some feature that's an hour you spend implementing a feature but if you spend an hour making every once they go five minutes faster and your team is 10 people or the season spreads to the whole engineering work and you've made. Everyone in the engineering work for five minutes faster every day you get that hour back very very quickly. And I think the other thing that see that you do as a senior engineer is kind of steer the team out of rabbit holes and this is where this is where I think the difference between the senior engineer title and the senior engineer as someone with actual work experience and a lot of battles cars. You get this sixth sense and you can say if we build it that way we're going to suffer in six months it's going to really hurt so why don't we try building it this other way that I've seen work in other companies or just hey you know. I see that you're all heading in a direction I've been there before in this like two companies ago or in this or in whatever project and these are the lessons I learned so we should really not go that way let's try to find even if I don't know yet what the bet what the better solution is at least I know what the bad ones are. Yeah, it's funny how much of our jobs as engineers is knowing what's what what the bad things are and just avoiding those and if we can find something that's less bad it tends to be a little bit better. Like one thing that I see a lot is it's hard to put into words but basically if you get the right data model or the right domain model of the problem you're solving everything else becomes so much easier. But it takes a lot of battles cars and like that's six that's by the sense to to be able to do data modeling well I think it's a it's one of those things that's really hard to learn unless you've just done it a lot. I don't think you can just read the book or take a course and now you're better at domain modeling it's something that just takes a lot of experience and that's good that's a really good way to force multiply your team or to just. Help with the moral is to step into those design conversations and just help them to help everyone define a better data or domain model so that they can then focus on the details or on the weeds of implementing the code because the most the part that has the biggest impact on how hard the code is going to be to write has already been solved. This is amazingly applicable to so many problems that I faced in software engineering I want to kind of stick on it for just a second and talk about how these problems that that you're pointing out like domain modeling they come back over and over to these things that we've probably heard a million times as engineers that you know for example one of the hardest things that we do as software engineers is that we do. So that's what domain modeling is all about right it's about knowing how to name a group of things so that it makes the most sense and as you move forward with that you know whatever that application is that wraps that model that the model itself kind of becomes obvious it helps kind of guide the way that it's used. It's amazing how so much of this comes back to that you know many of these things come back to some fundamental. You know truth that we learned when we were very early in our careers okay yeah we got to come up with good variable names and I think we substituted some of those lessons rather than saying oh this is a this is a hard problem right naming things is actually a hard problem it's not just we're just saying that it's a hard problem it really is. It really is it really in our heads we substituted something like oh that means that we can't use names like X and Y we need to use descriptive names well no it's more than that yeah yeah I think the best the best lesson I've learned from domain driven development is that naming things isn't hard it's super easy once you know what you're building if you can't come up with the name for it you probably don't know what it is you know what it is. Yeah well yeah that's that's a good point if you know exactly what it is I'll give you a practical example and we can use this as kind of a way to talk about this subject. I was talking with a with a colleague one time about how having vague names for let's say columns in a database almost insures that those columns are going to be used. For more than one purpose. So if you had a name like you know that suggests a type for example but doesn't necessarily require that type then two different people looking at this database they don't know. And so the name itself becomes kind of an interface for the people who are using this this piece of data the names of those columns becomes an interface and because it's not specific there's a very high likelihood that the data itself is going to come in and not be normalized right between those you know those two those two consumers or those two customers to that data and one of the worst problems to deal with is when. You have data that looks roughly the same but has subtly different meanings. Absolutely that is just you are going to suffer at some point somewhere. Yeah let's what's what's an exam I know it's this is hard to come up with on the spot but I'd love an example of that because I know there are junior engineers that are listening they're wanting to know one step further like what does that mean what is it mean to have data that looks similar but means two different things. I have a really good example from actually my current startup and this is an old decision that has been following us since it's been made but we we rebuild one of the things we build is appointment booking or medical or like when you want to see a mental health provider or some sort of doctor and there are two columns on the appointment table called scheduled time and booked time. Now tell me what is the difference between those two. Yeah hard to know unless you unless you have some special context right exactly because booked and scheduled are kind of synonyms one of them means where the actual time stamp when the appointment was created and the other one is when it's actually happening and I always get confused about the time. And so we as a senior engineer and this is where it all comes together for me as a senior engineer you could see this column and I'm obviously not speaking into your situation I'm sure there's a lot more complication to it than this but you could see this column and say okay scheduled time. Well actually this is appointment created at that's that's a maybe a better or more specific name than scheduled time and suggest that as a design kind of refactor that makes it may seem small right this is the amazing thing about these kinds of problems that the change is small and it's not fixing anything necessarily right but you imagine all these future. And all of these future you know cognitive overhead and all of these future bugs that could come as a result of this vagueness in the data and down the line things are necessarily better as a result of this. And good example that I've come across myself is especially when dealing with the kind of data that I deal with having a first name right this is a really interesting one addresses or a whole or another example of this. But first name is a really good example of this because what does that mean right what is the first name mean well for most people they say well it's whatever people call me is whatever I normally put down on a form but is it your legal first name or is it your nickname is it a shortened version of your legal first what thing is it specifically and how as a result of that what can we rely on this for can we rely on it just to send you a marketing email or can we rely on it if we're looking into you know a work day database or something and then there's entire cultures that don't even have first and last names exactly names yeah and really funny back to the example from earlier in our case it's actually book time that's created that's casual time oh yeah so even even when you're describing it still is confusing right exactly. Thanks so much for listening to today's episode of developer to you the first part of my interview with Swiz Teller you can find links to the things that Swiss is doing in the show notes and obviously find him on Twitter at Swiss at that's SWIZEC. Thanks again for listening to this episode and a huge thank you to today's sponsor cord cord is the messaging tool that gives you direct access to hiring teams inside technology companies in London Europe and New York get direct access to hundreds of people hiring your skill set you can send and receive messages directly from hiring teams themselves with everything happening in a simple messaging thread there's a calendar integration that's built in as well and all data is live and transparent including salary tech stack interview process and response times go and check it out cord.co slash T that's c-o-r-d-e-d-o slash T-e-a. Thanks so much for listening to this episode if you enjoyed this first part of the interview as was make sure you subscribe to this podcast and whatever app you're currently using and if you want to discuss this episode or anything about your career in your life with other engineers who are driven to grow and enjoy this podcast as well you should consider joining the developer to discord community head over to clappert.com slash discord that is free it always has been and always will be that's DeveloperTea.com slash discord thanks so much for listening and until next time enjoy your tea.