The DNA of Exceptional Software Engineers (Part 1)
Over the years, I’ve been fortunate to work on software used by banks and fintech companies. Along the way, I’ve helped solve production issues that kept entire teams awake at night, designed new systems, reviewed countless pull requests, mentored engineers, and like everyone else in this profession, made plenty of mistakes.
Some projects succeeded beyond my expectations. Others taught me lessons I could never have learned from a book.
Recently, I took some time to reflect on my journey, not on the programming languages I’ve learned, the frameworks I’ve used, or even the projects I’ve delivered. Instead, I asked myself a much simpler question:
What has actually made the biggest difference in my growth as a software engineer?
As I thought about it, something interesting became clear. The moments I’m most proud of weren’t possible simply because I knew Java, Spring Boot, Kafka, or distributed systems. Those technologies were merely tools.
The real difference came from the way I had learned to think, the habits I had developed, and the principles I had come to value.
And if there’s one lesson my career has taught me, it’s this: exceptional software engineers are rarely distinguished by a single breakthrough project. They’re shaped by hundreds of small decisions made over years of deliberate practice. Every bug investigated. Every production incident. Every difficult conversation. Every code review. Every line of code written with care.
The more I reflected, the more I noticed another pattern. Many of the engineers I admire (former colleagues, mentors, and friends who continue to build remarkable software) share these same characteristics.
Some work in startups; others in large organisations. Some are backend engineers; others build mobile applications, infrastructure, or AI systems. They use different programming languages. They have different personalities. They solve different kinds of problems.
Yet despite all those differences, there seems to be a common foundation beneath them.
That observation made me ask another question: why did these traits feel so interconnected?
That’s when I started thinking about DNA.
Why I Started Thinking About DNA
In biology, DNA contains the instructions that influence how living organisms grow and function. Individual genes contribute different characteristics, but no single gene defines the organism. It is the combination of many genes working together that creates the whole.
Software engineering feels remarkably similar.
There isn’t one technology that makes someone exceptional. There isn’t one framework, one certification, or one programming language. Instead, exceptional engineers develop a collection of traits that shape how they think, how they build software, how they collaborate, and how they keep growing throughout their careers.
I like to think of these traits as the genes that make up an engineer’s DNA.
Unlike biological DNA, however, engineering DNA isn’t inherited. It’s intentionally built, and it’s never finished.
I still remember one production incident early in my career. We eventually fixed the issue, but what stayed with me wasn’t the fix. It was realising how little I understood about the systems around it. I had solved the symptom without understanding the ecosystem. That experience permanently changed how I approached software design, and from then on I became far more interested in understanding why systems behaved the way they did.
That’s how engineering DNA is built. Every difficult bug teaches you something. Every code review leaves a mark. Every mentor influences how you think. Every failure humbles you. Every success gives you confidence.
That is why two engineers with the same number of years of experience can produce completely different outcomes. Experience alone doesn’t shape great engineers. How we respond to those experiences does.
Why This Is a Series
As I started writing this article, I quickly realised something: this isn’t a topic that can be covered well in a single post.
There are simply too many traits worth discussing. Some are obvious. Others are surprisingly underrated. Some may even challenge ideas we’ve accepted for years.
Rather than writing one massive article, I’ve decided to turn this into a series. Each article will focus on just a few genes, giving us enough room to think deeply about them instead of rushing through a long list.
It also leaves room for this framework to grow. As I continue learning, meeting exceptional engineers, and reflecting on my own experiences, I may discover new genes worth adding. After all, software engineering is constantly evolving. Perhaps our engineering DNA should evolve too.
I’m writing this series not because I’ve mastered these ideas, but because putting them into words forces me to examine my own habits as an engineer. Like everyone else, I’m still building my engineering DNA.
The First Three Genes
After reflecting on my career and observing engineers I deeply respect, I believe three genes sit at the foundation of exceptional software engineering.
I don’t think these are the only important genes. But I do think they’re foundational. In many ways, the others grow from them.
🧬 Gene #1 — Curiosity
One thing I’ve consistently noticed among the exceptional engineers I’ve worked with: they are relentlessly curious.
Curious engineers don’t stop after fixing a production issue. They ask why it happened, why monitoring didn’t catch it earlier, whether it has happened before, and what changes would prevent it from happening again.
In my experience, they’re also the ones who ask questions others never think to ask. They read documentation when everyone else watches tutorials. They explore technologies they aren’t even using yet. They enjoy understanding systems, not merely operating them.
Curiosity is what turns experience into learning.
And if you want to be world class, ignorance is one thing you can never allow to thrive. Today, almost every engineer has access to incredible learning resources.
Documentation. Open-source projects. Technical blogs. Conference talks. Books. AI.
Access is no longer the competitive advantage.
Appetite is.
Without curiosity, ten years of experience can easily become one year of experience repeated ten times.
I believe curiosity is the gene from which many of the others grow.
🧬 Gene #2 — Systems Thinking
Imagine this.
You’re asked to rename a database column.
An engineer focused only on the immediate task thinks: “Easy.”
An engineer thinking in systems asks:
- Which APIs depend on this?
- Will reporting break?
- Will the mobile app still deserialize the response?
- Does another service consume this event?
- What happens during rollback?
In financial systems, a seemingly harmless schema change can affect reconciliation, settlement, transaction history, reporting, or integrations with other services.
Same change. Completely different level of thinking.
That’s systems thinking.
Software never exists in isolation. Every API affects another service. Every database decision influences performance. Every architectural choice impacts maintainability. Every feature changes someone’s experience.
Exceptional engineers develop the ability to see these connections. Instead of asking only, “Will this code work?”, they also ask, “What else will this affect?” They think beyond individual classes and functions. They think in systems.
This ability changes the way software is designed, and it’s one of the biggest differences between engineers who solve problems and engineers who prevent them.
🧬 Gene #3 — First-Principles Thinking
“If the foundations be destroyed, what can the righteous do?” (Psalm 11:3)
Technology changes faster than almost any other profession. Frameworks rise and fall. Programming languages evolve. Best practices are rewritten.
Yet the engineers who consistently thrive aren’t necessarily the ones who know the most tools. They’re the ones who know how to think.
First-principles thinking means stripping away assumptions and asking:
“What problem are we actually trying to solve?”
Instead of copying yesterday’s solution, these engineers reason from fundamentals. It’s tempting to copy an architecture used by companies like OPay or Moniepoint simply because they’re successful. Exceptional engineers pause first and ask, “Do we actually have the same problem they were solving?”
That’s often where innovation begins.
It’s also why they adapt so quickly when technology changes. When your understanding rests on fundamentals rather than frameworks, a new tool is just a new expression of ideas you already know.
And if you have gaps in your fundamentals, there’s no shame in admitting it. But don’t stop at admitting it. Fix it as soon as you can.
One Decision at a Time
None of these three genes can be downloaded over a weekend. They’re grown, slowly, through how you respond to the work in front of you: the bug you chose to understand instead of patch, the design you questioned instead of copied, the system you traced end to end when nobody asked you to.
This article introduced the first three genes: curiosity, systems thinking, and first-principles thinking. In future articles, we’ll explore each of these in much greater depth and gradually expand this Engineering DNA framework with the other traits I’ve observed in exceptional engineers over the years.
If engineering DNA is built one decision at a time, then the encouraging thing is this: none of us are stuck with the version we have today. Every project, every bug, every review, and every lesson gives us an opportunity to improve it.
James Clear makes a similar point in Atomic Habits: our habits matter less for what they accomplish in the moment and more for the identity they build over time. Every small action is a quiet vote for the kind of person we’re becoming. Engineering works the same way. Every bug you investigate deeply, or skip past, is a vote.
So perhaps the most important question isn’t whether you’re a good engineer today.
It’s this:
What kind of engineer are your daily habits turning you into?