Software Engineer · Dublin
I’m Majed, with more than a decade of experience in backend and distributed software engineering. I currently work at AWS Dublin in the networking domain.
I believe two essential traits of good software are reliability and maintainability. My journey began as a self-taught engineer without a strong engineering background. Through sheer conviction and years of hard work, I learned a great deal about this domain. I have strong opinions, loosely held.
Please refrain from making false assumptions about system design skills by reading and solving random design problems.
In reality, designing even a small feature in any enterprise product is significantly more complex, and the hardest part is not always the technology.
A poorly written greenfield will always be a painful legacy system.
In the end, we are all dying. The same applies to software systems. But what matters is how well we lived and served our purpose.
Software systems don’t die naturally, we have to kill them when they become too hard to manage. We usually judge software by uptime or speed. But I think there is another important metric:
How the software treated its creators.
Generally, the term “legacy” implies wisdom, something to learn from. But in our industry, “legacy” scares developers. It implies pain. It shouldn’t be this way.
Imagine coding is a journey with no map. With every step and shortcut you take, you leave footprints. Later, you (or a new developer) have to walk that path again.
If you hacked through the jungle, the path is painful to walk. If you built a road, the next revisit is easier.
We need to stop viewing “Legacy” as a bad word and start viewing it as the goal. The goal of designing a system is to eventually become a good legacy system. One defined by value, not by the fear of making a small change.
The quality of a software system converges to the average skill of everyone who touched it. And now with AI, everyone is producing more code than ever. The average is about to shift fast in which direction, it depends.
Semantics play an important role in your system domain. There are commonly used industry wide terms those we mostly refer to when writing HLD and LLD like consumer, backpressure, and idempotency but then there are ones specific to your system.
We should always invent them and align the team on what they mean. This is similar to what DDD calls “Ubiquitous Language” that is a shared vocabulary that everyone on the team uses consistently. They help the team move fast and handle ambiguity faster. A good system is a collection of well defined local semantics.
It already replaced the part of my job I don’t miss, the hours spent on boilerplate and glue code.
What’s left is the interesting part. Understanding the actual problem, making trade-offs based on business constraints, and designing systems. No AI model does that yet.
We’ll write far more software now. That means we need more people who understand what good software looks like, not fewer. The feedback loop between human judgment and AI output is where the real work is shifting.
I’m not worried. I’m more productive than I’ve ever been.