Unix Philosophy as a Way of Life
April 20, 2025
One of the most quietly transformative experiences of my childhood didn't come from a book or a person — but from a machine. My new 2015 MacBook Air. At the time, I couldn’t quite pin what it was about that silver brick that felt so right, but everything just seemed to click. Everything behaved intuitively. There was a sense of underlying order, of clarity. Things worked not because they were flashy, but because they were well-constructed.
A little later, I'd stumble on the Bell System Technical Journal, and the key tenets of the Unix philosophy. A set of quiet, almost transcendental design principles rooted in simplicity, composability, and clarity — born decades ago, but still alive at the heart of the tools I use every day.
an excerpt from "The Unix Time-Sharing System"
It's been years since I made the switch to Unix — but it's only recently that I've started to see parallels between these software principles and my actual life.
So in the spirit of embracing being a total computer nerd, I'm going to try and document what I think, is the Unix Philosophy, as a way of life.
1. Do One Thing Well
“Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.”
We live in a world that celebrates breadth — the ability to jump between roles, skillsets, identities. In my opinion, you draw a lot admiration for your adaptability and fluency across contexts as a generalist. But while that surface flexibility may feel impressive, it always comes at the cost of depth. The “jack of all trades” tend to fade out in the long run; either from complete burnout, or from the late realization that they have to be really good at something.
At the other end of the spectrum you get specialists — people who go deep into one domain, carving out a narrow path and refining it to excellence. It's the Japanese chef perfecting the art of Tamagoyaki for 10 years. The artists who hand draw each panel of a Studio Ghibli film.
There’s a lot of value in work becoming a craft. You end up learning insights and building a muscle memory that only long, focused practice can reveal. But it can also become limiting. You might get stuck in the over-learning phase, and most of your day as a designer starts to turn into naming Figma layers. And in a world of AI, betting your entire defensibility on one thing feels like a risky bet.
So what does the Unix philosophy say? Try to become a "master of all trades” — not by spreading yourself thin, but by approaching one thing at a time with focused intentionality. This is the true wisdom of the Unix principle: you can just do many things. But counter-intuitively, it only works if you approach each one with the discipline to treat it as the only thing that matters.
I've been slowly trying to bring this into my own life — even though I spend most of my time writing code on servers, I actually started off as a UI designer. And who knows? Maybe in 10 years I'll be doing DCF valuations.
2. Expect the Output to Become an Input
“Expect the output of every program to become the input to another, as yet unknown, program.”
For some reason, we're told that all decisions carry a weight of finality. And so, we’re taught to optimize for immediate relevance — to only do things in service of the trajectory that you want to be on. You'll hear essentialists say that you should “only do the things the things that feel like an instant yes”.
And while I don't think that that advice isn’t wrong — I do think that it’s context-dependent. It's advice for a later stage of life, when you’ve already done the exploration and are optimizing for focus. But until I reach that point, I think the better strategy is to go in the complete opposite direction — and say yes to almost everything. To treat every project, every random thought, every seemingly unrelated detour as a building block — even if it makes no sense in the moment. Because you have to trust that it's going to be relevant and will make sense, even if only retrospectively.
Unix teaches you to design programs whose outputs can be reused in contexts not yet imagined. I'd argue that life works the same way. A few years ago, I spent a month teaching myself how to conduct quantitative analysis on public companies. It made absolutely no sense, and I ended up failing one of my CS exams over it — it was just something I had to do. Three years later, I ended up needing to fine-tune LLMs over financial statements, and I realized that that long-forgotten month was just a puzzle piece that was always waiting to click into place.
The point isn’t to predict the future utility of every choice — it’s to maybe have the blind faith that nothing you do is ever wasted.
3. Build to Rebuild
“Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.”
There’s a certain comfort in waiting until something feels perfect — in holding off on launching a project, sending a message, sharing a prototype. But that comfort is usually a trap.
In the Unix tradition, perfection isn't a prerequisite — it's an emergent property of iteration. You don’t get to excellence by planning your way there in isolation. You build something small, something slightly rough but functional. You watch how it breaks, how it surprises you, how others interact with it. You let people tell you that they love it — and some tell you that they hate it. And then you rebuild, a little better each time.
The goal isn't to minimize friction before launch — it's to embrace discomfort as part of the feedback loop. The faster you get real signals, the faster you get to something meaningful.
This isn’t about lowering standards. In fact, the opposite is true. The fastest path to high standards is to expose your work to reality, not to hide it away. If something doesn’t hold up, rebuild it. If it needs to be scrapped entirely, do it without ego. What matters isn’t preserving the original plan — it’s evolving toward what works.
4. Use Tools Over Unskilled Help
“Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.”
This one sounds pretty straightforward, but I think most people get lazy and miss out on the potential of automating away parts of their life. At its core, this principle is about the opportunity cost of your attention. Spending a week to save ~10 minutes a day pays off in 10 weeks — and keeps paying forever.
Relying on systems doesn't replace thinking — but protects it instead. They keep the low-leverage, repetitive parts of life at bay so that you can focus on the things that are actually important. There's a hidden cost to every repeated decision, every manual task, every hour spent on something that could be automated. The cost isn't just time — it's cognitive fragmentation. Every detour you avoid is energy you reclaim.
Sometimes, this means being willing to spend money to save time. If cooking dinner takes you three hours and leaves you drained, maybe that $20 salad is buying you more than just convenience — but focus.
You could map out my entire life between three Google Sheets, Superhuman, my iCloud account, and my Monarch subscription. Each of those pieces took me weeks to setup the first time – but I've never had to look at them again since.
...
The Unix philosophy isn't loud. It doesn’t draw attention to itself. It doesn’t try to be clever or aspirational. Instead, it just works.
Build simple things. Build with care. Stack them wisely. Let one thing lead to the next. Don’t cling too tightly to what doesn't work.
It's a way to write code. But more and more, I’ve started to find that it’s a way to live.