I build distributed systems that are meant to last.

Good software is mostly about clarity. Clear boundaries, clear intent, clear ownership. I've spent enough time in broken codebases to know the opposite is expensive. When the code doesn't reflect how the business actually works, you patch the gap forever. Domain-Driven Design isn't methodology theatre to me. It's the most honest answer I've found to the problem of keeping systems understandable as they grow.

That's not a new idea. But it matters more than most people think, and I've built my approach to architecture around it. CPSA-F certification confirmed what I already knew from practice, but it also sharpened how I think and talk about it. System boundaries need to match business boundaries. Services need names that the business understands. Code needs to say what it does without requiring a wiki.

I use AI-assisted development daily. I've introduced tools like Junie and GitHub Copilot into teams as part of their everyday workflow, working within whatever organisational rules applied around data handling and tooling governance. In practice that meant Spring Boot and Kotlin codebases, using Junie for code generation and review cycles, and Claude Code for heavier refactoring and exploratory work.

Twelve years in and I still find the hard problems interesting. Moving between Java and Kotlin. Monoliths to bounded contexts. Build systems that teams can safely evolve. Make the implicit explicit. Raise the bar quietly.

I got into software engineering because I love building things. The same instinct that made me take apart toys as a kid eventually led to Computer Science and then to a career where I get to design systems from scratch, make hard decisions, and watch them hold up under real load.

Java was my first professional language. I started using it during my early college years, it shaped how I think about type safety, verbosity as clarity, and the JVM as a long-term investment. Over time Kotlin became my second language, not because Java isn't good, but because Kotlin removes friction without hiding the model. I've been building production systems in both for over a decade and they still interest me.

Starting my career at a startup exposed me to the full cycle. Requirements to customer training. That foundation shaped how I think about ownership and delivery. From there I moved through individual contributor work to focusing on technical impact, from single-team work to cross-domain architecture, from building features to building the conditions that let teams build well.

Egypt to the Netherlands in 2018 was a turning point. Work scaled differently at Bol.. High-availability systems and event-driven architecture at scale is a different discipline. The consulting model sharpened how I onboard fast, earn trust in unfamiliar codebases, and build connections with teams quickly.

Language-wise, I'm native Arabic, fluent in English (my working language for the past decade), and learning Dutch since moving to the Netherlands. Most of my writing and thinking happens in English. I write about engineering because writing clarifies thinking.

Curious about how AI-assisted development fits into real workflows, not the hype. I believe good architecture is mostly about clarity and honesty. The rest follows.