Three people I respect — Derek Sivers, Seth Godin, Martha Beck — recently shared their approaches to simplifying life on Tim Ferriss's podcast. Different backgrounds, different methods, but a shared insight: remove what doesn't serve you, and what remains can flourish.
As I listened, I kept translating their ideas into software terms. Not to be clever, but because the software metaphors makes sense for me — and I dare say, more actionable. And it made me wonder: maybe the language of thoughtful software design is one of the best frameworks we have for thinking about intentional life.
Default States
Seth Godin talks about "telling the same story to everyone" and having non-negotiable boundaries around how he works. His speaking rider is specific; he uses the same tech setup; no exceptions.
In software, we'd call this designing your default state. The configuration that loads before any user input. Most people never change defaults, so good designers obsess over getting them right. Your life has defaults too. What you do when you're not actively deciding. The route to work, the apps you check first, how you spend Saturday morning when nothing's planned. Most of us never consciously design these defaults. We let them emerge from accumulated small choices. But defaults compound. The morning routine that starts with checking email leads to different days than the one that starts with writing.
Godin's rigid speaker requirements aren't inflexibility — they're intentional defaults. By refusing to negotiate the setup each time, he eliminates decision fatigue and protects the energy he needs for the actual talk.
The software/life-as-user-experience question: What's your default state? If someone observed your unplanned hours, what would they conclude you value? And if you were designing those defaults intentionally, what would you change?
Dependencies and Coupling
Derek Sivers opens with something every programmer recognizes: "Life is complex when it is intertwined with dependencies. You are depending on things and things are depending on you."
In code, we talk about "coupling" — how tightly connected different parts of a system are. Tight coupling means changing one thing breaks five other things. Loose coupling means components can change independently.
Sivers has systematically reduced his life's coupling. No subscriptions, no employees, no mortgage, no contracts. Each eliminated dependency is one less thing that breaks when circumstances change. His programming example is perfect: no external libraries. If something matters, he codes it himself. "It's harder up front to make what I need, but long term it makes everything objectively simpler, easier to understand, maintain, and change."
This is the Unix philosophy applied to life. Small, focused tools that do one thing well, loosely connected. Instead of one complex system that handles everything but breaks catastrophically, many simple components that can be swapped, upgraded, or removed independently.
The life-as-user-experience question: What are your tightest couplings? The dependencies that would cause cascading failures if they changed? Are they worth the complexity they create?
Feature Deprecation
Martha Beck describes releasing everything that "wasn't working" — culture, family, marriage, career, identity. The framing is emotional: following joy, trusting her deepest knowing. —There's a software parallel that makes this more concrete: feature deprecation.
In development, deprecation means announcing that a feature is sunsetting. Not deleting immediately, but signaling: this served its purpose, it's no longer supported, please transition to alternatives. Then, gradually, removing it. We deprecate features not because they're bad. Often they were brilliant once. But circumstances changed. User needs evolved. Better solutions emerged. The maintenance cost now exceeds the value provided.
Lives work the same way. The friendship that was meaningful but has run its course. The career identity that fit perfectly but you've outgrown. The morning routine that served you well and now creates friction instead of flow.
Beck's "follow joy away from what doesn't work" is deprecation — releasing what has completed its purpose. But the software framing adds something: it doesn't have to be dramatic. Deprecation is gradual. You announce the sunset, give transition time, make space for what comes next. Not abrupt deletion, but conscious completion.
The Norwegian phrase works here too: "takk for nå." Thanks for now. This was good, and now it's over.
The software/life-as-user-experience question: What in your life might be ready for deprecation? Not because it failed, but because it's complete?
Constraints as Liberation
All three guests circle around constraint as positive force. Sivers: "No by default, reluctant yes only when proven necessary." Godin: "Budgets and deadlines — when you run out, you're done." Beck: the constraint of following only genuine joy, not dopamine hits.
In software development we might learn this lesson through experience: Projects that fail aren't usually under-resourced — they're over-scoped. They try to do everything and end up doing nothing well.
Godin's example is telling: he decided in business school to never do spreadsheets. If a professor asked for numerical analysis, he'd simply say he didn't have one. The constraint forced him to become exceptional at the qualitative analysis instead. —«By simplifying the way I do one thing, I open the door to make other things richer, deeper, and more complicated."
Every "yes" contains hidden "no"s. Every feature added is cognitive load for users. Every commitment accepted is time unavailable for other commitments. Constraint isn't about having less — it's about having focus.
The life-as-user-experience question: What constraint would eliminate the most friction from your life? What would you need to say no to so that your yes could mean more?
Maintenance Mode
There's something the Tim Ferriss guests don't emphasize: systems need maintenance, and sometimes the right move is maintenance mode rather than expansion. In software, maintenance isn't failure to grow. It's sustained attention — keeping things working without demanding they also improve. Bug fixes, security patches, compatibility updates. The craft of upkeep.
Life systems need this too. The relationship that's working well and doesn't need to become something more. The career that provides what you need and doesn't require constant advancement. The routine that serves its purpose without requiring optimization.
The Norwegian word "vedlikehold" captures it: maintenance as craft. Not decline, not stagnation — appropriate tending of what already works.
Sometimes the most intentional choice is to stop improving and start maintaining. To let something be good enough and redirect the energy that would go to optimization toward something else entirely.
The life-as-user-experience question: What in your life is ready for maintenance mode? What could you stop trying to improve?
Versioning and Seasons
The Tim Ferriss guests describe their simplified lives as destinations. They've arrived at structures that work. But life has versions. What you needed at 28 might probably not serve at 42. The system that worked beautifully for eight months might feel forced by month nine. Circumstances change, and systems need to change with them.
Good software has version numbers. v1.0 becomes v1.1 becomes v2.0. Each version is complete for its moment, but none is final. The expectation of change is built in.
Life works this way too. Your morning routine has versions. Your social rhythms have versions. Your relationship to work has versions. The skill isn't finding the permanent right answer — it's building systems that can update gracefully when the current version no longer fits.
In Norway, we understand seasons deeply. When winter days have four hours of light, you don't pretend it's summer. You adjust. Different expectations, different rhythms, different ways of being. The same applies to life's metaphorical seasons. Expansion seasons and conservation seasons. Building seasons and recovery seasons. Social seasons and solitary seasons.
The life-as-user-experience question: What version of your life are you in? And what would the next version need to change?
The Integrated View
What software thinking adds to these three's simplification advice isn't just vocabulary. It's a particular stance: systems can be designed, defaults can be chosen, constraints can be embraced, features can be deprecated, versions can be updated.
This is more actionable than "follow your joy" or "simplify your life." It gives you specific things to examine:
- What are your default states?
- What dependencies create fragility?
- What's ready for deprecation?
- What constraints would create focus?
- What deserves maintenance rather than improvement?
- What version are you in, and what does the next version need?
None of this makes simplification easy. The software metaphors don't eliminate the hard work of actually changing your life. But they might make the work clearer.
Design your defaults intentionally. Reduce coupling where you can. Deprecate what's complete. Embrace constraints that create focus. Know when to maintain rather than expand. Expect versions to change.
Not revolutionary advice. But maybe useful advice, in a language that makes it concrete.
Making It Practical
If this framing resonates, I've spent a lot of time developing it further. Life as User Experience is my attempt to fully explore what software thinking offers to intentional living — not as gimmick or forced metaphor, but as genuinely useful design language.
The book includes a companion workbook with exercises that make these concepts concrete:
- Default state audits: What happens in your first hour after waking? Your last hour before sleep? What would you design instead?
- Dependency mapping: What are your tightest couplings? What would cascade-fail if circumstances changed?
- Deprecation worksheets: What relationships, identities, or practices might be complete? What would "takk for nå" look like for each?
- Seasonal check-ins: What season are you in? What does it need? What are you trying to force that doesn't fit?
- Version tracking: What version of yourself are you in right now? What's different from last version? What's ready to iterate?
The workbook isn't meant to be completed once. It's designed for ongoing use — during transitions, when systems stop working, at seasonal changes, after failures. The same way good software gets regular maintenance, not just initial deployment.
Because here's what I believe: the insights from Sivers, Godin, and Beck aren't wrong. They're just not complete without a framework for actually implementing them. "Simplify your life" is direction. "Audit your default states, map your dependencies, identify what's ready for deprecation" is actionable.
The software metaphors aren't the point. The point is living more intentionally. But sometimes the right language makes the work possible.
The best software is thoughtfully constrained, intentionally defaulted, loosely coupled, and designed to evolve. Maybe the best lives are too.