right now I want you to think about something that you do multiple times a day or even multiple times a week or something high stakes that you do multiple times a month or year something that you repeatedly return to that matters the outcome matters to you And I want you to think about specifically the friction that you experience in doing that thing. In today's episode, we're going to be talking about how a senior mindset changes as it relates to your tool set over the course of your career. My name is Jonathan Gautrel. You're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. And this idea of a tool set is something that's always changing. It's a living concept for the average creator, for the average software engineer. And most of you are probably experiencing the effects of those changes right now. At the time that we're recording this, it is April of 2026. The last four months, we've seen probably more change in our industry than any four-month period and maybe as long as the last 20 years. Rapid, rapid change, especially in startup-type organizations that can move quickly in adopting new tooling. And others will follow because agentic coding is kind of taking the industry by storm in a way. And so our tool sets are changing, maybe more than we ever remember them changing before. And so it makes sense for us to think about what is the senior mindset? What is the mature engineering mindset when it comes to tools, when it comes to your tool set and what you do with that tool set? And so that's what I want to talk about today. I want to talk about a couple of principles here that turn out to be applicable regardless of your tool set. And so as you are changing your tool set over the next, probably the remainder of your career, but certainly if you're moving from kind of the older style of non-agentic coding to agentic coding or if you like me if you've been adopting you know various parts and pieces of these tooling uh uh you know uh approaches like if you had kind of um done the the same thing that i did before where i was prompting an llm directly and then copy and pasting code out of that right um you know now there's we're taking new steps towards more mature versions of this kind of tooling. So our tool sets are changing. And hopefully, if you're listening to this, you probably know that already. You probably know that already. So what is the senior way? What is the mature engineer's way of thinking about this? And we have to go to principles because these specific tools are new. And so if we want to learn how to walk through this process and and how to think about it, we can't look at specific adoption. We can't look at specific patterns with these tools. We have to abstract and think about principles and then how those principles apply. How do we think using those principles with this situation? Okay, so that's the angle that I want to kind of present to you today. But first I want to talk about the relationship between you and your tools. There's a very interesting quote that often gets incorrectly attributed to Marshall McLuhan. the quote says that first we shape our tools. I'm going to paraphrase a little bit probably. First we shape our tools and then thereafter our tools shape us. Right? And let's think of a very kind of physical example of this. Let's say a jackhammer. This is a really good example. We first, we build, we invent the jackhammer. We create this machine that can break through the hardest of concrete, right? And it does so by a mechanism of essentially hammering over and over automatically for us. Okay, great. This is going to work wonderfully. And then we start using the jackhammer. So we've shaped the tool. tool. But now when we start using the jackhammer, it's going to have an impact on our body, right? We're going to end up sore probably. If you've never used a jackhammer before, you know this is probably the case. The first time you use it, you're going to end up with blisters. You're going to end up sore. You know, you may have that feeling that you're still on the jackhammer long after you get off. Okay. So our tools begin to shape us. And they do this both, you know, at this very physical level. If you think about the many software engineers who are listening to this right now that have, you know, potentially have symptoms of carpal tunnel, right? We have very physical relationship with our tools, but there's also a mental relationship that we have with our tools and an emotional relationship even, right? Many people right now are experiencing a unique sense of grief. a unique sense of grief. And I want to take a moment, and I hadn't planned to do this on this episode today, but I think it's appropriate when we're talking about our tools here to recognize that this grief is a very real experience for a lot of software engineers. Many of you cut your teeth on handwriting code. you have spent time uh you know hours days weeks months years learning the ins and outs of a language ruby python javascript java whatever you've spent time getting acquainted with the syntax and learning the tricks and learning the the culture surrounding the language, the community surrounding the language, learning how some people have kind of signature ways of using and designing in these languages. And so regardless of how the business impact, the very kind of transactional impact impact that all of the new agentic tooling has that would push so many of us to adopt it so quickly, right? We can quickly see the value to the shareholders, so to speak. We're losing something that is human in this process. Or at the very least, it's going to have an impact on us that is very human because we've connected a lot of our lives. We spend a lot of our lives with these languages. We spend a lot of our lives working with these tools. And so we shaped these tools, and now they are shaping us, the language, and the community, and all of these memories that we have writing this stuff. and plenty of us have uh stickers on our laptops from these you know conferences that were shaped around the lane i was i for many years a part of the ruby community and uh you know ruby had it has its own unique uh deeply seated community of people same thing with a lot of the front ends uh you know sasconf ruby uh ancient city ruby i went to on this show we We talk about, we had Ancient City Ruby interviews 10 years ago or so. So this is a culture and it's shifting. And so it may feel like you're losing something. And you may be losing something, right? This is a unique sense of grief. And I think that's important to recognize in order to understand how to deal with this. Because from an emotional standpoint, when we experience grief, sometimes we try to reject that. So what this will look like for a lot of people is rejecting the new tool, rejecting the direction that the industry is moving. And this can have unintended negative effects. We may even reject the premise of the new tools. We are emotionally attached. We are somehow connected to our tooling as humans become connected to things. And thus, we reject even the notion that new tooling is going to improve on the old. and so, you know, that's kind of a danger spot, right, because we start to see things through a not very objective lens, and we start making decisions through a not very objective lens, and so, my suggestion before we get into, you know, this kind of relating to your tool sets in a better way, and some of the principles that I want to share with you, my suggestion to you is that you honor the grief. Recognize that this is a very real experience that you're having, that there are plenty of memories and experiences and connection points and a lot of those things that you are very likely, if you're like me and like a lot of other engineers, you're experiencing a a feeling of almost nostalgic loss, right? This sense of grief. And so my suggestion is to honor that, to give it time, to give it the space, maybe even find ways, creative outlets, to express around this. Take the time to process through it. I would say this kind of thing is a perfectly reasonable thing to talk about in a therapy session. This isn't fake. It's not a small thing. You've spent a significant portion of your time. If you've been an engineer for very long at all, you've spent a significant portion of your time working with these things. And so for it to suddenly be gone is a very real experience. So honor your grief, work through it in ways that you feel is appropriate, right? That will help you kind of contextualize this as in the position that it needs to be for your professional life and to be able to move forward, right? To be able to move forward. And to be clear, I know that everybody has a different experience with this stuff right now. Now, different companies are adopting it in different ways. I'm not saying that unequivocally coding is dead. That's not the claim that I'm making in today's episode. Don't get me wrong here. But it is changing. It is changing. And it's changing in ways that very likely are going to reduce the amount of time we're spending in this stuff. It's going to reduce the likelihood that we're going to have these very deep cultural cultural touch points that we had before, you know, entire cultures around the language and that kind of stuff. Okay. So I want to talk about principles today. I want to talk about this idea that, you know, as we shape our tools, they shape us. But before we dive into those principles, I want to talk about today's sponsor, CERP API. 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, a price tracker, or anything else that needs to know what's happening on the web right now, SERP API is the web search API that handles that for you. You make an API call and you get back clean JSON. They deal with the proxies, the captchas, the parsing, all the scraping that you definitely don't want to be doing. You don't want to think about that stuff. They support dozens of search engines and platforms. They're fast and they've been doing this long enough. Companies like NVIDIA, Adobe, and Shopify, you probably have heard of those companies. Those people are relying 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're building with API, I'm sorry, if you're building with AI, SERP has an official MCP. 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 SERPAPI for sponsoring today's episode of T. So I want to talk about these principles. The principles of shaping. it is very likely, it's very likely that you have an opportunity to improve your tool set right now. Right now. And in fact, just to kind of make this a physical thing, you can look around you right now and there's very likely something that you can do at your desk today, right now, in the next two to three minutes. uh you could maybe it's a a simple cable organization um you know maybe making a charger a little bit more accessible um possibly cleaning your desk cleaning it off so you have less visual clutter maybe adjusting your monitor height okay these are very simple things these are things that you probably wouldn't have thought to do unless you listen to this episode right But the truth is that our tool set is an environment. And this is the first principle that I want to talk about today. Our tool set is the environment that we're living in. There's kind of a gradient, I guess, from environment to tool. And most of the time, we're somewhere in the middle. Is your desk an environment or is it a tool? Right, is your terminal an environment or is it a tool? Is your claw.md file, is that an environment or a tool? Most of these things are somewhere in between. And so if you think about your environment as kind of a first class citizen, right, in your tool set, then sharpening your tools means shaping your environment, and vice versa. Shaping your environment is essentially like sharpening your tools. So, this is the first principle. Think about your tools as an environment that you have control and influence over, and then shape that environment. Remember, we shape our tools, our tools shape us. If your, you know, if your air is set too hot, right, then you're going to be uncomfortable while you're working. And a little bit of your mental energy is going to be strained because you're not comfortable. If you have to crane your neck to see your monitor, if it's at the wrong height, or if your keyboard has a keycap that is faulty, then every single time you use that keycap, Every single time you crane your neck, that is shaping you back, right? You're losing some sense of flow or you're going to end up having to go to physical therapy because of the way that your body is moving, right? So there's the physical environment, but there's, of course, the software environment that you're working in. and the most senior engineers that I know, the most senior engineers that I know, this seems to be a constant with them. They obsess over the meta work. They obsess over the tooling. They obsess over finding ways to make their tool set work better for them. right this might mean they have aliases for common commands saving keystrokes is it really about the saving the keystrokes i just want to kind of dive into this for a second because you've probably seen that uh in an article somewhere save you know uh 77 of the keystrokes on this command and i used to look at that and kind of scoff a little bit because is it really taking taking that long to write that command, that's not really the bottleneck, right? It's not the thing that actually takes the time out of my day. And I realized along the way that it isn't necessarily about the keystrokes saved. Sure, we're saving keystrokes. It's not like I have, you know, a tank that gets depleted every keystroke that I, you know, that I hit. Of course, like you could think about it that way, but it's, that's not really the problem. The problem is friction. The problem is friction. And this is actually goes back to the environment shaping, right? Imagine if, uh, every time you walk from your, uh, let's say your desk to, to, if you're in an office, the office kitchen or the office bathroom, or if you walk from your desk outside to get fresh air. But every time you have to step over the top of some obstacles, right? And each time that you do it, you have to take your shoes off and put them back on. This is silly, right? Silly stuff that would be easily solvable. But it's friction. And so you're less likely to get up more often. You're less likely to go get the fresh air because it's kind of a hassle, right? It's a little bit of a hassle. It's not very hard, but it's hard enough that it's going to reduce the amount of time. And you'd be surprised at how little friction it takes to change your behavior. And reducing friction is one of the most important ways to encourage a particular behavior. You can read a lot more about that specific point in James Clear's book, Atomic Habits. All right. So in Atomic Habits, one of the things that James Clear talks about is the very smallest bit, the very first kind of improvement that you can make, the smallest commitment you you can make in ensuring that the friction to that small commitment is as low as possible. Right? So if you are, you know, making the commitment to go work out every day, well, actually what you want to do is make the commitment to putting your shoes on, putting your, your workout shoes on, right? Whatever, whatever your, whatever shoes you exercise in. That's it. Or, Or the next commitment you might make is to walk out the door. That's it. And as long as you walk out the door, you've met your commitment. You kind of negotiate with yourself in a way when you're trying to change your habits, right? And so his suggestion is to reduce the friction to making that step happen. So set your shoes out the night before so you don't have to go look for them. That reduces the friction a little bit. So this is environment shaping. It's exactly what we were talking about with our tool sets. If we shape our tools in a way that reduces friction for us to do the things that we want to do more often, then we will do those things more often. It's almost magic. It's not quite magic, but it feels like magic. For example, this is a very simple example. example, if you have a one or two letter alias to run your tests, run your test harness, or a key binding. Back when I was developing more regularly and I had test-driven development as it was a part of my flow, I watched Ben Orenstein, who's been on the show before, and he talked a lot about this specific concept of shaping your environment, setting your tools up, getting things kind of working for you. Ben was the reason why I personally adopted them as a text editor. And then after that, Tmux, Tmate, a few other tools like that. And with Tmux, you can send a key binding to trigger your tests in a secondary window. This is very important because it made test running as simple as pressing the space key S. It was almost literally muscle memory in order to run my tests. It's very different than having to remember the full command or typing out the full spec file, figuring out the line number. I was able to run exactly what I wanted to run in very few keystrokes. More importantly, very little friction. Very little friction. So I want you to think about some of the things that you do that you care about the outcome or that you want to do more often, that you want to increase the frequency of doing that thing. Right. And or similarly, things that you want to finish, but often the friction in the middle of the process keeps you from finishing. It keeps you from kind of following through to the end of that action. Right. This is a very common category for software. It's easy to get started. It's easy to pull the ticket down or, you know, to kind of get launched off. off, but actually finishing the delivery, finishing the details, finishing managing the JIRA cards, whatever it is, that friction in the middle is what keeps you from following through as quickly or as thoroughly as you prefer to, right? And so if you shape your tools to deal with the friction in the middle, then you're more likely to follow through. We have this kind of inverse relationship. with friction and action, which is not that surprising. I think the surprising thing is probably how little of a change you need to make in order to encourage that behavior, which is why these things like aliases are such a big deal and why you see the outsized effect, The very consistent behavior here of the most senior engineers that I know who kind of obsess over their workspace. They obsess over their environment, their working environment. And so that's kind of the first principle is to view your tools as your environment and your environment as part of your tools, as a spectrum. right the second principle uh that i want to bring to you comes kind of directly from uh adam savage adam savage uh of mythbusters fame he also runs tested now he has a youtube channel um and it's fascinating especially if you are in any kind of maker space if you're uh interested in that kind of thing but adam talks about this concept of first order retrievability And the basic idea is that anything that you do repeatedly should be accessible to you immediately, right? Without having to move something else. So the idea, you know, in a workshop might be that your most used tools should be on the top shelf of your tool bench or your toolbox. So you can grab it without any additional work, right? Right. The kind of worst version of this would be if you're always moving the location of that tool. You know, putting it in a bin and then putting the bin up, you know, out of reach or something like that. So you're the retrievability becomes harder. Right. And. I don't you know, I think the first order retrievability is interesting. I want to take from this a principle of first order thinking. thinking, first order thinking. And it kind of enhances the first principle. If you think this way, okay, what are the things that you're doing most often? And how can you think about improving those things, even the smallest amount? If you do something a hundred times, improving it by a very small, a hundred times a day, improving it by a very small margin can have a long lasting and kind of scaled effect, right? This is the point of building habits is that they have a scaled and outsized effect on our lives because we do it repeatedly. It's the thing that compounds over time. It's the thing that we become effectively, right? Right? So when something is within reach, we're more likely to use it. You've done studies on this, for example, about a pantry where you keep your food, right? If you put your healthier foods more within reach and you're less healthy, your processed snacks or whatever, out of reach, further away, you're more likely to eat healthier food. This seems like common sense, but we don't treat our tooling this way most often. Most often we're forgetting about the things that we do over and over and over. And this isn't just about automating. I want to be clear here because you may hear this constant refrain, especially as this kind of stuff becomes easier, more accessible to to build with the GenZik tooling. It's not just about automating. Some of these things, you actually want to do the opposite of automating. You want to spend more time with it, right? For example, as a manager, one of the first order things that I do every single week is one-on-ones. How can I make that better? Not faster, not just more efficient, but better. How can I improve whatever the process is for one-on-ones? What are the investments I can make so that my reports walk away from one-on-ones feeling more energized, more bought into the work they're doing, more supported, like they have more clarity, perspective, and purpose for their careers? What can I do to improve the thing that I'm doing regularly? The first order stuff. If you focus on those two principles, if you obsess over your tooling in your environment and your first order work, get that stuff right. These are the fundamentals, the fundamentals of your career, things that you're doing over and over and over. Make your standups better, right? Make your specifications, your documentation, whatever the basic thing is where you're, figuring out the work, specifying the work. Invest in that. Invest in your first order skills of prompting, for example. Whatever you do, whatever your workflow is, recognizing the things that you do over and over and the things that you do most often and then investing in the tooling, the environment around that thing. It may sound very simple, But hopefully if you're like me, then somebody telling you this helps trigger some thought in your mind that maybe you've been thinking about the fringes too much. Or possibly you hadn't really thought about the friction angle of this. Hopefully something in here is triggering a thought that these fundamentals are still worth working on. We often just ignore them or assume that we've kind of arrived, that we're good on the fundamentals. As long as nobody's giving me negative feedback on the way I'm running my one-on-ones or on the way that I show up to stand up or on the way that I document my work or that I manage tickets in JIRA, as long as nobody's coming to me about that stuff, then I'm good, right? I'm fine. But most likely, your biggest opportunities to improve the seniority of your mindset and ultimately the outcomes in your career are going to be in the fundamentals. The things that you do over and over. Thank you so much for listening to today's episode of Developer Tea. Thank you again to SERP API for sponsoring today's episode. Head over to SERPAPI.com. That's S-E-R-P-A-P-I dot com. regardless of what you're building. If it needs real-time web search, SERP API is the API for you. To get started with that, go and check it out, serpapi.com. If you enjoyed this episode, leave a review in iTunes or you can always subscribe in YouTube now. We're publishing YouTube videos. Usually YouTube videos are coming out a couple of days in advance of the podcast episodes now. So we finished the YouTube processing and we're still kind of figuring out the publication rhythm for YouTube and what the right kind of timing is to help that channel grow. One of the best ways to help any of these channels grow is through your subscription, your sharing, you going and telling somebody about this. That is an excellent help to help the longevity of the show. We're not going anywhere, but it certainly helps us when the audience grows on these different channels. So please share in whatever, you know, subscribe in whatever podcasting app you use, subscribe in YouTube and share in any of those places. That's the best way you can help the show. Thank you so much for listening. Until next time, enjoy your tea.