A couple of years ago I wrote a run of pieces with titles like “Screw the 9-to-5” and “If You Work a 9-5, Read This.” The argument was that no single employer should hold your future. Companies cut people who gave them twenty years. Loyalty runs in one direction. Build something of your own, own your career, and don’t hand the keys to anyone holding a budget spreadsheet.
I still stand by that.
But those pieces only covered half of it. They were about what a job can take from you. They never got around to what it gives you. And the longer I sit in my current role, the more I think the second half matters just as much.
Jack of all trades
For most of my career I worked in consulting and marketing. Every few months, a new client. A new industry. A new set of requirements somebody else had already figured out, handed to me as a spec. I built the thing, shipped it, and moved on.
I got good at the craft. I wrote once about mastering one path instead of being average at ten, and coding was that path for me. But when it came to what the software was actually for, I was a jack of all trades and master of none. I could build what you asked for. I didn’t deeply understand any of the businesses I built it for. I never stayed long enough to.
About a year and a half ago I moved into fintech. For the first time in a long time, I’m learning a domain.
What a domain actually is
Technical knowledge tells you how to build something. Domain knowledge tells you why it has to work the way it does.
It’s the business rules. The regulations. The reasons a process exists that nobody wrote down, because everyone who needed to know already knew. It’s how the technology lines up with the industry it serves, which is a different thing from the technology itself.
In consulting, the spec was the end of the question. In a domain, the spec is the start of one. Why is this check here? Why does this have to happen in this order? Why can’t we just skip that step?
Early on, a lot of it looks like friction. A validation that seems redundant. A process that seems slower than it needs to be. A rule that feels like bureaucracy for its own sake. Then you learn what it’s protecting, and you can’t unsee it. The rule that looked pointless turns out to be the reason someone’s money ends up where it’s supposed to.
That shift doesn’t come from a tutorial. It doesn’t come from a side project either, because a side project has no regulators, no history, and nobody depending on it getting the rules right. It comes from time spent inside somebody else’s real problem.
The philosopher on the farm
Musonius Rufus taught Stoicism in Rome in the first century. He was Epictetus’s teacher, and he was exiled more than once. One of his surviving lectures asks a practical question: what’s the right way for a philosopher to earn a living?
His answer was farming. Ploughing, planting, pruning, harvesting. Work with your own hands, for your own living. He thought it was more fitting than living off other people, and he gave a blunt reason: “not to require another’s help for one’s need is more dignified than asking for it.”
Then he took on the obvious objection, that real philosophy and manual labor don’t mix, and dismissed it: “let no one say that farming is an obstacle to learning or to teaching the lessons of duty.” He went further. He thought young people would learn more by watching their teacher work the fields than by listening to him lecture in the city.
The farm wasn’t the price Musonius paid so he could afford to do philosophy somewhere else. It was where the philosophy happened.
And a farmer doesn’t just know how to plough. He knows the land. Which field floods, what the soil will take, why the people who worked it before him did things in that order. Nobody lectures that into you. You learn it by staying.
That’s the difference between technique and understanding. The job is where you get the second one.
Load-bearing or leftover
Knowing the domain is what lets you tell which rules are load-bearing and which are leftovers. A strong developer with no domain knowledge can’t make that call. They’ll either treat every rule as sacred and build something rigid, or treat every rule as friction and build something dangerous. From the outside, both look like competence.
That judgment is what the day job is quietly handing you. You can’t pick it up on a weekend.
Still don’t depend on them
None of this changes what I wrote two years ago.
The company doesn’t love you. It can still drop you any Tuesday for reasons that have nothing to do with your work. Build your own thing if you want to. Own your career, because nobody else will.
But owning your career doesn’t mean writing off the forty hours. That’s the part I skipped. I spent a lot of words on depending on the job less, and none on what I should be taking from it while I’m there. Musonius never thought the field got in the way of the philosophy. The field was where he did it.
The stack you use at work is rented. So is the title. The employer decides both. What you understand about how an entire industry works, why its rules exist, what they protect, where the technology serves it and where it gets in the way, leaves with you. Of everything a job hands you, that might be the most portable thing there is.
Taking control of your career includes taking that seriously. While you’re there, don’t just close the tickets. Learn the land.
👉 If you enjoy reading this post, feel free to share it with friends!
Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏
You can find me on X and Instagram.