My name is Jonathan Cutrell. We're talking about reducing cognitive load in your work. You're listening to Developer Tea. We've been talking about reducing cognitive load for a handful of episodes now. And I want to share a few more strategies for reducing your cognitive load. And in today's episode, we're actually demonstrating one of those. That is to leverage work that you've done before. In this case, we're leveraging the exercise that you did in the last episode of identifying your primary activities. And then the modes within those activities. We're going to leverage that work. So that's actually kind of our first strategy that I want to talk about today. Which is leveraging work that you've done before. If you have not done this on a regular basis, or if you don't have a habit of doing this, it's likely that you haven't been able to make the connections between your current work and your previous work. And this is also critically important to understand that this isn't just your previous work that you can leverage. Hopefully, most software engineers can identify with the vast amount of kind of preceding knowledge and work that came before us in this industry that we're leveraging every single day, whether it's open source software, architectures, or even tools that you might be building on top of. So this is kind of a bonus one. Leverage the work that came before so that you don't have to reload all of that context. For example, in today's episode, I could have gone back through that same exercise. And if it was just slightly different, we would have breathed down about 95% of the work that we have already done in a past episode. But I'm going to give you a heuristic today that will lower your cognitive load. And hopefully this heuristic will make immediate sense to you if you go back and look at your primary activities. And even if you go and look at your different modes, I want you to choose. Choose three tools, just three that you use in the majority, when I say majority, I mean 80 to 85% of your work and primary activities choose three tools. And here's the thing, I do want you to treat this as strict for the sake of this exercise. But if you need to expand that to four or five, do what makes sense to you. The key here is to eliminate the endless treadmill of multiple tools that do similar jobs. And multiple to multiple multiple things that do similar jobs. So for example, if you take company notes, do that in one note taking location. And it just so happens that a note taking location may also be a coding location. If you choose this as one of your tools, most of the time tools fit into essentially four categories. Now this is a very broad generalization and we'll get into the nuances and semantics after this. But your primary tool said your tools are likely to fit into one of four categories. One is external information processing tools that fit into this category might be email or slack. Now you might think that these are communication tools, but that is external information processing. There are other tools that are not communication tools that still fit in this category. The idea here is that the information is somehow shared or it could be shared. The second type of tool is internal information processing. This would be something like a journal or a note taking application. The third tool is the one that people get most excited about that is some kind of creation tool. This could be a code IDE. It could be Photoshop or sketch or Figma or it could be a flow chart application. It could be anything that you use to produce artifacts that are a core part of your output. It just so happens by the way that these tools can often overlap with each other. This certainly happens for managers, managers, output, maybe communication that originated in an internal processing tool and it got moved into an external processing tool. The creation tool for the manager is also the internal processing tool sometimes. The fourth kind of tool is typically a scheduling tool. This takes information that you've processed elsewhere and the outcome of that information might be some kind of planning. There are two kind of subtypes of scheduling tools. One is a direct scheduling tool and the other is an abstract scheduling tool. A direct scheduling tool is something like a calendar. You're saying that you have an appointment at a specific time on a specific day. An abstract scheduling tool is something like a to-do list. You are scheduling something to be done but exactly when it gets done is unclear. Most often people tie these concepts together for some of their work and leave them separated for other parts of their work. The challenge here to reduce cognitive load is to limit your tool set and limit it drastically so that you have three primary tools that do those major jobs. Whatever those major activities are for you and we're not going to prescribe those in today's episode. An opalite is clear why this has the possibility of lowering your cognitive load. This is especially true if other people on your team can align with a similar tool set. For example, if you have your company documentation across two tools rather than one, that more than doubles the effort necessary in order to find that documentation. This is almost entirely attributable to the increased cognitive load. Where is that particular piece of documentation? Where did we track that particular process or method? Well, it's in one or the other of these tools. The fact that we spent the time to ask this question and then we went and looked for the thing in both tools is and you probably already know this entirely wasteful. The same is true at the micro level. If you have two tools for taking notes every time that you have a queue, which we talked about in the last episode, that it's time to take notes. Now you have a little bit of cognitive load to decide which tool, which note taking tool is most appropriate for this particular scenario. You can hear the engineering minds turning as they're listening to this episode in the future and you're asking how in the world can I limit my tool set to three things? That is not what I am intending for you to do. Very clearly, we have a huge tool set that we have to pull from as engineers. Instead, this exercise is about training your brain to think in terms of having a singular solution to a singular problem. And when you see these different modes, knowing what tools tend to be tied to that mode. There are some ways to automate this even if you have a particular series of primary activities and a couple of modes, you may be able to write a script that opens up the proper tool, the singular tool, so that you don't have any of that decision making to do. The underlying message here is that we shouldn't be evaluating our tools every time we use them. Instead, we should use our tools and evaluate them in different cycles. Trying to do both at once means that we aren't really able to take full advantage of the most important tool that we have, which is our own brains. Our focus is split. Our attention is driven in two different directions. And when your attention is divided, that is essentially the definition of cognitive load. Thanks so much for listening to today's episode of Developer Tea, this discussion on tools. I hope that it encourages you to start thinking about your tools as something to be chosen and something to be worked with in discrete events. You're not trying to choose the tool that you're going to work with while you're working with it, but instead you choose the tool and then go and work with it. Thanks so much for listening to this episode. I hope you enjoyed this discussion. And if you did, it encourages you to join the Developer Tea Discord. Head over to developertea.com slash discord. You can join totally free today. And there's always great conversation happening here. Thanks again for listening and until next time, enjoy your tea.