10x Engineers: The Purple Developer
jessitron.com
jessitron.com
Pairing, documenting the system, keeping everybody up to date and involved in decisions is obviously still important but i really don't buy the claim that this is what constitutes these differences alone.
There are these gurus who know how know how to hook up all kinds of debuggers, cross-compilers, IDE, profilers, fuzzers and packet sniffers which can jump into any other teams unknown module and in just a day or two kill of bugs they have been struggling with for weeks. I've seen this happen over and over again. These guys know how to systematically break down a problem, find the external dependencies, google-fu how to set up a dev-environment, create a minimum isolated test case for it, and get to the bottom of the problem, regardless if it's Java, Python, Node, C++, their own codebase or someone elses. In bigger systems they know how to build a mental model of all the microservice relations and database tables.
On the other extreme end of the spectrum you have the trial-and-error developer who will happily add a dependency to your database inside the otherwise stateless math-module. This difference has absolutely nothing to do with productive-in-this-codebase.
You could also stretch the original definition to say productive-in-X also includes any past experience with surrounding external dependencies. Such as linux, the programming language, its libraries and ecosystem. Those years of experience can't easily be shared with others, as the article explains.
I feel the fundamental difference between productive developers and less productive developers is the way they think, they way they look for solutions and the level of experience they have with what they're building and surrounding environment.
Some people are quick learners but lack experience. Some have tons of experience but they're not used to find solutions and get stuck.
Those with experience and the right attitude will blow past everyone's else performance.
I feel like saying this is politically incorrect nowadays, though, because meritocracy is not popular today.
Which is probably why we're seeing a rise in this articles trying to explain 10x developers in more social terms (it's teamwork, enabling others, you're lucky to be familiar with the codebase).
Not that I think familiarity with the codebase or teamwork are not important, but there's a difference between people who spent their best years programming night and days, learning advanced concepts and solving tricky problems and those who didn't.
Drop the first ones anywhere and they'll be productive.
But good luck finding them.
What I've seen:
* A person is tricked into thinking software engineering is like baby intro "get into CS" projects, and by the time they find out it's not for them, it's too late. I know several people who went this route, and range from having gone on to law school/MBA to working retail. The law school/MBA types are extremely successful, with the dual background. But I feel pretty bad for the folks working retail, with crushing engineering school debt.
* Companies have a severe shortage of qualified employees. Under-qualified employees have a severe shortage of jobs. I feel bad for people who can't find jobs.
My own opinions:
1) No, code camps are not sufficient prep.
2) No, application-focused CS undergrad programs are not sufficient prep (where you'd historically learn Java web development, or the current Microsoft stack)
3) Yes, having rigorous background in something, be it machine learning, low-level systems engineering, compilers, or what-not makes you far more effective. Ideally, a few.
4) Yes, freshman weeder courses are important
5) But no, having "highly-selective schools" like MIT or Stanford is not helpful (and no, it's not sour grapes, I went to one of those). Anyone should be able to try a freshman weeder course, rather than going through insanely competitive admissions criteria which correlate poorly with the ability to do this stuff.
I will say familiarity with code varies person-by-person. I'm generally known as at least a 10x developer, since I've created several major tools with name-brand recognition. I'm not great at jumping into other people's code, though. The article would have resonated with me if everyone's brain was wired like mine, but...
... one of the best developers I've worked with can jump into complex codebases in what seems like overnight (a couple of weeks to be literal), and work with them better than the original developers. You toss him a complex system with a bugs, and it will be debugged in a month, where it'd take me a year or two of work to even understand that code. On the other hand, I wouldn't trust him to write a new piece of complex code.
So it seems we're wired differently. I'm better than he is at imagining a new system, foreseeing possible use-cases, designing an architecture that's general in the right ways to allow all conceivable uses, yet constrained in the right ways to still be simple, and then building it quickly. I'm better than him at designing novel algorithms and data structures too. On the other hand, if I have a bug in a third-party library, I'll take literally 10-100x as long to fix it as my friend. And he'll be better at understanding the algorithms and data structures in existing systems (you can throw something complex like Cassendra at him, and he'll understand the design and its implications nearly overnight).
"A lot of people think the word commando means super-hero, or at least something close to it. In the popular mind, they're thought of as the ultimate elite soldier, the solution to every problem. The fact is, a commando is just someone trained to fight under a specific set of circumstances. He's the guy you send in when there are more bad guys than good guys, when surprise is the only advantage you can get in an operation. When it works, commandos seem unstoppable. Those are the operations that make the papers. When it doesn't work, commandos get killed just as dead as anyone else."
You will have a mental model from the beginning, and as decisions are made and code is added, you understand not only how everything works, but why it (currently) works that way.
By far the least productive I've been as a developer - looking back it's a shame - was working on projects in the MIDDLE of a tech stack.
At the bottom, you at least get to understand the hardware. At the top, you understand the problem and the rest of the stack abstracts stuff for you.
In the middle .. it's much harder to figure out why you're being used from above, or what is going on below you. So you'll be playing catchup for a long time.