[ ] What separates the 10x devs from the 1x? (what _is_ it? Environment, skill, ...)
[X] 10x productivity myths (why you shouldn't believe it)
[ ] 10x productivity truths (but, but, it IS true, see?)
[ ] Be the 10x developer (aspiring to be one)
[ ] Startup perspective (should startups try to acquire 10x devs?)
[ ] Why the 10x notion pisses me off (why it shouldn't matter)
[ ] If 10x productivity why not 10x salary? (or similar)
[ ] Some meta discussion on the metrics of "productivity" (solve for x)
[ ] Technologies/Languages/Tools/Methodologies that facilitate/impede 10x?
[X] 10x in other professions?
I feel there is a cycle to this 10x talk on HN. Roughly twice a year, some post will trigger this event, at which and a series of posts are made and new articles written, as if oblivious the the last cycle.
Whilst the simplification of the problem into a headline of 10x might be irksome to you, I think it is a symptom of a real problem.
Do people accurately value devs. I've never seen any evidence of it.
The free market doesn't really judge things on a long term quality, this problem isn't unique to software.
To generalise it as "superstar devs are the most awesome" and "bad devs are useless" isn't going to help matters either.
After all, we've all surely had a single line of code, which had been XP written, fully TDD with a good peer review, conducted entirely by superstars, then found it to contain a massive bug.
Micro or Macro level mistakes create problems, often the mistakes are very hard to understand. Even the very best will make 'mistakes', sometimes they might be unlucky and that mistake will become very costly.
If you want to talk about 10x devs, talk about understanding the value of what they do at every level. Otherwise you will have no idea what you have working for you.
Yes. I keep good developers in my contact list and look to hire them or refer others to them when I have an opportunity or they need a job. If you're not seeing evidence of it, you're either not moving in hiring circles or you're not moving in developer circles that are distinguishing themselves through the quality of their work.
The free market doesn't really judge things on a long term quality
Of course it does. It judges long term quality exactly as much as it feels it needs to.
Even the very best will make 'mistakes'
Isn't that a given? Good hiring managers or purveyors of talent will take a long statistical view on the abilities of developers (or anyone else working for/with them).
Far worse for the industry than all these supposedly awful programmers out there is the rampant egotism that dominates developer culture, and that's where this ridiculous 10x obsession comes from.
As good as some developers can be and as bad as others can be, even the best will routinely make severe mistakes and write bad code. Aspiring to be some sort of god among programmers won't actually make you great, it will just make you arrogant and unable to see your own failings and ignorance, which will always be vast compared to your skills and knowledge.
On the other side, it isn't fluffy snowflake talk to say that every human being has his or her areas of strength and exceptional insight. Helping less experienced programmers on a team learn and grow, and figuring out how they can contribute productively without causing problems is likely worth a much bigger bonus than one guru who thinks his shit doesn't stink and talks down to everyone else. According to Zen, the beginner's state of mind is ideal because it is free of preconceptions. Someone who believes the ideas of a novice are beneath him will be blind to a lot of wisdom.
As a last aside, every team I've ever worked on that inherits code thinks the code is shit and rewrites it. Then when some other team inherits the rewritten code, they proclaim it shit and rewrite it again. Some percentage of this is due to bad code. Some is because all complex applications which are developed in a hurry in shifting business environments end up pretty hairy. And the rest is because almost all complicated code looks like shit when it's unfamiliar, even if it's fairly well engineered. So you'll throw it out and run into all the same issues on your rewrite and your code will end up just as opaque, but you'll understand it now so you'll think it's brilliant, and then you'll write self-congratulatory blog posts about how great you are and how terrible everyone else is, blissfully oblivious that in 3 months, a new developer will take on the project and rewrite it and write the same exact blog post out of imperious disgust for your work.
I agree with a lot of your points; ego is a dangerous thing. However, I think it's important to differentiate between the two major types of rewrites (or claims as to why something should be rewritten): 1) The code is obviously subpar vs. 2) the programmer doesn't understand the code.
I've had to deal with code written by 3rd parties where I doubted the person was actually a programmer who wrote it; nonsensical or nonexistent naming conventions, large methods of dubious logic that were often never actually called (anymore?), and a general avoidance of best practices (and I don't mean advanced code; even simple things like code comments along the lines of "this is a for loop").
#2 is a different beast altogether and I think this more applies to your last paragraph. Is the source code too advanced for the programmer reading it, or is the code/architecture too obtuse? Unfortunately, I think it's often primarily programmer laziness more so than the design itself. I've been told by devs they don't understand a system and when asked what they don't understand, they simply shrug their shoulders. If you don't make an attempt to "get" the current system, in no way should you be allowed to rewrite it from scratch. You need to at least learn the mistakes of the current system.
Personally I think it's rare that rewriting subpar code is a great idea. Some refactoring is frequently in order, but that's true in general. Even understanding the faults of an existing system, it's a big undertaking to rebuild it and make it better in one go.
There is a certain class of code that is not merely subpar but actually can be easily rewritten with 1/10th the code and will be less buggy as a result. We may be talking about the same thing, but if so I think "subpar" is being too polite for code that will actually benefit from a rewrite.
Far worse for the industry than all these supposedly awful programmers out there is the rampant egotism that dominates developer culture, and that's where this ridiculous 10x obsession comes from.
In comparison to the psychopathic, dishonest, and often destructive class of narcissistic "executives" who run the mainstream business world, I'd say that the mildly-annoying social mediocrity of "10x developers" is a non-concern. Often, when a software engineer says "this won't work", it's because it actually won't work.
The reason why we have the 10x developer myth is that by the definition the author uses "good" developers are rare and "bad" developers are extremely common.
Entire development teams consist of such bad developers. Many of us worked in such teams at one time or another, and it's part what makes us so obsessed with quality and good development practices.
We're dealing with the unprecedented reality that software is already everywhere, but the process of identifying and training good developers has barely started. Most companies that develop software don't even supply their programmers with the proper tools and work environment. It's like living in a world where everyone has a car, but only 90% of all mechanics aren't capable of doing more than just applying some duct-tape, and most garages are ill-equipped barns.
Most software is appallingly badly made, and has a very short lifespan.
And no, this is not just because technology moves so fast. Most of the languages we code in are almost 20 years old, and the techniques and conventions for coding in them even older. Core architectures are based on design conventions that existed before most of us started programming. The fast innovation mostly happens around the edges.
Software development is a ridiculously immature profession compared to it's social and economic importance, and the majority of programmers are as incompetent as a neanderthal with a chemistry set.
To abstract and paraphrase (wildly): there are 10x work environments, and 1/10x work environments.
It seems to me that the least productive environments let "now" trump "great" – so attracting (and retaining) the top 0.1% of talent becomes necessary for a company to survive. I wonder which costs more in the long run.
When I make technical decisions, I think hard about how to keep things simple so that a reasonably smart and attentive person can use or extend whatever system down the road.
Most of the languages we code in are almost 20 years old, and the techniques and conventions for coding in them even older. Core architectures are based on design conventions that existed before most of us started programming. The fast innovation mostly happens around the edges.
We have more cores and memory caches and our address spaces have gotten larger but the most popular computer design, if I am not mistaken, is still the register-based machine. In that case despite advances in hardware, C and it's derivatives have scaled rather well to the problems at hand.
Given a sufficient proficiency for abstraction an evaluator should be capable of emulating any machine required to run a given process. Which is what has allowed Lisp based languages to scale and continue to be relevant over the last 50 years.
Some developers talk about "age," like it's a bad thing.
What all these 10x developer posts miss is really simple. 10x developer may not even work that fast. He might seem extremely slow to those around him. However 10x developers bring TCO of a system waaay below all the "I did this in a weekend" crowd.
10x developer thinks and implements just the right level of abstraction, does just enough testing and implements just enough unit testing. He will think of the forest and will not blindly howl at the trees.
I would go and write a blog post about it to harvest some free karma. But I am just too busy/lazy to do it.
However my point is that all the OP and everybody posting their blogs are ignorant pricks and should really at the very least read and try to understand the Mythical Man Month from Brooks, before they go and start overloading a perfectly fine and understandable term.
My gut feeling, based on years of experience in making unsubstantiated claims, is that the best developers are e^(i*pi) more productive than the worse ones. The measure I have chosen is the number of bugs per square centimetre of screen code in 12pt Comic Sans font.
OP correctly points out that productivity and monetary value created are non-linear and extremely problematic to measure for the software development profession. More importantly, OP reminds us that software dev is far from being the only career for which this is the case.
In "convex" work, as michaelochurch calls it, most of the time you are actually contributing less value than you are being paid for, if you are drawing a salary. Some days your work might contribute no direct value at all, or even subtract value. But occasionally, by creating something new that itself generates value, you can contribute exponentially more value than you are being paid for. But you still only get your salary. Because taking a salaried job is selling your downside risk along with the potential upside reward to buy income stability.
A "10x developer" isn't someone who writes 10x more LOC or even contributes 10x more valuable software on a daily basis. It's a developer who is able to occasionally make those big breakthroughs that you hope for when you're doing convex work.
The point Paul Graham (and the 10x hustler article) made was that if you are good, you could be 10 times more productive.
Not because you type 10 times faster or develop the same code 10 times faster than somebody else, it is because none of the big coorporation bureaucracy slows you down and you can choose whatever technology you want and don't have the burden of code that is growing in size and complexity that you have to maintain.
I think this was actually just another 1/10th developer article. There's developers that are worth paying, and then there are those developers that actually subtract value from your company by creating such a hacky mess that it costs more to fix it than it did to write it in the first place.
I've worked with one of those. We'll be cleaning up his code for years.
I'd have to agree with the article. When you talk about your doctor, you don't say you have a 1X doctor vs a 10X doctor and that with the 10X doctor you'll heal up 10 times as quickly.
10X is real. Spend some time in the enterprise. There really are programmers who only write 10 lines of code per day, maintaining bullshit that should have been taken out to pasture years ago, and who "flip the switch" on learning at age 23. And they're paid good money for it, too! Probably more than 90+ percent of the people here.
It's not necessarily "10". It's somewhere between 1.5 and 1000 depending on the project. It's 2-3x for typical business work; 10+ for infrastructural work that multiplies across the company (i.e. makes everyone more productive). I'm writing about developer economics (Part 22 of a series that was supposed to be 22 parts, but will be 23).
What 10X means is: give me a million bucks a year, or let me have 90% autonomy, or we both lose. And if more developers took that attitude, we'd have better software, more learning, and a better fucking world, too.
Ok, I declare myself winner of this thread and I am taking it home with me.
I have a piece that's coming out soon on this, but we need to rethink how we're measuring "10x." Is it speed of code? I know people who can write thousands of lines of poorly formatted code quickly. Is it the breadth of knowledge of the field and domain? I'll show you 10 lines of code in shell that can solve a client's problem. It's entirely possible to be slow but efficient.
Is it pure focus and dedication? I know people who can code 10 hours a day, others who can only code 3 hours before their brain is tired. Knowing which is which doesn't tell you who is the more productive programmer.
Perhaps it's the "smart" one. I know people who can solve deep problems, but they can't code a business app quickly. Yet we treat the two as the same developer skill. And what of someone who excels at clean code? Does this say anything about their skill in general?
All this is compounded by the way a developer presents themselves. We don't know if Steve Yegge is a great programmer or not, but he sounds like one. I've seen a lot of people who sound great. What if this is a skill in and of itself? If you can have a developer who can sit down with a customer who is angry, calm them down, find their needs and pain points, and create a small solution that's ugly as hell on the inside but serves the client's needs, is that a good developer?
Perhaps we need to step back and re-evaluate what 10x actually means.
It's from 0.0 to 3.0, and the vast majority of professional programmers are in the 1.0 to 1.9 range. I consider myself a 1.8 with a 95% confidence interval at [1.55, 1.95] (more room on the left, because inaccuracy in self-measurement would correspond with lower ability; cf. Dunning-Kruger).
The 1.0 level is basic professional competence-- you could get hired to write bank software. What most people call "10X" is 1.7-2.0, but there are so many contextual factors that it's hard to say how it really plays out. In some jobs, the 2.0 is worth 100 times more than the 1.0; in others, she's only worth 50% more; in still others, she's worth less than a 1.0 because she'll fight the existing way of doing things.
It's not necessarily "10". It's somewhere between 1.5 and 1000 depending on the project. It's 2-3x for typical business work; 10+ for infrastructural work that multiplies across the company (i.e. makes everyone more productive). I'm writing about developer economics (Part 22 of a series that was supposed to be 22 parts, but will be 23).
in other words, it's all about leverage. 10x in the abstract probably doesn't make sense, but a good developer that is able to leverage that ability can produce real value.
and of course, the opposite is true. if a cowboy style developer produces a ton of work while taking on technical debt, and this isn't probably accounted for, the technical debt can spiral out of control. this of course slows everybody else down, and the cowboy's reputation as the 10x is reinforced ... yeah, i've been there ... no i'm not bitter.
