Hey everyone and welcome to today's episode of Developer Team. My name is Jonathan Cottrell. My goal in the show is to help driven developers like you find clarity, perspective, and purpose in their careers. Today's episode is going to be short and sweet. I'm going to give you maybe the best career advice, hopefully the best career advice you'll hear this week at least, and possibly career advice that may change the trajectory of your career. I say that not because I have some secret that I'm coming down from the mountain from, but instead because I've seen this work over and over. I've seen the growth of my reports, I've seen the growth of other engineers when they take this into account. It's a very simple idea. There's no secret here. The simple idea is that as you grow in your career, as you become more senior, as you grow. Show more maturity and wisdom in your decision making. That will be directly reflected by your ability to synthesize multiple factors that you're optimizing for. Okay, so that's it. That's the whole piece of advice that I have for you. Synthesize multiple factors that you are optimizing for. Wow. How does this play out? In your next interview, if you're interviewing right now for a job, and you probably should be, even if you have a job now, unless you are totally happy with your job and you wouldn't change anything, there's a good reason for you to go and interview. All right? Even if it's just to learn, right? Try to talk with your manager about this so they understand that it's part of your ongoing practice to continue networking with people. It doesn't necessarily have to be a formal interview. It doesn't necessarily have to be a formal interview process. But especially if you're in some kind of design interview or theoretical kind of case study type interview where you're answering questions about how you would solve a particular problem, especially if it's something that's not just a simple coding problem. Hopefully, most of your interviews are not just straight leak code anymore. All right? So if you're in that kind of discussion where you're trying to solve some kind of problem, and regardless of if you're in an interview or if it's in an actual situation in your role, if you can bring to the table the many factors, many as in multiple, the multiple factors that need to be considered and calibrated against for the discussion. All right? So the opposite of this. What does the opposite of this look like? How does this look? When you are... Very early in your career. The younger engineers, and when I say younger in this situation, I mean experience-wise younger. Younger engineers tend to focus on one or two optimization factors that either they're very good at individually. All right? So it's kind of the hammer nail situation, right? If you're a hammer, everything looks like a nail, and therefore you're going to optimize for nails. All right? So some engineers may optimize for performance. Other engineers may optimize for maintainability. Some engineers may optimize just simply for a given architecture that they're very familiar with. All right? So that is kind of what it looks like when you're early in your career. Right? So you're going to optimize for one thing because it's the thing you're familiar with. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. where your value will show in your experience. So what do I mean by same unit? Well, if you think about how do you measure whether a given architecture is efficient and meets the necessary criteria? Well, if you're measuring for performance, you can probably find a single metric or one or two metrics that you can measure and say, yep, we hit a very high performance level. So that's a fairly simple task because the unit is pretty straightforward. Well, what if you're trying to optimize for a certain level of maintainability in addition to performance? What if you're optimizing for scalability in addition to maintainability? This synthesis is not necessarily about finding a common unit. At the same time, you may find that you may have But that is our default way of thinking. How do we know if we've succeeded? Is there something that I can measure to tell me? What level of certainty could I develop? What level of certainty could I measure? Could I externalize to ensure that I've met the goal? I've created some kind of binary situation where meeting the goal is easily measured. Now, synthesis requires that you weigh these factors separately about the same thing, about the same decision, about the same piece of code, about the same PR. And the hard part is determining. What the tradeoffs are that you're willing to make. Right, so being able to start with this synthesis by talking about these two things, holding them at the same time. And then being able to translate a decision that improves, for example, maintainability. But harms your your performance. A good example of this. A simple example might be choosing a framework that the engineers on your team are already familiar with. Right, so, you know, this this you might be optimizing for start time for time to market. Right, choosing something that people are familiar with versus performance. So you're optimizing for time to market, but you need a certain level of performance. Right. It may be that you need to optimize for a certain level of performance. Right. It may be that you need to optimize for a certain level of performance. Right. It may be that you need to make a hard decision to sacrifice one or the other. But being able to have this conversation is actually the mark of a of a more senior engineer. Right. It's not necessarily being able to, you know, look through a glass ball and come up with the answer. That's not really the trick to play here. The trick you want to pull. The kind of. The senior behavior is actually being able to identify what the tradeoffs are. Right. So for a given option, for a given direction, for a given decision, whatever those options are, you're able to identify the key factors that you're trading off between. Now, some of those factors may not even be important. Right. For example, you may not care that, you know, the framework that you chose doesn't run on some legacy architecture. It may have nothing to do. It may have nothing to do with the decision analysis that you are that you're putting on the table. But the key difference here is the synthesis part. It's not how good of an analyzer are you. That may be valuable on its own, but it's not the thing that distinguishes a senior from not a senior. The thing that distinguishes you as a more senior engineer is being able to identify the tradeoffs, the multiple types of tradeoffs. That have different base units. Right. So I'm talking about productivity. You know, is that engineering productivity? Is it the end user's productivity? Is it how often can we ship? Is it Dora metrics, for example? Are you measuring engineering productivity based on Dora metrics? And then something completely different like cost. Right. Cost of infrastructure. Being able to identify these two or three or four or five. You know, important factors and then weighing the options based on the factors that you care about. That is the mark of a senior. Most of the time, most of the time. You'll learn that. Tradeoffs are not always going to be, you know, a zero sum game. What does that mean? It means that very often a good senior engineer finds something that actually optimizes for multiple things they care about. Right. Maintainability and performance. And that's kind of the opportunity that you're looking for. But the key skill is the synthesis part. And being able to take these things in and combine them in your analysis rather than just going straight to a single factor. The single factor thinking is what very often will trip you up in interviews, for example. Right. Your interviewer actually cares more about, I don't know, maintainability. And you're optimizing for throughput. Your interviewer cares more about, you know, risk mitigation, for example. Dealing with errors or outages, reliability. And you're optimizing for maintainability. Or readability. Right. So you're, you know, choosing to make concessions or, you know, increase your investment in one area. Or spend a bunch of time talking. Talking about one area. And your interviewer actually cares about something else. Right. So you don't necessarily have to throw away maintainability. In fact, I'm telling you to do exactly the opposite. Start asking the questions about what are the many factors that we are trying to optimize for? What is the balance between these factors? Is any one of these factors more important than the others? Maybe we can get multiple of them. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right.! hallmark of every senior engineer I've ever worked with. It is one of many hallmarks, but that is a hallmark of every senior engineer that I've ever worked with. Any engineer that optimizes only for one thing or habitually goes back to only one thing that they're optimizing for, very often they miss the mark in a way that harms their solution, in a way that harms the team, it harms people's perception of them. They become known as, oh, the engineer who only cares about, right, fill in the blank, the engineer who only cares about performance, but they don't care about our developer experience, right? So being able to hold multiple things and optimize for multiple things, or at least doing the analysis to pick between these options, that is a skill that you should practice right away, like now. When you find yourself kind of default, and everybody does this, you're going to gravitate towards some way of optimizing that is default for you. It's your go-to. It's the thing that you know. It's the thing you're comfortable with. It's the thing that you care about. Whatever the reason, you almost certainly have one, maybe two or three factors that you're going to optimize for in any given circumstance. I challenge you to consider a factor that you're thinking about. Consider what is it that you're trading off? What do I give up? When I go with this option, what am I saying no to? Remember, decide specifically means cutting off other pathways. You're choosing to reduce your optionality when you make a decision, right? So what are you reducing? You're reducing the optionality of the decision. You're reducing what things are you saying no to? What optimization factors fail as a result of your decision? And if you wanted to go the other direction for those optimization factors, what might you choose? What direction would you choose? Is there something, this is the key insight, right? Is there a third option that actually optimizes or balances for both of those things? This is the key skill that every senior, engineer needs to develop. Thank you so much for listening to today's episode of Developer Tea. Hopefully this is insightful for you. And if you're watching on YouTube, if you're listening to the podcast, then please subscribe in whatever podcasting app you use or subscribe on YouTube. We are finally getting into the swing of editing these videos. It's a very simple editing process right now. So we don't have a lot of graphics or anything like that. We're really just focused on getting this content out. So thank you so much for listening, for watching, for watching, for watching. And until next time, enjoy your tea.