What exactly does it mean to be a senior engineer? We don't mean necessarily how much is 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 Swizz Eckteller. Swizz 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's seniormindset.com. Let's get straight into the discussion with Swizz Eckteller. Swizz, welcome to the show. Hi. I'm excited to have you on the show. 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 Swizz. I'm a software engineer. 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 know, trying to figure out how do I go from just writing code to, you know, being in some kind of higher level position, 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. And 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 specs. 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. To more like, 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 world. So that we can solve the problem rather than focusing so much on the code. Yeah. 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. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. noticed as I've 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 it themselves. And as I started talking more about, you know, 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 in 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. One, 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 going to be a lot more difficult to solve the problem. And so I think that's a lot harder to solve problem number five, six, seven, eight, nine, 10. And so we care about the code as a, 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, uh, 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, you don't care about the code being good enough. And so I think that's a lot harder to solve than you think. That's what you care about because you're solving the problem. And like you said, you're still, 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, uh, the initial, like the initial perfection or textbook perfection. I like to call it, uh, right now. The marker of a, of a kind of junior engineer is the inability to get past, uh, uh, uh, uh, an argument about, you know, what particular tool between two very close tools are we going to pick the marker of, of a, of a senior engineer is someone who, uh, leaves their vote on the table sometimes and says that actually this is not where we need to spend our time or, uh, potentially even says we don't need to write this code. Maybe they say, actually, this problem is the wrong problem altogether. We don't need to write this code in the first place. Uh, 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 started to do is, uh, my manager calls it bushwhacking is where instead of being in, like, I'm getting, I'm getting, I'm getting, I'm getting less and less involved in the day-to-day sprint work because I'm spending so much time looking ahead and working with product to get the, 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. So 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 be 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. Yeah. This, 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, you know, when you started taking on this role of being more connected to the product or, or looking kind of upstream of some of the specifications, do you find yourself in conflict or otherwise feeling like, you know, you're, 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, um, 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 of the then get trickled down to the engineers, it's more like your whole team gets an OKR or a business objective, and then you work together and to solve 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're not your boss. They're not someone external. 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 solved the problem or didn't. And they do a lot of glue work between business and design and 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. Yeah. Yeah. 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. That makes sense. So you're, 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, the, 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. Like, I think it's, uh, 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 I want. And I'm like, Oh, this is what I want. And they're like, Oh, 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. Hmm. Yeah, that makes sense. So, so you're not necessarily kind of getting out of your role. This happens to be what the senior engineer role is, is this kind of, you know, higher level of, you know, higher level of, you know, higher level of, you know, higher level of thinking and problem solving, not necessarily the decision-making side of things, but helping 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 are the kind of person who's also then going to take ownership. If the call was wrong, they're 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, we 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's a business case in that, in that need that is at odds in some ways with what you would consider to be, let's say clean engineering. That's kind of a, kind of a weird term, but we'll, we'll stick with that. Your best practices engineering is at odds with whatever this business need is. What is the role of the senior engineer to try to either fulfill or to improve the business? And I think that's a really important question. I think that's the evolution of 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 evolution evolution evolution evolution evolution evolution 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, but we also have users banging down our door and we can't, you know. Our biggest problem is that we have so much user demand that we can't keep up with the technology that we have. And they ended up hiring me as the first React person. And the dictum 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. And we ended up, so they just raised the Series A, which I don't know how big it was, but they used that to fund more time, more experts that could come in and work on a code base that wasn't that great because they've proved that, the business case is there. So they had essentially a prototype and now it was time to make it more serious. And over the next year, we rewrote the whole app in React from scratch. We hired an 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 dollars Series B. Wow. Yeah. So, that's my story of leveraging technical debt and it is okay and you should totally do it. Yeah. Yeah. It's, 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 having to work on that, on those problems. We'll get right back to our interview with Swizz right after we talk about today's sponsor. Developer Team is proudly supported by Cord. Cord 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. Cord enables what is currently not possible. A simple conversation with someone who wants to hire you. With Cord, engineers find work through these conversations rather than applications. The interactions and replies are meaningful, fast, direct, and relevant. And 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 Cord to hire, including recent Y Combinator alumni and publicly listed companies. And everything in between. Entire engineering teams are built on Cord 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 cord.co.tea That's C-O-R-D dot C-O slash T-E-A Thanks again to Cord for sponsoring today's episode of Developer Team. We'll see you next time. Thank you. 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, you're still in IC and you're very in the weeds. You don't necessarily have time for all of those one-on-ones. So I think it's a partnership in that the manager is kind of setting the tone and the senior engineer is, 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, Hey, we keep dealing with this stupid thing that's in our way all the time. How about we go 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. It's 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 than on exact implementations. Because, you know, if you spend an hour implementing something, some feature, that's an hour you spent implementing a feature. But if you spent an hour making everyone's day go five minutes faster and your team is 10 people, or this even 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, very quickly. And I think the other thing that you do as a senior engineer is kind of steer the team out of rabbit holes. And this is where I think the difference between the senior engineer title and the senior engineer as someone with actual real world experience and a lot of battle scars, 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, uh, 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. Yeah, exactly. Um, like one thing that I see a lot is, uh, it's hard to put into words, but basically if you get the right data model or the, 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, uh, like that six, that's by the sense to, to be able to do data modeling. Well, I think it's, uh, 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 team morale is to step into those design conversations and just help them define, 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, not 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've faced in software engineering. I want to kind of stick on it for just a second and talk about how these problems 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 name things. Well, 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. And it's, it's, 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 aren't just saying that it's a hard problem. It really is. It really is. 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 a name for it, you probably don't know what it is yet. Hmm. Yeah. Well, yeah, that's, that's a good point. If, if you know exactly what it is, um, I'll give you a practical example and we can use this as kind of a, a way to talk about this subject. Uh, I was talking with a, with a colleague one time about how having, uh, a vague names for, let's say columns in a database almost ensures that those columns are going to be used for more than one person. Yeah. So if you had a name like, uh, you know, that suggests a type, for example, but doesn't necessarily, uh, you know, 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 such a complex database, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, it's not a, Yeah, what's an example? I know 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 does 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 one of the things we build is appointment booking for 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? Ah, yeah. Hard to know unless you have some special context, right? Exactly. Because booked and scheduled are kind of synonyms. One of them means the actual timestamp when the appointment was created. And the other one is when it's actually happening. And I always get confused about which is which. 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 maybe a better or more specific name than scheduled time. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. necessarily better as a result of this. A 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 are another example of this. But first name is a really good example of this because what does that mean, right? What does a first name mean? Well, for most people, they say, well, it's whatever people call me, it's 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 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 a workday database or something like that? 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 booked time that's created that, not scheduled time. Oh, yeah. So even when you describe it, it still is confusing, right? Exactly. Thanks so much for listening to today's episode of Developer Tea. The first part of my interview was with Teller. You can find links to the things that Swizz is doing in the show notes. You can obviously find him on Twitter at Swizzek. That's S-W-I-Z-E-C. 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.co slash T-E-A. Thanks so much for listening to this episode. If you enjoyed this first part of the interview with Swizz, make sure you subscribe to this podcast and whatever app you're currently using. And if you want to discuss this episode or anything else, please leave a comment below. And if you have any questions or suggestions for the next episode, please feel free to ask them in the comments. And if you have any questions or suggestions 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 Tea Discord community. Head over to developertea.com slash discord. That is free. It always has been and it always will be. That's developertea.com slash discord. Thanks so much for listening. And until next time, enjoy your tea. Bye.