DE

Developer Tea

Jonathan Cutrell

Applying Durable and Transferable Skills

From Building Real Skills During the AI Boom - No, Not That Kind of SkillApr 22, 2026

Excerpt from Developer Tea

Building Real Skills During the AI Boom - No, Not That Kind of SkillApr 22, 2026 — starts at 0:00

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 a gentic 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 a 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 Guttrell. 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 moment ary 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 you know high intensity moments. This last couple of months is going to stand out as high leverage for most people in this career, right? 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 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 uh 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 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 uh uh you know 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 engag ed in by reading books and blogs and video tutorial you know, going through video tutorials and you know, 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 the, you know, 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 , uh, 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 dangerously reductive, as we probably many of you have learned, right? If 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've found that AI can solve the actual coding problem, right? The sliver that is implementation of some specification right if that is uh the value that you bring then you're in kind of a a very narrow place . And so I want to make the argument that we have conf used 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, from a 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 noting tapp into the things that we're uh 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 so we're gonna talk about uh we're gonna talk about ways of of thinking about the value chain of of your skills . And uh you know an another thing that kind of tricks us or or tricked us early on is that we had this this access if you said you could code, if people knew you could code , you have this this new kind of gate opened up to you, and it's a career changing o pportunity, right? And for many people, it started out as just that, that you were given a coding task to do. And um, you know, I've 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 sli ce 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 uh project that you were involved on . Our perception is that the code is the important thing. And that building with code was the important thing . But most likely, the things that made you valuable to the team uh were ancillary to that. They were different skills. So we're gonna talk about some of these skills right now . For example, you may have uh a lot of uh 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 -den se topics , right? Information-dense topics, or highly complex flows or systems . All right, so technical doesn't always mean software related. It doesn't necessarily mean uh you know uh technology to be clear. I uh technical in this sense just means it's very detailed, dense, information rich, and it's not something necessarily that um you know just anybody could pick up this information, learn about the key parts of it, understand, you know, how this, how the system works, what are the interaction points, et cetera . 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 scenario 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 you know opposite side of this would be something like uh the ability to understand um 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 uh uh is efficient. Right. So maybe you're leaning more into kind of a managerial uh 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 this uh 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 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 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 dec ide or what you uh build with these other skills . And no another example of this is is purely relational. Purely relational. These are skills that help you uncover complexity, that help you push through really difficult periods in a in a company's tenure, right ? And it may have very little to do with the code that you're writing , uh, but it has everything to do with the value that you bring as an engineer . You may be able to see, and you know, I could keep going for a very long time here about all of the other skills that kind of sit outside or around or support ing 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, you know, uh 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, right? That you that enjoyed coding by hand, right? They 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 gonna do that right after we talk about today's sponsor. Your coating agents have access to your code base and and probably more at this point. Maybe you've connected other tools via MCPs or you've built skills, but it's not easy to keep up with everything. And uh 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-Tunblock.com slash developer T. Getunblocked.com slash developer team. Thanks again to Unblocked for sponsoring today's episode of Developer Team So I want to give you this this simple framework , uh a way of thinking about skill development and how you can think about your existing skills and kind of map them . Um the most valuable skills the most valuable skills are the ones that have three things . All right, three things. And then when I say valuable, in this case, I mean valuable to you in your career. Okay . One is they represent clear business value. All right, so they're valuable in the business sense. Okay . Uh maybe we should say that these are these are desirable skills or things that that would make them uh useful, good skills to have, right ? Um valuable in the business sense. So so they they represent some kind of clear business need or they meet a clear business need . They're durable. We'll talk about that in uh 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 . Does that make sense, right? We need something to exist to solve problem X . So coding in a roundabout way does 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 uh meets a business need, that one's pretty clear, but what what about these other two? Dura ble 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. Okay, but I want to differentiate these because I think they do have uh you know 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 uh you know state of the art in this case, uh workflows are replacing c oding, which means that coding is probably not a very durable skill on its own. Right ? So what is a durable skill? Durable skill, uh certainly relationship building, right? Soft skills, most of those are are pretty durable . Uh 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? Is a typical response to our jobs. That person seems to have the most power over my career. I'm gonna pour a bunch of time into building a great relationship with them. Uh, if you do that, then it's very possible that the durability there is very low, right? That 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. Uh but think about this as places to invest, right? So you're gonna invest your time and build ing 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. Okay ? Another durable skill right now, especially, is understanding architecture. Understanding in particular software architecture, right ? In this case, what we what we mean by architecture is kind of how how does the 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 as far you need to and the same principles apply. Right? So if you can understand kind of at a at a micro level, you know, the architecture of this really specific routine or or you know this particular part , then you can abstract and use very similar uh you know domain language or you can use kind of same the same kind of mental constructs to understand architecture at a higher level, right? Durable skills tend to be the ones that take a long time to build , uh, they tend to be the ones that are used in multiple industries as well . Right? So this is the mental model. Think about what change would have to occur to make this skill uh obsolete. What change would have to occur? For for soft skills, for example, you'd have to stop working with people for that to not matter anym ore . And arguably, we're a long way off from that. Okay . So uh 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. Uh being able to transfer between domain, for example, is is important . Um but I want to specifically talk about transferability as you grow in your influence and scale 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 transferabil ity 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 uh soft skills become more and more important. They are transferable, right? So you can kind of see the shape of this . Uh similarly, transferable skills uh 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 uh uh, you know, uh pros and cons of things, making better decisions, all of this is in the realm of technical thinking or or thinking about high information density and high uh complexity , right? So lots of conditional thinking, for example, that's gonna 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. Uh, and you know, 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. Uh if you have a 401k, if you are 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, uh let' says like a paper envelope on your desk, uh, 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 the important part , uh the insight is that the interest grows on top of the interest that's already grown as well. So not only are you uh growing interest on whatever you put in that paper uh 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 it that I'm describing it is is a difficult concept to grasp, just uh you know, using using language um the first time you hear it. But if you know what I'm talking about, you'll certainly uh are trying to fast forward this section of the podcast because this is something that is very clear to you. As you uh 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 uh if you if you know uh lar a big O not ation, then you know that compound interest is uh specifically an exponential growth pattern, and uh 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 then 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 it's understanding what it is. This uh this idea is that you have transferable uh 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 the framework. It's very simple. You want to optimize for skills that hit as many of these points as possible, that maximize on value on, business value, on durability, and on transferability. Right? That's that's the uh that's the important kind of uh triad to make these skills long term help uh they'll make you more successful in your career . Right, so my argument here is one that engine ers 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 , uh if they 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 gonna 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 T. Thank you again to Unblocked for sponsoring today's episode. Head over to get unblocked.com/slash developer t to get started today. Uh building your context. It's uh three uh a free three-week trial uh and you're gonna have better context with unblocked than you would if you tried to home spin a bunch of MCPs or like figure out how they all map together. Unblocked will do a much better job for you uh looking at all of your sources. Go and check it out, get unblocked.com slash developer t if you are enjoying this episode if you're enjoying this show uh subscribe in all the places right we've got uh youtube channel we have uh podcast of course that's the longest running thing that we have uh 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 uh platform for us but leave a comment and in youtube share this video those are the ways you know this is this is how you uh uh make every show that you watch successful so don't just do it for me do it for all the shows that you 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 uh and show your support is incredibly important. So thank you so much for listening. And until next time, enjoy your tea

This excerpt was generated by Smart Features

Listen to Developer Tea in Podtastic

For listeners, not advertisers

All podcast names and trademarks are the property of their respective owners. Podcasts listed on Podtastic are publicly available shows distributed via RSS. Podtastic does not endorse nor is endorsed by any podcast or podcast creator listed in this directory.