I've been fixing things since long before I wrote code.

I was born in the Caribbean and grew up on the island of Montserrat. My relationship with technology started there, long before I wrote my first line of C#.

Walking home from school, I'd find televisions, stereos, and other electronics that people had thrown out because they stopped working. Where other people saw something broken, I saw something I wanted to understand. I'd take it home, open it up, figure out what was wrong, fix it when I could, and bring it back to its owner working.

When I was nine, I came across DOS and Where in the World Is Carmen Sandiego? What started as a fascination with the game quickly turned into a fascination with the machine running it. That set a pattern I still follow: understand how it works, find out why it doesn't, then figure out how to make it work better.

From desktop support to architecture

That curiosity carried me through desktop support, systems administration, and infrastructure before I moved into professional software development in 2010. I'm glad I came in that way. Supporting systems before building them teaches you how software actually behaves once it leaves a developer's machine.

From there my work grew through C# and .NET, ASP.NET MVC, mobile development, web applications, APIs, databases, enterprise systems, distributed architectures, DevOps, technical leadership, and eventually software architecture. Over the years I've designed, built, maintained, modernized, or contributed to hundreds of applications. Back in the Windows Phone days, one of my apps was named an App of the Month, which was an early milestone in a career that moved from building individual apps to designing complex enterprise systems.

These days most of my work is designing .NET systems with Domain-Driven Design and Clean Architecture, which is the approach my new book, Practical Domain-Driven Design with .NET, teaches. My first book, C# Cheat Sheet: The Keywords, is a short reference to the keywords C# is built from, for people learning the language. I also build products of my own, like CashAscent, a personal finance app.

How I think about software

I don't like complexity for the sake of complexity. If there's a simpler design that keeps the architecture honest, I'll usually take it. What I care about is software that another developer can understand six months from now: boundaries that mean something, business rules that live in one place, and decisions with a reason behind them.

I'm also practical about it. Architectural purity is nice, but not if it makes the software harder to build or maintain. So when I look at a design, the questions I keep asking are simple ones. Do we really need another abstraction here? What does it actually buy us? And what happens when somebody else has to change this?

The systems got more complex. The tools got better. The problems got bigger. The instinct to understand them and solve them never changed.