Vox

Leitura de 15 min

This One Skill Signifies Seniority For Software Engineers

Summary

In this episode of Developer Tea, host Jonathan Cottrell presents what he considers potentially career-changing advice for software engineers. He argues that the key skill distinguishing senior engineers from junior ones is the ability to synthesize multiple optimization factors when making decisions, rather than focusing on just one or two familiar metrics.

Cottrell explains that early-career engineers often default to optimizing for what they know best—whether that’s performance, maintainability, or a specific architecture—creating a “hammer and nail” situation where they apply their preferred solution to every problem. This single-factor thinking becomes limiting as engineers advance, because real-world decisions require balancing competing priorities with different units of measurement.

The core of senior engineering work involves identifying trade-offs between factors like performance versus maintainability, time-to-market versus scalability, or engineering productivity versus infrastructure cost. Cottrell emphasizes that the skill isn’t about finding perfect solutions, but about being able to articulate what’s being sacrificed in each decision and exploring whether third options might balance multiple priorities.

He provides practical applications for this skill, particularly in technical interviews where candidates might focus on their preferred optimization factor while interviewers care about something else entirely. By asking questions about what multiple factors need optimization and their relative importance, engineers can demonstrate the synthesis capability that marks seniority.

Cottrell challenges listeners to immediately practice this skill by consciously considering factors they normally overlook in decisions, asking what options they’re saying “no” to with each choice, and looking for solutions that might optimize for multiple priorities simultaneously.

Topic Timeline

  • 00:00:00 — Introduction to the key skill for senior engineers — Jonathan Cottrell introduces the episode’s premise: that synthesizing multiple optimization factors is the hallmark of senior software engineers. He positions this as potentially career-changing advice based on his observations of engineers’ growth. The core idea is that career advancement correlates with the ability to consider and balance multiple competing priorities in decision-making.
  • 00:02:33 — Contrast between junior and senior engineering approaches — Cottrell contrasts early-career engineers who focus on one or two optimization factors (like performance or maintainability) with senior engineers who synthesize multiple factors. He explains that junior engineers often default to what they know best, creating “hammer and nail” situations where they apply familiar solutions regardless of context. The challenge arises when factors have different units of measurement that can’t be easily compared.
  • 00:05:10 — The synthesis challenge and trade-off identification — The discussion focuses on how synthesis requires weighing factors with different measurement units about the same decision. Cottrell gives examples like choosing a familiar framework for faster time-to-market versus a more performant alternative. He emphasizes that the senior behavior isn’t about having perfect answers, but about identifying what trade-offs exist between options and being able to have that conversation transparently.
  • 00:08:40 — Examples of diverse optimization factors — Cottrell provides concrete examples of different optimization factors engineers might need to balance: engineering productivity (measured by DORA metrics), end-user productivity, shipping frequency, infrastructure costs, and reliability. He explains that senior engineers can identify multiple important factors and weigh options accordingly, rather than defaulting to a single preferred metric in all situations.
  • 00:10:01 — Application in interviews and team perception — The discussion turns to how single-factor thinking can harm interview performance when candidates focus on their preferred optimization while interviewers care about something else. Cottrell also notes how engineers who habitually optimize for only one thing become stereotyped (“the engineer who only cares about performance”) and harm team dynamics. He recommends asking questions about what multiple factors need optimization in any given situation.
  • 00:12:17 — Practical exercise for developing synthesis skills — Cottrell challenges listeners to immediately practice synthesis by consciously considering factors they normally overlook. He suggests asking: “What am I saying no to with this decision? What optimization factors fail as a result?” and exploring whether third options might balance multiple priorities. He frames decision-making as reducing optionality and emphasizes that identifying trade-offs is the key skill every senior engineer needs.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2025-09-03T07:00:00Z
  • Duration: 00:14:28

References

Podcast Info

Transcript

[00:00:00] Hey, everyone, and welcome to today’s episode of Developer Team.

[00:00:09] My name is Jonathan Cottrell.

[00:00:10] My goal in the show is to help driven developers like you find clarity, perspective, and purpose

[00:00:14] in their careers.

[00:00:15] Today’s episode is going to be short and sweet.

[00:00:18] I’m going to give you maybe the best career advice, hopefully the best career advice you’ll

[00:00:23] hear this week at least, and possibly career advice that may change the trajectory of your

[00:00:29] career.

[00:00:30] I say that not because I have some secret that I’m coming down from the mountain from,

[00:00:36] but instead because I’ve seen this work over and over.

[00:00:40] I’ve seen the growth of my reports, I’ve seen the growth of other engineers when they take

[00:00:47] this into account.

[00:00:48] It’s a very simple idea.

[00:00:50] There’s no secret here.

[00:00:52] The simple idea is that as you grow in your career, as you become more senior, as you

[00:00:59] show more maturity and wisdom in your decision-making, that will be directly reflected by your

[00:01:09] ability to synthesize multiple factors that you’re optimizing for.

[00:01:20] That’s it.

[00:01:20] That’s the whole piece of advice that I have for you.

[00:01:25] Synthesize multiple factors that you are optimizing for.

[00:01:29] How does this play out?

[00:01:31] In your next interview, if you’re interviewing right now for a job, and you probably should

[00:01:36] be, even if you have a job now, unless you are totally happy with your job and you wouldn’t

[00:01:41] change anything, there’s a good reason for you to go and interview, even if it’s just

[00:01:47] to learn, try to talk with your manager about this so they understand that it’s part of

[00:01:54] your ongoing practice to continue networking with people.

[00:01:57] It doesn’t necessarily have to be a first.

[00:01:59] It can be a formal interview process.

[00:02:01] But especially if you are in some kind of design interview or theoretical, case study

[00:02:08] type interview, where you’re answering questions about how you would solve a particular problem,

[00:02:15] especially if it’s something that’s not just a simple coding problem, hopefully most of

[00:02:21] your interviews are not just straight leak code anymore.

[00:02:24] All right?

[00:02:25] So, if you’re in that kind of discussion, where you’re trying to solve some kind of

[00:02:27] 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.

[00:02:28] All right.

[00:02:28] to solve some kind of problem. And regardless of if you’re in an interview or if it’s in an

[00:02:33] actual situation in your role, if you can bring to the table the many factors, many as in multiple,

[00:02:47] the multiple factors that need to be considered and calibrated against for the discussion.

[00:02:54] All right. So the opposite of this, what does the opposite of this look like? How does this look

[00:02:58] when you are very early in your career? The younger engineers, and when I say younger in

[00:03:05] this situation, I mean experience-wise younger, younger engineers tend to focus on one or two

[00:03:14] optimization factors that either they’re very good at individually, right? So it’s

[00:03:20] kind of the hammer nail situation, right? If you’re a hammer, everything looks like a nail

[00:03:24] and therefore you’re going to optimize for nails.

[00:03:28] All right. So some engineers may optimize for performance. Other engineers may optimize for

[00:03:34] maintainability. Some engineers may optimize just simply for a given architecture that

[00:03:41] they’re very familiar with, right? All right. So that is kind of what it looks like

[00:03:47] when you’re early in your career, right? So you’re going to optimize for one thing

[00:03:53] because it’s the thing you’re familiar with.

[00:03:58] It’s the thing that you think is most important in this circumstance. And it’s hard for

[00:04:04] folks who are new to, you know, optimizing for that particular thing.

[00:04:09] It’s hard for them to consider factors that don’t have the same unit,

[00:04:14] right? This is where your value will show in your experience.

[00:04:20] So what do I mean by same unit? Well, if you think about how do you measure

[00:04:26] whether, uh,

[00:04:28] given architecture is efficient and meets the necessary criteria? Well, if you’re measuring

[00:04:36] for performance, you can probably find a single metric or one or two metrics that you can measure

[00:04:41] and say, yep, we hit a very high performance level, right? So that’s a fairly simple task

[00:04:49] because the unit is pretty straightforward. Well, what if you’re trying to optimize for

[00:04:56] a certain unit? Well, what if you’re trying to optimize for a certain unit? Well, what if you’re

[00:04:58] trying to optimize for a certain level of maintainability in addition to performance?

[00:05:03] What if you’re optimizing for scalability in addition to maintainability?

[00:05:10] This synthesis is not about finding necessarily about finding a common unit

[00:05:15] of measurement, but that is our, uh, our default way of thinking.

[00:05:22] How do we know if we’ve succeeded? Is there something that I can measure to tell me

[00:05:26] what level of certainty?

[00:05:28] What level of certainty could I develop? What level of certainty could I measure? Could I

[00:05:33] externalize to ensure that I’ve met the goal, right? I’ve created some kind of binary situation

[00:05:42] where meeting the goal, uh, is easily measured. Now, synthesis requires that you weigh these

[00:05:53] factors separately about the same thing, about the same decision. So if you’re trying to measure

[00:05:58] about the same piece of code, about the same PR, and the, the hard part is determining

[00:06:07] what the trade-offs are that you’re willing to make, right? So, uh, being able to start with

[00:06:16] this synthesis by talking about these two things, holding them at the same time, uh, and then being

[00:06:24] able to translate a decision that improves, for example,

[00:06:28] maintainability, but harms your, uh, your performance. A good example of this simple

[00:06:37] example might be choosing a framework that the engineers on your team are already familiar with.

[00:06:44] Right. So, uh, you know, this, this, you might be optimizing for start time for time to market,

[00:06:51] right? Uh, choosing something that people are familiar with versus performance.

[00:06:58] So you’re optimizing for time to market, but you need a certain level of performance,

[00:07:04] right? It may be that you need to make a hard decision to sacrifice one or the other,

[00:07:10] but being able to have this conversation is actually the mark of a, of a more senior engineer,

[00:07:19] right? It’s not necessarily being able to, you know, look through a glass ball and come up with

[00:07:27] the answer.

[00:07:29] That’s not really the trick to play here. The trick you want to pull

[00:07:34] the kind of the senior behavior is actually being able to identify what the trade-offs are,

[00:07:42] right? So for a given option, for a given direction, for a given decision,

[00:07:48] whatever those options are, you’re able to identify the key factors that you’re trading

[00:07:52] off between. Now, some of those factors may not even be important, right?

[00:07:58] For example, you may not care that the framework that you chose doesn’t run on some legacy architecture.

[00:08:06] It may have nothing to do with the decision analysis that you’re putting on the table.

[00:08:11] But the key difference here is the synthesis part.

[00:08:15] It’s not how good of an analyzer are you.

[00:08:20] That may be valuable on its own, but it’s not the thing that distinguishes a senior from not a senior.

[00:08:28] The thing that distinguishes you as a more senior engineer is being able to identify the trade-offs,

[00:08:34] the multiple types of trade-offs that have different base units.

[00:08:40] So I’m talking about productivity.

[00:08:43] Is that engineering productivity?

[00:08:46] Is it the end user’s productivity?

[00:08:49] Is it how often can we ship?

[00:08:51] Is it DORA metrics, for example?

[00:08:53] Are you measuring engineering productivity based on DORA metrics?

[00:08:56] And then something completely…

[00:08:58] Completely different like cost, right?

[00:09:01] Cost of infrastructure.

[00:09:03] Being able to identify these two or three or four or five, you know, important factors

[00:09:10] and then weighing the options based on the factors that you care about.

[00:09:14] That is the mark of a senior.

[00:09:16] Most of the time, most of the time, you’ll learn that trade-offs are not always going to be, you know, a zero-sum game.

[00:09:28] What does that mean?

[00:09:28] It means that very often a good senior engineer finds something that actually optimizes for multiple things they care about,

[00:09:37] maintainability and performance.

[00:09:39] And that’s kind of the opportunity that you’re looking for.

[00:09:42] But the key skill is the synthesis part.

[00:09:47] Being able to take these things in and combine them in your analysis rather than just going straight to a single factor.

[00:09:55] The single factor thinking is what…

[00:09:58] The single factor thinking is what…

[00:09:58] Very often will trip you up in interviews, for example, right?

[00:10:01] Your interviewer actually cares more about, I don’t know, maintainability and you’re optimizing for throughput.

[00:10:10] Your interviewer cares more about, you know, risk mitigation, for example.

[00:10:17] Dealing with errors or outages, reliability.

[00:10:21] And you’re optimizing for maintainability or readability, right?

[00:10:27] Right.

[00:10:27] 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 about one area.

[00:10:38] And your interviewer actually cares about something else.

[00:10:42] Right?

[00:10:43] So you don’t necessarily have to throw away maintainability.

[00:10:48] In fact, I’m telling you to do exactly the opposite.

[00:10:51] Start asking the questions about what are the many factors that we are trying to optimize?

[00:10:57] What are the…

[00:10:58] What is the balance between these factors?

[00:11:01] Is any one of these factors more important than the others?

[00:11:04] Maybe we can get multiple of them.

[00:11:06] If we can get these two factors over here, is that better than this one factor over here?

[00:11:11] Right?

[00:11:11] This kind of analysis or provoking this kind of thinking and being able to decode, you know, an option into its various factors.

[00:11:22] That synthesis is the hallmark of every senior engineer.

[00:11:27] I’ve ever worked with is one of many hallmarks, but that is a hallmark of every senior engineer that I’ve ever worked with.

[00:11:36] Any engineer that optimizes only for one thing or habitually goes back to only one thing that they’re optimizing for.

[00:11:43] Very often they miss the mark in a way that harms their solution in a way that harms the team.

[00:11:49] It harms, you know, the people’s perception of them.

[00:11:52] They become known as, oh, the engineer who only cares about…

[00:11:57] Right?

[00:11:58] Fill in the blank.

[00:11:59] The engineer who only cares about performance.

[00:12:01] But, you know, they don’t care about our developer experience.

[00:12:05] Right?

[00:12:06] 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.

[00:12:17] Like now.

[00:12:19] Right?

[00:12:19] When you find yourself kind of default, and everybody does this, you’re going to gravitate towards some way.

[00:12:27] Of optimizing that is default for you.

[00:12:31] It’s your go-to.

[00:12:32] It’s the thing that you know.

[00:12:33] It’s the thing you’re comfortable with.

[00:12:34] It’s the thing that you care about.

[00:12:36] Whatever the reason, you almost certainly have one, maybe two or three factors that you’re going to optimize for in any given circumstance.

[00:12:45] I challenge you to consider a factor that you’re not thinking about.

[00:12:51] Okay.

[00:12:51] Consider what is it that you’re trading off?

[00:12:54] What do I give up?

[00:12:56] When I go with this…

[00:12:57] This option, what am I saying no to?

[00:13:03] What…

[00:13:04] Remember, decide specifically means cutting off other pathways.

[00:13:11] You’re choosing to reduce your optionality when you make a decision.

[00:13:18] Right?

[00:13:18] So what are you reducing?

[00:13:19] What things are you saying no to?

[00:13:23] What optimization factors fail?

[00:13:26] As a result…

[00:13:27] As a result of your decision.

[00:13:28] And if you wanted to go the other direction for those optimization factors, what might you choose?

[00:13:34] What direction would you choose?

[00:13:36] Is there something…

[00:13:37] This is the key insight, right?

[00:13:39] Is there a third option that actually optimizes or balances for both of those things?

[00:13:46] This is the key skill that every senior engineer needs to develop.

[00:13:51] Thank you so much for listening to today’s episode of Developer Tea.

[00:13:54] Hopefully, this is insightful for you.

[00:13:55] And if you’re watching on YouTube, if you’re listening to the podcast,

[00:13:59] then please subscribe in whatever podcasting app you use or subscribe on YouTube.

[00:14:05] We are finally getting into the swing of editing these videos.

[00:14:10] It’s a very simple editing process right now.

[00:14:12] So we don’t have a lot of graphics or anything like that.

[00:14:15] We’re really just focused on getting this content out.

[00:14:17] So thank you so much for listening, for watching.

[00:14:20] And until next time, enjoy your tea.

[00:14:25] Bye-bye.

Visão de gráfico