[Trasmatta]

In my mind and experience, a "10x engineer" (not sure I'm ready for the "50x" term) gets (or should get) that distinction because they write high quality, fault tolerant, secure, performant, well documented code, AND they empower their teammates. It usually has very little to do with the speed in which they accomplish all of that, which I think is why management has a hard time identifying who they are.

They may think the engineer who fixes 10 bugs a week is their best asset. But what about the engineer who quietly created high quality code with very few bugs, that's extremely easy to maintain?

A "10x engineer" gets that distinction because their software provides dividends in quality and maintainability for years and years, even if the initial implementation took them a seemingly long time. But management often just sees the engineer who's closing the tickets the fastest, even if that person's code becomes a curse on the company for years to come.

It doesn't help that so many teams are focused on 2 week sprints and quarterly goals. That kind of work favors a certain type of engineer, and incentives short term solutions.

[crazygringo]

I appreciate what you're saying... but I don't think that's the generally accepted meaning of 10x. You're just describing a good, responsible, effective programmer. Skills like good documentation or secure code are things anyone can learn from training and experience. And the qualities you're describing are also very much a function of what the company requires/expects/incentivizes, rather than what any individual chooses to do.

People generally reserve "10x engineer" who really do have the intellectual capacity and stamina to crank out 10x the amount of code of the same quality as a median engineer.

I think it's important not to confuse the two.

[Trasmatta]

I'm pretty dubious about the idea that this type of engineer actually exists.

[crazygringo]

They definitely do, I've worked with them.

As far as I can tell, it's mainly the ability to hold a lot more "connections" in their head at any one time, and extreme logical rigor.

So that instead of reasoning about just the function they're writing, they're always naturally reasoning about the entire framework it fits into, and so they don't tend to produce bugs where the function doesn't fit in right, where it has weird side effects, where it duplicates code elsewhere, where it will create unforeseen technical debt, etc.

And then their logic is just watertight, always. They don't make all the kinds of basic design and logic errors other programmers tend to repeatedly make.

They sit down, crank out 1,000 lines in a couple of hours, try to compile/run, fix bugs around mismatched braces and misspelled variables, and it just works.

In contrast with someone else who takes a couple days to get it even kind of working, then winds up having to rewrite large parts of it twice because they'd made basic design errors in the first place.

But I still stand by my original point that most programming jobs don't require you to write a tight 1,000 lines often. Most work is plumbing, bugfixes, CRUD, etc. where the connections/logic skills don't really pay off in a big way.