Take a moment to think about the tools you use to do your development work? What text editor are you using? Which web browser are you defaulting to? In today's episode, we're talking about tools that you could be using or already are using and intentions we can put in place to make them better.
Take a moment to think about the tools you use to do your development work? What text editor are you using? Which web browser are you defaulting to?
In today's episode, we're talking about tools that you could be using or already are using and intentions we can put in place to make them better.
If you're looking for an automatic platform and configuration detection, to build, test & deploy in minutes check out Bitrise. They've got an open source library of 170+ integrations, and the best part there's no scripting needed! Run the same config locally with the open source CLI by downloading the bitrise.yml
If you're looking for a job, they're hiring tooling & dev-Ops engineers at their Budapest office
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
I want you to take a moment and think about the tools that you use when you develop software. The immediate reaction, even for me, is to think about my text editor, for example I use them, 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 than 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 Cutrell, 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 2 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, and our physics classes and seventh grade physics class are 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 10 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 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. The tooling is not just about our primary tool set. It's not just about the thing that we're using directly. My goal in today's episode is to insight 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. It's 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? I want to give you an example of when a tool has failed me. 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 CSS language. For example, SAS or less or something like stylus. If you're using one of these, then you know that variables are now available. 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. All right, so the reality is we now have the ability to use CSS variables or pre-processed variables, which means that we can abstract some things away from their concrete definitions to more abstract definitions. While this has brought a huge jump in productivity for most people, it also brings along with 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 finding 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 changed 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 names like 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 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 ten different colors with ten 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, as 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 in 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 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 TestFlight 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 makescript. All of this stuff is supported directly by BitRise. Go ahead and check it out. By heading over to specs.fm slash BitRise and get started today. Again, mobile, continuous integration and delivery for your whole team delivered by BitRise. Think you can get into BitRise for sponsoring Developer Tea. 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 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 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. This obviously has a lot of bad implications because now the code becomes confusing. And you need an 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 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. 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, like 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's 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 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 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 is a desk toy, something that keeps you interested and engaged, and that you enjoy, another tool might be music. And that 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 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 an notebook in front of us. Instead our secondary tools very often are creating an environment. 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 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 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? The next 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. It's beyond the scope of this episode to determine all of the ways that a primary tool can fail you. It's likely if you can just start with the things that either are taking a lot of 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 today's 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, select out of them, slash BitRise. Thank you so much for listening. If this episode and other episodes Developer Teahave 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 at future episodes. The next minute of your time, I want you to spend going and leaving a review and rating for Developer Tea and iTunes. This will help other developers just like you find the show. 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.