|
Hello,
In the previous email, I wrote about finding a practice that strengthens our sense of agency. Today, I want to leverage this sense of agency to build other capacities.
We live in a society built around ease, convenience, and instant gratification. We never need to be bored, uninterested, or unknowing - at the very least, our phones are always within close reach. Shipments feel torturously slow if they take longer than two days. And development teams are always seeking ways to "reduce friction" both internally and for customers, often treating friction as a pure cost to be reduced as much as possible.
There's nothing wrong with creating and enjoying ease and convenience. Unnecessary toil and inconvenience are not things to value. But ease is not pure gain, and there are tradeoffs worth exploring.
I have been thinking about the most common failure mode when working with a team to introduce new tools or processes: the unwillingness to stay with the initial difficulty. The expectation seems to be that there will be immediate benefit without cost - no learning curve, no initial awkwardness from working in a new way, no problems to address. When those appear, teams throw up their hands and give up, as if there's any way to do something new without rubbing against these difficulties!
- "I didn't expect to see so many static analysis warnings, we can't afford to fix them, we're just going to keep working without it."
- "Writing the test before the implementation feels weird, there's no way this works."
- "We added observability support, and now management wants to know why we're seeing a spike in crash-induced restarts. We need to be focusing on new features, this is setting us back."
The teams that get value from making these changes are the ones who treat the initial awkwardness as part of the work, not as evidence that it's the wrong move.
We see this even more starkly with AI tools. Used well, they are valuable force multipliers. But we have to wonder: what is lost from relying on these tools habitually? One person recently shared their concern, "I'm having trouble not going to Claude with every issue I need to debug." More surprising to me has been seeing experienced engineers freeze when their particular coding agent is down. Nobody starts using these tools expecting to find themselves in this "stuck" state. They were just supposed to eliminate the drudgery and make us more effective. But suddenly you see that you've weakened the capacities needed to work through a problem when stuck, and perhaps lack the confidence to find your own way.
Many years ago, I started playing a "game" with myself, which I might call a practice now. I noticed that, thanks to GPSes and smartphones, most of my friends and family no longer knew how to get around on their own. I didn't want this to happen to me, so I began driving, walking, and biking without a GPS. Verbal directions and cross streets were preferred; otherwise, I would look at the destination and proposed route before leaving. I quickly realized how strong my internal map already was (and how useful road signs are, if you actually read them!). I still had my phone in case of any real trouble navigating, but this was rarely needed. Soon my experiments grew bolder. I started to challenge myself by making a wrong turn or two and then finding my way back home, often making a pleasant discovery along the way.
These experiments really drove home a truth: our capacities decay without practice. What ease costs is incapacitation in the face of difficulty and discomfort. A welcome boon quickly becomes a habit, and eventually we find ourselves dependent.
How can we appreciate ease without becoming so dependent? One thought, rooted in my experiences with GPS, is to develop a counter-practice: something we do that offsets the effects of the prevailing current. We do not need to eschew ease completely, but we can invite friction into our lives. We can create opportunities for doing things the slower, less efficient way and staying with discomfort. Working through that discomfort, which the mind so desperately wants to escape, is where our capacities get built.
The capacity I value most is my ability to direct focus, to sustain attention on whatever I'm working on. This has become so difficult for me, and for so many others. The internet itself is a great source of distraction, but I wrestle most with my smartphone. They are technological marvels, and yet they have also reduced our capacities to be bored, to be uncomfortable, to be unstimulated - all of which reduce our ability to sustain attention on anything difficult. I have to go to great lengths to preserve and practice these capacities:
- I've configured my router to block sites that I check habitually
- My phone has no web browser, no social media, no email, no Discord, no Slack
- I keep my phone in a different area of the house
- I often turn off my phone - turning it on then adds a delay that gives me a chance to interrupt the impulse
Friction, here, also serves as an aid: by making it more difficult to access my phone (and other distractions), I can interrupt the habitual reaching and stick to what I'm actually trying to do. Not only can friction be a practice, it can also be the scaffolding that supports us in the moment of choice.
We have to be careful in choosing our counter-practices, because we're not trying to immiserate ourselves. Handwriting isn't just a slower, more tedious form of typing, for example. It gives us a physical artifact that our brain can engage with. It can provide an aesthetic experience, feeding our appreciation of materials, textures, colors, binding techniques, or the pleasant feel of a pen gliding across paper. The act of writing by hand forces us to prune and compress thoughts we're trying to capture and aids in memory formation.
Or consider debugging, torturous and tedious as it can be. Finding and correcting errors reveals holes in our mental models of the system, of subsystems, of libraries and services we integrate with, and of the hardware our code runs on. We have an opportunity to push our understanding into new parts of the software stack, new tools, and new techniques. Most importantly, debugging strengthens and refines our theory of the system. We run up against how the system actually works, not just how we imagined it works. These capacities are immensely important for developing and maintaining any system, and as several of us are experiencing, they are easily lost.
Agency is the capacity that allows us to choose friction over ease. Friction is one of the practices required for strengthening our agency. Look for ways to introduce friction that build capacities in the ways you want: handwriting → memory, meditation → attention, navigation without GPS → spatial reasoning. Sometimes, it's the inefficiency and voluntary slowness itself that is the practice, as we train ourselves to tolerate our annoyance and desire for the easier version.
As with the phone example, we shouldn't look at it only as "just do the harder version of the thing." We might also view it as resisting the habitual patterns we want to change. Often, this looks like stopping, interrupting, and resisting. We can find ways to break the loop of reaching for the phone, heading straight to the AI agent, or speaking that cutting riposte aloud. We can assert agency over an impulse rather than being moved by it. I know that I, at least, could use more impulse control.
I invite you to reflect on your own life: do you have practices like mine? Could you benefit from a practice that incorporates friction, training your ability to stay with discomfort? If so, I encourage you to pick a single area where you'll keep friction this week.
Whatever we water will grow, whatever we avoid watering will wither, and this applies as well in our mind as in the garden.
In the next email in this series, I'll share my thoughts on one of the great traps: competing with machines on their terms.
Until then,
Phillip
|