About Hossein

Some careers have a clear shape. This one has a recurring argument instead, between the technical and the human, between what systems do and what they do to people. The timeline below traces a path through this journey.

Last century

I learned to program in high school because it was fun and, more importantly, I could make money with it. Small gigs, whatever was around. The lesson I didn’t know I was learning was a quieter one: the thing you do to pay for the rest of your life sometimes turns out to be the rest of your life.

Early 2000s — The Scramble

C++, Java, Python, R, even PHP and Delphi. Web, desktop, device drivers, scientific tools. Whatever job was around and paid better, I took it. These were my university years, and I learned more from that scramble than from anything else in those years. The most important thing I learned was that “knowing a language” is the least interesting part of writing software. The real difficulty starts the moment someone else has to use what you made.

2004 — Briefly, a Statistician

I graduated with a BSc in Statistics from the National University of Iran and took a job as a statistician at a dairy company, designing and analyzing experiments and quality-control trials. It was a perfectly good job. In a funny way, it was the only job I’ve ever held that I was actually trained for. Programming was more interesting, so I left.

2005 — First Real Software Job

I joined a small software firm in Tehran building enterprise applications. This is where I learned what software engineering actually is, as opposed to just writing code. Methodology, design, and the gap between a working program and a “system” an organization can run. I figured out the hard way, the way you have to, that the difficult part isn’t producing the software. It is fitting it into an organization that already has its own gravity, its own habits, its own ways of failing. UX and iteration matter more than cleverness, and most design elegance dies on contact with the people who have to operate it.

Alas, the company didn’t survive Iran’s economic turbulence. Some of the people I worked with there are still some of the people I most respect and cherish. And one very dear to me isn’t here anymore.

2009 — Building for Other Builders

Caspian, a medium-sized software company backed by a big private banks, had set out to write a banking solution from scratch. It went badly over time and budget as these projects often do. But for me it was a formative experience.

I was on the platform team, building the infrastructure and tooling that tens of other developers depended on. Architecture stopped being just a word and became a daily problem: every decision I made constrained or enabled tens of people downstream. Non-functional requirements in particular security, latency, throughput, turned out to be where the real arguments happened, because that’s where the trade-offs between competing concerns are most honest. Almost everything I genuinely know about enterprise architecture and developer tooling, I learned in those rooms.

2009 — The PhD, a Long Detour

In parallel, I started a PhD. I’d fallen hard for the critical theory of Frankfurt School, and I wrote on how recommendation systems reinforce political discourse, how the systems we’d built to give people what they wanted were quietly remaking what wanting itself looked like.

I wish I had pushed that work further. In the years since, it has become embarrassingly obvious that this is one of the defining problems of our time, that the algorithmic mediation of public life is a real threat to human judgment. But the conditions in Iran, political and economic, were not generous to the project, and I made my peace with leaving it unfinished. I still think about it almost every day.

2014 — The Doorway to DevOps

I took a non-academic position at the University of Melbourne, with a team building scientific and research applications — data-intensive, computationally expensive, often genuinely beautiful, usually held together with string and good intentions. My job was to deploy and operate them across whatever platforms and clouds that one could imagine.

This was my unplanned transition from development to operations, and the doorway into DevOps. Academic software is its own particular ecosystem: every project has its own theology, no two teams agree on what “done” means, and the most important work is often the work of bringing a little order without flattening the curiosity that made the project worth doing in the first place. I spent those years learning how to do that, and mostly failing in interesting ways.

2018 — Doing Software the GitLab Way

I joined GitLab a few weeks after my daughter was born. Everything I chose after that was, in one way or another, downstream of her. Among other things, GitLab has given me a way of working that I came to genuinely believe in. Iteration over perfection. Dogfooding everything. Async-first, with writing as the primary medium of thought. This is how the work is actually done in GitLab which was a strange and demanding experiment for me, like building a railroad while riding the train. After many years, I still don’t think there is a better metaphor for what it actually feels like.

The ground that we stood on has moved across that time, from platform engineering into AI-powered automation and the half-formed discipline of building agentic systems. What’s interesting is that this latest turn has brought me back to the questions I’ve cared about for the longest, the human ones.