> we can’t say anything more than "roughly order of magnitude"
This, to me, is the core of it. "10x" is just a shorthand for the compound interest of good decisions. Nobody would be surprised to learn that teams with good managers are 10x more productive, or that factories with a good safety culture have 0.1x the accident rate.
Where it gets confusing is that developers have substantially more scope for compounding than their roles suggest. They're generally not managers, executives, or cultural leaders, and yet their decisions seem to compound anyway. Why is this?
For the answer, I encourage you to watch the YouTube channel "Primitive Technology", where a brave and often shirtless soul spends weeks and months constructing tools and structures from scratch. He does so with a deftness and skill that is captivating, yet the stuff he makes is, by modern standards, totally useless. It's not his fault; it's just that technology compounds, and no amount of individual skill can ever make a skyscraper out of wattle and daub.
Only in software, the most questionable of all the engineerings, do we build the processes and tools we depend on while we're using them. If you showed up to a job site talking about making your own concrete mixer to get the building done faster you'd be laughed right back to wherever you came from. Yes, in cutting-edge applications and prototype manufacturing it's different, but almost every other area of engineering takes stuff that works and uses it to make more stuff that works.
To be clear, this isn't a long-form argument for "we should have stuck with Rails", nor is it "software is just getting started, give it some time". Rather, I believe that software development is essentially and unavoidably compounding. Every design decision, abstraction, function and data structure is a piece of your foundation that you build and then stand upon to build some more. We're creating abstract machines, and when they become concrete enough to rely upon they no longer need software developers.
Which is why it's so ridiculous to imagine this 10^x developer who crushes code 24/7, laughs in the face of process or documentation, and communicates only via a colourful aura of cheeto dust and misanthropy. It's an adolescent fantasy of expertise, no different from Doctor House or Detective Batman. Sophomoric macho bullshit. The 10x isn't the person, it's the compounding effect of good decisions.
Peter Norvig is a great developer, but try airdropping him into some dumpster fire codebase that's 99% finished, riddled with bugs and way behind schedule. Is he going to grab his wizard hat and 10x his way out of it overnight? No. He's going to have to slog through the mess like anyone else. His expertise doesn't result in faster typing, but in better decisions. Decisions that work well now, but enable even better work later.
Most importantly, this kind of compounding doesn't just apply to you, but to the people you work with and the environment you work in. To enable that, you need communication, leadership and generosity. Here's the man himself, describing his work at Google [0]:
> I've varied from having two to two hundred people reporting to me, which means that sometimes I have very clear technical insight for every one of the projects I'm involved with, and sometimes I have a higher-level view, and I have to trust my teams to do the right thing. In those cases, my role is more one of communication and matchmaker--to try to explain which direction the company is going in and how a particular project fits in, and to introduce the project team to the right collaborators, producers, and consumers, but to let the team work out the details of how to reach their goals.
Or some quotes from his essay "Teach yourself programming in ten years" [1]:
> Talk with other programmers; read other programs. This is more important than any book or training course.
> Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you're the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you're the worst, you learn what the masters do, and you learn what they don't like to do
> Work on projects after other programmers. Understand a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain them after you.
Or check out his lavishly documented walkthrough of approaches to the Travelling Salesperson Problem[2] (just one of many similarly educational "pytudes"[3]). Or the leading AI textbook he co-wrote[4]. Or the online AI course he co-developed[5]...
That's what real 10x looks like. Not some myopic ubermensch who divides the world into "code" and "dumb", but a thoughtful decision-maker who treats great work as a garden to grow, rather than a race to win.
This, to me, is the core of it. "10x" is just a shorthand for the compound interest of good decisions. Nobody would be surprised to learn that teams with good managers are 10x more productive, or that factories with a good safety culture have 0.1x the accident rate.
Where it gets confusing is that developers have substantially more scope for compounding than their roles suggest. They're generally not managers, executives, or cultural leaders, and yet their decisions seem to compound anyway. Why is this?
For the answer, I encourage you to watch the YouTube channel "Primitive Technology", where a brave and often shirtless soul spends weeks and months constructing tools and structures from scratch. He does so with a deftness and skill that is captivating, yet the stuff he makes is, by modern standards, totally useless. It's not his fault; it's just that technology compounds, and no amount of individual skill can ever make a skyscraper out of wattle and daub.
Only in software, the most questionable of all the engineerings, do we build the processes and tools we depend on while we're using them. If you showed up to a job site talking about making your own concrete mixer to get the building done faster you'd be laughed right back to wherever you came from. Yes, in cutting-edge applications and prototype manufacturing it's different, but almost every other area of engineering takes stuff that works and uses it to make more stuff that works.
To be clear, this isn't a long-form argument for "we should have stuck with Rails", nor is it "software is just getting started, give it some time". Rather, I believe that software development is essentially and unavoidably compounding. Every design decision, abstraction, function and data structure is a piece of your foundation that you build and then stand upon to build some more. We're creating abstract machines, and when they become concrete enough to rely upon they no longer need software developers.
Which is why it's so ridiculous to imagine this 10^x developer who crushes code 24/7, laughs in the face of process or documentation, and communicates only via a colourful aura of cheeto dust and misanthropy. It's an adolescent fantasy of expertise, no different from Doctor House or Detective Batman. Sophomoric macho bullshit. The 10x isn't the person, it's the compounding effect of good decisions.
Peter Norvig is a great developer, but try airdropping him into some dumpster fire codebase that's 99% finished, riddled with bugs and way behind schedule. Is he going to grab his wizard hat and 10x his way out of it overnight? No. He's going to have to slog through the mess like anyone else. His expertise doesn't result in faster typing, but in better decisions. Decisions that work well now, but enable even better work later.
Most importantly, this kind of compounding doesn't just apply to you, but to the people you work with and the environment you work in. To enable that, you need communication, leadership and generosity. Here's the man himself, describing his work at Google [0]:
> I've varied from having two to two hundred people reporting to me, which means that sometimes I have very clear technical insight for every one of the projects I'm involved with, and sometimes I have a higher-level view, and I have to trust my teams to do the right thing. In those cases, my role is more one of communication and matchmaker--to try to explain which direction the company is going in and how a particular project fits in, and to introduce the project team to the right collaborators, producers, and consumers, but to let the team work out the details of how to reach their goals.
Or some quotes from his essay "Teach yourself programming in ten years" [1]:
> Talk with other programmers; read other programs. This is more important than any book or training course.
> Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you're the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you're the worst, you learn what the masters do, and you learn what they don't like to do
> Work on projects after other programmers. Understand a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain them after you.
Or check out his lavishly documented walkthrough of approaches to the Travelling Salesperson Problem[2] (just one of many similarly educational "pytudes"[3]). Or the leading AI textbook he co-wrote[4]. Or the online AI course he co-developed[5]...
That's what real 10x looks like. Not some myopic ubermensch who divides the world into "code" and "dumb", but a thoughtful decision-maker who treats great work as a garden to grow, rather than a race to win.
[0] https://www.quora.com/What-does-Peter-Norvig-do-exactly-at-G...
[1] http://norvig.com/21-days.html
[2] https://nbviewer.jupyter.org/github/norvig/pytudes/blob/mast...
[3] https://github.com/norvig/pytudes
[4] http://aima.cs.berkeley.edu/
[5] https://www.udacity.com/course/intro-to-artificial-intellige...