Developer Tea

Breaking Out of Incremental Thinking

Episode Summary

In today's episode, we're talking about breaking the habit of incremental progress. How can we step away from solving the problems that are right in front of us and dig deeper into the core of a problem?

Episode Notes

In today's episode, we're talking about breaking the habit of incremental progress. How can we step away from solving the problems that are right in front of us and dig deeper into the core of a problem?

Thanks to today's Sponsor: Reaktor

They're looking for great software engineers for a number of product roles, with different emphases within the wide context of product development. Instead of predefining them as positions, they’d like to invite you to come to talk to them about your skills, experience, ambitions, and dream role.

Check them out and tell them about what work motivates you at https://www.reaktor.com/careers/

Get in touch

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

🧡 Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.

Episode Transcription

I want you to think about the last handful of bugs that you fixed in your projects. I want you to think about specifically how many of those bugs looked the same, or maybe a better way of putting it, how many of those bugs have you solved already? Perhaps it is a system that you use on a regular basis and it's a configuration that you always have to rewrite because the default configuration is incorrect for your use case. There's all kinds of examples of this. Perhaps it's not even just limited to bugs necessarily, but to any kind of process, any kind of use of energy. In today's episode, we're going to talk about ways that you can use your energy more efficiently. This is an extension of our previous episodes about productivity, but today's episode is less about getting more done with your time today and more about leveraging that time better. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on this show is to help driven developers connect to their career purpose and to help them do better work so they can have a positive influence on the people around them. We say this on every episode that my goal is to help you find your purpose, find your passion, and so many times we are buried under work. We're buried under what feels like progress. Now, imagine that for a moment that you can actually be buried by the feeling of work, by the feeling that you're actually doing something productive. You can end up in a place where all of your time is taken up, doing the thing that feels productive, and in fact, you're taking very small steps towards what you actually want, towards the things that you actually care about doing, towards the progress that you really are trying to make. We can feel like changing that config file is part of the job. It's part of the work. We can feel like the same bug that keeps on popping up, that fixing that bug is just a part of being a developer. That is true in some ways. You can't get around fixing bugs altogether. The part that is untrue is that we can't escape some of these repetitive features, some of these repetitive tasks that we continuously are having to go through. It seems as if the baseline is actually running away, and all of our work is just to get back to that baseline. Some of this happens as a result of bad engineering practice. Some of this can happen because you've accrued a lot of technical debt, and unfortunately, that debt is causing more debt. You have some kind of negative penalty that is attached to that debt. It is not a zero interest, a 0% interest kind of debt that you're actually accruing more debt into the future. Aside from the financial metaphors that we can use to describe this scenario, what often can happen is projects go underserved. All of the detailed work and all of the energy that is poured into a project and often is delegated to junior developers, for example, we end up swapping the time and the energy with all of this busy work, all of the stuff that we've done a hundred times before. How can we escape this? How can we avoid incremental progress? That's what we're talking about today. First we're going to discuss today's awesome sponsor reactor. There is a digital product studio in New York City. They're designing and building products and services for forward thinking businesses and organizations. Just a quick note. Reactor has a K in it instead of a C because reactor is based in Finland. There's no C in the Finnish language. Reactor has worked with people like HBO, Supercell, Viacom, and never think on their biggest product challenges. They've also partnered with Finair to design the perfect digital customer journey, complete with their mobile apps and next generation, in-flight entertainment systems. These are all these forward thinking products that reactor has worked on and they're looking for developers. They're looking for software engineers for a number of product roles with different infacies within the wide context of product development. Now instead of pre-defining these positions, like you see on a lot of job descriptions, they have very specific technology, very specific responsibilities. Instead of that, reactor has decided to let you talk to them about your dream role, your skills, your experience, and your ambitions. Head over to reactor.com slash careers to get started today and let them know that you heard about this on Developer Tea. Thank you so much to reactor for sponsoring today's episode of Developer Tea. So we're talking about how we can avoid incremental progress. How can we break out of this constant need to only solve the problem that is most salient, the thing that's right in front of us, the easiest problem to solve? Now since we've already referenced the financial metaphor, discussing technical debt, let's talk for a moment about another type of financial metaphor, investment. If you have a certain amount of money, let's say that you have a thousand dollars and you want to put that thousand dollars towards something that's eventually going to generate wealth for you. You have two options, two fundamental options. One is some kind of investment where that money is taken and it is used in some way and then hopefully value is added to that money and the value is returned to you since you fronted the cash. This is the common model for investment. You can either put your money on the line or you can put it kind of in a safe. You can take that cash, put it in a safe, nobody can touch it, it doesn't go anywhere. And if you continuously put money in a safe, eventually you will have exactly the amount that you put in the safe. But if you invest money, it's very possible that you will have significantly more. Now the downside and the reason that people even consider putting money in the safe in the first place is that very often investments fail. Investments end up losing money and so you put a thousand dollars towards your investment and the person that you trusted your money with comes back to you with less than a thousand dollars. This is a less than ideal scenario of course. We're very averse to loss. In this reality exists with the way we spend our time as well. You see if we consider the safe as our incremental progress is quite literally that. We incrementally add money. But if instead we are investing, what is the equivalent when it comes to how we spend our time as developers? And here's the takeaway for today's episode. Instead of spending your time building incremental value, solving incremental problems, I want you to think about building machines. What are some examples of machines? One example of a machine is your habits. Your habits are repeated every day. So when you create a single habit, when you effectively establish a single habit, the return on that habit is much more than a single incremental iteration of that habit. For example, if you establish a healthy regimen of going to the gym on a daily basis, the return on that investment is not that you went to the gym once. It's not that you went to the gym over the course of a week. It's that you haven't established rhythm and going to the gym is now a regular and continuously valuable resource for you. Other examples of machines specifically related to developers are automated processes. This is such a simple idea, but automated processes. If you have a configuration file that you are always changing at the beginning of a project, go ahead and create some kind of automated system that makes that configuration process automatic. And here's why people very often choose not to do this. Taking the time to build the automated process is significantly longer than it would take to just change the configuration. And so when it comes down to it, it seems a whole lot easier, a whole lot more efficient to just change that configuration. And this is the most common refrain that we hear from developers who stay in the incremental mindset. And it doesn't really take that long anyway, and I'm just going to do it in that these minor adjustments, these minor things that we're talking about automating, it's just not worth it. But here's the reality. We aren't just talking about saving a few seconds here and there. We're talking about cascading that and creating a mindset of higher leverage where you're constantly thinking about ways to invest your time, invest your energy into machines rather than incremental thinking. All of your energy going into maintainable investments where you have a little bit of cost, you have a little bit of risk, but ultimately the upside is significantly worth it. That's the way that I want you to think. If you're listening to the show, if you are a driven developer, I want you to start thinking rather than in terms of incremental value, I want you to think in terms of machines, of generators, of things that provide value that continues over time. I like to think that Developer Teafalls in this category for the people who listen to this show because every episode of Developer Tea is available, it's free, and we continuously add to this catalog. We try to keep as much of this content as evergreen as possible. And so what this means is that people are constantly finding this content. They're constantly getting new value out of it. This is a generator of value rather than just being a one time value where everybody can listen to the episode and then it goes away, new people can come to the show at any time and the same value that the regular listeners who have gotten out of that past episodes, those new people can get at any point in the future. I hope that you are excited by the idea of machine thinking. I hope it clarifies to you ways where you may be wasting your time and ways that you could be investing your time instead. Thank you so much for listening to today's episode of Developer Tea. Thank you again to today's awesome sponsor, Reactor. It's Reactor with a K. Reactor is hiring software engineers across the spectrum. It's Reactor with a K. Slave careers to get started today. Thank you so much for listening. If you haven't subscribed in whatever podcasting app you use, then it's very possible that you will miss out on future episodes. If you get any kind of value out of the show, encourage you to go ahead and subscribe. Thank you so much for listening and until next time, enjoy your tea.