1. Write down the problem. 2. Think real hard. 3. Write down the solution.
This is a joke of course, but much of the real 10xness is invisible. It certainly doesn't look like typing. Perhaps quite a lot of it occurs off screen, in conversations, whiteboards, on the computers of colleagues. I'll give you two analogies:
In some ways it's like one of those "bullet hell" shoot-em-up games, but played out over weeks or months. There are all manner of mistakes that can derail a project but only become obvious later (e.g. poor dependency or architecture choices), and there are all manner of techniques that may let you skip a section or avoid a whole category of problems, perhaps at the cost of requiring more immediate skill (e.g use of higher level but unfamiliar programming languages like Haskell or APL). Someone with 10xness dodges all the bullets and takes the correct shortcuts, while people with less talent and experience mistake the one for the other or don't see it coming.
Or there is "bug sniping", which I think is the place I've been able to make "10x" contributions: it's possible for your colleagues to be simply stuck on something, consuming a lot of time for no progress. Maybe they can manage a workaround, but at an efficiency cost - like people driving slightly broken cars which you have to open the passenger's side first to unjam the driver's door. This is the field in which puzzle-solving ability really helps. It's just that the puzzle has been created accidentally by other developers or yourself.
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.
That’s one thing that makes them really hard to recognize by non technical people. I would say that to recognize them and admire their work, you have to bang your head against the same problem as they do, and then see how they solve it. But just looking at their work from the outside will probably be very unimpressive.
It was so much simpler.
I don't know about 10x engineer (I actually think that whole line of thinking is bullshit), but Blow has shipped a few games.
Have you ever had things where bad decisions caused lots of headache and cost a lot of time to fix? With a 10x engineer you have... fewer of those instances... maybe 10x fewer
See also https://www.gun.io/blog/what-i-learned-from-watching-notch-c...
They don't have to type fast, but they're also not relying on Stackoverflow for learning concepts.
Most web applications start as prototypes written by one guy in 90 days or less, then just re-labelled as "production."
https://www.youtube.com/watch?v=1e0OCwlaEZM
Yep, a busdriver. That's what he does. I find having these videos open during coding is pretty inspiring, too bad there's so few of them.