What will be different at the end of today as a result of the work and the actions that you take? This is a fundamental question that you can put at the top of your journal. You can put it in your code editor to remind you every day that the work that you do and the actions that you take, they have outcomes. And perhaps more importantly, you can think about the mode of your work. This is something that we don't often think about as developers, but you can think about the mode of your work to convert your energy into better outputs. And that's what we're talking about in today's episode, finding better outputs. My name is Jonathan Cutrell and you're listening to Developer Tea and my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. If you're like many people, work becomes monotonous. Your job is no longer about outputs. It's no longer about evaluating what was changed at the end of the day because of your presence and your actions. Instead, your work, your efforts are about the effort itself. You come in and you check emails because emails are part of your job. The action itself is how you define success. And while there are some benefits to this, actually we talked about this at the end of last year, the benefits of thinking about the things that you can commit to, specifically, you can only commit to actions. You don't control outcomes. You only control actions. And so you can only commit to actions, but what often happens is we think about our actions as proxies to outputs. We forget the actual output. For example, we check our emails because at some point in the past, emails had an important outcome. That outcome might be that you receive some urgent communication from a coworker. Or perhaps you find out about somebody's birthday over email. Or maybe you get support tickets coming to your email. All of these things have good reason. They have good outputs. But we aren't thinking about the mode of our actions every single day. It's much easier to think about the action on its own, rather than pairing the action with outputs. In fact, we talked about this in a previous episode as well when we talked about functional meetings. Functional meetings are meetings that have a return value. What are you returning at the end of the meeting? What is the output in this way? They are functional in the same way that a pure function has inputs and outputs. We're going to take a quick break and then we're going to come back and talk about how you can evaluate your modes a little bit better and set up some defaults, some good default modes. But first, let's talk about today's sponsor, Pathrise. If you are in your job search, it is easy to feel like you are alone. Of course, there's other people who are searching for a job as well. But what you really need and what you probably really want is some kind of mentorship. Pathrise is an online mentorship program. It gets you a job at a top tech company. Work with you on your job search all the way through you getting hired. This can take a month. That's probably pretty unlikely. You've probably already been looking for a job for a month or up to a year. However, long it takes Pathrise will be there walking with you. With Pathrise, you can receive unlimited weekly one-on-ones until you get hired, along with workshops, small groups, support over email, text messages, and other types of support. Now, Pathrise doesn't dull out your normal BS, your generic career advice that you can get on YouTube. They actually focus on data in this specific industry, specific tactics, insider information, and that kind of stuff. It's based on your schedule and the important part is you aren't going to pay a dime until you get hired first. Pathrise believes in their program enough to not charge you until you have a win yourself. Go and check it out. Head over to pathrise.com slash T. That's pathrise.com slash T-E-A to get started today. Thanks again to Pathrise for sponsoring today's episode of Developer Tea. When you walk into work today and you look at your list of things to do, maybe you have a scrum board or you're pulling things off of Jira or Trello or some kind of maybe you have a notebook, whatever it is, wherever you are storing your list of things that are going to prompt action from you, you probably don't have modes. You aren't thinking about the mode for each of those actions. What do we mean by mode? You can think of this as kind of a role that you'll play, a hat that you'll wear. The mode that you're working in is going to determine the types of output that you produce for a given task. And as a result of that, it changes the way that you operate while you're doing that task. So for example, let's say your mode is to be a highly detailed oriented fact checker. And you're going to put this hat on, you're going to assume this role, you're going to work in this mode whenever you are evaluating a pull request. In particular, a pull request that is going into production because not every pull request should be treated the same. So you might have that mode in mind when a pull request that is just exploratory comes through. And this is where the nuances actually turn out to be really important. If you start fact checking and being highly detailed on a spike and exploratory bit of code that was never meant to go into production, it's more intended to show an idea. Well, that level of scrutiny is not very useful. In fact, it can be wasteful or harmful to the intention of that pull request. And so the mode that you're operating in, even though it's the same kind of motions, the same name of a task of reviewing a pull request, the mode that you're operating in can entirely change the output and the effectiveness of that output to your goals. Other important modes might be information gathering. If your mode is to learn as much as you can about a topic, then you're trying to gather as much information as you can. Maybe you have multiple ways of gathering that information. You're taking a lot of notes, you're recording whatever the input stream is. There's a lot of things you can do when the mode is information gathering. On the flip side, if the mode is personal connection and presence, then taking notes may actually detract from that presence. Asking too many questions about the details may actually frustrate someone. Imagine that you are a manager and you're dealing with some interpersonal issues on your team. One person is coming to you and they're trying to give you a kind of explain how they're feeling about a certain situation. You start asking them for times of certain events. Well, that's probably not going to be very helpful to that person, to making them feel like you're connecting with the problem that they're having. The mode that you operate in as we've illustrated in these two examples, and there's plenty more, is both nuanced and incredibly important. What can happen is we can default back to modes that are wrong for a given scenario because we are working in that mode, perhaps most comfortably or most regularly. For example, software engineers may default to the mode of conserving time and energy so that we can get as much of the work done as possible, and in this scenario, in this mode, work is defined as feature shipped. It makes sense that this mode would be the useful default for a software engineer. What are we actually shipping as a result of whatever it is that we're talking about? But this isn't the only mode that exists for engineers. If this is the only useful mode for engineers, then you might ignore someone's story about their weekend, and you may end up having a less effective relationship with that person. This mode also may keep you from engaging in discussions, higher level business discussions about what the next thing is or how to approach a new market. It's important to understand what your default or natural modes might be, and also to evaluate when those modes are not going to be helpful. Once again, I'm going to refer you back to that list of to-dos or your calendar. Try to understand what mode you're going to be in for all of those tasks that you have, all of the events that you're participating in, especially in meetings, all of the things where you are interacting with another person. Unified the mode that is most effective for each of those. Thank you so much for listening to today's episode of Developer Tea. Think you can to Pathrise for sponsoring today's episode. Today's episode can be found at SPECT.FM, along with every other episode of Developer Tea. I do want to take a minute to thank all of you. This show has been around officially now for five years, and honestly, I cannot believe that it's gone by so fast first of all. That we've been able to keep on doing this show, and it's because of listeners like you, and it's because you've shared this podcast with your friends. You've given reviews on iTunes. You've subscribed. You've stayed a listener for a long period of time. We have so many people who listen to the show on a regular basis, and I couldn't be more grateful for you. Thank you so much. Please continue to do those things, the sharing, and the leaving of reviews. Those are the things that help this show continue forward for another five years. Thank you so much for listening to today's episode, and until next time, enjoy your tea.