I worked with two coding gods. It was never about speed.

I have worked at two product companies, Spyne in Gurgaon and LambdaTest in Noida. At each one, I worked next to a coding god.

That is what their teams called them, half as a joke: the one engineer who operated a level above the rest. The first time I heard it, I rolled my eyes. By the time I worked with the second, I had stopped. I meant it.

Working next to them rewired me. Not just what I thought a great engineer was, but how I spend my own days now.

I had walked in sure I knew what greatness looked like. Both of them proved I had it backwards.

I used to think the best engineer was the fastest one#

When I started out, greatness had a very specific look. Fast. Clever. The person who closed the ticket before lunch, dropped the one-liner that ended the review, and made the rest of us feel a step behind. I wanted to be that. Most of us did.

So that became my measure of a great engineer: speed, and the kind of cleverness that makes a hard thing look easy. I held myself against it every day, and most days I came up short.

Then I joined a product company, and being fast stopped setting anyone apart. The room was already full of fast, clever people. IIT, NIT, the top colleges, and plenty who had cracked interviews brutal enough to break most people. Smart was not the exception here. It was the price of admission.

So I did the obvious thing and kept measuring the same way. If everyone was fast, the best had to be the fastest of the fast, the sharpest mind in a room full of sharp minds.

I was measuring the wrong thing. Not slightly off, the wrong thing entirely. It took two people, one at a time, to show me what I had been missing.

The man the room waited for#

The first one was at Spyne. He led a core platform team, the backend infrastructure everything leans on and nobody notices until it breaks.

He wasn't the fastest person in the room. He didn't need to be. He was the one who decided. When an architecture argument went in circles, people stopped arguing and looked at him. He'd think, make the call, and the room moved with it.

It went up the chain too. Drop him in a room full of VPs and senior people who had never read the code, and he could lay out exactly what was solid and what was quietly on fire, in plain language they could decide on, without once hiding behind jargon. Most of us can do the work or explain it upward. He did both, which is why leadership trusted his read of a system over any status report.

He had earned that the slow way: by being right so many times that doubting him felt like a waste of everyone's day.

I thought that was the ceiling. I was wrong. I just hadn't changed companies yet.

LambdaTest: He had the entire frontend memorised#

LambdaTest was bigger, the product on another scale. Its flagship AI product had a frontend of more than two hundred components, piled up over years of features. One engineer owned the whole thing. The claim people kept making about him sounded made up: he had every component memorized, down to its quirks.

A standup made me believe it. A teammate was three minutes into a bug that had eaten two days of his week when the engineer cut him off, named the file, named the component, and told the room which piece of Redux state was wrong and how it had gotten that way. He never opened his laptop. Someone checked later. He was right.

And it wasn't a trick he saved for the room. You could describe almost any bug out loud and he'd walk you to the exact line before you finished. After a while you stopped digging through files. You just asked him.

The first god had impressed me. This one unsettled me. I kept probing for the edge of what he knew, the one corner that would finally catch him out. It never showed up. Then the roadmap handed him the single job I was sure would find it.

A months-long migration, done with one hook#

We had to move the entire frontend off an old version of React Router onto a much newer one. If you've never made that jump, the two versions are barely the same library. Routing changes fundamentally underneath you.

It's painful on a single screen. Now picture it across two hundred components built up over years. By any honest estimate, that's a multi-month slog with a long tail of regressions. We braced for exactly that.

He did it with one reusable hook.

Instead of rewriting two hundred components by hand, he wrote one piece of shared logic that absorbed the entire difference between old routing and new. The rest of the code barely moved. The scariest thing on the roadmap turned into a non-event.

I had braced for a war. He ended it with one good idea, possible only because he understood the whole system well enough to find the one place it all converged.

That was when "coding god" stopped sounding like a joke. And once it did, the two of them snapped into focus as the same engineer.

Different people, identical underneath#

As people, they couldn't have been more different. One lived in backend infrastructure, the other had a frontend memorized down to the line. But the thing that made them great was the same.

Both were deep. They carried the whole system in their heads instead of just their corner, so they spotted problems the rest of us couldn't even locate. That depth surfaced the same three ways:

• They were where the hard questions went to get answered for good.

• They owned the calls everyone else was too nervous to make.

• When something looked impossible, they reached for one sharp idea instead of brute force.

None of it was speed. It was years of carrying a whole system in your head, finally visible from the outside: a line named from memory, a migration ended with one hook, a call no one else would touch.

Knowing that didn't make me one of them. It did change what I do with my days.

Why I now read code I have no reason to read#

I am not a coding god. Sitting next to two of them did not transfer the gift.

But you can't watch that up close and stay the same. Once you've seen the actual ceiling, being merely quick stops feeling like enough. So I stopped just admiring them and started studying them.

I read their pull requests line by line, even the ones I had no reason to open. I watched them take work that should have cost months and close it in a week, then tried to reverse-engineer how they got there. The way they wrote code, the way they debugged it, I wanted to understand from the inside instead of clapping from the crowd.

That is why I now read code I have no reason to read. I am trying to learn the whole system instead of my slice of it. I want to be the person a question stops at, not the one who passes it down the line.

Since then I spot them everywhere. There's usually one on every team, quietly holding up the part that just works while everyone else moves around them. Most teams get exactly one, if they're lucky.

If you ever get to work with yours, don't waste it. It is the best education this job will give you, and nobody charges you for it.

I am not one of them yet, and I am putting today's date on this, 31 May 2026, so I can be held to it. Maybe not today. Maybe it takes two or three years. But one fine day I will be one of them, and someone will describe a bug out loud while the line is already waiting in my head.