Applying First Order Thinking to Work

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 Cottrell. You're listening to Developer T, and 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 uh is something that's always changing . It's a 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 . You know, at the time that we're recording this, it is April of 2026 . The last four months, we've seen probably more ch ange in our industry uh than than any four-month period and maybe the maybe as long as the last 20 years. Rapid, rapid change, especially in organizations that are uh especially in startup type organizations that can move quickly in adopting new tooling. Um and others will follow because um a gentic coding is uh uh is kind of taking the the or the uh industry by storm in a way . And so 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 uh 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 are uh that that turn out to be applicable regardless of your tool set. Right. And and so so as you are changing your tool set uh over the next uh you know probably the re the remainder of your career, but certainly if you're moving from uh you know uh uh 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 uh approaches like if you had kind of um done the the same thing that I had did before where I was prompting an LLM directly and then copy and pasting code out of that, right? Um , you know, and now there's we're taking new steps towards more mature versions of this kind of tooling. So our tool sets are changing, and and hopefully, if you're listening to this, you probably know that already. You probably know that already. So what is the what is the senior way? What is the the mature uh engineer's way of thinking about this? And and we have to go to principles because these specific tools are new. And so if we want to learn uh you know how how to walk through this process and how to think about it, we can't look at specific uh 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.. Right How how do we think using those principles with this situation? Okay . So that's that's the the angle that I want to kind of produce pr 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 uh let 's think of a very kind of uh physical example of this . Uh let's say a jackhammer. This is a really good example. We we first we build, we invent the jackhammer . We create this machine that can break through you know 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 gonna work wonderfully. And then we start using the jackhammer. So we've we've shaped the tool, but now when we start using the jackhammer , it's going to have an impact on our body , right? We're gonna end up sore, probably. If you've never used a jackhammer before, you know this is probably the case. Uh the first time you use it, you're going to end up with blisters, you're gonna end up sore. Um, 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 uh you know at this very physical level, if you think about the many software engineers who are listening to this right now that have uh you know potentially have symptoms of carpal tunnel, right? We we have very physical uh 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 very a very real experience for a lot of software engineers . Uh many of you cut your teeth on handwriting 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 uh you know some people have kind of signature ways of using and designing in these languages . And so regardless of how you know how the the business impact, the very kind of uh uh you know transactional 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 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 that is very human because we've connected a lot of our lives. We spent a lot of our lives with these languages. We spent a lot of our lives uh working with these tools and so we shaped these tools and now they are shaping us , the the language and the community and all of these memories that we have writing this stuff. Plenty of us have uh stickers on our laptops from these conferences that were shaped around the lane. I I was I've 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 end, uh, you know, SASConf, Ruby, uh, ancient city Ruby I went to uh on this show we talk about uh we had uh ancient city ruby uh interviews 10 years ago or so so the this 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 uh the direction And this can have unintended negative effects. We may even uh you know reject the premise of the new tools. Right? We we uh are emotionally attached, we are somehow you know connected to our tooling as humans become connected to things . And thus we you know we we reject even the notion that new tooling is going to s to improve on the old . And so you know that's kind of a danger spot, right? Because we start to see uh things through a a not very objective lens, and we start making decisions through a not very objective lens . And so my suggestion before we get into 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 uh you know there there are um 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 feeling of almost nostalgic loss, right? This this sense of grief. And so my suggestion is to honor that. To give it time, to give it the space, maybe even uh you know, find ways, uh, creative outlets uh you know to express around this , take the time to to process through it . Um I would say this kind of thing is a perfectly reasonable thing to talk about in in a therapy sess ion . It's not uh a small thing. You you've spent a significant portion of your time . Uh if you're if you've been an engineer for very long at all, spend a significant portion of your time working with these things. And so for it to suddenly be gone, uh is a very very real experience. So honor your grief, work through it in ways uh that you feel are uh is appropriate, right? Uh that that will help you kind of uh contextualize this as you know the the 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's ha has a different experience with this stuff right now. Different companies are adopting it in different ways. I'm not saying that , you know, 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 often or very likely are going to uh you know kind of 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 like very deep cultural touch points that we had before, you know, entire cult ures 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 as we shape our tools, they shape us. But before we dive into this principles, I want to talk about today's sponsor, SERP 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 uh uh 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. Uh 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 that 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 ap i uh i'm sorry if you're building with ai ser p 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 erpapi.com. Thanks again to SERP API for sponsoring today's episode of Developer T is. Sorry, wouldn't talk about these principles. The principles of shaping . It is very likely, is 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 a physical thing. You look can around you right now and there's very likely something that you can do uh at your desk today, right now, in the next two to three minutes. Uh you could maybe it's a a s a simple cable organization , um , you know, maybe making uh 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'm going to talk about today. Our tool set is the environment that we're living in. Uh you know, th there's there's kind of a 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 is your terminal an environment or is it a tool? Is your uh you know 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 you're uh, you know, if if your air is set too hot , right, uh, 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 . Right? If you have to crane your neck to see your monitor, if it's at the wrong height, or if you have to uh you know, if if your 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 you're losing uh some sense of flow, or you're gonna end up having to go to physical therapy because of the way that your body is moving. All right, so there's the physical environment , but there's of course the 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 that 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 kinda kind of scoff a little bit because is it really taking that long to write that command? That's not really the bottleneck, right? It's not the thing that actually takes the time uh out of my day. And I realized along the way that it isn't necessarily about the keystrokes saved. Sure, we're saving keystrokes. I it's not like I have, you know, a a a tank that gets depleted every keystroke that I um 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 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 uh 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 hass le, 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 atomic habits, one of the things that James Clear talks about is the very smallest bit, the very first kind of uh uh you know improvement that you can make, the smallest commitment you can make in ensuring that the friction to that small commitment is as low as possible. Right? So if you are 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 you're whatever shoes you exercise in. That's it. Or uh, you know, 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 your commitment. You can't, you know, you you uh you kind of negotiate with yourself in a way uh 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 s ets . 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. If you have a one or two letter ali as to run your test s run your test harness uh or key binding back when I was uh you know b developing more regularly and I had test-ridven development as was a part of my flow. Um I watched Ben Orenstein, who's been on the show before , and he talked a lot about this specific uh uh concept of shaping your environment, setting your tools up, getting things kind of working for you. Ben was the reason why I personally adopted Vim as a text editor and then after that, tmux, teammate, a few other tools like that. And with tmux, you can send uh 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 test s . It's very different than having to remember the full command or you know typing out the full uh you know um the spec file figuring out the 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. Okay . 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 And uh so or 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 ac tion, right? This is a very common category for software. And just it's easy to get started. It's easy to pull the ticket down or you know, to to to kind of get launched off, but actually finishing the delivery, finishing the details, uh uh finishing managing the Jira cards, whatever it is, uh that friction in the middle is what keeps you from following through as quickly or as 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 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 uh the outsized effect, right? The very um consistent behavior here of the most senior engineers that I know who kind of obsess over their workspace. They obsess over their uh you know their environment, their working environment. And so uh that is that's kind of the first 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 Myth 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. The basic idea is that anything that you do repeatedly should uh be accessible to you immediately, right? something else. Um so the idea you know in in a workshop might be that your most used tools should be on the top shelf of your toolbench or or your toolbox. So you can grab it without any additional work, 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 I I think the the first order retrievability is interesting. I want to take from this a principle of first order thinking . First order thinking . And it kind of uh 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 and kind of scaled effect, right? This is 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 ? So when something is within reach , we're more likely to use it. You've done studies on this, uh, for example, about a pantry, um, 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 furt,her 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 uh 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, uh, because you may hear this constant refrain, especially uh as this kind of stuff becomes easier and more accessible to build with agenti 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 uh you know more energized, more bought into the work they're doing, more supported, uh, 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 stand-ups better. Right? Make your uh specifications, your documentation, whatever the the basic thing is where you're you know figuring out the work, specifying the work. Invest in that . Invest in uh you know your your first order skills uh 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 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. Okay ? Hopefully something in here is triggering a thought that these fundamentals are still worth working on. We often just ignore them or uh assume that we've kind of arrived . Uh that that we're good on the fundamentals. That 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 uh that I document my work or that I uh you know manage tickets in Jira. As long as nobody's coming to me about that stuff, then I'm I'm good, right? I I'm 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 T. Thank you again to SERP API for sponsoring today's episode. Head over to SERPAPI.com that's s erpapi.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 uh subscribe in YouTube now. We're publishing YouTube videos. Usually YouTube videos are coming out a couple of days uh in advance of the uh the podcast episodes now. So we we finis thehed the YouTube processing a little bit faster. Um and we're still kind of figuring out the the publication rhythm for YouTube and 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 uh your subscription, your sharing, you going in telling somebody about this. That is an excellent help to help the longevity of the show. We're not going anywhere. Um but uh it it certainly helps us when the audience grows on these different channels so please share in whatever uh you know subscribe 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. And until next time, enjoy your tea