Vox

Leitura de 17 min

Some of My Productivity Mechanisms

Summary

In this episode of Developer Tea, host Jonathan Cutrell delves into his personal productivity mechanisms, emphasizing the interplay between clarity and perspective. He argues that much of the administrative work in productivity—managing tasks in tools like Asana or Jira—is fundamentally about increasing clarity regarding how tasks relate, their priority, ownership, and necessity.

Cutrell introduces two core principles for practical task management. The first is simplifying work by breaking tasks down into the smallest actionable steps. Using the example of adding a field to a software model, he illustrates how decomposing a seemingly simple task into discrete steps (creating a migration, running tests, adding validations) reduces friction to starting work, helps identify blocking issues and variations, and ultimately provides more clarity. He advises finding a balance, using heuristics like splitting tasks containing ‘AND’ or separating multi-concept tasks like CRUD operations.

The second principle is to view all life priorities—work, personal, hobbies—in an integrated manner rather than in separate silos. By considering everything together, one can arrange responsibilities to support each other, avoid burnout, and maintain awareness of balance across life domains. Cutrell concludes by encouraging listeners to reflect on their own approaches to simplification and priority integration to enhance their daily productivity and clarity.

Recommendations

Communities

  • Developer Tea Discord — A free community for listeners to discuss ideas from the show, including productivity, gaining clarity, and how clarity informs perspective.

Tools

  • Asana — Mentioned as an example of a tool used for task management and dragging cards, part of the ‘administrivia’ of productivity processes.
  • Jira — Referenced alongside Asana as a tool for managing tasks and backlogs in the context of productivity processes.
  • Chord — The episode’s sponsor, described as a messaging tool that gives direct access to hiring teams at tech companies, enabling job searches through conversations rather than applications.

Topic Timeline

  • 00:00:00 — Introduction to productivity and the theme of clarity — Jonathan Cutrell introduces the episode’s focus on his personal productivity mechanisms. He frames productivity as gaining clarity and perspective, not just employing hacks. The administrative process of task management is described as a means to increase clarity about task relationships, priorities, and necessity.
  • 00:04:29 — Sponsor message from Chord — A sponsored segment for Chord, a messaging tool that connects engineers directly with hiring teams at tech companies. It emphasizes finding work through conversations rather than traditional applications, highlighting speed and direct relevance in the hiring process.
  • 00:06:05 — First principle: Simplifying tasks into atomic actions — Cutrell explains his first key mechanism: breaking tasks down into the smallest possible actionable steps. He uses the detailed example of ‘adding a field to a model’ in software engineering to show how this decomposition reduces starting friction, helps identify variations and blocks, and provides clarity. He advises balancing detail with manageability and offers heuristics like splitting tasks with ‘AND’ or separating multi-concept work.
  • 00:13:44 — Second principle: Integrating all life priorities — The second mechanism discussed is viewing all priorities—work, personal, hobbies—together as an integrated whole, rather than in separate compartments. This approach allows for arranging life so priorities support each other, helps avoid burnout, and maintains awareness of balance across different life domains.
  • 00:15:27 — Conclusion and call to action — Cutrell concludes by summarizing the discussion on simplification and integrated priorities. He encourages listeners to reflect on their own systems and invites them to join the Developer Tea Discord community to continue the conversation about productivity, clarity, and perspective.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2022-01-24T08:00:00Z
  • Duration: 00:17:00

References

Podcast Info

Transcript

[00:00:00] Getting work done one moment at a time, that is a theme of productivity on this show.

[00:00:12] It’s not a simple hack that you can employ instead.

[00:00:16] It is a way of thinking and in today’s episode, I want to talk you through some of the mechanisms

[00:00:22] of how I personally deal with the things that I need to do on a day-to-day basis.

[00:00:29] How do I stay productive?

[00:00:30] My name is Jonathan Cotrell.

[00:00:31] You’re listening to Developer T. My goal on the show is to help driven developers like

[00:00:36] you find clarity, perspective, and purpose in their careers in today’s episode.

[00:00:43] Mostly we’re going to be talking about clarity.

[00:00:48] As we gain clarity, this is one of the most important kind of interactions that we can

[00:00:53] talk about on this show.

[00:00:55] The interaction between clarity and perspective.

[00:01:00] Perspective provides us a unique vantage point, whereas clarity gives us a full vision from

[00:01:10] that vantage point.

[00:01:13] As we begin to gain clarity, we may want, naturally, to adopt a new perspective.

[00:01:22] This interaction between clarity and perspective.

[00:01:26] As you gain clarity, you might choose a different perspective.

[00:01:30] You might seek a new perspective or if you suddenly have encountered a new perspective

[00:01:38] that may provide clarity to your current one.

[00:01:43] This interaction between clarity and perspective is critical to our day-to-day productivity

[00:01:49] because a lot of the process of, and I use that word very carefully because we can get

[00:01:57] wrapped up in process, but a lot of the process of productivity, the management of your tasks,

[00:02:05] the dragging of cards in Asana or in Jira or whatever tool you’re using, the checking

[00:02:12] off on your to-do list, a lot of this kind of administrivia that you probably engage

[00:02:18] in is about increasing clarity.

[00:02:25] So what is this clarity that I’m talking about specifically?

[00:02:28] Well, the clarity of how things interact with each other.

[00:02:32] For example, how does this task relate to the other one?

[00:02:37] How does this work relate in terms of priority to the rest of the work?

[00:02:44] What exactly needs to be done and can I do it or should someone else do it?

[00:02:51] Should we do it at all?

[00:02:53] All of this kind of clarity is what we’re seeking in that administrivia, in the process

[00:03:01] part of our work.

[00:03:03] And interestingly, as we move through our work, we begin to validate and hopefully adjust

[00:03:12] our processes because we can find what kinds of clarity we are getting or most importantly,

[00:03:21] the kinds of clarity we aren’t getting that we need.

[00:03:23] Now, I want to be very clear about something.

[00:03:26] I am not going to push you towards any specific kind of process.

[00:03:31] Some processes work better for certain scenarios than others.

[00:03:34] This is a long belabored discussion on teams of all sizes and types over the years.

[00:03:43] Certainly, there are some principles that I would recommend that you pay attention to

[00:03:48] and in kind of bring into whatever process you do choose, but I’m not going to push

[00:03:54] you towards any particular process.

[00:03:55] Instead, I’m going to talk about some of the things that I do.

[00:04:00] Some of the more atomic and practical parts of the way that I kind of mechanically deal

[00:04:05] with my tasks in today’s episode.

[00:04:09] And hopefully this will help you as you go through the management of your things to do,

[00:04:15] it’ll help you gain a little bit more clarity.

[00:04:18] Before we do that, though, I want to talk a little bit about today’s sponsor, Chord.

[00:04:29] Hiring for jobs can be a bit of a drag, it can be certainly it takes a ton of energy,

[00:04:36] it takes a lot of time usually, and sometimes you put a ton of this energy into something

[00:04:41] that never returns, even the first conversation and Chord is changing that.

[00:04:46] Chord is the messaging tool that gives you direct access to hiring teams inside technology

[00:04:51] companies in London, Europe and New York.

[00:04:54] Chord enables what is currently not possible, just a simple conversation with someone who

[00:04:59] wants to hire you.

[00:05:00] The wider impact of these conversations is far reaching.

[00:05:04] With Chord, for example, engineers find work through conversations, not applications.

[00:05:10] Interactions and replies are meaningful, fast, direct and relevant, and hiring teams inside

[00:05:15] the world’s most advanced technology companies use Chord to hire.

[00:05:19] From recent Y Combinator alumni to publicly listed technology companies, whole teams are

[00:05:25] built on Chord that wouldn’t even exist without it.

[00:05:30] Inside companies whose work develops vaccines, tackles climate change and builds autonomous

[00:05:35] vehicles.

[00:05:37] Get direct access to hundreds of people who are hiring your skill set by heading over

[00:05:41] to Chord.co, that’s Chord.co slash T, that’s C-O-R-D dot C-O slash T-E-A.

[00:05:51] Thanks again to Chord for sponsoring today’s episode of Developer Tea.

[00:05:55] Before we get into talking about the kind of mechanics of how I manage my tasks on a

[00:06:05] day to day basis, I do want to take a step back and say, this is not a recommendation

[00:06:11] that you just carte blanche adopt the system that I use.

[00:06:15] In fact, I don’t think you should do that with anybody’s system.

[00:06:17] It might be a good starting point if you have nothing at all, but the important thing here

[00:06:22] is to pay attention to the underlying commonalities between your situation and my situation.

[00:06:32] We mentioned it before, the principles of what I’m doing.

[00:06:36] One of the most important principles is the one I’m going to start out with, which is

[00:06:39] simplifying.

[00:06:40] Now, I don’t mean reducing the work.

[00:06:45] I don’t mean necessarily reducing the final output of the work.

[00:06:51] Our job as engineers is not necessarily just to build things that are simple.

[00:06:56] Sometimes we do have to build complicated things, and sometimes we have to have difficult

[00:07:01] conversations or make hard trade-offs between options that we don’t really know which option

[00:07:06] is necessarily better.

[00:07:08] We just eventually have to make a decision, so it’s not cut and dry.

[00:07:13] But what we can do is at the very atomic level, at the very smallest part of the way that

[00:07:19] we manage our work.

[00:07:20] For me, it might be an item on a list or a card in a backlog or some kind of representation

[00:07:28] of something that needs to be done.

[00:07:32] At that level, we can simplify.

[00:07:35] So when I say simplify, in this particular case, there’s a couple of rules that I use

[00:07:40] when I talk about simplifying.

[00:07:43] is to break down a task into the smallest action that I can take.

[00:07:49] Now, there is an important intuitive balance here that you have to learn how to strike.

[00:07:55] You can’t break it down into steps that are so small that you have more time managing

[00:08:02] this very long to-do list, but you should break it down into singular steps that are

[00:08:08] easy to manage.

[00:08:09] I’ll give you a simple example in software engineering.

[00:08:14] Add a field to a model.

[00:08:17] Now this seems like a simple thing that has a lot of implied underlying steps, and maybe

[00:08:23] you know all of those steps even by heart.

[00:08:26] But if you were to start on this task, you would likely have to block out X amount of

[00:08:33] time to finish all of those steps.

[00:08:36] We’ll list a couple of them here.

[00:08:38] You might have to create some kind of migration, add some kind of declaration in the models

[00:08:44] themselves.

[00:08:46] You may have to run the migration on your local machine, run all the tests to make sure

[00:08:50] that these fields don’t create some kind of issue with your old code or with unit tests

[00:08:58] on that model directly.

[00:09:00] You might have to create new validation rules around how those fields get set and how they

[00:09:06] get saved, are they nullable.

[00:09:09] There’s a lot of things to consider when you’re adding a field to a model.

[00:09:14] Now this doesn’t necessarily mean that each of these things is necessarily difficult,

[00:09:19] and I’ve certainly heard this argument over and over from myself and other senior engineers.

[00:09:24] Oh, I know how to do that.

[00:09:26] It’s kind of secondhand.

[00:09:28] It’s normal process for me.

[00:09:31] I know how to do it.

[00:09:32] Just put it in a single card and I’ll get all of it done.

[00:09:35] But there’s a couple of problems with this way of thinking.

[00:09:38] One, the first and perhaps the most important problem is that you can’t really predict everything

[00:09:43] that’s going to happen.

[00:09:45] And so breaking these kinds of changes down into smaller steps, for example, create the

[00:09:51] migration file might be a reasonable first step and running the migrations in your local

[00:09:58] instance might be another step.

[00:10:00] When you break the problem down into these small pieces, and especially if you make this

[00:10:05] a habit, right, not just on these seemingly simple kinds of tasks, but also on the much

[00:10:11] harder ones.

[00:10:13] If you make it a habit, you start to identify places where variation exists.

[00:10:19] And when you when you can identify places where variation exists, you can also identify

[00:10:23] places where blocking happens, which makes the variations and the blocking easier to

[00:10:32] into the future.

[00:10:33] Perhaps you can start to see ways of reducing the variation and making those otherwise kind

[00:10:38] of complicated things less complicated in the future.

[00:10:42] For me, perhaps the biggest benefit of simplifying things down to the most atomic level is that

[00:10:48] it reduces the friction to progress.

[00:10:51] What does that mean?

[00:10:52] Well, if you had, let’s say, a third of the amount of time that it would take to do the

[00:10:58] entire process of adding a field to a model, they may not be willing to start on that.

[00:11:04] It’s hard to leave things in progress.

[00:11:06] It takes a lot of our mental capacity up to put something in progress and then come back

[00:11:11] and try to remember where we were.

[00:11:13] And so instead, we might have friction actually starting on that work.

[00:11:20] If we instead had very small things to do, if we broke up what we were doing for that

[00:11:26] overall kind of meta task to be complete, we might be a little bit more likely to get

[00:11:33] started on that, even if we can’t necessarily finish all of those tasks now.

[00:11:38] Breaking things down also ends up providing more clarity and an easier step to start if

[00:11:46] you have all of those pieces kind of already thought through up front.

[00:11:52] Now again, I want to reiterate that this does require some level of balance and temperament.

[00:11:58] You can’t break everything down into every single small action that you’re going to take.

[00:12:04] You have to kind of decide what that threshold is for you.

[00:12:10] But you can start with some heuristics.

[00:12:12] For example, if your task has anything dealing with AND, if you have two actions in the task,

[00:12:19] try just breaking those two actions out into two different tasks.

[00:12:24] Another example of this is when you have tasks that represent multiple concepts that are

[00:12:30] usually tied together.

[00:12:31] For example, adding CRUD operations.

[00:12:34] Well, there’s four different kinds of operations in CRUD and each of those have their own concerns.

[00:12:40] So it might make sense to have create, read, update, and delete as their own tasks.

[00:12:46] Even if you’re doing some of the work together at the same time, it doesn’t necessarily hurt

[00:12:51] to have those tasks broken out into their own representations in whatever your process

[00:12:57] of choice is.

[00:12:59] One way to think about breaking tasks up is to explain how the work is going to get done.

[00:13:06] When you explain it to, let’s say, another engineer, you’re likely to explain each of

[00:13:12] those steps that we’re talking about at one layer deeper than whatever the overall

[00:13:17] metatask is.

[00:13:19] When you do this, notice the themes and the kinds of things that you talk about as steps

[00:13:26] and then use those steps as your tasks.

[00:13:30] To be clear, we’re talking about kind of conversational explanation here, not tutorial explanation

[00:13:35] where you give each step-by-step process.

[00:13:39] The second principle that I use when managing my time and all of the work that I have to

[00:13:44] do is to look at all of my priorities together.

[00:13:49] Don’t separate work or personal life or podcast life or hobby life.

[00:13:54] Look at everything together.

[00:13:57] Sometimes time is going to dictate when something has to be done.

[00:14:01] In other words, I’m unlikely to prioritize all of my personal life during my work hours,

[00:14:07] that kind of thing, but when you can kind of integrate your life together, you can

[00:14:14] begin to get more connected to what your true priorities are for yourself both now and in

[00:14:22] the long term.

[00:14:24] Instead of sequestering all of your thoughts about your personal life to only be allowed

[00:14:30] after five o’clock during the day, consider everything together.

[00:14:35] Ask yourself, how can I arrange my life, arrange my work, arrange my priorities, my responsibilities

[00:14:42] in such a way that everything on this list makes sense, that I’m not having to choke

[00:14:49] one thing out for another.

[00:14:53] It’s possible that your list needs to change, but it’s also possible that you can start

[00:14:58] to see your life as an integrated unit so that one priority actually helps the other

[00:15:06] priorities.

[00:15:07] When you consider your priorities together, you have the opportunity to stack them in

[00:15:11] a way that is beneficial to more than just one part of your life.

[00:15:16] This will help you avoid burnout and stay aware of when certain parts of your life are

[00:15:23] becoming unbalanced with the rest of it.

[00:15:27] Thanks so much for listening to today’s episode of Developer Tea.

[00:15:29] This certainly doesn’t comprehensively cover everything that I do to stay productive or

[00:15:34] every mechanism that I use to manage my tasks, but I hope this gives you some food for thought.

[00:15:42] I hope you take some time to go and review the way that you think about priorities and

[00:15:47] the way that you think about simplifying your work.

[00:15:51] Thanks so much for listening.

[00:15:52] Thank you again to today’s sponsor, Chord.

[00:15:55] Chord is the messaging tool that gives you direct access to hiring teams inside technology

[00:15:58] companies in London, Europe, and New York.

[00:16:01] You can get direct access to hundreds of people hiring your skill set.

[00:16:04] You’ll send and receive messages directly from hiring teams themselves with everything

[00:16:08] happening in a simple messaging thread with a calendar integration built into.

[00:16:13] All data is live and transparent, including salary, tech stack, interview process, and

[00:16:18] response times.

[00:16:19] Go and check it out.

[00:16:20] Thanks so much for listening to this episode.

[00:16:28] If you want to discuss the ideas and share your ways of staying productive, of gaining

[00:16:33] more clarity, and allowing that clarity to inform your perspective, all of these topics

[00:16:39] are the kinds of things that we talk about on the Developer Tea Discord.

[00:16:42] Head over to developertea.com slash discord to join that totally free forever for you

[00:16:48] as a listener of this show.

[00:16:49] Thanks again, and until next time, enjoy your tea.

Visão de gráfico