Getting work done one moment at a time. That is a theme of productivity on this show. It's not a simple hack that you can employ instead. It is a way of thinking. And in today's episode, I want to talk you through some of the mechanisms of how I personally deal with the things that I need to do on a day-to-day basis. How do I stay productive? My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose and their careers in today's episode. Mostly, we're going to be talking about clarity. And as we gain clarity, this is one of the most important kind of interactions that we can talk about on this show. The interaction between clarity and perspective provides us a unique vantage point, whereas clarity gives us a full vision from that vantage point. As we begin to gain clarity, we may want naturally to adopt a new perspective. So this interaction between clarity and perspective, as you gain clarity, you might choose a different perspective. You might seek a new perspective, or if you suddenly have encountered a new perspective that may provide clarity to your current one. So this interaction between clarity and perspective is critical to our day-to-day productivity, because a lot of the process of, and I use that word very carefully, because we can get wrapped up in process. But a lot of the process of productivity, the management of your tasks, the dragging of cards in Asana or in Jira or whatever tool you're using, the checking off on your to-do list, a lot of this kind of administrative that you probably engage in, is about increasing clarity. So what is this clarity that I'm talking about specifically? Well, the clarity of how things interact with each other, for example, how does this task relate to the other one? How does this work relate in terms of priority to the rest of the work? What exactly needs to be done, and can I do it, or should someone else do it? Should we do it at all? All of this kind of clarity is what we're seeking in that administrative, in the process part of our work. And interestingly, as we move through our work, we begin to validate and hopefully adjust our processes, because we can find what kinds of clarity we are getting, or most importantly, the kinds of clarity we aren't getting that we need. Now what do we very clear about something? I am not going to push you towards any specific kind of process. Some processes work better for certain scenarios than others. This is a long, blabbered discussion on teams of all sizes and types over the years. Certainly, there are some principles that I would recommend that you pay attention to and you can bring into whatever process you do choose. But I'm not going to push you towards any particular process. Instead, I'm going to talk about some of the things that I do. of the more atomic and practical parts of the way that I kind of mechanically deal with my tasks in today's episode. And hopefully this will help you as you go through the management of your things to do, it'll help you gain a little bit more clarity. Before we do that though, I want to talk a little bit about today's sponsor, Cord. Applying for jobs can be a bit of a drag. It can be certainly, it takes a ton of energy. It takes a lot of time usually. And sometimes you put a ton of this energy into something that never returns even the first conversation. And Cord is changing that. Cord is the messaging tool that gives you direct access to hiring teams inside technology companies in London, Europe, and New York. Cord enables what is currently not possible. It's just a simple conversation with someone who wants to hire you. The wider impact of these conversations is far reaching. With Cord, for example, engineers find work through conversations, not applications. Interactions and replies are meaningful, fast, direct, and relevant. Hiring teams inside the world's most advanced technology companies use Cord to hire. From recent Y Combinator alumni to publicly listed technology companies, whole teams are built on Cord that wouldn't even exist without it. Inside companies whose work develops vaccines, tackles climate change, and builds autonomous vehicles. Get direct access to hundreds of people who are hiring your skill set by heading over to cord.co. That's Cord.co slash T. That's c-o-r-d dot c-o slash T-e-a. Makes again to Cord for sponsoring today's episode of Developer Tea. Before we get into talking about the kind of mechanics of how I manage my tasks on the day-to-day basis, I do want to take a step back and say, this is not a recommendation that you just carte blanche adopt the system that I use. In fact, I don't think you should do that with anybody's system. It might be a good starting point if you have nothing at all. But the important thing here is to pay attention to the underlying commonalities between your situation and my situation. We mentioned it before, the principles of what I'm doing. One of the most important principles is the one I'm going to start out with, which is simplifying. Now, I don't mean reducing the work. I don't mean necessarily reducing the final output of the work. Our job as engineers is not necessarily just to build things that are simple. Sometimes we do have to build complicated things. And sometimes we have to have difficult conversations or make hard trade-offs between options that we don't really know which option is necessarily better. We just eventually have to make a decision. So it's not cut and dry. But what we can do is at the very atomic level, the very smallest part of the way that we manage our work. For me, it might be an item on a list or a card in a backlog or some kind of representation of something that needs to be done. That level, we can simplify. So when I say simplify, in this particular case, there's a couple of rules that I use when I talk about simplifying one, is to break down a task into the smallest action that I can take. Now there is an important intuitive balance here that you have to learn how to strike. You can't break it down into steps that are so small that you have more time managing this very long to do less. But you should break it down into singular steps that are easy to manage. I'll give you a simple example in software engineering. Add a field to a model. Now this seems like a simple thing that has a lot of implied underlying steps. And maybe you know all of those steps even by heart. But if you were to start on this task, you would likely have to block out X amount of time to finish all of those steps. You'll list a couple of them here. You might have to create some kind of migration. Add some kind of declaration in the models themselves. You may have to run the migration on your local machine. Run all the tests to make sure that these fields don't create some kind of issue with your old code or with unit test on that model directly. You might have to create new validation rules around how those fields get set and how they get saved or they knowable. There's a lot of things to consider when you're adding a field to a model. This doesn't necessarily mean that each of these things is necessarily difficult. And I've certainly heard this argument over and over from myself and other senior engineers. I know how to do that. It's kind of second hand, it's normal process for me. I know how to do it. Just put it in a single card and I'll get all of it done. But there's a couple of problems with this way of thinking. One, the first and perhaps the most important problem is that you can't really predict everything that's going to happen. And so breaking these kinds of changes down into smaller steps. For example, create the migration file might be a reasonable first step and running the migrations in your local instance might be another step. When you break the problem down into these small pieces and especially if you make this a habit, not just on these seemingly simple kinds of tasks, but also on the much harder ones. If you make it a habit, you start to identify places where variation exists. And when you can identify places where variation exists, you can also identify places where blocking happens, which makes the variations and the blocking easier to manage into the future. Perhaps you can start to see ways of reducing the variation and making those otherwise complicated things less complicated in the future. For me, perhaps the biggest benefit of simplifying things down to the most atomic level is that it reduces the friction to progress. Was that mean? Well, if you had, let's say, a third of the amount of time that it would take to do the entire process of adding a field to a model, they may not be willing to start on that. It's hard to leave things in progress. Takes a lot of our mental capacity up to put something in progress and then come back and try to remember where we were. And so instead, we might have friction actually starting on that work. If we instead had very small things to do, if we broke up what we were doing for that overall meta task to be complete, it might be a little bit more likely to get started on that even if we can't necessarily finish all of those tasks now. Making things down also ends up providing more clarity and an easier step to start if you have all of those pieces already thought through up front. Now, again, I want to reiterate that this does require some level of balance and temperament. You can't break everything down into every single small action that you're going to take. You have to decide what that threshold is for you. But you can start with some heuristics. For example, if your task has anything dealing with AND, if you have two actions in the task, try just breaking those two actions out into two different tasks. Another example of this is when you have tasks that represent multiple concepts that are usually tied together. For example, adding crud operations. There's four different kinds of operations in crud and each of those have their own concerns. So it might make sense to have create, read, update, and delete as their own tasks. Even if you're doing some of the work together at the same time, it doesn't necessarily hurt to have those tasks broken out into their own representations in whatever your process of choice is. One way to think about breaking tasks up is to explain how the work is going to get done. When you explain it to, let's say, another engineer, you're likely to explain each of those steps that we're talking about at one layer deeper than whatever the overall meta-task is. When you do this, notice the themes and the kinds of things that you talk about as steps and then use those steps as your tasks. To be clear, we're talking about conversational explanation here, not tutorial explanation, where you give each step by step process. The second principle that I use when managing my time and all of the work that I have to do is to look at all of my priorities together. Don't separate work or personal life or podcast life or hobby life. Look at everything together. Sometimes time is going to dictate when something has to be done. In other words, I'm unlikely to prioritize all of my personal life during my work hours, that kind of thing. But when you can integrate your life together, you can begin to get more connected to what your true priorities are for yourself, both now and in the long term. Instead of sequestering all of your thoughts about your personal life to only be allowed after 5 o'clock during the day, consider everything together. Ask yourself, how can I arrange my life, arrange my work, arrange my priorities, my responsibilities in such a way that everything on this list makes sense, that I'm not having to choke one thing out for another. It's possible that your list needs to change, but it's also possible that you can start to see your life as an integrated unit so that one priority actually helps the other priorities. When you consider your priorities together, you have the opportunity to stack them in a way that is beneficial to more than just one part of your life. This will help you avoid burnout and stay aware of when certain parts of your life are becoming unbalanced with the rest of it. Thanks so much for listening to today's episode of Develop or Tea. This certainly doesn't comprehensively cover everything that I do to stay productive or every mechanism that I use to manage my tasks. But I hope this gives you some food for thought. I hope you take some time to go and review the way that you think about priorities and the way that you think about simplifying your work. Thanks so much for listening to you again to today's sponsor. Cord. Cord is the messaging tool that gives you direct access to hiring teams inside technology companies in London, Europe, and New York. You can get direct access to hundreds of people hiring your skill set. You'll send and receive messages directly from hiring teams themselves with everything happening in a simple messaging thread with a calendar integration built in to all data is live and transparent, including salary, tech stack, interview process, and response times. Go and check it out. Cord.co slash T. That's c-o-r-d dot c-o slash T-e-a. Thanks so much for listening to this episode. If you want to discuss the ideas and share your ways of staying productive of gaining more clarity and allowing that clarity to inform your perspective, all of these topics are the kinds of things that we talk about on the Developer Tea Discord. Head over to developertea.com slash discord to join that totally free forever for you as a listener of this show. Thanks again and until next time, enjoy your tea.