I want you to take a moment and think about the tools that you use when you develop software. Now the immediate reaction, even for me, is to think about my text editor. For example, I use Vim. And then to think about the different languages or perhaps the build processes that I'm using to support my development. And then I think about the browser because most of the time I'm developing for something that's visible in a web browser. So I have this set of primary tools that I imagine are the tools that I use to develop software. And the truth is, these tools get most of the attention. They get most of the headlines and they usually get most of our investment. Both in time and learning them as well as our actual monetary investments. But far too often, we leave it there. That's where we stop. That's where the list ends. And in today's episode, I'm going to talk to you a little bit more about tools that either you could be using or you already are using, but you're not putting the right intentionality into using them. My name is Jonathan Cottrell and you're listening to Developer Tea. My goal on the show is to help driven developers connect to their career purpose and do better work so they can have a positive influence on the people around them. And as it turns out, tooling is a big part of this discussion. In fact. A lot of our time and a lot of our energy and our mental space and even our anxieties and our frustrations and sometimes our moments of excitement, our moments of celebration and breakthrough, they happen centered around our tooling. Because for most people and for most developers, and not only developers, but in other areas too, tooling, tools specifically, act as a leverage point. They abstract something that previously took X amount of energy to do, and they allow you to use something like half of that. X over two amount of energy. They divide that energy and they use your energy more efficiently to accomplish the same goal. And you can think about tooling in the manual sense, and this helps us understand it. In our physics classes, in seventh grade physics class, I learned about simple machines, for example. How a simple machine can be used to leverage energy in more efficient ways. And these concepts are very powerful, and these types of tools can make a very big difference. We see languages, for example, develop these new tools that are brought into the core of the language that allow us to do things that previously took a lot more effort. JavaScript is a perfect example of this. JavaScript from ten years ago looks very different from JavaScript from today. And if you're writing JavaScript now, you know that a lot of the reason for that is because we've developed these abstractions. We've developed tools that allow us to do more with less energy. And so this concept is well proven, and it's well accepted, and it's well adopted. But tooling is not just about our primary tool set. It's not just about the thing that we're using directly. Now, my goal in today's episode is to talk about the concept of tooling. And I'm going to talk about that in a little bit. My goal in today's episode is to incite you to think more about your secondary tools, your supportive tools, the things that allow the work that you're doing with your primary tools to be better. Not just about lowering the amount of energy, but increasing the overall quality. Perhaps increasing the enjoyment factor that you have as a developer. Tooling that allows your processes to be more fault-tolerant. For example. So what are these tools? What are these secondary tools that we're talking about? Well, I want to give you an example of when a tool has failed me. And it's a difficult example because it doesn't really have a perfect answer. If you're a front-end developer, then you've probably started using a pre-processed version of a CSS language. For example, SAS or LESS or something like Stylus. And if you're using one of these, then you're probably going to have a problem. And you know that variables are now available. And even in CSS, we have new variables that you can use, that you can define a CSS variable. This is something that has been in the works for a long time. And more recently, it has been adopted by most major browsers. So the reality is we now have the ability to use CSS variables or pre-processor variables, which means that we can abstract some things away. From their kind of concrete definitions to more abstract definitions. And while this has brought a huge jump in productivity for most people, it also brings along with it some interesting questions and some problems that we have to solve as developers. I'll give you an example. When I define a color, let's say I wanted to define some kind of color that would hold the value of blue. And so I define the color with the name blue. And this is all fine and good until we decide to shift everything that is on the website that is blue. We decide to change that to green. Maybe the company rebranded or maybe we're reusing those styles in a different place. And unfortunately, everywhere that the name blue shows up, if I only change the value that that variable is holding, the name blue now stands in my mind for green. And so a lot of smart people saw that this was happening. And instead of using, like a blue, they started using names like primary color. And the interesting thing is that most websites have more than one color, don't they? And most websites have more than one key color. They have a blue and then maybe a lighter blue. And then maybe a contrasting color like an orange. And so we start creating variables for all of these colors. Maybe we have a secondary color. And then we have a primary color variant one. Or we have, we have some other kind of system for naming these things without being specific about the color itself. And so by the time that you've encoded all of your colors into your variables file, you have five or even 10 different colors with 10 different names. And then as you're writing your CSS, as you're actually using those variables, you're trying to remember just exactly which one of those was blue. And so this conundrum appears, very often, because as you are writing your code, you're having to go back and what originally was a tool that had the capacity to save you a bunch of time. Now, well, it's actually increasing the amount of time that you're using to develop the same thing. So how can we fix this problem? We've seen lots of blog posts on this discussion. We've seen a lot of people trying to figure out exactly how we should be naming our variables. And, we know as computer scientists or as developers or whatever you want to label yourself, that naming, as it turns out, is a whole lot harder than it seems at first. So how can we fix this problem? We're going to talk about that right after we talk about today's awesome sponsor, Bitrise. Bitrise provides you and your team with mobile continuous integration and delivery, and they do so in such a cool way. You can build your workflows, how things go from one step to the next. You can build them all, and this awesome graphic interface. They have over 170 integrations that you can bring in, and it's not just integrations with external services. They've done the work to do even simple integrations for you. So you don't have to write all that code yourself, and you don't have to create this, you know, massive internal testing process. And all of that is handled for you on Bitrise. And beyond that, you can share this kind of integration with other people, but you can also pull it down locally. And run it locally using the Bitrise YAML file. So to give you an idea of some of the services they support, you can actually go through the entire deployment process. You can deploy to iTunes connect, and you can deploy to things like test flight or to the Google app store. You can do all of these things, but you can also do much lower level things like sending a file to Dropbox or creating a zip file or running a make script. All of this stuff is supported directly by Bitrise. Go and check it out. By heading over to spec.fm slash Bitrise and get started today. Again, mobile continuous integration and delivery for your whole team delivered by Bitrise. Thank you again to Bitrise for sponsoring developer T. So how can we solve this problem? It seems kind of like a paradox, doesn't it? That if you name something blue, if you name a variable blue, then at least you know what it is when you're using it. But then what happens when you need to change all of the things that are referencing blue to, uh, re, in reality, a green color. And I have worked on code bases where blue actually meant green and that was kind of put into the documentation. It was something that, you know, the developers knew as long as they were working on the project. And in fact, I've seen variables like green set to the blue variable. So now you can use green or blue interchangeably and they both mean the same thing. And this obviously has a lot of bad implications because now the code becomes confusing and you need a, you know, a lot of exorbitant amount of documentation to be able to understand these things, especially if it's not just happening in one place. So what is it exactly that we can do to circumvent this problem? I think the most common issue that we run into when we try to solve problems like this is that we're trying to solve it with the same approach that we've always tried, which is what is the right name? How can we come up with the right name? How can we capture both of these things? At the same time? And this problem is in and of itself not solvable by that particular metric. You're not going to be able to both reference blue and not reference blue at the same time. A much better way of thinking about a solution to a problem like this is to think about your secondary tools. For example, and this isn't a cohesive way of solving this problem, but the way that we can do this is to think about the secondary tools. So, let's say, let's say, let's say, one way that you could solve this problem is by highlighting the color itself in your IDE. This is a supporting mechanism and there are tools that will do this. They'll go through and read your variables and see what they're set to. And if it is indeed a color, then whenever you write that variable, it will show up highlighted as that color. But what if you did something even more primitive, even more simple? What if you just had, well, you know, a notebook and in front of you, you have in your notebook, you have an easy way of scratching down which one of these things maps to blue and which one maps to red and orange and whatever other colors that you have. Of course, this isn't the best solution necessarily, but as it turns out, it is a pretty good solution because what you're doing is you're taking this thing that you're trying to hold in your brain or you're trying to hold in code and you're relieving the relationship between the two. And so, you're taking this thing that you're trying to hold in your brain, relieving the responsibilities of your brain and of the code base of holding that information with a secondary tool. Another example of this, if you stop thinking about things in terms of writing code as a document and instead you think of your code as kind of a living program, then maybe you can have just a few simple macros. So whenever your code editor sees the word blue, you can expand that to the correct variable name. And this is a secondary tool because it's supporting the process. It's supporting the process of writing, right? It's not something that you're writing directly in, but it's supporting that writing and it's actually changing what is being written. It's changing the outcome. But I don't want you to limit your perspective on what a secondary tool could be. For example, it's possible that a secondary tool for you is a light, just a simple lamp on your desk. This may help your energy level, or maybe another tool for you, another tool for you is a desk toy, something that keeps you interested and engaged and that you enjoy. Another tool might be music. And this sounds obvious to a lot of people. And in fact, it sounds obvious to me, even as I say it, of course, music will help me focus in some ways, or maybe music will distract me in some ways. Lighting can help me focus or the wrong kind of lighting can distract me. And these things seem obvious. But unfortunately, we so often don't think about problems. And so we tend to think about problems in terms of both the primary and the secondary options for solving them. And so our perspective on tools can shift. And in fact, sometimes a tool is actually an action. For example, if you're having a hard time solving a problem and you're looking to a tool to help you do it, maybe the best tool you can employ is a walk around the block. And as it turns out, a lot of research would support that decision. This is something that is very difficult for us to see because most often it's a second order effect. In other words, it's not going to directly solve our problem. These tools that we have are not directly managing something for us. We're not directly fixing the variable issue by having a notebook in front of us. Instead, our secondary tools very often are creating an environment. This is why I love this tool. This is why I like the term IDE because a text editor is only one part of the software development process. And so we need to be thinking about secondary tools in this way. How we are shaping the space that we are working in. Not just the physical space, but also the mental space. So I want you to ask you a few questions as we wrap up this episode. I want you to ask yourself a few questions about your tooling and specifically about your tools. About your tooling and specifically about your secondary tooling. Number one, what secondary tools do you rely on? This is something that maybe you need to take some time to write this down because it's not going to be top of mind for most people. What secondary tools are you relying on? The next question I want you to ask is, where are your primary tools failing you? Where are your primary tools failing you? Now the goal of both of these questions is to start pointing you at ways that you can improve your tools. And that's the way that you can supplement those primary tools with secondary tools. Perhaps you haven't even thought about having a secondary tool. Perhaps you haven't really thought about the option of writing things down as you're coding. Because what's out of sight is typically out of mind. So I want you to evaluate those two questions. Number one again is, what secondary tools am I currently relying on to help me as I develop software? And the second question is, how do my primary tools fail me? Now you may not be seeing these as failures, but ways of evaluating whether or not a tool is failing you is, think about the time that you spend performing an action. If you're having to spend a lot of time doing the same thing over and over, then that primary tool is failing you in some way most likely. And it's beyond the scope of this episode to determine all of the ways that a primary tool can fail you. But most likely, if you can just start with the things that either are taking a lot of your time, or causing a lot of frustration, causing a lot of rework, or maybe causing a lot of translation error between you and another developer, those are places where your primary tooling very likely is failing you. And the last question is very simple. What secondary tools can I adopt or improve? So new tools or old ones that need some improvement. What secondary tools can I invest in in some way to make me a happier, more productive, and more focused developer? This answer will take some time to develop, but it's one that you should ask yourself on a regular basis. Very often we are asking ourselves this question only about our primary tool set. We're asking ourselves, what language should I learn next? What IDE? What text editor should I use? These are things that we answer constantly. So often we forget the importance of our secondary tools. Thank you so much for listening to this episode. Thank you again to Bitrise for sponsoring today's episode. Go and check out Bitrise, particularly if you have mobile continuous integration on your list of things that you wish you had. By the way, this is a good example of a tool set that you can use. Lots of support for secondary tools in that list of 170 integrations. Go and check it out. spec.fm.com. Thank you so much for listening. If this episode and other episodes of Developer Tea have been valuable to you, then I want to ask for two minutes of your time. In the first 20 seconds or so, I want you to subscribe to this show so you don't miss out on future episodes. Because again, if you felt like other episodes were valuable, then hopefully subscribing will ensure that you get more value out of future episodes. The next minute of your time, I want you to spend going and leaving a review and rating for Developer Tea in iTunes. This will help other developers just like you find the show. And you have 40 seconds. I just want you to do whatever you want to with that 40 seconds. It really doesn't take very long at all to do those two things, and it helps the show out tremendously. Thank you so much for listening. Until next time, enjoy your tea.