Clearly the idea of the 10xer has too big a place in the mythology of our industry. It's oddly masochistic and as far as I know it's unique to us. There are no doctors blogging about "10x doctors" for example.
Anybody who has watched N0tch code on Twitch knows that there are certainly people who are far more productive coders than the average engineer. I have no idea if he's coding 10x faster than I could but it's probably close. And my ego is... healthy sized. But it ignores the truth that few of us work as "programmers." A software engineer has many responsibilities and doing the other things well brings a force multiplier to your work.
I personally subscribe to the belief that we all have a superpower or two, and figuring them out and pressing their advantage is a strong catalyst to success. So figure out what you 10x at and be happy for it.
I wouldn't be surprised to hear there's a 10x difference in, say, error rates between the best and worst doctors. In fact, I'm almost definitely sure that's a lower bound, given my experiences with doctors in third world countries. Barbaric, some of them still are. Depending how bad the worse doctors are, 10x from "average" might be reasonable.
In software development, I think that 10x number is also a lower bound if anything. Bad developers are everywhere, churning out volumes of terrible, pointless, code. In a code review a while back for a client, I made an offhanded comment about a minor thing like "make sure this list is sorted and deduped". The code owner then started "discussing" that and estimated it'd take about 2 hours. I was stunned and added the code ".Distinct().OrderBy(...)" right there in the review. I'm at a loss at how to explain that kind of difference, and that's on a micro-scale.
At the other end, I've seen projects/companies go down colossally wrong paths because they simply couldn't understand basic algorithmic complexity. So, say, I dunno, a week or two to do it right, versus a year spent chasing down fake paths? That doesn't even measure the business impact of floundering around for a year while impacting customers.
Focusing on "coding 10x faster" is simply misleading. Like measuring an author based on how fast they can type.
Doctors are also somewhat "presorted" by ability. Certain specialities just aren't attainable by any but the most "gifted", whatever this means in that context, for example tenacity, ability to remember vast amounts of facts and, of course, dexterity.
Objective Performance in doctors is harder to judge than in developers. Some specialities lose a high percentage of patients no matter how good the doctors are. Sometimes even a difference of "10x" in error rates may require more cases to judge than a particular doctor actually has in a year.
10x difference between error rates? No, this is not the case. Well, it might be in some special situations, like a scammer and a specialist, but you'll wont find that in the case of GPs, for example. Obviously you should only compare doctors on the same field (N0tch would be quite unproductive if he suddenly had to work with COBOL, for example), and between those the difference is measured in percentages, not 1000 percentages. (I can dig up the data if you want but I definitely read this when I recently had to look into diagnostic errors.)
I would be interested in the source and how they defined the error rate. (Although I'm not sure error rates are the best way to define a doctors "productivity")
Are you taking into account doctors in shitty countries? I've personally seen people seriously harmed and killed due to what, in the US, would be viewed as criminal intent. Yet inside such a country, the cases were viewed as nothing notable.
And are you really saying that inside the US, there are no practitioners with an error of 1/1000 where another one has 10/1000? That seems awfully tight.
"The Stakhanovite movement was named after Aleksei Stakhanov, who had mined 102 tons of coal in less than 6 hours (14 times his quota).[1] However, his record would soon be "broken" by his followers.[1] On February 1, 1936, it was reported that Nikita Izotov had mined 607 tons of coal in a single shift.
The Stakhanovite movement, supported and led by the Communist Party, soon spread over other industries of the Soviet Union.[2] "
Basically all this 10x is just a way to make people produce 10x while paying still for 1x. Programmers as a blue colar job also subject to it. White collar jobs like doctors or real engineers are much more resistant to it (as psychologically they are individuals not a member of a crowd what is typical for blue collar jobs)
Thank you for this link, here's a great quote from there:
> The Stakhanovites were responsible for organizing the two-hundreders movement (Russian: двухсотники, or dvukhsotniki; 200% or more of quota in a single shift) and one-thousanders movement (Russian: тысячники, or tysyachniki; 1000% of the norm in a shift)
The idea of "one-thousanders" movement is numerically identical and almost linguistically identical to the "10xer" movement.
"Basically all this 10x is just a way to make people produce 10x while paying still for 1x. "
Actually, I see it more frequently referenced as reason to pay people more than 1x based on productivity. There are some that deny 10x productivity exists, which is the controversy around it that I am most familiar with. If you are an order of magnitude more productive than your peers, but paid only marginally more, this becomes an incentive to start your own business, or join one where you significant equity, where you will be able to capture more of the value.
Not blue-collar because we wear blue collars or perform physical labour, but because programmers are not professionals - we're not architects, we're bricklayers.
In the conventional business mindset programmers just implement a plan devised by someone else. Consequently we are fungible (easily replaced by cheaper alternatives), and a cost rather than an asset.
That's like arguing that surgeons are performing a blue collar job when they're given a diagnosis and test results from another physician. In theory they're performing the same repetitive motion, just like programmers are in theory creating an implementation to solve a given problem.
However, there are provably good and bad surgeons and provably good and bad programmers. The reality is that you're making a lot of decisions when you cut out a tumor or implement a spec, decisions which take skill and practice to get right. I certainly wouldn't want my surgeon to be a cheaper alternative, nor would I want a programmer working for me to be the same. Not all programmers or surgeons are equivalent, since there is a large element of skill and practice.
Surgeons are briefed on the problem, the diagnosis, the patient's medical history, given all the information they need to know about the project. They are then locked in a small room with all the tools and assistants they need, and given complete and total authority and autonomy over the process and results. Because of that, surgeons are some of the most respected people in their environments.
Programmers are dripfed information on a "need-to-know" basis by managers who have no clue about the process involved (and therefore with no clue about what information is needed). They are then placed in an open area, interrupted regularly, have to justify the cost of any tools, are never given assistants, and have exactly zero authority or autonomy over the process or results. Because of that, programmers are some of the least respected people in their environment.
But we do have a few things in common: if the patient dies it's the surgeon's fault, and if the project fails then it's the programmer's fault.
This stark comparison is exactly why we're blue-collar workers not professionals.
I see your point. I'd argue that programmers who are treated that way have bad managers, though, rather than it being a function of programming as a profession. I've never dealt with a company that hasn't given me some autonomy, though, so I can't really comment on that perspective.
A company can give programmers autonomy, or it can give them bits of information and treat them poorly. It could also do this for its sales team, its lawyers, or its marketing department. This strikes me more as a problem with the company rather than a problem with the nature of programming.
Yeah, there are business out there who treat programmers "properly", but they're unfortunately the exception rather than the rule, and that's not going to change any time soon.
I push back when the business hands me implementation in requirements (e.g. "Make me a button that rings a bell 10 seconds after I click it" versus "I need to know when a query finishes; it usually takes 10 seconds." which leads to "holy CRAP, that query takes 10 seconds?! Lets solve that!").
The first few times I did it, it caused a bit of an uproar, but very quickly they came to realize that they got better quality software when the person making it understood why he was making it.
Likewise, if you're in an environment where you're an eyes-down bricklayer (and unhappy about it)... Maybe it's time to put your big-boy pants on.
I agree, and I've done the same, but I do find it ridiculous that we have to be the ones to fight the battle.
This is all known stuff, there's endless research and case studies showing that providing creative programmers with autonomy and authority over their environment creates massively better software results.
But the illusion of control is hard for some people to let go, I guess.
>Programmers are dripfed information on a "need-to-know" basis by managers who have no clue about the process involved (and therefore with no clue about what information is needed). They are then placed in an open area, interrupted regularly, have to justify the cost of any tools, are never given assistants, and have exactly zero authority or autonomy over the process or results. Because of that, programmers are some of the least respected people in their environment.
That doesn't describe my job very well. (OK, I don't have an assistant, but I don't think I need one.)
Or are you deliberately making a contrast between "coders" and "software engineers"?
>They are then locked in a small room with all the tools and assistants they need, and given complete and total authority and autonomy over the process and results.
A surgeon of that level would be more analogous to a very senior programmer with management responsibilities. Said surgeon only got to that point after years of working very long hours with little autonomy.
And surgeons only get that autonomy for a fraction of their day, every doctor I've ever met complains about hospital and insurance company bureaucracies.
If you want to compare a bunch of 20-40 year old programmers sitting in an office plan at facebook to doctors, you'd do better comparing them to ER residents who definitely don't have the kind of autonomy you're talking about.
There are also plenty of "professional" programmers working as consultants.
But from my understanding of the health industry, the consultants are absolutely the top of the food chain despite their whinges about management. This is not true of even highly-paid consultant programmers (and highly-paid tech consultants are almost never allowed to waste their time actually programming).
>and highly-paid tech consultants are almost never allowed to waste their time actually programming
There are plenty of niche programming consultants that are highly paid to actually program--firmware reverse engineering, and cryptographic security specialists are 2 of them.
There was a whole thread a few years ago where tptacek argued that $400 an hour is reasonable for certain specialty programmers, which is more than all but the highest paid surgeons make.
He gave 4 example categories: "expert developers with domain expertise in finance" also "cryptographic security specialists", "hardware reverse engineers", and "high-end SEO"
true, good point, but I still think (from my vast stock of unresearched and ill-informed opinions) that the combination of authority and respect is massively more common in surgeons than it is in programmers.
And if it isn't actually, then it certainly is in the public consciousness.
I'm much more familiar with "Here is this problem space that there's great rewards in addressing successfully, we don't actually know how to address that problem space, we can just see that it needs to be addressed because of (business indicators a-z). Can you help us address this problem space?" And then figuring out how to do that + implementing it (if it's actually possible at all).
Is this not programming?
Programmers are dripfed information on a "need-to-know" basis by managers who have no clue about the process involved (and therefore with no clue about what information is needed). They are then placed in an open area, interrupted regularly, have to justify the cost of any tools, are never given assistants, and have exactly zero authority or autonomy over the process or results. Because of that, programmers are some of the least respected people in their environment.
That sounds horrifying, how on earth are you ever expected to accomplish anything worthwhile in such an environment, and in the present ultra-competitive market, why would anyone tolerate being treated that way?
> we're not architects, we're bricklayers. In the conventional business mindset programmers just implement a plan devised by someone else.
I think this analogy is wrong. Like architects, we can and must help requesters understand what's possible. "Architect, please design me a house supported by tiny pillars." "Programmer, please solve the traveling salesman problem for me."
> Consequently we are fungible (easily replaced by cheaper alternatives), and a cost rather than an asset.
The more central to a business their code is, the more this mindset will hurt them.
That is how we are often treated. That is also (one of many reasons) why large projects constantly fail (or else go so massively over budget that you should still call it a failure).
"Clearly the idea of the 10xer has too big a place in the mythology of our industry. It's oddly masochistic and as far as I know it's unique to us. There are no doctors blogging about "10x doctors" for example."
It takes 6-8 years of intense training to become a doctor. This is after already doing well in college and passing a tough skills/general intelligence test.
The bottom 70%+ who want to become doctors are simply not able to get through the system. If we got rid of the bottom 70% of developers we wouldn't be having these 10x conversations either.
How do you justify the 70% number? Do a Google site search of healthgrades.com and you'll find doctors practicing in America who graduated from American University of The Caribbean, which is among the lowest regarded of medical schools American doctors attend. I don't think admission into this university is difficult.
I don't think it's a given that someone with excellent grades in high school/college could become a good doctor, even with training. The same goes for a programmer.
I've been in the industry for >20 years. I've met 2 engineers/programmers that some would call the mythical 10x engineer. These are engineers that you can literally build your entire company on their shoulders because they do everything and they do everything with very few mistakes. The problem with the term is that everyone thinks they are 10x engineers, when they aren't. As I've mentioned, there were only 2 people I've met in 20+ years, so they are basically like unicorns.
One of them was the VP of Engineering for the startup I was working at. He was and continues to be brilliant. He was online almost every hour of the week/day and he was always working. He singlehandedly kept our site up by himself, and when he left, it literally took 5 engineers to replace the work that he did. His leaving left such an impact that the Engineering team almost disintegrated because of how much work we had to take on, and the lack of any truly great engineers to mentor the other engineers.
The other was a friend of mine who was the most productive coder I'd ever met. He would also work as hard as I've ever seen anyone work, and the code that he produced did things I've never seen people do since then. Tragically, he committed suicide 2 months ago, and it's heartbreaking. Probably the intensity to which he coded reflected on the intensity that he pursued every other thing in his life, and when things didn't work out his way, like his marriage, it probably hit him much harder than it would a regular person, who would be rightfully devastated.
Not many people can work that much in raw hours, and be as productive for each of those hours as someone who works normally are during each business hour.
10x engineers do not work 10x harder or produce 10x code. What they do is write code that is 10x better, in that it has few problems, few design errors, does not have to be rewritten (at great cost), is more adaptable, maintainable, etc. They make the right decisions up front about the approach to make.
For example, they can select the right approach to concurrency for a particular problem, rather than spending much time later chasing concurrency bugs.
But you are likely aware that this type of 10x engineer is not who the vast majority of corporate managers and "non-technical" start-up founders are thinking of when they describe a 10x engineer. For them, a 10x engineer is simply one who produces code 10x as fast as the other engineers.
In fact, simply writing code 10x as fast as usual is not a difficult task for a competent developer to accomplish. With significant overtime, and reckless abandon, any skilled developer can churn out poorly thought-out code at a rate roughly 10x greater than the rate at which a skilled developer can write well-designed, tested, documented, refactored code.
This is why we have so many "10x" engineers, and so much technical debt.
Its rather strange you would bring up Notch, as I wouldn't consider Notch-run Minecraft a marvel of engineering. I'd hate to be the guy who cleans up after him, and while Minecraft works (and it is a really great game), most people consider to be terribly built.[1] So yes, while Notch is a rather speedy engineer, I wouldn't consider the skills of an engineer based on how fast they code. Maintainability is an important feature (however, at the same time maybe building a house of cards really quick than flipping it to Microsoft for 1B, maybe ignoring maintainability is not so bad).
game devs like notch have made a conscious and canny decision to value actually making something over code quality. also, notch didn't build minecraft expecting it to be a runaway success.
see, you are a programmer - you make code. notch is a game developer. he USES code to make THINGS. the things matter, not the code. the game developer ethic is "nothing matters but getting the game running." it's not that notch is a shoddy programmer at all, it's that he has different priorities than you.
game devs like notch have made a conscious and canny decision to value actually making something over code quality.
These aren't mutually exclusive. When Carmack, Sweeney et al. built Quake/Unreal, they made something that was both fun and had incredible code quality. Derivatives of the Quake & Unreal engines run today and have been for the last 20 years. I'm doubtful that any code written by Notch for Minecraft will be running anywhere 20 years from now. Likewise, don't NASA engineers "actually make something" while adhering to strict code quality? Doesn't Google "actually make something" while adhering to strict code quality? The choice between "code quality" and "actually delivering" is a false dichotomy invented by people who needed an excuse.
Next, I never implied Notch was a shoddy programmer. Notch is a great programmer by his own merits and I don't think anyone can doubt that - however great programmers can produce shitty code. What I was responding to was OPs assertion that 10x programmers exist. Notch produced some pretty great stuff, and iterated quickly, but that speed didn't come free and surely theres a lot of technical debt that others now have to deal with.
Lastly, I'm not saying this is a bad thing. Sometimes its more important that you can ship first, and fix later. Sometimes being first to market is better than being the best. What I want to point out however this is a normal tradeoff and this doesn't make Notch a "10x engineer" (when I say 10x here I mean a mythical man who has achieved enlightenment that none of us can achieve even if we worked for 1000 years). He's a great developer, but we shouldn't pretend that there weren't tradeoffs to his approach and that his style is anyway mythical (like a unicorn).
uhh...when you mention NASA engineers and Google "actually making something" while adhering to strict code quality you seem to overlook the fact that NASA and Google are organizations with thousands of developers and notch is ONE GUY.
the point is that game development is inherently a big job and you have to make massive tradeoffs if you want to get something working in a reasonable amount of time by yourself. of course if you have thousands of people to throw at the problem you can go nuts and adhere to the highest of quality standards.
but i agree that notch isn't a mythical programmer or "10x engineer".
uhh...when you mention NASA engineers and Google "actually making something" while adhering to strict code quality you seem to overlook the fact that NASA and Google are organizations with thousands of developers and notch is ONE GUY.
And Tim Sweeney did a lot of development on Unreal 4 on his own[1]. The trade offs of structure & abandon can work at many scales, you don't have to be Google to do it. Likewise Redis[2] has largely been the work of a single developer, and isn't reckless.
Now while Minecraft is a toy and Notch likely didn't start out with the thought to develop it into a business, that doesn't mean the value of its code is worthless. Yes the tradeoffs are there, but we shouldn't get carried away and start to believe you can only write "good" code if you have a thousand engineers.
I think we all use code to make things. However, not caring about the code can spell disaster for the thing we're making. In the case of Minecraft it appears the code is good enough but I wonder how many more features would exist if it wasn't for the poor design.
worth noting that games have a fairly short half-life normally, so dev's are writing a new game rather than adding features to an existing legacy game (unlike mainstream software development). You also get to vary the scope of the game as the time budget runs out.
Minecraft is fun. However I'd clearly state that Minecraft, especially the early multi-player stuff that Notch worked on, /was/ a disaster.
Only now, three numbering schemes later (alpha, beta, release), in release version 1.8, does the core game actually have features such as abstracting implementation IDs from object types (EG: now there is minecraft:glass to resolve instead of remembering decimal value 20. Though mods for r1.8 are only just beginning, so that scoping might not yet exist.)
Even though Minecraft is not top quality code, you've provided very weak source. See [0] which provided memory usage analysis, that turn out pretty bad. It credits Notch (remember that he stopped working on the game at some point) as author of more optimal code, though ("The original Notch code (pre 1.3) was allocating about 10-20 MB/sec which was much more easy to control and optimize.").
There are other problems with original Minecraft, that surfaced when people started to actively disassemble (or deobfuscate) it. But those are mostly unsourced, and I do not feel the authority to speak about it.
Not all code has to be a platform. It's entirely acceptable to write code that "just works" and does not pretend to be 'future proof' or any nonsense like that.
In YC they tell you the same thing: just write the hell out of it and get it done. You will rewrite everything later anyway when you know more about the business and the customers. Games work a bit different, but the lesson applies.
Yes good engineering is important, and Google is a great example. Do you think the code Larry and Sergey wrote early on was anything close to shippable code at Google today? I guarantee you it was a mess of python scripts and c libraries.
YAGNI. Make your product the edifice, not your code.
> There are no doctors blogging about "10x doctors" for example.
Sure there are. Unlike programming where most of it is unique, and that stuff that's not is widely dismissed as "crud" (create update delete), with Dr's almost all of their work is routine.
Except when it's not, and when you have difficult cases you most DEFINITELY have 10x Dr's.
Have you never heard stories of patients going from Dr. to Dr. trying to figure out what's wrong with them, until they find that one genius Dr. who finally figures it out?
And regarding blogging, that's what the entire series of columns on NYT called "Think like a Doctor" is!
"Have you never heard stories of patients going from Dr. to Dr. trying to figure out what's wrong with them, until they find that one genius Dr. who finally figures it out?"
Part of that is throwing die after die until a six comes up. The die that gives a six need not have _anything_ to do with it.
N0tch's Twitch streams are rather misleading. It seems like he has incredible speed and productivity but that's mainly because he's repeating a well-rehearsed implementation.
[1] When writing code to solve problems I've encountered frequently in one of the languages I've used long enough to thoroughly memorize all facets of the syntax and most of the available libraries.
[2] Consistently using those 10x powers would quite possibly be the most boring life I could imagine as a software engineer ... give me a hard problem to solve once, then never ask me about that problem again!
I strongly agree with your point [1]. I think the 10x programmer exists, and the phenomenon is primarily as you describe: you spend a long time figuring out how to do something with a lot of moving parts and hidden gotchas. You eventually track down every bug, resolve every misunderstanding, reorganize and simplify, and you remember what you learned.
Next time something similar arises, you blow the doors off anyone else starting from scratch. I've done it myself, and it has be to quite common.
I disagree with your point [2], though, at least in part. I would get bored, too, if all I ever did was to repeat things I had figured out years earlier, but if I put the effort into figuring out how to do something hard, I want to USE that hard-earned knowledge more than once. I don't want to always be a slow, awkward newbie at everything I do, which is what I am the first time I tackle most new, serious challenges, but I don't want to stop tackling new challenges either. I'd prefer a mix of the two: sometimes a newbie, sometimes an expert.
I think we actually agree on point [2] ... using the hard-earned knowledge again while solving a new problem (of sufficient complexity) still requires significant problem-solving (puzzle solving?) skills. I've also mastered making web interfaces that perform CRUD operations against databases ... I don't want to spend my career reliving the ground-hog day of CRUD interfaces.
I still think we disagree a little on [2], but I love your "Groundhog Day" metaphor. It's perfect, couldn't be better. If you've seen the Bill Murray movie Groundhog Day, you'll know what I mean when I say that sometimes that's exactly what I want. I want to be the guy who has lived this day before and looks like a genius to all those mere mortals who are experiencing it for the first time. It feels great to have such a huge advantage, especially when it was earned.
But, like you, I don't want to be stuck there. I want to experience it often, but I want to have plenty of new days, too.
Every time I see someone challenging the notion that there could truly be developers who are an order of magnitude better than average (faster, fewer bugs, more maintainable code, etc), I can only conclude that either:
A) The person posting simply hasn't had the pleasure of working with such awesomeness.
B) The person is threatened by the possibility of 10X'ers really existing, since that's a threat to their own ego.
I'm a great programmer, and still know many people who leave me in the dust. I'm glad for that.
"The vanity of others offends our taste only when it offends our vanity" -- Nietzsche
Or give them an office to think their 10x thoughts in when you can have them elbow to elbow and back to back with your most chatty, whistling, foot-tapping, phone-using employees.
If one person can really do the work of ten, you can save money on overhead:
- Fewer managers - a group of 10 will probably require a programming lead who spends some fraction of their time not coding.
- One tenth the amount of office space and hardware.
- Only paying for one person's health insurance instead of ten peoples'.
- Vastly reduced communications overhead - a team of 10 people is going to spend a lot of time communicating with each other to insure that everyone is doing what they need to be doing.
So I'm guessing you'll come out ahead even if you do pay ten times more for ten times the productivity. But companies rarely even pay twice as much for a developer who is exceptionally productive.
The downside of having one person doing the work of ten is that it's a disaster when the person decides to quit - it's the equivalent of a whole team of people simultaneously quitting.
Well, yeah, if you actually pay <10x when all is counted but get an actual 10x more, then you will have gained, but grandparent said "they won't pay 10x for 10x."
My tongue is in my cheek or some other such place right now because I kinda find this 10x business a bit funny, given that we can't even roughly quantify productivity. The thing I do believe in is that some people fit some kinds of work so well that it's silly to consider many other seemingly similarly qualified people as a practical alternative; as in, a hammer is good at hammering and it's not a question of it being 10x better than a shoe or 5x, it's just silly to hammer with a shoe, just don't do it. This is obvious but if phrased as "hammers are 10x shoes", it loses its obviousness and gains ridiculousness.
Still sounds like a win to me. Think of The Mythical Man-Month.
Do you want a kitchen with 10 chefs and the coordination that demands, or a kitchen with 1 chef that is just as productive as the raw sum of the 10 chefs? Assuming that the productivity of each chef was tested in isolation.
While I agree with you, at least in part a few problems here as mentioned by the previous replies.
As far as N0tch, I think that's a bad person to compare yourself against. While I can respect what he achieved and envy his good luck, he is hardly what many would call a good programmer. My standards may be different than others. He may code fast compared to some people (and slower than others), but code speed/output != productivity. Judging by the state of Minecraft and bug counts of what he's done, one could do the same by shifting emphasis or priorities on getting something usable vs. bug free. It is more correct as you imply that other things are just as valuable or perhaps more. It all depends on context. N0tch might be a great prototype programmer, but a terrible programmer for writing banking software and sending things into space. We still don't have many good ways to judge people, which is why dumb managers look at things like lines of code or total hours.
Indeed we know that many factors influence productivity - familiarity with the task and technologies involved, language choice, library choice, deadlines, environment, external influences, and so on. This sick culture of work will make you free is not a good one. I do believe though that many good developers who can work together in a group (very important) are better than having 100x as many people who are bad coders. It really depends how big or small a team is, how it is managed or not, and so on. Having a team of only the best coders isn't enough and can actually seal the doom of a project.
It is hard to quantify programmer productivity objectively, but most of us know subjectively when we are productive and when we are not and the difference that can make. If at my baseline I am 1x, at my peak productivity I can easily see myself being at 5-15x. (How this works and how to induce this boost is a separate discussion). I believe others experience what I am talking about. From here it isn't a far leap to think that another developer may just work at that pace naturally all the time.
I think this is the basis for the 10x developer mythos. Whether there is a great variation or Notch just recorded himself on days when he felt really productive (or the fact of recording himself made him productive) remains debatable.
Then again, I have seen my share of the 1/10x programmers, so it is possible that it is all relative. In either case, like you said, programming a computer is only a part of the job for most people. Gathering requirements, building a product, selling it, supporting it, marketing, all factor in. Otherwise, you might say that all a car mechanic ever does is change the oil.
Faster had nothing to do with it. If anything these guys code slower. 1 line of brilliant code will always beat 10 lines of mediocre code typed very fast though
I love to write code. And it's about 20% of my job. As an engineer, I spend most of my time in design (and meetings). The code is the fun, relaxing part.
Many times, I don't even write code; I "review" code. We have "grunts" (younger programmers, usually) who pump out code all day. They're are involved in design too, of course. But in a very limited way.
But you know, I think all of this comes with age. If you 22 years old, fresh out of school, you are going to be writing code all day. And that's how it should be, You need to cut-your-teeth.
Also, one last thought, just being a [overly] productive programmer doesn't make you a good programmer. I'd rather someone take there time, be comfortable and get it right.
But I have met that rare bird, who is confortable writing code 18 hours a day.
> If you 22 years old, fresh out of school, you are going to be writing code all day. And that's how it should be, You need to cut-your-teeth.
I'm 22 years old, fresh out of school and I'm as involved in design, recruiting and peer reviews as my older peers. And that's how it should be. Why? Because age has nothing to do with productivity, understanding or ability to come up with simple, elegant and maintainable designs.
Experience has a lot to do with productivity, understanding, and the ability to come up with simple, elegant, and maintainable designs. The "22 years old, fresh out of school" programmer is more pointed at the inexperienced individual rather than age itself. I would say the same comments could apply equally to 38-year old programmers that just started work after graduating from a hacker school. The fact is, when so many problems are merely iterations of previous ones, how can you ignore the wisdom of people that have been doing the same work for 20-30 years? It's ludicrous to believe that the contributions coming from a fresh grad with no practical experience will be on par with the quality of the solutions from programmers much more experienced.
Age and experience have everything to do to come up with efficient software architectures, except on trivial problems. Every coder I know (and I know 2 that are world class) look at his/her old code with regrets, and a kind an awe saying "What I was thinking ?".
You will improve with time. Coding is no different than any skill.
While age might not have anything to do with productivity, experience definitely has. Especially when it comes to recognizing which problems are worth solving and giving (appropriate) pushback to product owners and managers.
Think of it as an apprenticeship: university doesn't give you the experience to jump in as a senior dev, but you'll eventually get there with practice and mentorship from an experienced dev.
Every 22 year old thinks they can do everything just as well coming out of school...very rarely are they right, and looking back just 5 years later provides a lot of different perspective.
So you have no experience and you are just as involved in design? I could see that maybe for UX, but not for engineering. Either your entire team is inexperienced or they are just patronizing you.
Fresh out of school does not necessarily mean "no experience." Many students have written a lot of software before even entering college, and then work as developers during school, leaving with 2-3 years of development experience.
Or maybe I'm involved in design because I've proved I can handle complexity, know when an abstraction would be needed, and got good fitting ideas to work my way out of a problem.
If schools don't teach you that, what's their purpose? (genuine question, I'm from a "special" school in France, and I've definitively been trained with that goal in mind (ie: gathering real world experience))
"10x" is not without parallel. Most of the creative and sporting fields accept logarithmic pay scales - a few multimillionaires, a tier of people making a living, and a vast number of amateurs. It's just that in sports being 0.1% better can mean winning 10x the salary.
"Illusory superiority" applies to a lot of things. Most people think they are 'good drivers' and that is where it starts.
For most cognitive tasks the people who do them probably did fairly well at school, possibly the top 5 or 10 percent and so assume they are smarter than 19/20 or 9/10 people...
I wouldn't be surprised if surgeons feel like 10X'ers compared to general practitioners, in a sense (of course, a surgeon "being 10X as productive as a GP" doesn't make literal sense).
The 10x engineer is actually rather common place imho. If we can acknowledge that the work of some engineers create debt then we can simply find an engineer that doesn't and assume there's compound value in their work (which is probably the case).
> Clearly the idea of the 10xer has too big a place in the mythology of our industry. It's oddly masochistic and as far as I know it's unique to us.
I think it's really just unique to the Bay Area, and it's wacked out culture it's been cultivating that focuses on the bang-bang-bang go-go-go 100x multiple return on dollars.
I've been an engineer for over a decade, and the first time I heard the term "10x" was 6 months ago when a product manager referred to me a "10x engineer" during a conference call.
> There are no doctors blogging about "10x doctors"
There are still 10x equivalents though. For instance, a PhD MD that chairs a department at a major hospital, publishes significant research, participates in NIH or similar organisations, and still sees patients is going to be a very different sort of professional than your local GP.
It's the notion that 10x applies only to NCLOC production that needs rethinking, so you're in the ballpark in that respect.
But which doctor will give you better care? And which doctor will save more lives, or improve them in a meaningful way? Those are different jobs. Is a security researcher more or less productive than a programmer on a team of 10?
but those 10x equivalents are specialized, and there's absolutely a place for your local GP. Whereas every company is falling over themselves to hire the 10x programmer.
A local GP is what you want for tracking your longitudinal health and being a personal interaction with the health care system for you. Not someone chairing a department & publishing research
Whereas every company is falling over themselves to hire the 10x programmer.
Is this true? I've been involved in a number of hires over the years where we quite specifically did not want a "10x programmer". We knew the position didn't pay enough, and had enough tiresome, non-novel work (e.g. building data processes for client data. Not big enough or interesting enough to be big data or technically challenging) that we simply wanted, in effect, a marginally competent chair warmer.
From seeing hiring and employment practices, this seems to be absolutely common across the industry.
Similarly there is another comment that opines that every programmer thinks they're a 10x programmer. Now maybe it's because I have a work history in places like financial firms and banks and insurance and telecom, rather than pure software or Google-esque, but this is absolutely untrue. I found that the vast majority of developers were simply careerists.
We all have a super power or two (or none or, sometimes more than two ...).
Do you not think what you wrote is just liberal dogma? I think there probably are people with few things going for them. Possibly removed from you socially due to the various filters that act on our lives.
Unfortunately you are right. But the people who you speak of, who are without any platform or privilege, are not reading my comment on Hacker News today.
It's a bad myth that "speed" has anything to do with the 10x or 100x programmer. The thing that sets great programmers apart is their ability to instinctively and intuitively design elegant and correct solutions to a given problem while introducing minimal bugs. A great programmer whose code will stand the test of time without needing a total rewrite 6 months later and without a horrendous maintenance and complexity overhead could write their code at 10 words a minute and still be worth their weight in gold.
Personally I think "great" programmers are really just "good" programmers - those that understand the problem domain, have expertise in their tools and know how to minimize complexity - this should not be some white albatross but rather a level we should all aspire too. I think it is more useful to identify bad programmers - those that rage in like a bull in a china shop, adding layers of complexity and abstraction to cover up their lack of knowledge and expertise, who flippantly choose bad designs for a given problem because they believe in some universal "right way" and spend half their time on premature optimizations before their buggy product is even in a testable state.
I have come across numerous bad programmers in my time, and if they were nipped in the bud early before they could leave reams of damage in their wake, I can testify to many man-months in effort rectifying their mistakes.
I don't think this gets nearly enough praise when assessing people. I've worked at a few different software companies with a raft of different programmers and among those who were deemed "superstars" there were certainly a few who I wouldn't want to work with (or inherit code from) given the choice due to the hideously complex nature of their output.
Despite their ability to produce major functionality with incredible speed, which is often what led to them being seen as superstars by management, code that is so complex that it is virtually unmaintainable is a huge ongoing burden. Its great that you rescued a late project when everyone said it could not be done but some poor sucker is going to have to maintain that mess.
I'm currently working for a company where "Move Fast" means "Write lots of code". As a result, there's a lot of sloppiness, duplication, and pieces that don't quite fit together right. I'm having difficulty explaining the importance of reductionism; In the words of Antoine de Saint Exupéry: "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."
Interestingly I think that the propensity to create complex systems is a sign of inexperience (but aptitude nonetheless). I used to create the most hideously "enterprise" architectures in my projects that even I have problems grokking after years of not touching them. I've reached the stage of moderately complex and out of sheer love of the concept, actively work toward simpler solutions.
Ultimately a "10x hire" who overcomplicates things can probably be toned down through some mentoring.
I guess the "work smart, not hard" truism can be reworded to "solve smart, not complex" in this case.
> some poor sucker is going to have to maintain that mess.
Although complex is not the same thing as a mess, it merely might as well be.
> ability to instinctively and intuitively design elegant and correct solutions to a given problem while introducing minimal bugs.
That is very important. Code that is not written is just as important importat (maybe more important) than code that is written. What I mean is good programmers will find way to solve something using less code. That is very imporant for understandability, maintenance, and long term support.
That is hard to convey to an outsider. Say a manager who has never programed that is in charge of evaluating programmers they are managing. They will usually value more code, more nights spent at the office and more churn fixing bugs vs less code, less nights spent at the office, no churn or "putting out fires". Heck to them it looks like the 10x programmers is a 0.1x programmer compared to others.
>What I mean is good programmers will find way to solve something using less code. That is very imporant for understandability, maintenance, and long term support.
It's not about less code, it's about simplicity of code. I have known people who have played code golf with production code, either out of bordom or a desire to generate job security. That's not actually solving the core problem of making it easier for someone to port to a new version of an OS in 5 years time, it only looks that way if you aren't paying attention. Short code can be just as confusing as long code.
Your code should, in all places where it is not necessary to do crazy speed optimisations, be understandable by the average intern. Yes, that means comments, and yes, sometimes it means doing something in one line that is more commonly done in 20 lines and yes, sometimes it means taking 20 lines to do something you could do in one line.
Great programmers use source control, integrate often, and communicate with their team. They basically do all the the things we know we're supposed to do, but most only give lip service to it.
It's not a matter of coding 10X times faster than another coder. It's a matter of coding to not put yourself into common traps/pitfalls that waste your time trying to get out of. And also to make the correct decisions/strategies early in the project to put it on a track that uses the correct tools, libraries, etc. that won't waste your time later.
A junior developer is almost always a net negative on a team of developers as the other developers end up having to fix their code. (one doesn't hire junior devs for their productivity but instead to train them to the point where they're no longer a net negative).
If you extrapolate it further, there are developers that have so much diverse experience and think at a higher level than others that their time brings 10x time to the project than even other experienced developers.
What i commonly notice is if a developer starts solving the problem at its core, and then builds the interfaces around it, or he starts writing "utility" code, like writing code in hope that the problem will solve itself if enough helper code (or framework code) has been written for it. When i see a developer doing the latter, i know he will not be too productive, because he has no clear vision of the solution.
Perhaps if you have a poor definition of utility code. Sure if you spend all your time writing random string functions or a new web framework or whatever. But that's sorta tautological: writing useless code is useless and bad.
I often find bottom up coding to be fantastic. I'll start with a general idea of what I want to do, then start writing low-level "helper" functions. Like "save image to blob storage", "perform search against remote API", "normalize search result into our document type", etc.
When I get around to tying it all together, if I've done it well, I find that hey, my "main" function is only 5 lines long as I've built up all the primitives I need.
And sometimes the reverse works, too, where I start off writing main and end up with a 1000 line function with lots of nested bits. Then go back over it and start extracting parts/structuring.
Like many things in software creation, this is one of those "artistic" or "creative" or "intuitive" parts where the developers internal heuristics and experience hopefully guide them to the right approach. Not to say it should be that way, but that seems to be a big difference between good and bad programmers, and I've not seen really hard, structured, learning approaches to teach the difference.
I have heard the expression that wiring bottom-up is "building a DLS for your problem".
That would explain why we don't see a lot of it in the Java world and therefore why "traditional developers" think it's useless - first, creating DSL may need stronger language than Java to be practical, and second, most of the DSL is already done as parts of Spring or JEE.
Ha! All this time I thought DSLs were more, well, languages. More flexible syntax, or at least differently behaving functions or operators. Like some of those fluent APIs (usually not a fan), or test frameworks love to do. I'd not thought of just regular domain functions to be a DSL.
I'm curious though, what do you mean that Spring is the DSL? Certainly that's the opposite, being so generic?
You're dismissing bottom up programing. That is actually a wide used technique, especially useful when the problem is not completely understood at the beginning.
It is also useful as a refactoring technique. Pulling common structures and patterns out to helper code often reveals the true structure of the existing code, which makes the end result easier to see.
.. That is, provided you refactor again afterward to put things into the correct abstractions.
I call this pulling out into helper code function "blowing up" the code, because it usually results in an order of magnitude larger amount of lines of code.
This refactoring technique certainly helps make the core logic of the (usually) over complicated program visibly easier to see / grok from a distance.
From there its just a matter of reducing / refactoring / simplifying things down to more correct (at least I hope) abstractions that don't overcomplicate the solution.
This is most useful when you're given something like a 5k line script that does far too many things for far too many different reasons, all with very little if any documentation. (ie, bottom up refactoring, don't really know what the solution is but you know the current solution isn't the way to go)
>when the problem is not completely understood at the beginning
That was my point too, you just formulated it in a more positive way. If the developer does not understand the problem completely, then he will do what you describe as bottom up programming.
Experimenting, in addition to taking more time than just spilling out the solution, also produces code that is not used in the final solution. So yes, a library for manipulating a certain kind of data is nice. But when it has functions that are never used, that is lost productivity. And even if the library is there, when a function becomes necessary, it might require different parameters or different application over data. Then making a conversion routine around the library function to fit the new usage also takes time, and potentially leads to inefficiency.
So my principle is that understanding the problem well is still better. That does not exclude experimenting, but its easier to experiment without spending time actually coding up a false solutions, just in ones head, when the problem is well understood.
I find the whole idea of using "writing speed" as the factor describing how good is a programmer, plainly: stupid. Honestly, you can be a mindless person making weird, overblown constructs all day, and then you can be a smart developer that thinks before writing few characters and solving the same problem. I would rather consider efficiency as the factor: process and output efficiency.
Process efficiency is how organised is the process of the development — a.k.a. getting things done. If somebody keeps shipping stuff, they are process efficient. Even if it's the smallest thing ever, just keeping the flow going.
Then there's the output efficiency — how efficient is the thing that was shipped. Is the code high quality? Is the algorithm performing well in the problem's domain? Is the code running "fast"?
I personally think that the best developers optimise their work on these two fields: they keep delivering great output code most of the time. Because what is better: lots of bad code in short time, or good code taking more time?
Who cares if you're 10x, we'll all be 10x dead at some point. In 50-100 years I doubt most of your 10x work will still be around. Might as well go enjoy some life before it ends.
2) Well, given the associated uncertainty, that's not strictly true. The relationship between money spent on aging research and lifespan extension could converge on a marginally higher average lifespan rather than growing infinitely long with infinitely increasing expenditure. Until better than marginal gains are realized, I would say it's premature to hold massive lifespan lengthening out as a realistic possibility since we don't know what road blocks lie ahead. Sure, it's possible in the 'anything is possible' sense, but, IMO, not as a practical consideration.
Say a 10xer is 30, and the average lifespan is 80 years. If ageing could be halved, then the remaining 50-year-left-pre-intervention results in 100 years of life. But has there already be any substance which has doubled lifespan? Yes[0]! In rats. Humans aren't rats; but it's a clue to what's possible in mammals (verses C. elegans, or yeast).
> Until better than marginal gains are realized, I would say it's premature to hold massive lifespan lengthening out as a realistic possibility since we don't know what road blocks lie ahead. Sure, it's possible in the 'anything is possible' sense, but, IMO, not as a practical consideration.
People are working on the problem of radical live extension today. So even if you consider it impractical, that's certainly not a view held by everyone.
Plus, a gradual improvement is all that's needed. As long as someone can live long enough to reach longevity escape velocity[1], that's the problem solved!
GitHub and BitBucket are going to delete sources after a period of time? Could you please point me to that licence agreement paragraph? Are museums going to throw away paintings in 50-100 years as well?
He's talking about the guy who did Viaweb, which became Yahoo Store. First server side application which allowed designing a web site via a browser, written in LISP.
The way to deal with overoptimistic programmers is to put them on maintenance programming, fixing bugs in the code of others, for a few months or years.
Um, I'm assuming that you are purposefully avoiding mentioning Paul Graham's name. You know, they guy who wrote the software that runs the site on which you are posting your comment. :-D
(wasn't sure if you were trying to be funny by doing so, or if there is something else relevant I've missed in the many posts above and below this that I haven't read)
10X developers have and exercise vision. Similar to how a CEO is arguably the best business person in the company, a developer may have the same differentiation in performance without the business domain counterpart's visibility in the organization. A CEO knows not to enter a competitive market, a great dev knows not to increase code complexity. A CEO knows to choose opportunities worth pursuing, a great dev knows which resources to use and avoid. A great dev makes decisions based on 100s of datapoints instead of 10s. It's like chess-and there are certainly 10X chess players.
For an industry with a very high rate of depression, and disproportionately populated by demographics where suicide is the #2 leading cause of death, it's a very inappropriate joke.
I have suffered from chronic depression for almost 20 years now, so I am sympathetic to your perspective. Most humor is "inappropriate" in my experience. So, inappropriateness seems VERY appropriate when attempting to be humorous... Hehe, go watch some stand-up by Louis CK, Richard Pryor, or George Carlin for example.
This is just a subjective feeling blending personal and second-hand experience, but it seems extremely unlikely to me that a joke in presentation context would drive someone over the edge.
Being unable to joke about it, however, is stifling. The reaction to clamp down on the joke suggests that suicide is something normal people don't do.
I feel like it's making light of it, as if suicide weren't anything serious. When Louis CK jokes about, say, racism, he's not acting like racism isn't a big deal.
More than that, it's just the slide notes (things that people other than the presenter don't usually see, even when the slides are published) that say it. Those are ordinarily shorthand speaking notes; memory aids for an extemporaneous talk to make sure that you include all of the points that you had intended to include. It could as easily have been written as "you are beyond help" or some such, but the idea is to convey the maximum information to the speaker with the fewest number of words.
Clearly the idea of the 10xer has too big a place in the mythology of our industry. It's oddly masochistic and as far as I know it's unique to us. There are no doctors blogging about "10x doctors" for example.
Anybody who has watched N0tch code on Twitch knows that there are certainly people who are far more productive coders than the average engineer. I have no idea if he's coding 10x faster than I could but it's probably close. And my ego is... healthy sized. But it ignores the truth that few of us work as "programmers." A software engineer has many responsibilities and doing the other things well brings a force multiplier to your work.
I personally subscribe to the belief that we all have a superpower or two, and figuring them out and pressing their advantage is a strong catalyst to success. So figure out what you 10x at and be happy for it.