« All Episodes

Breaking Out of Incremental Thinking

Published 6/18/2018

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.

Transcript (Generated by OpenAI Whisper)

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 Cottrell and you're listening to Developer Tea. My goal on the 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. 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. And so we can feel like changing that config file is part of the job. It's part of the work, right? We can feel like the same bug that keeps on popping up, that fixing that bug is just a part of being a developer. And while that is true, it's not. It's not. 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. Perhaps it is not a zero interest, a zero percent 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, Aside from the financial metaphors that we can use to describe this scenario, What often can happen is projects go underserved and then 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. All of this stuff that we've done a hundred times before. Now how can we escape this? Now 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. Reactor 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 Neverthink on their biggest product challenges. They've also partnered with Finnair 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 emphases. They're looking for people who are going to be able to help them with their product development. 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? Since we've already referenced the financial metaphor, discussing technical debt, let's talk for a moment about another type of financial. Investment. If you have a certain amount of money, let's say that you have $1,000, and you want to put that $1,000 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. The value... Value is returned to you since you fronted the cash, right? 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, right? 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're going to get a lot of 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 $1,000 towards your investment, and the person that you trusted your money with comes back to you with less than $1,000. This is a less than ideal scenario, of course. We're very averse to loss. And this reality exists. And this is a very important part of the problem. And this is a very important part of the problem. You see, if we consider the safe as our incremental progress, it's 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 have an 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. That it doesn't really take that long anyway, and I'm just going to do it. And that these minor adjustments, these minor things that we're talking about automating, that 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 just doing it on your own. So, 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 Tea falls in this category for the people who listen to the 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. 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 the 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. Head over to reactor.com. That's reactor with a K dot com slash 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 haven't. Reactor is a free app. You will miss out on future episodes. And if you get any kind of value out of the show, I encourage you to go ahead and subscribe. Thank you so much for listening. And until next time, enjoy your tea.