Can you clearly articulate the important concepts and how they inter-relate? Define the problem boundaries (and later, as a consequence, boundaries of functions, data structures, objects)? Separate which component is responsible for what, in a way that makes sense to the business need? Choose the right algorithms? Focus on optimizing what matters, know your tools to get standard parts done in a standard way?

Like all true craftsmen, the final output will make everything seem so easy, so concise and obvious. But it's anything but. The same problem solved by an army of mediocre engineers will just end up a huge convoluted mess. And it doesn't matter how many of them you unleash during the initial architectural stages of a project — arguably the more, the worse the result. Being able to handle uncertainty (as opposed to an unrealistic list of minute specs), ask the right questions and make the right technical choices is what makes 1000x engineers.

The value chain of software is long, and the higher up the chain you can empathize with and code to, the better for you.

yeah. Jeff and Sanjay (of Google) are famous for pair programming. I've never seen them (or anyone) do it but can you imagine how slow it is?

OTOH, I have witnessed Craig Silverstein (1st google employee, not as well recognized as Jeff and Sanjay I think) typing and OMG the thoughts just flow from his brain to the screen. That must be a boost. I personally find that the expression of the thought into code is soooo slow and limiting. I feel like I could be a 10x engineer if I had 2 transcribers that were very good technical typists, like a steno recorder.