The Case for Strategic Laziness
How to maximize your time while minimizing wasted effort.
I’m married.
I’m a father.
I have a full-time job.
And I’m in grad school.
And yet, I still have time to write, tinker, and do other stuff.
How? With the help of a little something I like to call Strategic Laziness.
My method for strategic laziness is built from a couple of core concepts:
Lazy Evaluation in programming language theory
The Law of Diminishing Returns
The Law of Diminishing Returns is a concept in which there is a maximum yield for your output related to some level of effort. You will commonly see a graph that looks like this:
That yellow dot is the sweet spot. Any amount of effort before the yellow dot leads to increased output, but any level of effort after that dot leads to less output. I find it more beneficial to show this on a logistic curve:
Here we see that as I continue to put time and effort into something, I approach “perfect” as the time spent approaches infinity. At the same time, the Diminishing returns point comes much earlier and is much closer to the “good enough” boundary. Finding that “good enough” boundary is critical to any effective strategic laziness plan.
We see this pragmatic approach to “good enough” in many disciplines. In Site Reliability Engineering, there is a concept of “five Nines,” where a company aims to have 99.999% reliability. If applied to uptime, this means less than 5 minutes and 30 seconds of downtime per year. But at what cost? Is “four nines” good enough (52 minutes per year)? Or is it critical to have less than 3 seconds of downtime per year (seven nines)? What if each “nine” 10x the cost of operating your business, but each minute of downtime only lost 1 in 1000 customers per year? How would you define “good enough”?
The core takeaway
Know your thresholds on the level of effort. Define “good enough” and avoid putting more effort into things than you should. Ignoring this will cause a waste of your most precious resource: time.
Lazy Evaluation
Lazy evaluation is a deep topic, but in a simplified form, it’s a way of structuring work so that you only “do work” as needed. This is the opposite of how most programming languages work by default, which is based on a concept called eager evaluation. Lazy evaluation is beneficial to describe something like an infinite data structure.
For instance, instead of eagerly pre-calculating all even numbers from 2 to 18,446,744,073,709,551,614 for an unsigned 64-bit integer, we can lean on the lazy generator pattern to only return the next even number, just in time, like this:
| package main | |
| import "fmt" | |
| func nextEven() func() uint64 { | |
| var state uint64 | |
| return func() uint64 { | |
| state += 2 | |
| return state | |
| } | |
| } | |
| func main() { | |
| next := nextEven() | |
| for i := 0; i < 10; i++ { | |
| fmt.Println(next()) | |
| } | |
| } | |
| // OUTPUT: | |
| // 2 | |
| // 4 | |
| // 6 | |
| // 8 | |
| // 10 | |
| // 12 | |
| // 14 | |
| // 16 | |
| // 18 | |
| // 20 |
You can also see the working code in the go playground here: https://go.dev/play/p/5-TsGmjGz9D
Core takeaway
Laziness can be a handy pattern if appropriately structured. If you are too eager to get specific work done before it’s needed, you can waste precious time and resources on work that might never be required.
A real-world example
With these two concepts defined, it’s time to dive into how they can apply to time management. My strategy comes down to defining patterns in which I can lazily evaluate work when the time is right and I know when I pass the “good enough” threshold. This means that I should avoid “eager” evaluations of my work. I shouldn’t do any extra work before that work is needed.
Up to this point, things have been pretty abstract, so let’s look at a real-world example. I’m taking a project-based summer course.
I know that a new project comes out every two weeks.
I get instant feedback on my project submissions because it is a “capture the flag” style submission process with an auto-grader
Some projects come with bonus problems ranging from 2% to 10% bonus on the project.
With these constraints, let’s use Strategic Laziness to ensure I get an A in the class but minimize wasted effort.
Front-load effort in the class. Earlier in the semester, I didn’t know how challenging future projects would be, so we put the most effort up front until I got a feel for the level of effort. This includes bonus work. If bonus projects are available and time permits, default to performing these. Here I shoot for 100% or 100%+.
Keep a rolling calculation of minimum scores required to get an A in the class on future projects with the known value of existing projects.
As the semester progresses, learn from your previous attempts. Phase out bonus work overtime if bonus work is a time sink. (In my case, several of them were, so I skipped them)
Once the final project starts, calculate the minimum effort required to receive an A in the class. (In my case, I only needed a 39/100).
Spend no more than the average amount of time you’ve allotted for previous projects while meeting your “good enough” threshold.
(Note: If you find the material interesting and you have the time, and you want to shoot for a higher score, by all means, do that, but now you’ve left the realm of strategic laziness)
I hope this helps! If you find yourself time-constrained, I’d recommend giving this a try. It can be beneficial in framing level-of-effort to achieve desired outcomes.
Quick note: I thought I’d come up with the term Strategic Laziness, but boy, was I wrong. Here is a list of sites that explore the topic. We all dance around similar themes, but the methods and take-a-way vary slightly. These are worth checking out, though:
https://getitdoneblog.com/what-is-strategic-laziness-use-laziness-to-your-advantage/
https://time.com/5379422/why-being-lazy-is-actually-good-for-you/
This Week’s Notable Links
I’m off work this week, so I’ve got a few more links and youtube videos than usual, but these are all fun. I hope you enjoy them.
Names should be as short as possible while still being clear - Ben Hoyt
don’t name things to explain everything they do; name things so the meaning is clear in context
This is a short read full of wisdom. It captures how I aspire to name and structure my code as well.
How to think about `async`/`await` in Rust - Cliff L. Biffle
I’m not a rust programmer, but I am an of Inversion of Control and State Machines, and deep insights and framing on technical topics. So this checks a lot of boxes.
The Most Misunderstood Concept in Physics Veritasium
Fancy that. Veritasium posted a fantastic video on Entropy (in Physics) days after my post on Entropy (in Information Theory). I love how he always dives in deep into topics while keeping them approachable.
Building the Impossible | 100 Dart per Second Nerf Gun - Part 1 - 3DPrintedLife
Another great video from a channel that is new to me. I enjoyed the design and tinkering process required to get to 100 darts per second. Wild.
The coolest robot I’ve ever built - Workshop Nation
From another new channel to me. The production quality of the video and the creation process floored me. This is by far the coolest Alexa project I’ve ever seen. I love the mix of practical robotics, retro aesthetics, and modern tools.
Why Do Wes Anderson Movies Look Like That? - Thomas Flight
Before this video, I’d never heard of “planimetric composition.” I knew Wes Anderson’s style was iconic, but I didn’t have the vocabulary or framing to understand why before seeing this. Whether you love or hate Wes Anderson films, this video will help you articulate those feelings better.