Real world "10x" developers are almost always in that class because they can solve the same problem with 1/10th the code of a 1x developer.
Ability to solve problems with less code will always outpace faster typing.
Because the people who shorten code at the cost of clarity are some of my least favorite people. I once saw “half = num >> 1” instead of, say, “half = floor(num / 2)”. The latter is 100% more clear to more people and doesn’t gate-keep on engineers who haven’t memorized bitwise operators. (Also, this wasn’t a context where the bitwise operator would be optimized by the compiler in case they wanted to throw that hogwash out there.)
But personally, short, standard, and sweet is preferable to crazy newfangled mental model. I've seen way too many real-world examples of the idiom "it takes a lot of skill to write Java in every language."
half = num >> 1
Was standard practice and understandable by most engineers, as well as far and away much faster than a divide.
Now-a-days, using a compiled language they are going to be translated into the same machine code supporting your point. However, it might still be a good idea in a scripting language doing heavy math lifting.
> I once saw “half = num >> 1” instead of, say, “half = floor(num / 2)”.
Again, that's just stuff that's getting you a small constant factor less code, a few characters here and there. To get closer to an order of magnitude smaller program solving the same problem requires a deeper understanding of the problem and different strategies for solving it.
To me, the gold standard example for the 10x to 100x coder is always Peter Norvig.
https://norvig.com/spell-correct.html https://norvig.com/sudoku.html
Notice the clear comments and detailed explanations and reasonable identifier names. But do you think the median developer would solve these problems with a similar amount of actual code?
Also, research shows the number of bugs per line of code is pretty much constant across programming languages and kinds of programs. So reducing the number of lines of code will almost certainly reduce the number of bugs, statistically speaking.