Vox

Leitura de 24 min

Two Principle Categories To Judge Productivity Advice

Summary

In this episode of Developer Tea, the host introduces a framework for evaluating productivity advice through two core principles. The discussion begins by establishing a meta-framework: all productivity advice should be judged against whether it helps you progress toward your specific motivations, whether those are fixed goals (like a job title) or process-oriented values.

The first principle is reducing interruption. Interruptions—whether from multitasking, status reports, or context switching—create inefficiency by stopping progress. The host illustrates this with metaphors like filling a gas tank only partially on a road trip, which adds frequent stops without meaningful progress. The sponsor segment for Jam, a bug-reporting tool, exemplifies this principle by reducing back-and-forth interruptions for engineers.

The second principle is planning adjustments. While staying focused is crucial, you must also periodically evaluate whether your actions are aligning with your motivations. Adjustments help correct course if you’re moving in the wrong direction or if your motivations shift. The host notes that these two principles must be balanced, as adjustments can themselves become interruptive if not planned thoughtfully.

The episode concludes by challenging listeners to analyze other productivity advice through this lens. Most advice will fit into reducing interruption or planning adjustments, with sheer speed (raw capacity) being a lower-leverage factor. The host encourages joining the Developer Tea Discord community to discuss how different advice maps to these principles.

Recommendations

Books

  • The Goal — Written by Eliyahu Goldratt, this book introduced the theory of constraints and discusses concepts like the ‘full kit’ to reduce interruptions.
  • The Rules of Flow — By Efrat Goldratt, this book applies principles from ‘The Goal’ and discusses the ‘full kit’ concept for maintaining productivity by having all necessary resources before starting work.

Tools

  • Jam — A free tool (jam.dev) that creates comprehensive bug reports with videos, console logs, and network requests to reduce interruptions for software engineers by providing all context upfront.

Topic Timeline

  • 00:00:00 — Introduction to evaluating productivity advice — The host opens by questioning the purpose of consuming productivity content and introduces the goal of the episode: to provide two principles for judging such advice. He emphasizes returning to principles-based understanding to avoid getting lost in details.
  • 00:02:32 — Meta-framework: Motivation as the foundation — Before introducing the principles, the host establishes that productivity advice must be evaluated against your motivations. Motivations can be fixed (like a job title) or dynamic (like aligning with values). The effectiveness of advice is measured by whether it helps you progress toward these motivations over time.
  • 00:04:48 — First principle: Reducing interruption — The host introduces the first principle: reducing interruption. He explains that interruptions—often intentional, like multitasking—derail progress by adding switching costs. The sponsor segment for Jam follows, highlighting how the tool reduces interruption in bug reporting.
  • 00:08:01 — Examples and importance of reducing interruption — The host elaborates on reducing interruption, referencing Efrat Goldratt’s concept of a ‘full kit’ from ‘The Rules of Flow.’ He uses metaphors like partial gas refills and frequent status reports to show how interruptions waste time without adding value toward motivations.
  • 00:15:07 — Second principle: Planning adjustments — The host introduces the second principle: planning adjustments. This involves periodically checking if your actions are leading toward your motivation. Adjustments correct inefficiencies from moving in the wrong direction or from shifting motivations.
  • 00:17:34 — Balancing interruption and adjustment — The host discusses how the two principles can conflict, as adjustments can become interruptions. He introduces a ‘sneaky third principle’ of balancing them. He also explains why sheer speed (capacity) is a lower-leverage factor compared to reducing interruption and planning adjustments.
  • 00:21:39 — Challenge and conclusion — The host challenges listeners to analyze other productivity advice through the lens of these two principles. He invites them to join the Developer Tea Discord community to discuss findings. The episode ends with a thank you to the sponsor, Jam.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2024-03-16T07:00:00Z
  • Duration: 00:23:34

References

Podcast Info

Transcript

[00:00:00] You may be wondering, what is the point, what is the point of all of these podcasts you’ve

[00:00:21] been listening to about personal productivity, about career development?

[00:00:28] What is the point of all of the process that you’ve been learning about?

[00:00:33] What is the whole idea?

[00:00:35] What is the kind of macro picture?

[00:00:38] How can I think about this without having to remember every single detail, every single

[00:00:44] time?

[00:00:45] I know this is the place that I find myself very often and returning to some kind of principles

[00:00:51] based understanding of the point is helpful.

[00:00:57] So that’s what we’re going to do in today’s episode.

[00:01:00] I want to talk to you about two basic principles that virtually all of the information that

[00:01:05] you get on this podcast and on other podcasts, at least as it relates to productivity, to

[00:01:12] habits, to process, all of those parts of the advice that we give on this show and the

[00:01:19] advice that you hear on other shows.

[00:01:21] I want to bring it down to two simple principles that you can then kind of extrapolate and

[00:01:27] hopefully find your own ways of thinking about these things.

[00:01:32] These principles are where you would start from, by the way, using these principles and

[00:01:38] going and doing your own kind of investigation research, whatever you want to call it, in

[00:01:43] areas of other mental models to determine, okay, how can I apply learning from social

[00:01:50] sciences to my career as a software engineer?

[00:01:56] And it may not be immediately obvious when you think about it in those terms, but if

[00:02:00] you put on this lens of these two principles we’re going to talk about today, then drawing

[00:02:05] on those mental models from cross-examples, cross-domains is a much more productive process.

[00:02:16] So that’s why I want you to have these.

[00:02:18] It also will help you kind of test the metal of any given idea as it relates to productivity.

[00:02:24] So we’re going to talk about two principles today, but first we need to kind of lay this

[00:02:29] meta framework for what it is that we’re even talking about.

[00:02:32] When we talk about productivity, when we talk about any kind of process, the productivity

[00:02:40] process, all of this, our habits, everything, are driven by some motivation.

[00:02:48] So coming into this discussion, it is assumed that you have a particular motivation that

[00:02:57] you’re trying to accomplish, and maybe more than one motivation, maybe a series of motivations.

[00:03:03] And these can be personal, they can be corporate, they can be aspirational, whatever the motivation

[00:03:09] is, there is either a perceived destination or a perceived state.

[00:03:16] These are kind of fixed motivations.

[00:03:18] Or there’s a perceived identity or process, and these are more dynamic motivations.

[00:03:25] A fixed motivation might look something like, I want to achieve this particular job potential,

[00:03:30] this particular title.

[00:03:32] And a process motivation might be, I want to align with this kind of value in my life.

[00:03:38] But the reason we have to clarify that up top is kind of a meta framework, that there

[00:03:43] is some motivation, that you care about something, that you’re trying to either do or become

[00:03:51] a certain way, do something, become a certain way.

[00:03:56] These accomplishments are essentially the way that you would measure whether the advice

[00:04:01] was good in the first place.

[00:04:03] And that’s over the course of many actions, of course, not just one to one, I took your

[00:04:08] advice and then I failed.

[00:04:11] Those are possible outcomes.

[00:04:12] But if you’re taking the advice over and over and over and you’re not seeing any results

[00:04:17] towards your motivations, then either you are unlucky or the advice is not very good

[00:04:23] or perhaps a combination of both.

[00:04:25] So I want you to judge the advice you get on this show and any advice that you get through

[00:04:31] that kind of combined lens of, okay, have I applied this long enough to see a difference?

[00:04:38] And am I actually progressing towards the thing I’m motivated to progress towards?

[00:04:45] All right, so that’s the meta framework.

[00:04:47] We’re going to share the two principles.

[00:04:48] The first principle is, this is going to sound very reductive, reducing interruption.

[00:04:57] Reducing interruption.

[00:04:59] Why is reducing interruption such a big deal?

[00:05:02] We’re going to talk about that right after we talk about today’s sponsor.

[00:05:08] If I were to take a snapshot of your backlog, my guess is that you’ve got a bunch of bug

[00:05:21] reports in there.

[00:05:23] And my second guess would be that not every bug report looks the same.

[00:05:28] Your teammates have sent them to you or maybe users have sent them in, but sometimes it’s

[00:05:33] just a text description.

[00:05:35] No screenshot, no logs, no user ID, no additional context, no walkthrough.

[00:05:41] You have to go chasing the information on what the reproduction steps actually are.

[00:05:47] In my time as an engineer, I’ve seen some crazy bugs happen.

[00:05:50] Things that you’d have to have all the context to be able to solve.

[00:05:53] And if you’re wasting a bunch of time going and getting this information, as we’re going

[00:05:58] to talk about in today’s episode, the importance of having all this information upfront so

[00:06:03] you can solve these bugs more holistically cannot be overstated.

[00:06:09] Today’s sponsor is Jam.

[00:06:10] You can find them at jam.dev, jam.dev developer friendly bug reports in one click.

[00:06:16] You may have heard of this already.

[00:06:18] It’s already used by more than 75,000 people, probably more by the time this episode comes

[00:06:22] out.

[00:06:23] It’s growing very quickly.

[00:06:24] That’s because it’s a free tool that saves software engineers a ton of time and frustration

[00:06:28] going back and forth.

[00:06:29] It forces your teammates to make the perfect bug report and improves your overall flow.

[00:06:35] Reducing interruption of having to go back and forth for that information is absolutely

[00:06:39] critical to your productivity, to your team’s productivity.

[00:06:43] Your bug reports literally can’t be wrong because they’ll include information that you’ve

[00:06:48] probably never had in a bug report.

[00:06:50] It includes a video of the bug, the console to log, network requests, all the information

[00:06:57] like even what was the internet speed at the time that the bug occurred, even automatically

[00:07:02] lists out the steps that you need to reproduce the bug to the degree that you can actually

[00:07:06] take these steps and create an automated test just by copying the attributes from the report.

[00:07:13] It’s so easy to get your teammates to use because it’s just a Chrome extension.

[00:07:16] When they see a bug, they just click a button and right away it creates a ticket and whatever

[00:07:20] your issue tracker is.

[00:07:21] It saves time for them and it saves you a lot of hopping on calls and meetings to debug.

[00:07:26] Go and check it out, head over to jam.dev.

[00:07:28] That’s J-A-M dot D-E-V.

[00:07:32] It’s free.

[00:07:40] Sometimes the topic of the show serendipitously aligns with the sponsor of the day as we were

[00:07:46] just talking about.

[00:07:47] Jam’s whole kind of value proposition is to reduce interruption.

[00:07:52] And that’s exactly what we’re talking about in today’s episode.

[00:07:54] So this idea of reducing interruption is a core principle of productivity and the advice

[00:08:01] that you receive around productivity.

[00:08:04] There’s a concept discussed by Efrat Goldratt.

[00:08:08] She is the daughter of Eliyahu Goldratt.

[00:08:11] Eliyahu is most famous for writing some of the earliest books on the concept of the theory

[00:08:19] of constraints.

[00:08:20] In fact, his book, The Goal, actually introduced this concept.

[00:08:25] But Efrat discusses in a book called The Rules of Flow, which is using the principles from

[00:08:31] Eliyahu’s book, The Goal, Efrat discusses the idea of a full kit.

[00:08:37] And similarly, Eliyahu talks about this in The Goal as well.

[00:08:40] The idea of a full kit is that in order to accomplish any particular chunk of a project,

[00:08:48] you need some amount of materials and tools and time, whatever other resources you may

[00:08:53] need.

[00:08:55] In the case of solving a bug report, you need the context related to the bug.

[00:09:00] And the whole idea of figuring out what the full kit would be to solve a bug report is

[00:09:07] to reduce interruption.

[00:09:09] Similarly, the many times that we’ve talked about multitasking or the myth of multitasking

[00:09:15] on this show, we’re talking about the idea of interruption, reducing interruption.

[00:09:23] It’s just as detrimental, OK?

[00:09:25] It would be just as detrimental if you stayed focused on a single task, but you had other

[00:09:30] types of interruptions.

[00:09:32] And one of the most amazing things about interruptions as they occur in the workplace is that they

[00:09:38] tend to not be accidental.

[00:09:39] They tend to be on purpose, not ill intent on purpose, not malicious, but on purpose

[00:09:45] in a way that we think they’re going to produce a positive outcome rather than a negative

[00:09:50] one.

[00:09:51] This is kind of counterintuitive.

[00:09:53] We imagine that making progress on multiple things at once is what we need to be doing

[00:09:58] to be successful, that we have to keep a certain number of plates spinning.

[00:10:03] And thus, we’re willing to interrupt ourselves, we’re willing to interrupt others because

[00:10:09] we have something that we think is important at that moment.

[00:10:13] And it’s important enough that the thing that we thought was important before can go

[00:10:17] on hold.

[00:10:19] Of course, the problems with interruptions we’ve detailed many times on the show, and

[00:10:24] you can see them in very simple illustrations and metaphors.

[00:10:28] I’ll give you a few really quickly.

[00:10:31] Imagine you’re on a road trip and instead of getting a full tank of gas, you get only,

[00:10:36] let’s say, a tenth of a tank of gas.

[00:10:39] And you’re rationalizing this by saying, well, we don’t know if maybe the next gas station

[00:10:46] we get to, maybe it will have a cheaper price for the tank of gas.

[00:10:52] And so we’re only going to take a certain amount at a time.

[00:10:55] And so every time that your tank gets a little bit low or close to empty, you only fill it

[00:11:02] by one tenth.

[00:11:04] And so you’re stopping every 50 miles or something, which is taking a lot of extra time.

[00:11:11] Now on the one hand, you may say that, well, we were able to save a certain amount of money

[00:11:16] with this strategy because we were only taking the gas that was the cheapest.

[00:11:21] We were always optimizing for a certain type of spin.

[00:11:27] On the other hand, you’re discounting the importance and scarcity of time in this situation.

[00:11:33] And as a general rule, the principle of reducing interruption is about putting a premium on

[00:11:41] time.

[00:11:43] More specifically, if you recognize that you are spending time on things that are not producing

[00:11:49] value for you, specifically the switching costs, in the case of a car, you know, getting

[00:11:55] off of the highway, the time spent finding a pump to pump the gas, all of this is not

[00:12:00] producing direct value.

[00:12:03] Once again, in this metaphor, the direct value is going back to that motivation kind of meta

[00:12:09] framework.

[00:12:10] The motivation is to arrive at a location and you’re not getting any closer to that

[00:12:14] location when you are looking for a gas pump.

[00:12:18] Another great example of this that’s directly applicable to many managers is the status report,

[00:12:25] especially the frequency of status report and the style of status report.

[00:12:31] Imagine that you are tasked with writing an essay.

[00:12:36] And imagine that every time you wrote a paragraph, you had to look up at somebody who’s watching.

[00:12:44] They’re not looking at the paper, they’re looking at you.

[00:12:47] And you’re going to have to summarize whatever that paragraph says.

[00:12:50] Now, you may need to reference previous paragraphs in order to summarize what this paragraph

[00:12:56] says, but every paragraph you have to stop and explain what you just wrote to someone

[00:13:01] who’s watching you.

[00:13:02] Now, this seems a little bit silly, right?

[00:13:04] It seems like the better way to do this would be to write a first draft of the essay in

[00:13:10] total and then look up at the person and explain the first draft and then go back and revise

[00:13:17] based on notes that you receive or something that you may have learned during that reporting

[00:13:22] process.

[00:13:23] This is very often what status reports look like.

[00:13:26] We’re talking about the same kinds of work.

[00:13:29] The status report itself is not incredibly valuable or insightful to people who care

[00:13:34] about it.

[00:13:35] But most importantly, it again is the same thing as kind of getting off the X ramp.

[00:13:41] We’re taking our focus away from the actual productive work.

[00:13:45] Perhaps a better status report would be a way of observing the writing itself.

[00:13:51] This would be a clearer way to provide a status.

[00:13:56] If you’re looking for ongoing information, if you want to look more into it, what is

[00:14:02] a way that you can get more direct reporting out of the work itself?

[00:14:07] Again, if we’re thinking about this principle, there are a hundred other things that we could

[00:14:13] derive from the principle itself, reducing interruption.

[00:14:17] The effect of reducing interruption is it provides the opportunity to stay focused,

[00:14:24] to have fewer things that are in progress or fewer things that are requiring your attention.

[00:14:31] You fill up the gas tank and then you just drive.

[00:14:34] You stay kind of utilized, if you want to use that word, to a degree that you are remaining

[00:14:42] focused and you’re making progress towards your motivation.

[00:14:47] You’re making meaningful progress.

[00:14:49] You’re not stopping progress to then make a different kind of progress towards a similar

[00:14:53] motivation.

[00:14:54] You’re staying focused on fewer things at once.

[00:14:58] The second principle is a good complement to the first one and that is planning adjustments.

[00:15:07] Planning adjustments.

[00:15:08] What does this mean?

[00:15:09] As you are making progress towards your motivation, if you put your head down and you don’t ever

[00:15:15] evaluate if your actions are taking you the right direction, then it’s very possible that

[00:15:22] you’ll go the wrong direction or at least you’ll spend a lot of time moving in an inefficient

[00:15:27] direction.

[00:15:28] Basically, these two principles are reducing two types of risk of inefficient motion.

[00:15:35] The first risk of inefficient motion is stopping motion just to start again, just to stop again,

[00:15:41] just to start again.

[00:15:43] The second type of inefficient motion is moving with focus but in a wrong direction.

[00:15:51] In this wrong direction, hopefully most of the time if you’re adjusting consistently,

[00:15:56] if you’re planning your adjustments, once again this principle, if you’re planning your

[00:16:00] adjustments then the wrong direction is only slightly wrong.

[00:16:04] But if you never plan to have an adjustment, it’s very possible that you’ll continue getting

[00:16:09] further and further away from your motivation.

[00:16:13] Now unlike a road trip, this is where the metaphor kind of falls apart, unlike a road

[00:16:18] trip, your motivation has no explicitly clear destination or route to arrive.

[00:16:26] And so as you are taking action in your career or in your personal life, as you are focusing

[00:16:34] and trying to use your time as efficiently and positively as possible towards your motivation,

[00:16:43] your adjustment may happen in two ways.

[00:16:47] Either your motivation has shifted, this is an important thing to know, or you realize

[00:16:52] that the direction you’re going, that you’ve been going for a while, that you recognize

[00:16:57] that the direction you’re going is not taking you towards your motivation like you thought

[00:17:01] it would.

[00:17:02] And both of these can happen simultaneously.

[00:17:05] You may find out as you’re approaching your motivation, for example, oh actually I didn’t

[00:17:10] want to do that.

[00:17:12] Hopefully that motivation is not quite true for some reason or another.

[00:17:17] Now the astute listener hopefully is recognizing there’s some very careful language here.

[00:17:22] Planning your adjustments is critical.

[00:17:25] The planning part is the careful language because these two principles can be at odds

[00:17:32] with each other.

[00:17:34] Think about it, if your goal is to reduce interruptions, but you’re making adjustments

[00:17:39] an adjustment could become interruptive.

[00:17:42] So there’s kind of a sneaky third principle here, which is balancing these two other principles.

[00:17:49] Balancing your interruption with your adjustment.

[00:17:53] Now you’ll notice that I left out a perhaps third principle, and this was done on purpose.

[00:17:59] And that is the sheer speed, the top capacity.

[00:18:03] If you were to be fully focused and if you were to be headed in the right direction making

[00:18:07] the proper adjustments, the only thing remaining that will make you more productive is the

[00:18:12] speed at which you operate.

[00:18:15] The reason I left this out is because it is very likely the lowest leverage opportunity

[00:18:21] on this list.

[00:18:23] It’s very likely the lowest leverage opportunity on this list.

[00:18:26] And the reason for that is your speed is unlikely to increase or have an impact on your progress

[00:18:33] relative to these other two measures.

[00:18:37] Your personal capacity.

[00:18:40] If you’re learning on a regular basis, then your speed is already increasing.

[00:18:44] The fact that you are actually operating on a day-to-day basis in an environment, you

[00:18:49] are naturally increasing.

[00:18:50] This is again where the metaphor does not quite cover the basis here.

[00:18:55] But your speed is not going to increase in a stepwise motion.

[00:19:00] If you were to eliminate all distractions, you’re going to have an overnight, in a moment,

[00:19:09] increase in productivity that is drastic.

[00:19:12] If you’re eliminating your distractions or even if you’re cutting them in half, if you’re

[00:19:19] finding a way to eliminate interruptions, this is a moment in time change.

[00:19:24] In reality, it probably wouldn’t be a moment in time, but it’s possible, right?

[00:19:29] It’s possible to have a moment in time change on both making an adjustment and on reducing

[00:19:38] your interruptions.

[00:19:39] Now, it’s interesting.

[00:19:40] Most advice about improving your velocity is actually focused on reducing interruptions.

[00:19:47] Leveling up your sheer capacity is a much longer term investment.

[00:19:51] And it certainly is not one we want to ignore completely.

[00:19:54] But the first two principles that I want you to focus on is getting this part correct,

[00:20:00] getting your operating procedures correct, because your speed is dependent on getting

[00:20:06] those two things right.

[00:20:08] Your speed mattering is dependent on getting those other two things right.

[00:20:12] So I wouldn’t worry too much on becoming the 10X developer in terms of your sheer capacity

[00:20:19] to get things done when you are focused.

[00:20:22] The differences between a true 10X and 1X developer, if we have to talk about that here,

[00:20:28] most of them are actually in these other two categories.

[00:20:31] Staying laser focused and reducing the interruptions is a huge part of whatever that 10X is.

[00:20:36] Of course, learning about the domain, learning about the tech, all of that is important.

[00:20:41] You wouldn’t be where you are today as an engineer if you didn’t learn some of that

[00:20:45] stuff in the beginning.

[00:20:46] And you’re likely, in order just to keep your job, you’re probably having to learn

[00:20:52] new things.

[00:20:53] Yes, this will increase your kind of linear delivery capacity, if you want to think about

[00:20:59] it that way, your top speed on a straightaway on the highway.

[00:21:02] But most of the time, most of the time, if you can get these other two factors right,

[00:21:06] your top speed matters drastically less.

[00:21:10] It matters drastically less than you making good adjustments, planning your adjustments

[00:21:15] on some cadence where you’re balancing your adjustments to your interruptions.

[00:21:20] If you’re a manager that’s listening to this, these are the areas that you can improve your

[00:21:24] team best in.

[00:21:27] If you can reduce interruptions across your whole team, this is going to have a much larger

[00:21:31] impact than if you were to get your team training on some particular tech.

[00:21:36] My challenge to you, we’re not going to do homework in this episode.

[00:21:39] My challenge to you is to listen out, listen out for the, if you have another podcast that’s

[00:21:44] about to play right after this one finishes, listen for the kinds of advice that you’re

[00:21:48] hearing and try to see.

[00:21:50] Does it fit one of these two categories?

[00:21:52] If not, what is a category or a principle that it would fit?

[00:21:57] What is a underlying truth that’s going to, it’s going to carry me towards my motivation

[00:22:04] if I take this advice?

[00:22:06] What you’ll find is most advice is likely to fall in one of these two and possibly that

[00:22:10] third one.

[00:22:12] And if it doesn’t, then it’s worth questioning, how does this fit into the picture?

[00:22:16] How does it help me get to that other piece?

[00:22:19] It’s very possible that you find advice that kind of leads to, that maybe doesn’t fit directly

[00:22:26] in one of these categories, but it leads to a behavior that improves one of these categories.

[00:22:32] I’d love to hear about your experiences with this.

[00:22:34] If you have advice that fits outside of these, or if you’re finding advice that, yes, indeed,

[00:22:40] it does fit in both of these categories, I’d love to hear about it.

[00:22:43] Head over to developert.com slash discord.

[00:22:45] You can join that community totally free and it will always be free.

[00:22:49] There’s no paid tier.

[00:22:50] It’s not just the joining that’s free.

[00:22:52] Come and talk about the kinds of advice that you’re getting and how they kind of work back

[00:22:59] towards a principle.

[00:23:00] I’d love to hear more about that.

[00:23:01] That’s developert.com slash discord.

[00:23:03] The community would also love to hear that as well.

[00:23:06] Another big thank you to today’s sponsor, Jam.

[00:23:09] If you’ve experienced a bad bug report and you want that to stop, then head over to jam.dev.

[00:23:15] If you’re an engineer and you’d rather spend time writing code than responding to comments

[00:23:19] in your issue tracker, head over to jam.dev to get started.

[00:23:23] It’s free.

[00:23:24] Thank you so much for listening to today’s episode and until next time, enjoy your tea.

Visão de gráfico