About me

I’m Mehdi Ahmadirad, a software engineer. Much of my experience has been shaped by building and evolving enterprise systems, working with software and infrastructure teams, and dealing with the kinds of problems that tend to appear only after a system has outgrown its first, simpler version.

What I work on

Over the years I’ve worked across software architecture and development, infrastructure and DevOps, system reliability and performance, technical leadership, and more recently AI and agent-based development tools. Part of my work is also concerned with development processes and governance, where the problem is no longer just code. Decisions, architecture, documentation, teams, and the system that eventually gets built need to remain meaningfully connected.

I mention these mostly as context for the writing here, not as a compressed résumé. LinkedIn is better suited for the complete professional chronology.

What matters to me in engineering

I enjoy technology itself, but I’m usually more interested in the reasoning behind a choice. Why was a system designed this way? What assumptions support the decision? What might fail as the system grows or as its environment changes? Are we even solving the right problem?

So when I look at a solution, I rarely stop at “how do we implement this?” I also want to know why this approach was chosen, what alternatives existed, what hidden cost comes with the decision, and whether the same choice will still make sense under different conditions.

That way of working can make things slower. Engineering, despite what architecture diagrams occasionally suggest, is not made entirely of tidy rectangles and well-behaved arrows. A large part of the job is understanding the forces, constraints, and trade-offs hidden behind those rectangles.

What I write about here

This blog is mainly about software architecture, systems engineering, software development, AI, development tools, and the lessons that come from building and maintaining real systems.

I don’t want it to be strictly technical, though. I’m also interested in books, history, culture, and self-understanding, and sometimes a technical question naturally leads somewhere more human. That connection doesn’t feel artificial to me. Technology is built by people, for people, and technical decisions are often shaped more than we admit by the way we think, collaborate, and make mistakes.

The posts here are not meant to be a collection of final answers. They are closer to an attempt to frame problems more clearly, record what I’ve learned, and distinguish between what I know, what I infer from experience, and what I’m still uncertain about. Some of those views will naturally change over time.

Outside engineering

Reading is an important part of my life, and my curiosity doesn’t stay inside very clear boundaries. I may move from a software architecture problem to history, from history to a question about people, and eventually return to engineering from a different angle.

That is probably why I don’t see engineering only as a profession. It is also, to some extent, a way of looking at problems: identifying parts, relationships, assumptions, and constraints, then accepting the mildly inconvenient fact that there is almost always something important we haven’t noticed yet.

Contact

For technical work and public projects, you can find me on GitHub. My professional background and work contact details are available on LinkedIn.