This career has always been exciting, engaging, especially for people who attach to the creative side of software engineering. I come from a background where I didn't have formal engineering training until much later in my journey as a software engineer. I started as a front-end engineer. If you've been listening to the show for a long time, you probably know this already about me, that I came from a music background, and I got interested in engineering through a side door. And many of you probably did the same thing. And this career, this industry, this practice, even as a hobby, has always been engaging for so many intellectual and creative reasons. And many of you are probably feeling a lot of the added energy, maybe some conflicting feelings about the current state of the industry, the current wave, and the change in our tooling, the change in our thinking, and how we think about coding from the ground up. And you're probably feeling it in your jobs. You're probably feeling it in discussions with other people, with other engineers. You probably are, if you're like me, a little frustrated at times with the amount. You probably feel an expedition of low-quality slop and bad products that are getting released. But on the flip side, if you're also like me, you're very excited by the possibility of the industry. And that's not necessarily a brand-new feeling. I felt that feeling when I first started out as a software engineer, when I didn't really even know that I was a software engineer. I was just putting code together to play with things in the browser. I hadn't really considered the possibility that this would become a job. It was just a lot of fun initially for me. And so there's a lot of excitement. And there's so much change that we probably, as engineers, as seasoned engineers especially, our mental models of what it means to work in this industry, to continue participating like we have in the past, our mental models probably have gone a little stale. What it means to be a good engineer. What it means to continue improving. So that's what I want to talk about today. I want to talk about, specifically, I want to talk about the major moments, I already see emerging, both in conversations that I have with my coworkers, as well as people beyond the company I work in, the industry at large, and in conversations that I'm seeing, you know, threads online and all of these places, this is playing out. This is a mindset shift. And it is, I think, it will become the kind of cornerstone mistake. Right? Cornerstone mistake for a lot of engineers, seasoned engineers especially. Seasoned engineers in particular, I think this could be the cornerstone mistake that you make. So if you're listening to this, if you're a senior engineer, if you're a staff engineer, you should really, really be paying attention to this because this is not going to be as naturally intuitive, per se, for all of you. Okay? And I want to really kind of hone in on, and focus in on, this idea of improvement. Because what we buy into early on, most of us, most people in this career, who last longer than a couple years, you bought into the idea that you could always be learning. In fact, one of the very first episodes of this show, like in the first 10 episodes, I think, we talked about learning as a lifetime thing. It's just kind of the way you approach the world. You're always looking, always paying attention and learning. And I want to talk about the juxtaposition that we're going to face. Increasingly, as a result of a much faster moving industry. We're going to talk about that right after we talk about today's sponsor. No matter what you're building, SERP API is the web search API for your needs. If you're building an application that needs real-time search data, whether that's an AI agent, an SEO tool, ice tracker, anything else that might need to know what's happening on the web right now. And SERP API is the web search API that handles it for you. It gives you much better control over what gets searched. You make an API call, you get back clean JSON. They deal with the proxies and the captchas, the scraping and the parsing. All those headaches that you probably have tried to deal with in the past. If you have done this for very long at all, and you know how much of a headache it can be, that's shifting sand out from under your feet. And I have to maintain all of that. That's not really the core of your business, but it is the core of SERP API's business. They support dozens of search engines and platforms. They're fast. They've been doing this long enough. Companies like NVIDIA, Adobe, Shopify rely on SERP API. There's a free tier to get started. So you can build and test your application before you commit to anything. And by the way, if you are building with AI, which let's face it, if you're listening to this show, you probably are at this point. SERP has an official MCP to make getting up and running a simple task. If your app needs to search the web in real time, check out SERPAPI.com. That's S-E-R-P-A-P-I.com. Thanks again to SERP API for sponsoring today's episode of Developer Tea. So the juxtaposition that we're talking about here is that we, for many years of our careers, we had to learn a lot, sure. And that was a part of our daily life. But the progression, if you imagine that we have kind of two surfaces that come into contact with each other, right? It's our understanding, right? Our knowledge, our set of skills, our conception of the tools that we use and what's available in the state of the art. All of that is how I approach the industry. And then the surface that I'm touching is the industry itself. The actual state of the art, what tools are actually available. And of course, we've always had to deal with the fact that the surface area that we could learn about is far drastically, far larger than we actually can. In other words, that our limitations exist. We've always had to deal with the fact that there's going to be something new to learn all the time. And so we have to place our bets. We have to come up with a strategy of learning that keeps us functional, right? In other words, there's some set of tools that you're going to invest time in, but you're not going to learn every single library. You're not going to learn every single language. The amount of time you would spend just changing would far exceed any time you spend actually practicing. All right? So this is the juxtaposition of the two things that we're going to draw, is that we have improvement by way of change and improvement by way of practice. Change is the fundamental adoption of something new, right? And so when we adapt, when we learn a new technique, when we learn about some new protocol or some new framework, when we learn about an architectural pattern that we've never used before, these are adaptations that we're making, okay? And then we practice is wielding all of those things that we've adopted. The adaptations that we've made, these are kind of choices that we're making. And then we take those choices and we put them, we kind of fold them into our repertoire, all of the many tools or all the many approaches, the models that we have to then go and practice, to then go and use, And for many seasoned engineers, the amount of time that you spend adapting as you get later in your career goes down. Now, it probably doesn't actually go down as much as it changes or it shifts away from more technical things and more towards softer skills. And the adaptations that you're making are more systematically about your role and how your role is changing. So early in your career, you may not have mentored many engineers. And then later on in your career, that becomes an important thing. And so you're going to adapt by adding that to your repertoire. The biggest mistake that I am already seeing engineers make is too quickly moving towards practice and not recognizing that the industry right now is calling for more adaptation. So what this actually looks like in practice is recognizing that the circumstances. The surface area is moving really, really fast. And it's moving so fast that unless you can intentionally engage with kind of systematic adaptation, what does this actually look like? It looks like taking time on a, let's say, a scheduled basis, for example. And this isn't a new concept, by the way. Systematic adaptation is fundamental to. Sprint retros. This is this is an old concept that your goal is to inspect and adapt. You're inspecting what you've done, finding out how you could improve something about what you've done and then adapting. Now, where people get lost, where the the really effective senior engineers that would have been promoted last year, where you're going to get lost, most likely, most likely. Is in recognizing that that adaptation. You may imagine that it's. Iterating on your practice right on this, you know, getting better at the thing that, you know, you already kind of know it, but you're just going to practice it. You're going to refine and sharpen those skills. And that's the thing that you are. You know that you bring it up in retro. It's a minor adaptation, right? But right now. And most likely for some time into the future. And really what those sprint. Retros were actually about. The intent of inspect and adapt is to think about the system. To step up one level. To. Think about the way. That you do something. And so this adaptation inspect and adapt is not focused on. Improving your bug rate, for example. Is. Not focused on. How can I get a little bit better at. Prompting. How can I get a little bit better. At writing a spec. That's not what adaptation is about. Adaptation. Is. Is about taking it a step back and saying. Am I thinking about prompting. In the wrong way entirely. Am I thinking about. How I can fit. This agentic. Uh, you know, maybe sub agents or an agent team. Am I, have I really thought about how those things are. Are working on the problem that I'm, that I'm producing. Or do I have the mix of human and agents? Do I have the ratio right here? Have I tried to rely on the agent for things that I shouldn't or vice versa? Maybe I'm not relying on the agent for enough of the right things. This kind of adaptation. Right. Is, is. than just doing this over and over until it becomes muscle memory. A lot of practice is about embedding things that you already know the best practice for, right? It's about kind of making, becoming smoother with those things. A lot of practice is about, you know, getting rid of errors that you know are errors rather than what we're talking about here is shifting more towards an adaptive mindset. Adaptation is about changing the way you think about something. And this might be changing your tool set entirely, right? This might be, you know, actually learning completely new techniques or completely new models of architecture models. It might be completely changing the way that your team works in terms of rhythms. Maybe you're used to, you know, refining every ticket and you're realizing that refinement is a big part of it. Is refinement is changing? Well, practice, if you were to just go with the old way of practicing, you would say, well, we need to figure out how to do refinement faster, or we need to figure out how to refine, you know, our tickets in a way that's a little bit better for agents to pick up. Adaptation is going to look at this problem and say, is refinement even the right thing anymore? We're going to take a step up and we're going to inspect. We're going to adapt the way we think about reality, right? Add it. Add a more, uh, kind of a more abstract level. Now you may notice that those are not necessarily different. They're both changes, right? They're, they're both like adjustments that you would make. And it's a reasonable argument to say that this is actually a spectrum, right? That, that practicing, you're going to make micro adjustments when you're practicing. You're going to think about your refinement process slightly differently. Maybe you're going to avoid, uh, you know, uh, subtasks or something, right? These are smile, minor, smaller changes, um, that you would make. And then on the flip side of this, an entirely different, uh, way of thinking, a totally new adaptation experimentation would be on the other end of the spectrum, right? Where you might even ask, well, should we even have engineers, uh, you know, planning the work? I don't know. That seems like a crazy leap, but that would be the level of, you know, the, the kind of spectrum that we're talking about. And my point here today is not to say. That practicing is gone. It's not to say that we can't refine the way we think, or that refinement is bad either. Okay. Um, because there's, there's going to be a wide variety of experiences as we continue seeing these tools change so rapidly. And that's actually the point. The point here is that the industry is changing and I've been saying it for many episodes now. Hopefully, you know, this, you can see it, you can feel it. If you don't yet. You will at some point, right? You're going to feel what I'm feeling in my corner of the industry. And it's extremely likely that you're already in the throes of this. And so what do we do about this? What does it mean for us as senior engineers? In my opinion, right now, right now, what it means is we need to think about the way that we used to think about adaptation. There's a lot of incredible opportunities. There's a lot of incredible, uh, entirely new kind of categories of thinking. And if we stick with our old categories of thinking and try to just practice our way through this, we are very likely to lose. We're very likely to fail, very likely to fail. But if instead we focus on adaptation, if we focus on inspecting the way we think and your own thinking, then you're going to be able to do a lot of things. changing at a more meta level, we're much more likely to arrive at something where we're improving with the industry. Thank you so much for listening to today's episode of Developer Tea. I know there's a lot of change happening. This show has shifted tone, and I know a lot of you have heard that as well. Hopefully, when you listen to the show, you're not getting AI hype. You're not getting anything that is saying that engineering jobs are all gone tomorrow, but you're also not going to hear from me that AI is useless and it's only going to produce bugs. What I really want to do here, my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. You know this. I don't want to put my head in the sand. I want to recognize where the industry is going and help you find clarity, perspective, and purpose through that process. That's the goal of this show. As the industry changes, that part doesn't change. That part doesn't change, but what we talk about has to change with the industry. Hopefully, we're talking about principles and how they apply to today's industry as it changes. Thank you so much for listening. Thank you again to today's sponsor, SERP API. You can get started for free at serpapi.com. That's serpapi.com. SERP API is your solution for industry. For a search engine API. It's that simple. Thank you so much for listening. Until next time, enjoy your tea.