Vox

Leitura de 11 min

Engineering Your Habits Like Interfaces

Summary

In this episode of Developer Tea, host Jonathan Cottrell proposes applying software engineering principles to personal productivity and habit formation. He introduces the metaphor of treating days and tasks like functions with defined inputs and outputs, similar to how interfaces work in code. This structured approach helps encapsulate processes and clarify what is needed to achieve desired outcomes.

Cottrell explains that just as a code interface defines a contract for interaction without worrying about implementation details, we can define the expected outputs for our day and identify the necessary inputs to achieve them. He uses the example of packing for a trip, where people often explicitly list needed items (inputs) to ensure a successful trip (output). Most daily activities, however, lack this explicit structure, leading to missed goals and mindless repetition.

The discussion extends to habits, which Cottrell compares to recurring cron jobs—processes run regularly that produce positive outputs over time, even if not identical each time. He emphasizes the importance of periodically reviewing these habits, as life circumstances change, and what was once effective may need adjustment. The key is to avoid assuming that routine activities will automatically yield desired results without conscious design.

Cottrell recommends a practical exercise: define a single, achievable output for your day and work backward to identify the inputs (time, resources, actions) required. This method of ‘engineering’ your day helps prioritize and align daily actions with broader goals. By thinking of life in terms of interfaces and functions, developers can bring more clarity and purpose to their personal and professional routines.

Topic Timeline

  • 00:00:00 — Introduction to the episode’s core question — Jonathan Cottrell opens the episode by posing the central question: ‘What are the outcomes that you are expecting in your day-to-day life?’ He introduces the podcast’s goal of helping developers find clarity and purpose, and sets the stage for applying software metaphors to life. The focus shifts from typical mental models to a new direction: discussing the concept of interfaces.
  • 00:00:48 — Explaining software interfaces as a metaphor — Cottrell explains the software concept of an interface as an expected way of interacting with a piece of code, like a class or function. He describes how interfaces allow consumers to rely on a contract without knowing implementation details, enabling encapsulation. This sets up the parallel to how we can structure our daily activities with similar clarity around inputs and outputs.
  • 00:02:06 — Contrasting structured code with unstructured life — The host contrasts the reliable, documented interfaces in software (like APIs) with the often unstructured nature of our daily lives. He notes that we frequently lack specific outputs we’re aiming for and don’t consider the necessary inputs to accomplish tasks. The example of packing for a trip is given as a rare case where people are explicit about needs, unlike most daily routines.
  • 00:03:39 — Treating each day as a function with inputs and outputs — Cottrell suggests imagining each day as its own function, with desired outputs and required inputs. He expands the timeframe, noting that inputs today might be for outputs far in the future, and today’s outputs become inputs for later processes. While this seems obvious, he argues we often fail to meet goals because we don’t explicitly think this way, instead mindlessly repeating routines.
  • 00:05:03 — Practical application: defining outputs and reviewing habits — The host offers a practical way to apply the metaphor: if you seek a specific output, imagine what creates it. He distinguishes between specific outputs and ongoing optimizations, comparing the latter to recurring cron jobs or habits. Habits are processes that produce positive outputs over time, but they should be reviewed periodically as circumstances change, to ensure they remain effective.
  • 00:07:13 — Recommendation: define a daily output and work backward — Cottrell recommends starting with one day: define an achievable output you want from today. By bounding expectations to what’s possible, you can then work backward to identify the necessary inputs, particularly how your time will contribute. This backward-working approach from the solution helps prioritize and align daily actions with the outcomes you care about most.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2020-02-03T10:00:00Z
  • Duration: 00:08:34

References

Podcast Info

Transcript

[00:00:00] What are the outcomes that you are expecting in your day-to-day life?

[00:00:11] This is the question we’re going to be talking about in today’s episode.

[00:00:14] My name is Jonathan Cottrell and you’re listening to Developer Tea.

[00:00:17] My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers.

[00:00:22] A lot of the time on this show, we talk about mental models or metaphors, ways of thinking outside of code that apply to the way that we construct software.

[00:00:38] But in today’s episode, we’re going to take things kind of the opposite direction.

[00:00:43] We’re going to talk about this idea of interfaces.

[00:00:48] Some kind of expected way of interacting.

[00:00:52] With a piece of code, whether it’s a class or maybe it’s a definition of a function, we can think about interfaces as what we expect.

[00:01:05] We can consume code then in a way that doesn’t really care about the internals, doesn’t care about the implementation details.

[00:01:13] It really only cares about the contract that it’s signed with that piece of code, the interface.

[00:01:21] And of course, we can talk about having a public interface and then a private interface, or public functions and private functions.

[00:01:31] Some of this may be a little bit foreign to you depending on what your programming background is.

[00:01:36] But suffice it to say that these are all concepts that you can apply and code that allow you to encapsulate some kind of process.

[00:01:47] Right?

[00:01:47] And the output of that process and the input…

[00:01:50] The inputs to…

[00:01:51] to that process, if there are any, can be well documented. This is how you can have things like

[00:01:58] an API and documentation, because you have some reliable interface. But very often in our lives,

[00:02:06] when we structure our days, when we structure our activities, we don’t think about it in a

[00:02:12] similarly structured fashion. Instead, much of our lives are unstructured. We don’t have specific

[00:02:20] outputs that we’re looking for, and we don’t consider the specific inputs we might need

[00:02:25] to be able to accomplish whatever it is that we need to accomplish.

[00:02:30] For example, let’s imagine that you are packing for a trip. It makes sense for you to identify

[00:02:39] what inputs do you really need for this particular trip to make it successful. And most people do

[00:02:46] this explicitly. They’ll list out the things that they need based on the number of

[00:02:50] days that they’re gone, and sometimes they’ll forget something. They take note of it, and in

[00:02:56] the future when they’re packing, because of the pain they experienced, they might have a better

[00:03:01] recollection or a better heuristic for what to pack this time. But being explicit about what

[00:03:08] we’re packing or explicit about what we need to make this particular event successful,

[00:03:14] it’s kind of rare. And most of the time we don’t really need to write down a list of

[00:03:21] everything we need to make our afternoon hanging out at our house successful, right? That seems

[00:03:28] like overkill. But it might make sense to imagine each day as its own function, and imagine the

[00:03:39] kinds of outputs that you want from today, and the kinds of things that you might need

[00:03:44] together.

[00:03:44] inputs. And it might not just be for today. You might look a week in advance or a month or a year

[00:03:54] in advance. Because some of the inputs that you have for today might be inputs for things that

[00:04:01] you care about, for outputs that you care about, that you won’t have for a long time. But the

[00:04:07] inputs are necessary to even get the ball rolling. And some of the outputs that you have from today

[00:04:13] will carry forward as inputs to another process. Now, if you’re like me, you’re listening to this,

[00:04:21] and I’m even listening to myself saying it, thinking, wow, this is kind of obvious, right?

[00:04:26] Of course, we should think about our outputs from one day as inputs to the next day. But very often,

[00:04:35] we don’t meet our own goals because we don’t take the time to think about the input and output.

[00:04:42] Instead, we just…

[00:04:43] mindlessly run the same functions. Time passes by, and the outputs that we’re striving after,

[00:04:50] we never really achieve because we didn’t identify the necessary inputs. And we may be

[00:04:56] surprised by outputs that we didn’t necessarily specify. So here’s how I recommend you think about

[00:05:03] this, a way of practicing this. If you’re looking for a particular output, imagine what might create

[00:05:12] that output.

[00:05:13] Can you be explicit about this specific thing? Or is this something that you kind of want to

[00:05:21] optimize for over time, that you have a never-ending kind of soft requirement for this

[00:05:28] output? Once again, since we’re using a metaphor, there might be something like a recurring job,

[00:05:36] right? A recurring cron job, if you want to call it that. These are processes that you know are

[00:05:41] good for you, even though you don’t have a necessary output. So if you’re looking for a

[00:05:43] specific specific output that you’re looking for, and so you might set those up, and you might

[00:05:49] review them on a regular basis. These are called habits. If we have a recurring habit over time

[00:05:56] that produces some kinds of positive outputs, even though they don’t necessarily produce the

[00:06:01] same output each time we do them, those habits can have a major effect on our lives. And so we

[00:06:09] might set up a habit initially because it produces some positive effects. But if we’re looking for a

[00:06:13] but over time, that positive effect may change because our environment changes, or our bodies

[00:06:18] change, our team situation might change, our family situation might change, relationships. And so it

[00:06:26] makes sense to review those habits. It makes sense to review those cron jobs that we set up for

[00:06:32] ourselves. Additionally, doing mindless things or assuming that our normal everyday patterns,

[00:06:41] not just our habits, but

[00:06:43] the tasks that we take on or the attitudes that we present in a given meeting, assuming that they’re

[00:06:49] going to produce the outcomes that we want, assumes that we have decided what those outcomes are, and

[00:06:57] that we have kind of optimized all of those activities. And we already have an implicit input

[00:07:03] system. So backing out once again, imagine this for starting at one day. What kind of outputs do

[00:07:13] you want from today? If you can define this a day in advance, or even early in the morning, define the

[00:07:22] kind of outputs that you hope for from today. And of course, you need to bound this, right? You can’t

[00:07:29] imagine that today you want an output that you can’t achieve today. But imagine a single output

[00:07:36] that you know you can achieve. And what do you need to make that possible? Working backwards,

[00:07:43] from this solution, helps you prioritize and it helps you understand what inputs and specifically,

[00:07:51] how your time will input towards the outputs that you care about.

[00:07:55] Thank you so much for listening to today’s episode of Developer Tea. Of course, we didn’t have a

[00:08:01] sponsor for today’s episode. But in lieu of a sponsor in lieu of supporting us by visiting that

[00:08:06] sponsor, I’d love for you to take a moment to share this episode with someone that you think it will

[00:08:11] have a positive impact on.

[00:08:13] Thank you so much for listening. Today’s episode, like every other episode of Developer Tea can be found at

[00:08:18] spec.fm. Today’s episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy

[00:08:26] your tea.

Visão de gráfico