Hey, everyone, and welcome to today's episode of Developer Team.
My name is Jonathan Cottrell.
My goal on 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.
And 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 is that as you grow in your career, as you become more senior, as you 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.
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.
Hopefully most of your interviews are not just straight leak code anymore.
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 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, or 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 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.
Right.
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, or it's the thing that you think is most important in this circumstance.
And it's hard for folks who are new to optimizing for that particular thing.
It's hard for them to consider factors that don't have the same unit right.
This is where your value will show in your experience, right?
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 right.
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 of measurement, 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 thing.
And the hard part is determining what the trade-offs are that you're willing to make.
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 into, but harms your performance.
A good example of this simple example might be choosing a framework that the engineers on your team are already familiar with.
So you might be optimizing for start time, for time to market.
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 make a hard decision to sacrifice one or the other, but being able to have this conversation is actually the mark of a more senior engineer.
It's not necessarily being able to 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 senior behavior is actually being able to identify what the trade-offs are.
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.
For example, you may not care that the framework that you chose doesn't run on some legacy architecture.
It may have nothing to do with the decision analysis 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.
So we're talking about productivity, 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 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 trade-offs are not always going to be 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 maintainability and performance.
And that's kind of the opportunity that you're looking for.
But the key skill is the synthesis part.
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.
Your interviewer actually cares more about I don't know maintainability and you're optimizing for throughput.
Your interviewer cares more about risk mitigation for example, dealing with errors or outages, reliability and you're optimizing for maintainability or readability right.
So you're choosing to make concessions or increase your investment in one area, or spend a bunch of time 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.
If we can get these two factors over here, is that better than this one factor over here?
This kind of analysis or provoking this kind of thinking and being able to decode an option into its various factors.
That synthesis is the hallmark of every senior engineer 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.
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 not 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?
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, and 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.
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.
And until next time, enjoy your tea.
