The question sounds simple. Most engineers answer it too quickly — "yes, I ship things that work" — or too anxiously — "probably not." Neither answer is useful. The right answer requires a different kind of self-assessment entirely.
Not About MAANG. Not About the Salary Band.
We have inherited a narrow definition of excellence in engineering. It gets conflated with employment at a FAANG company, a competitive total compensation, a conference talk, or an impressive open-source repository. These are all valid signals of recognition — but they are not excellence itself. They are outcomes. Excellence is something that precedes the outcome.
It lives in the quality of thinking you bring to an ordinary Tuesday problem. In how carefully you name a variable when nobody is watching. In whether you write the test even when the deadline is tight. Excellence is not a destination you arrive at when a prestigious company makes you an offer. It is a practice — invisible, daily, and entirely personal.
In 18+ years of building software across Pakistan, Japan, and Germany, I have found that the engineers who stand out — the ones in the top three to five percent globally — are not always the ones who know the most. They are the ones who hold themselves accountable to a higher standard of craft, regardless of whether anyone is looking.
Nine Questions That Reveal Everything
The way I have approached this question over the years is to counter it with a set of more specific ones. Not theoretical questions about algorithms or system design — but honest, practical questions about the code you are writing right now, today.
If you can answer all nine with confidence, you are already operating at a level most engineers never reach. If you cannot — then you have found your next frontier.
-
01 —
Quality & Ownership at Every Stage How can I ensure quality at every step of the SDLC while taking personal ownership and accountability for each stage — not just my ticket?
-
02 —
Business Value How will my code add real business value for customers? Am I solving the right problem, or just implementing a requirement without questioning it?
-
03 —
Language & Tool Selection Which programming language or technology solves this use case most efficiently — and am I choosing it for the right reasons?
-
04 —
Readability & Testability Am I writing code that the next engineer — or future me — can read, reason about, and test without reverse-engineering my intentions?
-
05 —
Testing Strategy How will my code be tested — for both functional correctness and real business value? Have I thought beyond the happy path?
-
06 —
Build & Integration How will my code be built and integrated? Have I considered the pipeline, dependencies, and how this fits into the broader system?
-
07 —
Deployment How will my code reach production? Have I thought about deployment strategy, rollback, and the impact of a bad release?
-
08 —
Non-Functional Attributes How will my code be monitored for security, scalability, resource utilisation, mission criticality, and resilience — not just when it is green, but when it degrades?
-
09 —
Business Value in Production How will I know — measurably — whether my code is delivering the value it was built for? What does success look like six months after deployment?
These questions are not a checklist to complete once. They are a lens to apply continuously — across every feature, every PR, every architecture decision. The goal is not to answer all nine perfectly. The goal is to hold all nine in mind.
What Has Actually Guided Me
Achieving technical excellence is complex and has no shortcuts. No company will hand you a curriculum for it. No 30-day coding challenge will build it. Here is the approach that has shaped my thinking across four countries and two decades of building software — not theory, but what has actually worked.
Be a Kind and Empathetic Human Being First
Technical skill without empathy produces fragile teams and brittle codebases. The best engineers I have worked with understood that they were building for people and with people — and that shaped every decision they made. Empathy is not soft. It is a force multiplier for technical excellence.
Coding Is a Reflection of Your Character
Your code tells the truth about you — your discipline, your attention to detail, your respect for your team, your intellectual honesty. Two engineers can be given the same problem and the same deadline. What they produce will be entirely different — and those differences are not technical. They are character. Develop a strong and positive one.
This Is a Personal Journey — Own It
No company will sponsor your growth the way it needs to happen. Organisations hire and promote based on their own business goals, not your personal development trajectory — and that is a reasonable truth, not a cynical one. Your growth is your responsibility. Embrace learning as a lifelong commitment that happens beyond the 9-to-5, on your own terms, at your own pace, driven by your own curiosity.
Understand the Business Reality — Without Bitterness
Companies hire and fire based on business conditions, not personal loyalty. Understanding this clearly — early in your career — is one of the most liberating realisations you can have. It removes the dependency. It forces you to build skills and a professional identity that belong to you, not to an employer. It is a harsh truth, but it is a useful one.
Stay Curious. Stay Transformed.
The engineers who remain relevant and excellent over decades are not the ones who mastered the stack of 2015. They are the ones who stayed genuinely curious — who saw every new paradigm, every new tool, every failure, as material for growth. Be ready to be transformed. The version of you that knows enough is always a little behind the version of you that needs to grow.
Excellence is a journey, not a destination. Be the master of your own.
The next time you sit down to write a function, ask yourself the nine questions. Hold them lightly, not anxiously. Let them sharpen your work. And then — keep going.