*Coders*, by Clive Thompson

The list of small-person or one-person innovators is long…[long list follows]…

The reason so few people can have such an outsize impact, Andreessen argues, is that when you’re creating a weird new prototype of an app, the mental castle building is most efficiently done inside one or two isolated brains.  The 10X productivity comes from being in the zone and staying there and from having a remarkable ability to visualize a complex architecture.  “If they’re physical capable of staying awake, they can get really far,” he says.  “The limits are awake time.  It takes you two hours to get the whole thing loaded into your head, and then you get like 10 or 12 or 14 hours where you can function at that level.”  The 10Xers he has known also tend to be “systems thinkers,” insatiably curious about every part of the technology stack, from the way currents flow in computer processors to the latency of touchscreen button presses.  “It’s some combination of curiosity, drive, and the need to understand.  They find it intolerable if they don’t understand some part of how the system works.”

The subtitle is The Making of a New Tribe and the Remaking of the World, I enjoyed the book very much, you can order it here.


'The 10Xers he has known also tend to be “systems thinkers,” insatiably curious about every part of the technology stack, from the way currents flow in computer processors to the latency of touchscreen button presses. '

That description sounds very similar to two of Google's top coders, who have studied computers down to the hardware level to ferret out bugs and to figure out how to squeeze performance increases in their code. At least that's what this article claims.


Thanks for the Link.

The height of this is to code in machine language and not a higher level language.

Only for the parts that really need hand-tuned efficiency. Avoiding modern tools for more mundane tasks is like digging a basement with a spoon.

You are correct. In fact specific routines are better written in machine language , more efficient and take less memory. Also some tricky capabilities can be tapped using machine language.

Yup, and one of the more important decisions is where do you put your best talent and time in creating highly efficient low-level code, versus where can you say that some sloppy off-the-shelf solution is good enough. That's an art in itself. In Google's case, with their ... what is it, billions of operations per second that they have to do? ... they've got a clear incentive to spend a lot of time and talent squinting at every bit of their code to find inefficiencies or invent new solutions.

But according to that article, even at Google the very most talented people who can do the very best job of this are very rare. Two men to be precise, although one would have to guess that the article might be over-emphasizing the power and uniqueness of their talents, compared to say the 3rd and 4th best coders at Google.

I began my career coding in machine language. In fact a year after I started I first saw an assembler language and was in awe over the problems it solved for me. But that was 55 years ago so I won't be sending my resume to Google.

Incredibly well written piece! Thank you forr sharing with us and I've moxt definitely acquired some tips.
Do you have a subscriber list I can also subscribe to?

This looks like something I want to read. I've seen people do this, and I've experienced something similar.

Youth is one major factor in the ability to do this. And being able to immerse yourself for the long hours without distraction; having kids and a spouse is a barrier.

On the other hand, the youth and relative inexperience in everything but coding and technology may make the end result either useless or destructive.

Something that comes to mind is nodejs. It was written over a few months mostly by one person, building on lots of work done by others in the same space. When released the basic ideas were quite remarkable, and many others got involved. It was one of these ideas and implementations that changed the direction of the industry; server ability to handle loads was about adding threads and processors, and figuring out how to make the spawning of threads and processes quicker. Node rather ingeniously recognizes that a network machine is waiting most of the time, so it maximizes the processing done within a core and a process. The industry as a whole changed direction. https://www.youtube.com/watch?v=ztspvPYybIY is worth watching knowing what has happened since.

Yeah, I've had experiences like this too. As I get older, I find it's harder to sustain this immersion for more than a couple hours though. The really deep stuff is for younger minds.

'The list of small-person or one-person innovators is long'

And list of shoulders they stand on is even longer. As noted by a certain innovator in several fields - 'If I have seen further it is by standing on the shoulders of Giants.' - Isaac Newton in 1675, expressing a concept that was about as distant from his time as he is from our time.

And of course, the idea of the GPL, a concept originated by one of the more famous 10xers in computing history, is to allow everyone to share the work of such people, and to take advantage of such sharing to build robust and innovative systems using the best work from others.

(Well, that is the concept - the reality often seems to be that everyone wants to write their own text editor, instead of actually doing something new or combining available ideas.)

While your statement is true, it is also obsequious. We all stand on the shoulders of giants and dwarves. Does that mean that some people are not exceptionally gifted at applying knowledge to immediate and unique needs? Does that obviate a person's mental focus?

I'd guess that these people have some high functioning autism. They are happiest taking a deep and solitary dive into problem solving. And it need not be purely mental. The guy who free climbed El Capitan had a similar personality that he directed toward a physical skill and epic feats.

Agreed. We all stand on the shoulders of giants but very few of us make a difference. Actually, we might stay on fewer shoulders than we think and at the end of the day, I don't think that makes a lot of difference.

What's the most times in one lifetime that one person has done accomplished some historic project in coding? I'm guessing ... three projects is about the maximum?

What proportion of the time are big things done by one guy versus two guys working together?

How oftten do these software projects actually change the world?

As a ancient software guy, ive seen lots of world changing software products become footnotes in history even I can barely remember.

Amazon is about 1% software and 99% a thousand rrefinements to logistics for which the US miltary set a new high bar in the 40s by convertng and building a supply chain from rural America to the shores of Europe and Asia and beyond in a few years.

Converting factories from farm, cars, washers to weapons, jeeps, tanks in two years surely beats Elon's production hell to produce Tesla Model 3s, especially given hundreds of factories were converted all at once.

Fives years gearing up US industry for war, and then back was world changing.

Not MSDOs, the work of one coder, which was the basic of getting really rich selling software coded by a guy or twp.

The rent seeking honed by Bill Gates changed the way a few people get really rich quick. And Elon used a few software projects to get the cash for taking Tesla and Spacex toward a more than $100 million trip to gthe edge of personal bankruptcy.

The idea of space rockets and electric cars was not new, but Elon "coded up" the rapidly evolving business plans almost single handedly, and changed the world with two factories with engineers working mostly on manufacturing.

I am sure if we gave Musk the same percentage of our GDP as the US war effort got he would have been able to do things faster. It’s easy to do things when you don’t have to worry about making a profit.

'It’s easy to do things when you don’t have to worry about making a profit.'

And a lot harder when all you have to worry about is losing a war. Ask the Japanese or the Germans how that works. Or for that matter, ask the Soviets, who were never worried about making a profit, unlike Japan or Germany, who saw their war plans being simply economics by another name.

Musk might be one smart guy but he doesn't know a single thing about war let alone how to win one. I'm going to have to disagree.

Thanks for sharing this valuable information to our vision. You have posted a trust worthy blog keep sharing.

-insatiably curious about every part of the technology stack, from the way currents flow in computer processors to the latency of touchscreen button presses. “It’s some combination of curiosity, drive, and the need to understand. They find it intolerable if they don’t understand some part of how the system works."-

I sometimes code at work and this is a very good description of what the job really is. However, 10Xers have an incredible tolerance to frustration. I can code for 1 or 2 weeks daily, then I lose all motivation....bugs are endless, never ending work, start thinking about what's the purpose of life.....then switch to other tasks and feel better. So, people that code effectively for a living are a special kind.

PS. it helps having a manual/physical hobby where you can have tangible results because some days the abstract work yields 0 or even negative results. When coding, my mountain bike is perfectly clean and oiled, and I cook a lot =)

So much for collaboration (the buzzword in tech). If the innovation in tech is produced by the "long list of one-person (super) innovators", what do all of the rest of the coders do? Bill Gates certainly changed for the better the way I produce my work (thank you very much). But when my computer crashes it is an inconvenience, it's not life threatening. When an aircraft crashes because the on-board computer confuses up and down, that's more than an inconvenience. As tech ventures beyond data collection, storage, and mining to self-driving aircraft and cars, to autonomous electric grids and telecommunications systems, to fully automated home appliances, are the super coders up to the (inhuman) task? I know, the next generation of super coders won't be human. https://www.nytimes.com/2019/03/27/technology/turing-award-ai.html

There is a scale issue.

One or two guys can write a (relatively small) point solution - they can't write or usually even really understand in detail the millions of lines of code for aircraft or autonomous vehicle control systems.

All very interesting, but begs the question - what % of people who are 'insatiably curious', work for 14 hours - and still just perform at '1x'?

My experience suggests that this number is not zero.

It would be interesting to study the role of performance-enhancing substances in these individuals. A lot of driven, successful people used to be chain smokers. (Today, less.) Erdos famously took amphetamines regularly and I have read that Von Neumann did too. I recently read about one of these 10X guys who was constantly chewing Nicorette.

Coffee, coffee, coffee.

That and microdoses of LSD.

The coders adapt to Moore's Law, that is the drive. Moore's law opens new methods. When adapting to a Moore's law increment, the idea is to move the first hardware layer up to software. It is actually quite systematic, something that can be done step by step, as if the coders had instructions.

Go back, look at linux and its history. Same with Microsoft, each new speed advance was accompanied by a Moore's Law advance, and the fist coders that systematically boost the stack in response are called heros. No, just the first people assigned to the current Moore's Law increment.

Go backward, to Ben discovering the electron. Once we knew that charge 'flowed', the Morse, a portrait painter with an eye for detail could create the Morse code and become a hero. Moore's Law has been operational ever since.

It's legit. I won't bore you with how I made my millions.

As someone who has worked on IT companies for 25 years, what I've seen is that these innovators are indeed rare and quite important. It is not that they do all the work and other people just watch. They come up with the groundbreaking pieces that enable all the other important but more mundane pieces of code to come together and work. Companies know that and usually do a good job in identifying these "super stars" and rewarding them. It is a somewhat messy process though since this same recognition seem to damper a bit the impulse of some of these guys. Usually, the most important part is to allow these folks to "float" around the company and find opportunities they are attracted to.

In your 25 years, you have seen one maybe two Moore's law jumps. Look at the current increment, 64 bit address and data. There is no need to support 32 bit code, the cost in instruction to support the mode is more expensive then converting all to 64 bit. That is what the Linux heros coders are doing, systematically removing, and layering as they eliminate 32 bit code hacks. They will naturally shrink and shift and add to the stack; do it in a systematic manner. In fact, the hero coders are often replaced with semantic translators, deriving the new layer automatically after a Moore's shift, some hero coders figuring out how to automate the other hero coder.

In the last 200 years, the baud rate for digital has doubled every five years. That is a phenomenal, predictable career path for anyone who does crossword puzzles.

I’ve become convinced that the “10x developer” is a myth. There are a select few, though, whose impact is 100x or even higher. Unless you are in a very select group of firms you can forget about attracting them. You’re better off focusing on assembling teams of 2x or 3x devs and giving them the space and tools to succeed. I have many senior colleagues who I respect greatly but even they would not claim that they deliver 10x the value of a rank and file dev. Their value comes from mentoring and using their expertise to make architecture decisions that allow others to maximize their contributions.

Even Silicon Valley is moving away from the cult of the 10x Nietzschean superman dev, many of the latest crop of successful startups have dramatically different recruiting practices. They focus on ensuring a baseline level of technical competence and beyond that, communication and collaboration skills are the differentiators.

Just so. 10x-ers are more like the apparent superhuman prowess of Richard Feynman, who could shoot down a grad student's bright idea in minutes because he'd already gone through it.

The most pernicious is the Mozart Myth" in general. It combines the worst of 10x-er-ism and youth affinity.

I would say that there may be a lot of counterproductive activity in software when large, complex stacks are involved. Much of that is in favor of "allowing others to maximize their contributions". Might work, might not. In general there should probably be much more reticence about scale in projects to start with.

And as software slowly evolves into an exercise in category theory, we will see how that plays out. I expect it won't substitute for just doing projects, but it fits better with the preference for credentials.

Don't tell the kids but it all takes along time to learn.

I've been writing code since 1980. The cost of interruptions is one thing that management never seems to understand, and probably explains why I prefer to shift my hours so I can work after hours, or on weekends or from home.

The worst example of such management blindness I experienced was a VP who would issue weekly voicemail messages about half an hour long. He had IT track our listening to them and made them mandatory. There was _never_ any content which made a difference. Half an hour a week for hundreds of workers cost the company several man-weeks of work in a single shot.

A reaction to this from someone who is plausibly a 10Xer:

Google used to be the exception to the rule that large companies couldn't do innovative tech work, since they used to give folks a lot of space to do that kind of 'castle building.'

I wholeheartedly agree that the most effective engineers are the ones who find not understanding their systems intolerable. When I was interviewing engineers, I tried my best to screen for that.

I will say that there is a misconception that software work requires intense concentration because they need to write immensely complex code. The best engineers I have worked with needed lots of space to understand the problem they were trying to solve, but once they did, the code would follow very quickly, and the solution itself would ultimately be quite simple. (Reminds me of that Mark Twain quote about needing time to write a short letter.) A great example was when (Mentor) replaced a giant
(50,000 lines of code) and terrible build system at (employer) with fewer than 100 lines worth of shell scripts, and our build times improved by *hours*. The engineers that wrote the original system thought they needed to build a castle, when really they just needed a shed.
(Mentor) wasn't more productive because he could write more lines of code (although he could), but because he knew when and how not to. That's the 10x-er secret.

Comments for this post are closed