Many engineers have misunderstood the value they bring to the table and therefore have misunderstood so much about the transition that the industry is making into agentic coding and AI-driven workflows.
And in today's episode I want to help you understand more about your valuable skills, more about what this shift, this kind of seismic shift in the industry really means for you.
But most importantly, I want to give you framework for thinking about building skills, going into the future and perhaps understanding the skills that you already have, that maybe you've discounted or didn't realize somebody would write down on a list of skills.
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.
And when we talk about finding purpose in your career, a lot of what we're talking about there is finding value.
Things that you value doing, ways that you value spending your time.
We've talked about this Annie Dillard quote many times on the show before.
How you spend your days is, of course, how you spend your life.
That might be a little bit paraphrased, but the fundamental idea is that the things that you're doing right now, the momentary work that you're doing Minute to minute, hour to hour,
That becomes how you spend all of your time.
Of course, there's critical moments.
There are high intensity moments.
This last couple of months is going to stand out as high leverage for most people in this career.
It's going to change the trajectory of a lot of careers.
But ultimately, the things that you're doing over and over the way you're spending your time.
This is how you spend your career.
It's how you spend your life.
So finding something that you value is not some lofty goal.
It can be something as simple as enjoying the kinds of tasks that you are assigned, the kinds of work that you're doing with your team, the kind of domain you're working in, the actual technologies that you're working with.
All of these things are a part of finding your values.
It doesn't have to necessarily be platitudes or and philosophy all the time right, it can be as simple as minute to minute what you're doing with your hands, your mind, your body your, your brain, etc.
Right okay, with that said, so many of us, so many engineers, have misunderstood value as it relates to the rest of the industry and their role in a business context.
And, more specifically, we have kind of adapted or adopted the message of That what we do as engineers is code.
What we do as engineers is write code, build features, build software, sure.
But really, so much of it has hinged on our ability to write code.
And some of this is because it's an easy way to grasp and understand the job.
It is a unique skill that not everyone has, right?
There are a lot of nuances to it.
It is the thing that we believed that we learned in order to get into the industry.
It's the thing that we engaged in by reading books and blogs and going through video tutorials and building pet projects on the side to try to learn how to code.
Right?
There's products on the shelf in big box stores teaching kids how to code.
So it makes plenty of sense why we would believe that our fundamental skill, the thing that we bring to the table as software engineers a major flagship at least is writing code.
And you wouldn't be blamed for believing that.
In fact, most of you probably still believe that code is a critical part of your jobs, that it's a valuable thing that you can do.
But I want to make the argument to you that viewing an engineer's value as whether or not they can code is valuable, dangerously reductive, as we probably many of you have learned right if, if coding is the value that you bring to the table then uh, you know ai is threatening that value, right?
Um, if ai can code as good as you and for many tasks we've found that it can.
Not every task certainly, but for many tasks we found that AI can solve the actual coding problem, right?
The sliver that is implementation of some specification, right?
If that is the value that you bring, then you're in kind of a very narrow place.
And so I want to make the argument that we have confused the things that we value, the enjoyment that we get from the coding process, with the things that are valuable from a business sense, from a role perspective, even from a true engineering perspective.
We have overloaded this concept and we've underserved other concepts, right.
Okay, and so as a result of this, we...
Have a bunch of skills that we may be underutilizing or undervaluing.
In this sense, I mean undervaluing in terms of market value.
We're not tapping into the things that we could be tapping into and generating value from, because we've seen coding as kind of the king of the hill for so long.
Right?
So we're going to talk about.
We're going to talk about ways of thinking about the value chain of your skills.
And...
You know, another thing that kind of tricks us or tricked us early on is that we had this access.
If you said you could code, if people knew you could code, you have this new kind of gate opened up to you.
And it's a career changing opportunity, right?
And for many people, it started out as just that, that you were given a coding task to do.
And I've talked to plenty of people as a result of this podcast, who they were in a totally different field and they learned how to code in order to automate some of their tasks.
And so then they decided to jump in headfirst.
The truth is that coding is a small slice of what an engineer does, and good engineers, this will resonate.
You may not necessarily cognitively, you may not have arrived at this articulation before, but what I'm saying will resonate because if you think about the last uh, you know a project that you were involved on, our perception is that the code is the important thing and that, you know, building with code was the important thing, but most likely the things that made you valuable to the team were ancillary to that.
There were different skills.
We're going to talk about some of these skills right now.
For example, you may have a lot of domain knowledge.
You may be an expert subject matter expert in the field.
And so you know more about intuitively what the right kinds of things are.
You know more about the user base or you know more about the actual domain itself, right?
There's something that is kind of adjacent to coding.
That is a different skill, which is technical ability.
In this specific sense.
What I mean is the ability to understand very information-dense topics or highly complex flows or systems.
So technical doesn't always mean software-related.
It doesn't. necessarily mean technology, to be clear.
Technical in this sense just means it's very detailed dense information-rich, and it's not something necessarily that just anybody could pick up this information from learn about the key parts of it, understand how the system works, what are the interaction points, etc.
And then to build on that technical knowledge and to be able to leverage that technical knowledge to make good decisions is another skill set.
To be able to understand what parts of this system represent a risk factor.
Or what parts are likely to become a bottleneck, with a certain kind of throughput in that system, right?
So this kind of systems thinking comes into play.
On the totally opposite side of this would be something like the ability to understand systems.
The relationships of the teams or organizational design around a project and how to avoid blocking each other or how to organize work so that the throughput of that work is efficient right.
So maybe you're leaning more into kind of a managerial set of skills.
But even your manager may not necessarily know how to connect that to the work itself.
And so you, maybe you're a tech lead, right?
And you help the manager understand that, okay, well, actually we need to shift this around.
This team over here should own this service and this team over here has expertise.
They can own this for a while and then we'll cut over.
Right.
There's a lot of this kind of process, orientation and how who's going to.
You know what are the marching orders?
Who's going to be solving problem A versus problem B versus problem C?
Where are the integration points?
Should we slice it horizontally or vertically?
You know, how does this all fit together?
Both now and in the long run, what's the continuity plan if we lose the tech lead?
These are all things that, as you gain experience in your career, part of what you're doing is coding as a result of what you decide or what you build with these other skills.
And another example of this is purely relational, purely relational.
These are skills that help you uncover complexity, that help you push through really difficult periods in a company's tenure right.
And It may have very little to do with the code that you're writing, but it has everything to do with the value that you bring as an engineer.
You may be able to see and I could keep going for a very long time here about all of the other skills that kind of sit outside or around or supporting your ability to code.
So I want to give you a framework for thinking about skill development and thinking about your existing skills.
You've probably discounted a lot of the skills that you have.
And if you're like most engineers, The advent of AI as a primary tool in your toolkit is both new to you, but it can also feel a little bit threatening because if you do believe, like most engineers have for many years, that coding is one of your absolute critical value, generating skills,
And now there's something else that may be able to do that.
You may feel fear.
You may feel threatened.
Similarly we recently talked about this on the show you may feel a sense of grief over losing something that you did value, that you enjoyed coding by hand.
You didn't necessarily want to become a manager of a robot.
So I want to give you a framework for thinking about skill development during this AI boom and beyond.
We're going to do that right after we talk about today's sponsor.
Your coding agents have access to your code base and probably more at this point.
And maybe you've connected other tools via MCPs or you've built skills, but it's not easy to keep up with everything.
And access doesn't necessarily mean true context.
And your skills may be going out of date.
Agents can't reason across MCPs very easily.
They don't know your architectural decisions, your team's patterns or why the API was shaped the way it was in the first place.
So agents can tend to look in the wrong place and deliver bad outputs, whether it's because it's old, it's out of date or because it's totally wrong.
Then you spend time correcting the agent, trying to teach it how to do it right next time, and maybe it will, maybe it won't.
You're wasting your time and your tokens.
Unblocked is the context layer your agents are missing.
It synthesizes your PRs, your docs, your Slack messages, JIRA issues and more into organizational context that agents actually understand.
So they make better plans.
They write higher quality code.
They use fewer tokens, which saves you money, and require fewer correction loops, which makes it faster.
If you're running clogged code cursor or any agentic workflow and you probably are at this point unblocked is worth a look.
Get a free three week trial. at getunblocked.com.
That's G-E-T.
Unblockedcom slash developer T.
Getunblockedcom slash developer T.
Thanks again to Unblocked for sponsoring today's episode of Developer T.
So I want to give you this simple framework, a way of thinking about skill development and how you can think about your existing skills and kind of map them.
The most valuable skills, the most valuable skills are the ones that have Three things, all right?
Three things.
And when I say valuable, in this case, I mean valuable to you and your career, okay?
One is they represent clear business value, all right?
So they're valuable in the business sense, okay?
Maybe we should say that these are desirable skills or things that that would make them useful, good skills to have right.
Valuable in the business sense.
So they represent some kind of clear business need or they meet a clear business need.
They're durable.
We'll talk about that in just a second.
What does durable mean?
And then they're transferable.
And so you kind of know what business value means here.
Coding meets a business need, right?
Does that make sense, right?
We need something to exist to solve problem X. So coding in a roundabout way does do that.
But there's other business needs that coding absolutely doesn't solve.
That you are solving as an engineer.
Knowing what to build in the first place, for example, right?
Okay.
So meets a business need.
That one's pretty clear.
But what about these other two?
Durable and transferable.
Durable and transferable.
And these are kind of a spectrum, by the way.
You can have something that is... And it's not opposing ends of the spectrum either.
You can have something that is durable partially because it is transferable and vice versa.
But I want to differentiate these because I think they do have...
Something that is clearly differentiated between them.
Durable means that this is likely to persist, even if there are major changes in the industry.
Right.
That means, you know, state of the art in this case, agentic.
Workflows are replacing coding, which means that coding is probably not a very durable skill on its own.
So what is a durable skill?
A durable skill, certainly relationship building.
Soft skills, most of those are pretty durable.
Something that would not be considered durable is a specific relationship optimization, knowing a particular person very well.
That doesn't mean it's a bad thing, but it means that if you put all of your effort and attention into, let's say, impressing your manager, right.
It's a typical response to our jobs.
That person seems to have the most power over my career.
I'm going to pour a bunch of time into building a great relationship with them.
If you do that, then it's very possible that the durability there is very low, right?
If that person leaves for any reason or if you get moved to a different team.
It's not a very good uh, it's not a very durable uh way to spend your time.
That's arguable whether that would even be considered a skill.
But think about this as places to invest, right?
So you're going to invest your time in building.
Maybe you could call it a skill of knowing that particular person.
It's really hyper-specific.
What you'll recognize is with both durability and transferability that we're going to try to abstract away from really specific circumstances.
Another durable skill, right now especially, is understanding architecture.
Understanding, in particular, software architecture right.
In this case, what we mean by architecture is kind of how does this system work together?
And there's different levels and layers that you can understand this at.
But the interesting thing about that is, if you understand how architecture generally works in software, then you can abstract as far as you need to.
And the same principles apply.
Right.
So if you can understand kind of at a micro level, the architecture of this really specific routine or this particular part, then you can abstract and use very similar domain language or you can use the same kind of mental constructs to understand architecture at a higher level.
Durable skills are... tend to be the ones that take a long time to build.
They tend to be the ones that are used in multiple industries as well.
So this is the mental model.
Think about what change would have to occur to make this skill obsolete?
What change would have to occur?
For soft skills, for example, you'd have to stop working with people for that to not matter anymore.
And arguably, we're a long way off from that.
Okay. transferability, transferability.
So we kind of touched on it a little bit with the.
As I said, there's some crossover here between durability and transferability.
Being able to transfer between domain, for example, is, is important.
But I want to specifically talk about transferability as you grow in your influence and scale in in in your career.
So, Instead of just thinking about lateral transferability, in other words, does this skill apply if I work in a different industry or on a different team?
Think about transferability, as does the skill apply as I continue to grow in my career into more and more senior roles.
A great example of this going back to the durability skills. would be relationship building.
Relationship building becomes arguably even more important as you continue to grow up in your career, as you continue to grow more senior in your roles.
So soft skills become more and more important.
They're transferable, right?
So you can kind of see the shape of this.
Similarly, transferable skills, being able to deal with complexity.
Higher level roles, you continue to deal with complexity.
You just deal with higher leverage complexity, right?
But being able to analyze risk or analyze bottlenecks, understanding system level.
You know pros and cons of things.
Making better decisions.
All of this is in the realm of technical thinking, or thinking about high information density and high complexity.
Right,
So lots of conditional thinking, for example, that's going to be transferable, right?
A lot of times what lives in the transferable skills is a skill that you might see applied in a really narrow context, but the transferable part is whatever principles govern that same skill.
A good example of this is understanding compound interest.
We've talked about mental models a lot on this show and we're certainly not the first to tell you, I imagine, that mental models from all kinds of backgrounds and disciplines can apply in other disciplines right.
So compound interest is a great example.
If you have a 401k, if you are aware of any kind of investing portfolio and financing, then you know that interest rates create compound interest.
What this means is that, instead of putting money into you know, say like a paper envelope on your desk, which would just end up having the same amount of money that you put in at the end of that time,
You can put it into an interest-bearing account, and that interest will grow.
And the important part.
The insight is that the interest grows on top of the interest that's already grown as well.
So not only are you growing interest on whatever you put in that paper envelope, But now you're also growing interest on what you've earned in interest.
Right.
So that's the compounding part.
This is kind of a difficult and you can kind of even see the way that that I'm describing it is a difficult concept to to grasp.
Just you know, using using language, the first time you hear it.
But if you know what I'm talking about, you all certainly are trying to fast forward this section of the podcast, because this is something that is very clear to you.
As you, you know, build these models in your mind and you also probably could immediately recognize this if you've taken an algorithm course right.
That there's.
There's a transferability in compound interest, because if you know a big O notation, then you know that compound interest is specifically an exponential growth pattern.
And you know it would be big O of N?
Squared.
If you don't know what I'm talking about, you can go Google these things and the visuals will show up and you'll learn something new that you can apply.
And there's a lot of other things in your life where this particular skill of compound interest applies right.
It's not necessarily even a skill.
It's understanding what it is.
This idea is that you have transferable transferability in this knowledge and this applied knowledge.
Arguably this is a skill to be able to apply this thing that's in one domain to other domains, to be able to extract the principles out of that and understand how they apply in another domain.
Okay.
So, so this is, this is the framework.
It's very simple.
You want to optimize your skills that hit as many of these points as possible that maximize on value on business, value on durability and on transferability.
That's the important kind of triad to make these skills long-term.
They'll make you more successful in your career.
So my argument here is one that engineers for a long time have, I believe, incorrectly believed that coding is their primary value that they bring to the table, perhaps the only value they bring to the table.
And two.
So if that's the wrong belief, then there's another kind of accompanying wrong belief, which is there's a bunch of other skills that you have that are actually on this list, right?
That are valuable, that are durable, and that are transferable.
And so the homework I'm going to leave you with is go figure out what those skills are.
It's different for everybody.
Not every engineer brings the same skills to the table.
Go figure out which ones for you are valuable, durable, and transferable.
Thank you so much for listening to today's episode of Developer Tea.
Thank you again to Unblocked for sponsoring today's episode.
Head over to getunblocked.com slash developer T to get started today building your context.
It's a free three-week trial and you're going to have better context with Unblocked than you would if you tried to homespin a bunch of MCPs or figure out how they all map together.
Unblocked will do a much better job for you. looking at all of your sources.
Go check it out.
Getunblockedcom slash.
Developer T.
If you are enjoying this episode.
If you're enjoying the show, subscribe in all the places, right.
We've got a YouTube channel.
We have a podcast.
Of course, that's the longest running thing that we have.
These episodes are on iTunes.
They're on every podcasting platform.
If you're listening to our podcasting platform, Go ahead and subscribe in that platform so you don't miss out on future episodes, but also leave a review.
Leave a review.
ITunes is still the most important review platform for us, but leave a comment in YouTube.
Share this video.
Those are the ways.
This is how you make every show that you watch successful, so don't just do it for me.
Do it for all the shows that you watch. enjoy that are bringing you content for free.
This is certainly not the easiest thing in the world to pull together.
So you all taking the time to go and share and show your support is incredibly important.
So thank you so much for listening.
And until next time, enjoy your tea.
