How I Apply Engineering Thinking to Everything I Own

I'm packing for my first international trip. Web Summit Qatar. A week abroad, conferences, meetings, new environments.

Most people would stress about this. What to bring? What if I forget something? Do I need backup chargers, extra shoes, different outfits for different occasions?

I'm not stressed.

Not because I'm experienced at travel, I'm not. But because I realized, while laying out what I'd bring, that I've been unconsciously preparing for this moment for years. Not by buying travel gear. By developing a system for how I decide what deserves space in my life at all.

The same way I think about code, I've started thinking about everything I own.

Why Minimalism Failed Me

I tried minimalism. The whole thing, getting rid of stuff, living with less, the aesthetic of empty spaces and clean surfaces.

It didn't last.

Here's what happened: I'd remove something, feel good about it, then a few weeks later find myself needing exactly that thing. A cable I threw away. A tool I donated. I'd end up rebuying or borrowing or improvising.

Digital minimalism was worse. I deleted apps to "simplify." Then reinstalled them because I actually needed them for work, communication, specific tasks. The cycle felt pointless.

The problem with minimalism, as I experienced it, is that it treats subtraction as the goal. But we don't live in isolation. We have jobs. Environments. Responsibilities. People depending on us. You can't just remove things and expect life to adapt.

What I needed wasn't fewer things. I needed a better system for deciding what stays.

That's the difference between minimalism and essentialism.

Minimalism asks: Can I live without this?

Essentialism asks: Does this earn its place?

One is about deprivation. The other is about intention.

Engineering Principles, Applied to Life

I'm an engineer. A tech lead. I spend my days thinking about systems, how to make code maintainable, how to reduce complexity, how to build things that don't break when requirements change.

At some point, I started noticing that the same principles that make software good can make life decisions clearer.

Here's the framework I've built, principle by principle.

DRY: Don't Repeat Yourself

In code, DRY means you don't write the same logic twice. You abstract it, reuse it, solve it once.

Applied to ownership: solve each category once.

I don't want to keep deciding which watch to wear. I want one watch that works with everything, casual, professional, travel, whatever. The category is closed. Decision made. I move on.

Same with a bag. Same with how I organize cables.

Every time I catch myself re-deciding something I've already decided, I know the system is broken somewhere.

Modularity

Good code is modular. Components work independently but combine well. You can swap one part without breaking everything else.

Applied to ownership: each item should work across contexts, not be tightly coupled to one specific scenario.

If I buy a jacket that only works with one outfit, that's bad modularity. If I buy a watch that only fits casual settings, that's coupling I don't want.

The Casio G-Shock GA-2100 passes this test. It works with a t-shirt. It works dressed up. It's water-resistant. The design is clean enough to not clash with anything, bold enough to have presence. And the community around it, people swapping bands, adding kits, creating new looks, means the same watch can evolve without buying a new one. That's modularity.

Single Source of Truth

In a codebase, you don't want the same data stored in multiple places. It creates sync issues, confusion, bugs.

Applied to ownership: consolidate.

All my cables, chargers, and small tech live in one pouch. When I travel, I grab the pouch. When I'm home, I know where everything is. One source of truth.

My MacBook Pro is the single source of truth for work. I don't split tasks across devices hoping they'll sync. Everything happens in one place. Yes, it was expensive. But the return on investment over years of daily use makes it one of the most justifiable purchases I've made. Sometimes the essential thing is the premium thing, when it genuinely earns its place.

Hire and Fire: The Employee Principle

This is the core principle. I read it somewhere years ago and it stuck.

Treat every product like an employee. You hire it to do a specific job. After a few months, you evaluate. Did it do what you hired it for?

If yes, it stays.

If no, you fire it. Sell it, give it away, let it go. No guilt.

This reframing changes everything. It removes the emotional weight from getting rid of things. It's not about whether you like something or whether it was expensive. It's a performance review. Did it deliver?

The Apple USB-C EarPods passed this test. I hired them to replace wireless earbuds that needed charging, pairing, and maintenance. Job description: plug in and work. Good sound. Good mic for calls. No friction.

They do exactly that. No charging. No Bluetooth pairing failures. Type-C into my MacBook or phone, done. They stay.

Research Before You Hire

You wouldn't hire an employee without checking their background. Same with products.

I've started using AI for this, genuinely. When I need something, I describe the job to be done, my constraints, my context, and let it research options, compare reviews, surface things I wouldn't have found.

Recently I needed a sunscreen. Not a random one, something that fits my skin type, available locally, good protection without the white cast. AI helped me narrow it down faster than hours of scrolling reviews.

Same with a hair clipper. The new ones needs replacement blades every few months. AI searched, couldn't find the replacement blades available in my country, then pivoted: helped me find the best budget option from a reliable brand, one that'll last five years minimum. The kind of research I would have abandoned halfway through, it handled.

I trust this process more than my own impulse decisions now. Not blindly, I still verify. But the research phase is no longer something I skip or half-do.

Community and Maintainability

When choosing a library or framework, I look at the community. Is it active? Will it be maintained? Can I extend it if needed?

Same logic applies to products.

The G-Shock community is a good example. People don't just buy the watch, they modify it, share band combinations, create accessories. A product with that kind of ecosystem stays relevant longer. You're not stuck with what you bought; you can evolve it.

For apps, I lean toward open source when possible. Obsidian, for example. The plugin ecosystem means developers keep adding features, and if the core team ever stopped, the community could carry it forward. That's maintainability.

I'd rather own something with a living community than something polished but abandoned.

Build Quality Over Surface Polish

You don't judge code by how pretty the syntax looks. You judge it by whether it runs reliably, handles edge cases, doesn't break under pressure.

Same with products. I don't care about premium materials for their own sake. I care about build quality.

Plastic over glass? Fine, if it's durable. A brand I've never heard of? Fine, if reviews confirm it lasts. The goal is function that holds up over time, not aesthetics that impress for a week.

The Failure That Taught Me

Not every hire works out.

I bought an iPad Air. The job description was clear: take online meetings away from my desk, sketch ideas visually, take notes more fluidly than typing allows.

Sounds reasonable.

The performance review, a few months later: I kept reaching for the MacBook. Every time. Meetings happened at my desk anyway. Notes ended up in markdown files or on sticky notes, not in some elegant iPad app.

The iPad sat there. Fully functional. Nice to have. Never essential.

I'm selling it.

This isn't a criticism of the iPad. It's a good product. It just didn't do the job I hired it for. And that's the point, this system removes guilt from letting go. You're not admitting you made a mistake. You're just acknowledging that a hire didn't work out. It happens. You move on.

What "Always Ready" Actually Means

The goal of all this isn't to own less for the sake of owning less.

It's to reach a state where you're always ready.

Ready for a trip, not because you packed last night, but because the decisions were made months ago. Ready for a meeting, an opportunity, a change. Not scrambling to prepare, but already prepared by default.

Engineers call this reducing deployment friction. The less setup required, the faster you ship.

Life works the same way. The fewer daily decisions about what to wear, what to bring, what to use, the more mental energy left for things that actually matter.

I'm packing for a week abroad, and it feels like nothing. Not because I'm naturally organized. Because decisions were already made.

That's the payoff.

Still Iterating

I'm not going to pretend this system is finished.

Clothes are still a mess. I have a general direction, neutral colors, versatile pieces, quality basics, but I haven't systematized it the way I have with tech and accessories.

My toiletries kit is still in progress. Every trip I tweak something. Haven't landed on the final setup yet.

But that's the point. Essentialism isn't a destination. It's continuous refactoring. You ship what works, learn from what doesn't, and improve over time.

The system doesn't need to be perfect. It needs to be better than no system at all.

Closing

The same thinking that makes code maintainable can make life lighter.

DRY. Modularity. Single source of truth. Hire and fire. Research before committing. Community matters. Build quality over polish.

These aren't just engineering principles. They're decision-making principles. And once you start applying them outside of code, you stop drowning in choices about things that shouldn't require choices.

Solve once. Evaluate honestly. Keep what earns its place.

That's it. That's the system.