I can think of two people who might fit this bill. Both have a propensity to jump to conclusions and not fully understand various perspectives before passing judgements and weighting their judgements significantly more than others who are more knowledgeable and familiar with a problem (aka big ego). Brilliant by themselves but very difficult interacting with others.
Imagine a quick thinker from an accomplished competitive programming and math background who has a raging ego and a chip on their shoulder. From what I've observed some companies see this in interviews and won't hire despite solving the technical challenges significantly better than others.
Some of the people I've worked with who fit this description have this tendency to jump to conclusions. But they also love debating, and correctly feel no shame in changing their positions once proven wrong.
I have found that many people find debates uncomfortable. I love them. They create value.
(In fact, whenever I meet these people I've met from previous jobs, inevitably we end up arguing intensely about random stuff. And enjoying it...)
The no shame in changing positions is key; it describes the difference between humble and egotistical or science and religion.
I think you're right that many 10xrs like to debate, and that value can come out of debate. However the best 10xr Ive worked with was equally at home with a 3+ hour technical debate or collaborating with folks who don't give their best contributions during debates. Brilliant, efficient, effective, collaborative, quick, and humble.
I'm not sure I can be described as "humble". I do however place extreme importance on sincerity, particularly in debates. (Being able to switch positions when proven wrong is another essential part, of course.)
I work with people who, while smart enough, aren't mature enough. Common statements include why "(insert technology or platform or editor) is made by idiots" or whatever because they made a decision to look at certain design choices as strawmen in their argument.
HFS+ not supporting true case sensitivity was one example. Or "I hate spring/struts/etc." just because they once had to deal with a bad codebase.
A lot of it is just tripping over one's ego to me. I don't think you can become a mythical 10x by placing so many filters in front of your work.
I had typed up a point-wise list but decided against it.
In short, they bullied, insulted and did not inspire co-workers positively, instead demotivating them by acting impatient and making fun whenever interacting about work.
Vague statements, but don't really want to get any more specific.
Trying to recall/summarize how the 10x:ers I worked with behaved, particularly against people who hadn't proven themselves (or were.. well, doing stupid stuff):
Some patterns I have noticed:
They are really eager to share their knowledge if you invest serious amounts of time with them AND you are capable of intellectually challenging them. The only way I have made this work is in-person. It is really time-consuming, but also quite rewarding.
When communicating with random people/strangers in the company via email they can appear cold/hostile.
None of the people I've worked with have made fun of people. The more common (but still as disruptive) reaction when dealing with "stupid" people over email is to "shut down communication" - only delivering the minimum bare facts that a competent person would require.
During the past 19 years in software I have had the pleasure of working closely with five different 10x engineers.
None of them have been assholes - the opposite actually - once you've gotten to know them. If I were to generalize: most of them are not particularly extroverted, so that may be a cause of misunderstanding.
Some of the 3-5x engineers (they also exist!) have a tendency to treat people as "idiots" until they have proven themselves worthy intellectually/engineering-wise.
That might be a social dynamic thing. Think of how say high school dynamics work. It's never the most popular person that puts others down (it doesn't do them any good), it's the kids that are popular, but not quite.
I would not be surprised if this also held true for engineers. 10x engineers already distinguish themselves through their work output. It's the 3-5x engineers that are good enough to tell themselves that they produce more than your vanilla engineer, but not good enough that they couldn't get lumped up with them. It's that uncertainty that produces viciousness in the attempt to remove yourself from that set.
Unless your show them that your are a "3+x engineer", they'll try to distance themselves from you to not be tainted by association. I guess it also follows that they will be the ones obsessed with 10+x engineers.
Of all the observations of social dynamics in this thread; this one was so on point that I had to follow up with some sort of affirmation; it's a good point to think about and to watch for in people, whether that's yourself (and I've certainly had to) or your people as a manager, due to the symptoms this situation can breed.
To provide some context for while I feel this is important, when I first moved into BigCO, there was a period of reorgs in my org entirely out of the control of anyone not in "the powers that be". As such; there was a "generation" of new engineers brought in as juniors who were laterally moved multiple times in a few years. New engineers continued to be brought in, but due to the promotion structure of the org, a lateral transition essentially "resets" you, so new grads were coming in at the same level of people who had been delivering for years.
Now; there's another discussion if this relates to the "3x engineer" thing, which I wasn't even going to get into, but for practical purposes these engineers WEREon average performing multiple X better simply by nature of domain experience and rampup. This resulted in different symptoms from different people; the more zen of my peers simply got saddened about feeling looked over for promotions and started considering other options. Many left for other companies. The less zen (myself included) got more "fierce" as a sister post elsewhere put it, realizing that to "catch up" with the career track, high visibility, high impact projects were needed, and that required pushing harder.
To bring some sort of conclusion out of this rambling mess; I'm not sure your statement of "vicious" is the right word, but needing to stand out from that set seems to be an inevitable consequence of how many promotion structures are built, and being aware of this dynamic, engineers can be both better at their job by staying on top of their internal responses and keeping them productive (why I differentiate "fierce" and "vicious"; you can have the former without the latter I think), and Managers can better stay on top of their team dynamic and keep employees happy by realizing these emotions happen, since I find it's an oft under-appreciated dynamic.
Man that ended up being FAR more of an essay than I intended. Hope there was at least one well expressed thought in there.
A lot of people suggest that 10x programmers aren't jerks because they reflexively disqualify jerks from the 10x category. That's wrong and reflects wishful thinking. Do they think Linus is a middling developer because he's also a jerk?
> There’s no such thing as a 10x engineer spending time on something that never ends up delivering business value. If something doesn’t deliver business value, it’s 0x.
If it's your company then by all means you should listen to everyone's advice. But if it's not your company then you should give your advice, but if your employer doesn't want it then that's their issue. At that point there's no ethical imperative on your part to try to prevent your business from going bankrupt, so as long as the checks keep clearing I don't see the issue.
Sure. My point though is that if an engineer is building something without value, it's only really fair to call them 0x if A) it's their project, and B) it's something where they should have been able to figure out if it had value.
>1. It doesn't look good on your CV if you only worked on projects that don't have any business value.
I completely disagree. If you work on a really cool project that's very technically interesting, that looks great on a resume.
Do you really think your interviewer (at the company you're applying for a new job at) is going to call the old employer and ask them "Hey, did this project on this guy's resume delivery any real business value?" Of course not. They only go by what you write on your resume, so you can spin it however you like. If it was an interesting project but was shit-canned because of bad management or bad timing or whatever, you don't put that part. You talk it up in the interview when asked about it, talk about how technically interesting it was, what you learned there, etc., you don't volunteer that it ended up being a bust. Even if you have to spill that (because you're specifically asked), you concentrate on the good points, how it was a great learning experience, how what you developed should be useful on future projects, etc.
Prospective employers are looking for skills and experience you have which will help them in the future. How financially successful some project you worked on was is really irrelevant, since there's far more to the success of a project than just the technical aspects. Lots of companies have built technically superb products only to have them fail in the marketplace because of bad marketing, other bad management decisions, too much competition, etc. OS/2 was completely superior to Windows 3.1 and 95 yet it failed in the marketplace; that doesn't mean that you wouldn't hire a guy who worked on it.
I feel that the most fitting medium for rebuttal to portions or whole, is a separate article.
Having said that, I have seen projects and management lean on one or two guys out of a whole group to deliver the quick and mostly working plumbing + base work. And then pass off the polish work to the 1x or 0.5x employees.
Also, I saw no link between output and 'being a jerk', and that is highly anecdotal.
This is a similar way that sports teams work, or certain skills propel you to a different rank in army. Office work seems mundane, but management is well aware of the ghost benefits for hiring multiple-x engineers at 1.15x the salary.
I work with a 10x engineer, I know they exist. Or at least ONE exists. We'd be DEAD without him. He's by far the smartest, fastest, and most thorough person I've worked with since starting in IT in 2000. I'm not sure he knows how good he really is and I am afraid some day he'll figure it out and leave. He's also generally nice and humble, and at the same time can be fierce and mean to get things done. He makes me feel old dumb and slow, and I love it.
I worked with a guy who everyone thought was 10x, I thought he was shit. This guy and another built all the systems for this company, and a product that was the cash cow. Started in 2005 using struts. Everything they built was struts. They duplicated the entire code base for the next web app. There were like four versions of this thing customized to do different things (ie trivial shit like the web sign up form). These guys couldn't even factor out the data access/service stuff into separate modules for reuse.
When it came time to learn Spring, this guy flailed, and wrote Spring like it was struts. In addition, he was a pontificating jack ass, real abrasive personality.
The non technical and business users thought this guy was a super star. I've only quit a job once because of personalities, and this was that time.
Anecdotal, of course, but .. I've worked with quite a few 10x guys in my time, none of them liked Java, most of them would consider Java a reason to quit. It's been a while, I would guess some of them would find Scala acceptable.
Yes, just think how many throwaway unicorn greenfield projects these Java developers didn't participate in because they absolutely have to insist on maintaining crufty decade old code bases that actually solve a tangible business problem instead of thinking software is an afterthought to a fluffy full page HTML5 marketing video about revolutionizing the world.
At present time, Java8 is acceptable (wit lambdas, RxJava, etc.). But yes, you are right: Spring, Hibernate, JBoss, etc. are huge reason to quit.
My own web projects in java 15 years ago were coded in java and glued by JavaScript (Rhino) with templates in JavaScript, which were compiled into bytecode for speed: fast, secure, simple, 10x faster to code.
I sometimes feel like the guy you describe (although perhaps because I do indicates that I am not?)
I have a webapp that I maintain for a family member written, by me, in 2005. It was using WebWork (which became Struts 2) and still is, and I am trying to move it to something more modern in bits and pieces. But it's requiring me to learn a lot, which I am trying to do in the limited time I have.
At my work we do way more modern thing, but so much so that I'm not able to do any UI stuff since they use tech I'm not "hit the ground running" capable of doing. But I'm trying.
If he built all the systems and especially the cash cow, isn't that some objective measure that he's more valuable than the average employee?
Maybe he's messy, but nobody pays the janitor millions of dollars to clean up everyone else's messes even if they tell themselves he's important. Rather, they pay the people who made it worth cleaning up the building in the first place.
One issue some programmers have is discerning that not all code has the same value. I think with code it's harder than with physical things to "know where the value is".
It's obvious, for example, that we don't need titanium cupholders in a car, but maybe titanium rods _are_ necessary to achieve a particular level of performance.
But in software, you'll see programmers doing the ethical equivalent of putting in titanium cupholders "because it's the best" or whatever, with no regard to the cost.
In my experience, a 10x programmer is a 1x programmer who knows where the value is and spends their time on that.
This describes me in the past. Don't let him date someone from HR, it opens up Pandora's box about relative value and standard practices with salary negotiation. The largest factor for salary at most companies is how much you ask for rather than your skills or contributions.
However there may be other things he values besides money. Continue to make those great and I'm sure he will continue to enjoy being your coworker.
I think I am a 10x engineer sometimes. It's kind of like the tide. Sometimes it's there, sometimes it isn't. Also, if you think you are something, are you really that something?
Last week I was pulled into the tail end of a project which had just got pushed back to the end of February for complications. The project was now billed at 3 guys, 3 weeks. After spending an hour in a meeting I came up with a solution that is going to be implemented on Tuesday by one guy. Same risk, but a fraction of the work.
I know most of the time when you think about 10xers you think about some kind of math / programming / algorithm god, but don't discount big picture skills. Unfortunately I'm not sure how you teach big picture skills or put them down on a resume.
I don't think it is possible to really be sure that you are a 10x engineer - it's more of an outside validation thing. Everyone thinks they're really good and that only they run into weird emotional issues that slow them down. People like to rationalize.
If you see one of your co-workers doing 10x the work of your other co-workers at high quality, then it's much easier to label them at a 10x engineer than trying to label yourself. Objective vs subjective.
Ha! Good question. I wrote this comment with out much thought really. He CAN be... maybe "stern" is a better word? He's generally totally professional, nice and friendly, but he doesn't let people push him around, and he pushes back when he needs to. He's "well rounded", how's that?
Ah, OK. It's been a few years since I've worked in the sort of place where anybody would need to be "stern" to anyone, but I can remember it! thanks for the clarification.
I imagine it's just a phrasing thing, he probably means someone that sticks up for themselves. I've seen a lot of very effective engineers get bogged down in bad work because they wouldn't push back on ideas/projects that were obviously not great ideas.
10x engineers definitely exist. Know a few and have hired a few. They are not 10x compared to anyone ever, but generally 10x to their currently aged or experienced peers.
They learn for fun. They are endlessly curious. They are incredibly humble and get things done.
They do get more done in their part time hours in the evenings than a full time equivalent. More importantly, 10x really helps with building the quick things quickly and growing them as quickly as possible.
I really think this list has a lot of truth to it.
"There’s no such thing as a 10x engineer spending time on something that never ends up delivering business value. If something doesn’t deliver business value, it’s 0x."
I have found myself to work really well as a "value enabler" of 10x engineers. It's a symbiosis thing - my best work has been done working with a 10x engineer with our skills complementing each other (I'm strong on the business value/UX side, defining overall architecture/network protocols/optimizations etc, but weak in e.g. hardcore C low-level implementation.)
A challenge: Whenever I've stopped spending 20 hours a week working closely with these guys (in order to focus on building other essential parts of the business where there are no 10x engineers), their output value has severely decreased. They often fall back to like 2-3x. (Really nothing to be ashamed of, but...)
Things like this can make company switching challenging :).
I don't think being a 10x engineer is about engagement, work ethics, ability to code fast or anything like that.
It's about making great decisions. That includes using the right tools, using libraries instead of inventing everything yourself, not using libraries when not appropriate and pushing back on a product decision that does not make sense.
Right, which is why 10x engineers don't really exist in places that don't value some level of engineer autonomy -- you can't make great decisions if you can't make decisions at all.
I personally see my own productivity improve by about 4 fold given the right conditions - i.e. being able to focus on the one task at hand, not jumping between projects and not being interrupted with questions every half hour. Anyway that's my comment having not read the article.
Oh yeah, the 1/10 engineers are a problem as well (and 1/20, etc)
Usually a mix of not knowing how to use docs, google things or just stick to their old ways (the 1/20 miraculously find bugs on well tested software used by lots of people - at least that's what they think)
10x engineer is a relative comparison based on the engineers around you, not a universal ranking. Most of this can be explained by managers who dont know what they don't know. (Never hired or managed hundreds or thousands)
I have met, hired, and worked with engineers of all stripes and tend to think this idea is just a mental way of covering that "we have a guy our company or team relies on to a high risk degree".
10x engineers are a bad sign because it means she or he probably belongs with a better crew... And someday either they'll realize that or leave for another reason, exposing our over reliance on them.
But I think focusing on this work is wrong-headed. As noted in the article, making 5 other developers twice as efficient is roughly equivalent. The difference is that I can't sustain a 10x rate (I do a lot of "research programming" where I'm probing a domain rather than producing production code), while there's a good chance that training other developers will translate into a 2x (or better) increase in the team's productivity.
C is self-contradicting. "10x engineer" means "an engineer that's ten times better than most others", and if most others are ten times worse than someone, then that person is a 10x engineer.
Also, I hate the term "10x engineer". Everything follows a normal distribution.
Can you back this up with some data? This might actually match my observations but I never considered the possibility that it might be a bimodal distribution.
Is there anything more to that than just willingness to learn (like how some people will ignore the instructions and then demand help because "it doesn't work")?
Yes, and it's so well-understood that talking about whether 10x engineers do and don't exist is ridiculous. It seems like it's just a circlejerk, where everybody secretly thinks they're a 10x engineer so we keep talking about it.
Even if people were to use a new term such as "3-Sigma Programmer" instead of "10X Programmer", the ensuing debates would still be the same.
To make peace with the "10x" label, I suggest people just think of it as a figure-of-speech instead of a mathematical term. We don't get hung up when people say "Star Wars IV was ten times better than Phantom Menace" or "I'm not even 1/2 the football player I used to be."
I think that's kinda the point. It's saying the ratio is accurate, but it's not due to humans with some superpower. It's that there are many people in the field who underperform.
That’s true in a mathematical sense, but it’s not how some or possibly most brains work. For example, “plenty of .1x” engineers doesn’t have to imply a majority, it could be just enough that you run into them on a regular basis.
If you were interviewing and on Monday you have a 1x engineer and 9 .1x engineers, you’d assert you met a 10x engineer. Then on Wednesday if you had 9 1x engineers and one .1x engineer, you’d assert you met a .1x engineer.
Yes, and the actual 10x engineer will probably be compared to a 1x engineer who the organization currently considers their 10x engineer. This may cause the organization to reject the 10x engineer, simply because they don't know what a real 10x'er looks like.
I think it's sort of funny when people think 10x engineers don't exist. For most of us, it's pretty obvious because we've probably worked with one. (If you haven't: you might want to rethink your job choices :-))
If you think about it, there's essentially no physical or finite limit to how much you can get done in a day with software (outside of, like, typing speed), so it boils down to how fast and comprehensively you can think. So you might think, well, nobody is 10x smarter than anyone else, and that's probably true, but you could certainly imagine someone that has learned 10x more and has 10x more experience and given the right context can apply that effectively.
I strongly agree with the no-jerks part. I think, short term, you can be a jerk and still be effective, but long term if you're unpleasant you'll develop blind spots because people don't want to deal with you. Once you have significant blind spots, I suspect it's very hard to maintain the 10x pace. There is of course, a strong counter example here, which would be someone like linus torvalds (who is both extremely effective, and, by his own admission, kind of a jerk), but I think while exceptions like that exist they're not the common case.
To be a 10x engineer, you don't have to be 10x smarter. There are a lot of ways to get to an overall multiplier of 10x.
You can be 2x smarter and 2x more experienced and have 2x better research skills and 1.25x better administrative skills/support (time management, office layout, etc.) with the net result of 10x effectiveness.
You can be 12.2% better in 20 different but mutually-reinforcing skill areas.
Or, thought of a different way, an ordinary engineer might solve 90 problems easily but get bottlenecked on 10 challenges. You can approach 10x by solving 99 problems easily and only bottlenecking on one. Being an outlier isn't necessarily a matter of one big advantage, but can be about combining a lot of small advantages.
Yeah, I entirely agree. I think sports are a good example of this (because in most sports, it's much easier to measure performance than in programming).
LeBron James, for instance (arguably the greatest basketball player in the world), isn't really 2x better at anything compared to other top basketball players. He can't run twice as fast or jump twice as high. He's just slightly better at everything. Small things can stack to a large degree. Like, how many programmers know the important keyboard shortcuts in their development environment? Obviously it doesn't take a genius to learn keyboard shortcuts, but shaving 5 seconds off operations here and there can have a huge effect when you start thinking about how that multiplies in timescales of weeks or months. (Not that knowing keyboard shortcuts makes you a great developer, just saying, seemingly minor advantages can be huge multipliers)
I think the keyboard example hints for something bigger. Yes it's a small example.But it may allow you to stay in the flow(and optimal focus) better than someone who'se looking around menus. And the effect is probably non-linear to effort. And it accumulates. Now every month you get to learn more/better than the other guy.
So yes, similarly minor things can be huge multipliers , like you say.
It isn't about the total intelligence - it is about the excess intelligence. If someone has to have a programming intelligence of 100 to do some job, you might only need a pi of 110 to be 10x them, not 1000. Very similiar concept to climb performance based on excess power in a twin engine airplane.
The "10x engineer" I worked for quit and left me with an extremely over-complicated piece of software to manage. He's a sweet guy and a good friend, but really left me holding the bag because he was not happy.
An often overlooked point is made here. If you hire a 10x gal, then to replace her you have to hire 10 people. The question then is: long term, can you afford to hire 10x people?
Did they build it? Because I dispute that someone is a 10x engineer if they build overcomplicated pieces of software. A good engineer builds according to the business' needs, maintainability, scalability, and a whole bunch of other considerations. Just building the cleverest thing you can build is poor engineering.
Yup totally agree. That was not a 10x engineer, that was a 1x at best and probably < 1x. Building overcomplicated systems is a sign of a bad or inexperienced engineer and nothing else.
What looks overcomplicated to a 1x engineer may be quite simple to the 10x. This in fact the most painful point to overcome with them: that not everybody is as skilled as them so the software should be designed and written accordingly.
In my (limited) experience, those that don't learn this tend to do all by themselves "because the others can't do shit", get overworked and are unpleasant to work with. Those who do are able instead to focus on the most important (and interesting) parts while letting the others taking their boring share.
I disagree. The entire practice of development is making simple parts and linking them together in a simple manner to create more complex parts that are still simple to understand at their level.
Your computer is extremely complicated, but it can be broken down to parts that are simple to understand in each level. That's pretty much the entire benefit of a good engineer. They know how to make self-contained things whose purpose and interface with the rest of the system is easily understandable.
This is not strictly true, and happens when complexity is needed for some of the simple lower level parts or due to the libraries and tools available changing over time.
For example, lets say the 10x engineer wrote fast inverse square root [0]. Most people would look at the code and not understand what's going on. It requires a lot of domain knowledge but provided nice speeedups at the time. Is it more complicated than necessary for some problems? Absolutely. However when used frequently as originally intended that speedup allows for more compute to be spent on higher level components useful to the rest of the team. It would also be a pain to maintain for those unfamiliar with some of the details but can be well encapsulated into a simple function call in a math library.
Thw other case this illustrates is that code evolves and a solution available now to make a system simpler may not have been available in the past. Today the same code for fast inverse square root is outdated in favor of hardware calls, so if observing the code now it is certainly over complicated for the solutions available at hand.
This is about optimizations, which are the exception to the rule. Optimizations are just a necessary evil, they aren't what we should base our coding standards around. As you also pointed out about hardware support, we tend to stick these in as lower a level as possible, so we can back to our simple and elegant abstractions as quickly as possible.
I find whenever some code is "simple", it's just not really doing anything at all and whatever it's actually doing, it's doing it badly. E.g. it's not handling anything other than some basic cases and performs horribly.
No I strongly disagree. The better engineer should take a complex problem and create layers of abstraction such that any idiot can manage the problem. It isn't sufficient to just solve harder problems, they need to rotate the basis such that it becomes a simpler problem, or change the problem so that it is simple, or comprised of simple components.
> not everybody is as skilled as them so the software should be designed and written accordingly.
I don't know if I'm a 10x dev, but I've heard this mantra few times.
It's most annoying when it happens because I actually strive to make something simple. Like I once needed to index members of some C++ STL container, so I used std::map<key, container::iterator>. It went like that:
- WTF? A map of iterators? It's complicated! Remove it!
- But the objects need to sit in this container and this extra index is also required.
- But... but.. It's complicated! Remove it!
I can relate to a situation where a container of iterators is the seemingly correct solution yet not necessarily the best thing to adopt for maintenance considerations.
Containers tend to persist over relatively large blocks of code, whereas iterator invalidation can be very tricky and most people get bitten by it at some point.
My advisor said to me "A really smart person isn't one who comes up with complicated solutions to solve difficult problems but someone who can make very simple and elegant solutions to complicated problems."
To be fair, it functions how it is supposed to, it WORKS on the platforms it is supposed to work on (not without bugs, of course), and is not likely to completely fail at any point. However, it is still a crazy, relatively unique mess for me to figure out alone. My life sucks until I can figure it out.
Companies die when they lose their competitive spirit, and start valuing internal considerations over technical effectiveness. One symptom of this inevitable disease is denying the reality of the 10x engineer, or start to think that being a jerk somehow negates technical accomplishments. It's because every company inevitably succumbs to this disease that startups can frequently wreck established players; the latter forget what's really important.
> The easiest way to be a 10x engineer is to make 10 other engineers 2x more efficient. Someone can be a 10x engineer if they do nothing for 364 days then convinces the team to change programming language to a 2x more productive language.
The article goes on to suggest that there are "1000x" engineers who can do things other engineers cannot do. The article intentionally obfuscates the point to try to disguise the idea that talent really does vary tremendously and that no amount of teamwork can match rare insight.
It's become politically fashionable to discount the contributions of individuals, because if we think about differences in talent and follow the implications, we're led to crimethink. There was even an article on HN a little while ago suggesting Einstein didn't really do anything important and that his discoveries were just a product of his time.
>The article goes on to suggest that there are "1000x" engineers who can do things other engineers cannot do.
It's a very easy statement to make but really hard to prove. I will probably never write a solid OS kernel, but I'm also not going to spend 5 years trying to learn all of the concepts and hard-won knowledge just to prove that I can when I really don't want to be doing it in the first place. Especially when you can back out of that original argument by saying "Oh, well you were 10x, you just didn't know it".
I also haven't read too much about career progression for engineers which plays into all of this, i.e., what percentage of 10x should I be after 6 months? 1 year? 5? 10? What skills should I possess on that career timeline? The answer right now is pretty much open-ended.
Yeah and Jeff Atwood is a 1000000x engineer because he wrote some blog posts that made other programmers more productive and then built Stack Overflow and made even more programmers more productive.
I think the question of 10x engineers is actually ill-defined. There are developers I can consistently outperform by a factor of ten, do in half a day what they spent an entire week on and end up with a better solution. They are not necessarily fresh out of school but somehow managed to survive year after year even though they don't even know the language they are developing in. And I don't mean the ugly details of the memory model but basics for professional developers like generics or interfaces.
But what does that proof? I think nobody doubts that the difference between a bad developer and a good one can be a factor of ten or more. Outperforming a good developer by a factor of ten is a totally different story. It is certainly possible if you have some good insight, if you spot some non-obvious structure in the problem that you can exploit to make your life a lot easier. But doing this consistently is probably at least a rear feat.
So the question is to whom do we compare our 10x engineer candidates? The average one maybe, but the average of what? Your team, your company, the entire industry? I would argue that the age respectively experience structure is really important. When you begin you learn a programming language but it takes some time until you really learn programming, until you reach the point that the languages no longer matters and you are able to focus on mapping your problems to more abstract concepts and typing it out in some language becomes the boring but necessary part of your work.
It proves the industry pays people who are barely competent, and that the median professional standard isn't high.
Possibly related - it's interesting that everyone has heard of the 10X developer, but there's no equivalent concept of a 10X company or department, or even of 10X or 0.1X management.
It's not that the concepts aren't obvious once they're mentioned, it's that - unlike the 10X programmer - they're often mentioned.
Is it naive to wonder if management would improve if managers had to worry about getting tagged with the 0.1X label?
IMO a 10x engineer is, more often than not, just a well-positioned engineer - the right person at the right place and right time.
Someone working within their field of expertise, with the tools to get it done, and without the typical roadblocks that stand in the way. Hopefully you've been there and know how it feels.
And maybe you've also been at the other side of the spectrum, working with an ever-changing, badly designed and documented piece of technology, with many surprise problems biting you in the ass, ever changing goals, and bad management decisions.
I've been a 10x engineer at times. But I know I've also been a 0.5x engineer. The knowledge on how to solve a problem and how to find an answer doesn't change, but the perceived throughput of a person definitely does.
Agreed, there are no 10x engineers, we all have 10x moments in time once in a while. We all have moments when we feel we can't tie our own shoelaces without help.
Of course there are outliers. Nobody disputes that Jordan was a 10x basketball player (probably closer to 100x when compared against the true mean and not just among professional players). Nobody disputes that Coltrane was a 10x jazz musician. Why would software be unique among all fields by not having any outliers?
You're talking about exceptional geniuses, of which there are maybe a few dozen in a given field across an entire generation of people.
Every two-bit company is demanding "10x engineers". That is what doesn't exist. There are not tens of thousands of genius software developers in the world.
I think this is the problem, and my main concern with the overuse of "10x engineer": they don't live in a vacuum.
If you hire a 10x engineer and get him to move a button two pixels left, and then tomorrow someone else tell him to move the button two pixels right, he won't be a 10x engineer, he'll be a 0x engineer. There's a lot more involved and it compounds. An engineer knowing what to do and what not do (a skill often overlooked) can help immensely, but everyone needs plenty of support to be at their 10x.
Same here. I have worked on projects where we had a very good understanding of where we wanted to go and had autonomy to make the right decisions. We cranked out a product in 6 months the company is still living off 15 years later. That was with 3 people who could be rated as 10x for this project.
And I have worked on projects where nobody knew where things should go but a lot of people had a say in what not to do. So we all ended performing at 0.1x.
173 comments
[ 2.7 ms ] story [ 205 ms ] threadAnecdotally, I have.
Imagine a quick thinker from an accomplished competitive programming and math background who has a raging ego and a chip on their shoulder. From what I've observed some companies see this in interviews and won't hire despite solving the technical challenges significantly better than others.
I have found that many people find debates uncomfortable. I love them. They create value.
(In fact, whenever I meet these people I've met from previous jobs, inevitably we end up arguing intensely about random stuff. And enjoying it...)
I think you're right that many 10xrs like to debate, and that value can come out of debate. However the best 10xr Ive worked with was equally at home with a 3+ hour technical debate or collaborating with folks who don't give their best contributions during debates. Brilliant, efficient, effective, collaborative, quick, and humble.
I'm not sure I can be described as "humble". I do however place extreme importance on sincerity, particularly in debates. (Being able to switch positions when proven wrong is another essential part, of course.)
HFS+ not supporting true case sensitivity was one example. Or "I hate spring/struts/etc." just because they once had to deal with a bad codebase.
A lot of it is just tripping over one's ego to me. I don't think you can become a mythical 10x by placing so many filters in front of your work.
In short, they bullied, insulted and did not inspire co-workers positively, instead demotivating them by acting impatient and making fun whenever interacting about work.
Vague statements, but don't really want to get any more specific.
Some patterns I have noticed:
They are really eager to share their knowledge if you invest serious amounts of time with them AND you are capable of intellectually challenging them. The only way I have made this work is in-person. It is really time-consuming, but also quite rewarding.
When communicating with random people/strangers in the company via email they can appear cold/hostile.
None of the people I've worked with have made fun of people. The more common (but still as disruptive) reaction when dealing with "stupid" people over email is to "shut down communication" - only delivering the minimum bare facts that a competent person would require.
None of them have been assholes - the opposite actually - once you've gotten to know them. If I were to generalize: most of them are not particularly extroverted, so that may be a cause of misunderstanding.
Some of the 3-5x engineers (they also exist!) have a tendency to treat people as "idiots" until they have proven themselves worthy intellectually/engineering-wise.
I would not be surprised if this also held true for engineers. 10x engineers already distinguish themselves through their work output. It's the 3-5x engineers that are good enough to tell themselves that they produce more than your vanilla engineer, but not good enough that they couldn't get lumped up with them. It's that uncertainty that produces viciousness in the attempt to remove yourself from that set.
Unless your show them that your are a "3+x engineer", they'll try to distance themselves from you to not be tainted by association. I guess it also follows that they will be the ones obsessed with 10+x engineers.
Kings aren't vicious, it's their courts that are.
To provide some context for while I feel this is important, when I first moved into BigCO, there was a period of reorgs in my org entirely out of the control of anyone not in "the powers that be". As such; there was a "generation" of new engineers brought in as juniors who were laterally moved multiple times in a few years. New engineers continued to be brought in, but due to the promotion structure of the org, a lateral transition essentially "resets" you, so new grads were coming in at the same level of people who had been delivering for years.
Now; there's another discussion if this relates to the "3x engineer" thing, which I wasn't even going to get into, but for practical purposes these engineers WEREon average performing multiple X better simply by nature of domain experience and rampup. This resulted in different symptoms from different people; the more zen of my peers simply got saddened about feeling looked over for promotions and started considering other options. Many left for other companies. The less zen (myself included) got more "fierce" as a sister post elsewhere put it, realizing that to "catch up" with the career track, high visibility, high impact projects were needed, and that required pushing harder.
To bring some sort of conclusion out of this rambling mess; I'm not sure your statement of "vicious" is the right word, but needing to stand out from that set seems to be an inevitable consequence of how many promotion structures are built, and being aware of this dynamic, engineers can be both better at their job by staying on top of their internal responses and keeping them productive (why I differentiate "fierce" and "vicious"; you can have the former without the latter I think), and Managers can better stay on top of their team dynamic and keep employees happy by realizing these emotions happen, since I find it's an oft under-appreciated dynamic.
Man that ended up being FAR more of an essay than I intended. Hope there was at least one well expressed thought in there.
If it's your company then by all means you should listen to everyone's advice. But if it's not your company then you should give your advice, but if your employer doesn't want it then that's their issue. At that point there's no ethical imperative on your part to try to prevent your business from going bankrupt, so as long as the checks keep clearing I don't see the issue.
1. It doesn't look good on your CV if you only worked on projects that don't have any business value.
2. If what you do does not have any value chances are someone will figure out at some point.
3. It's not fun to work on a project that has no value for anyone. This is the kind of thing that will create burnout.
If what you are doing is very intellectually challenging for you, or it has value other than business value then it might be different.
I completely disagree. If you work on a really cool project that's very technically interesting, that looks great on a resume.
Do you really think your interviewer (at the company you're applying for a new job at) is going to call the old employer and ask them "Hey, did this project on this guy's resume delivery any real business value?" Of course not. They only go by what you write on your resume, so you can spin it however you like. If it was an interesting project but was shit-canned because of bad management or bad timing or whatever, you don't put that part. You talk it up in the interview when asked about it, talk about how technically interesting it was, what you learned there, etc., you don't volunteer that it ended up being a bust. Even if you have to spill that (because you're specifically asked), you concentrate on the good points, how it was a great learning experience, how what you developed should be useful on future projects, etc.
Prospective employers are looking for skills and experience you have which will help them in the future. How financially successful some project you worked on was is really irrelevant, since there's far more to the success of a project than just the technical aspects. Lots of companies have built technically superb products only to have them fail in the marketplace because of bad marketing, other bad management decisions, too much competition, etc. OS/2 was completely superior to Windows 3.1 and 95 yet it failed in the marketplace; that doesn't mean that you wouldn't hire a guy who worked on it.
Having said that, I have seen projects and management lean on one or two guys out of a whole group to deliver the quick and mostly working plumbing + base work. And then pass off the polish work to the 1x or 0.5x employees.
Also, I saw no link between output and 'being a jerk', and that is highly anecdotal.
This is a similar way that sports teams work, or certain skills propel you to a different rank in army. Office work seems mundane, but management is well aware of the ghost benefits for hiring multiple-x engineers at 1.15x the salary.
http://webcache.googleusercontent.com/search?q=cache:ikC6A7V...
When it came time to learn Spring, this guy flailed, and wrote Spring like it was struts. In addition, he was a pontificating jack ass, real abrasive personality.
The non technical and business users thought this guy was a super star. I've only quit a job once because of personalities, and this was that time.
Which language has standard library small enough that people can memorize the whole thing?
My own web projects in java 15 years ago were coded in java and glued by JavaScript (Rhino) with templates in JavaScript, which were compiled into bytecode for speed: fast, secure, simple, 10x faster to code.
I have a webapp that I maintain for a family member written, by me, in 2005. It was using WebWork (which became Struts 2) and still is, and I am trying to move it to something more modern in bits and pieces. But it's requiring me to learn a lot, which I am trying to do in the limited time I have.
At my work we do way more modern thing, but so much so that I'm not able to do any UI stuff since they use tech I'm not "hit the ground running" capable of doing. But I'm trying.
I hope I'm not abrasive however.
Maybe he's messy, but nobody pays the janitor millions of dollars to clean up everyone else's messes even if they tell themselves he's important. Rather, they pay the people who made it worth cleaning up the building in the first place.
It's obvious, for example, that we don't need titanium cupholders in a car, but maybe titanium rods _are_ necessary to achieve a particular level of performance.
But in software, you'll see programmers doing the ethical equivalent of putting in titanium cupholders "because it's the best" or whatever, with no regard to the cost.
In my experience, a 10x programmer is a 1x programmer who knows where the value is and spends their time on that.
It's poor code design, poor code management.
It's more like:
- irresponsible house developer builds house very fast and very cheaply but he doesn't care about safety or design
- then building is beginning to collapse and tennants have to hire another developer to fix mistakes of previous developer.
They must pay twice! One time - for creation of the building. Second time - for fixing.
However there may be other things he values besides money. Continue to make those great and I'm sure he will continue to enjoy being your coworker.
Last week I was pulled into the tail end of a project which had just got pushed back to the end of February for complications. The project was now billed at 3 guys, 3 weeks. After spending an hour in a meeting I came up with a solution that is going to be implemented on Tuesday by one guy. Same risk, but a fraction of the work.
I know most of the time when you think about 10xers you think about some kind of math / programming / algorithm god, but don't discount big picture skills. Unfortunately I'm not sure how you teach big picture skills or put them down on a resume.
If you see one of your co-workers doing 10x the work of your other co-workers at high quality, then it's much easier to label them at a 10x engineer than trying to label yourself. Objective vs subjective.
Good lord I sound like a ridiculous fan boy.
They learn for fun. They are endlessly curious. They are incredibly humble and get things done.
They do get more done in their part time hours in the evenings than a full time equivalent. More importantly, 10x really helps with building the quick things quickly and growing them as quickly as possible.
"There’s no such thing as a 10x engineer spending time on something that never ends up delivering business value. If something doesn’t deliver business value, it’s 0x."
I have found myself to work really well as a "value enabler" of 10x engineers. It's a symbiosis thing - my best work has been done working with a 10x engineer with our skills complementing each other (I'm strong on the business value/UX side, defining overall architecture/network protocols/optimizations etc, but weak in e.g. hardcore C low-level implementation.)
A challenge: Whenever I've stopped spending 20 hours a week working closely with these guys (in order to focus on building other essential parts of the business where there are no 10x engineers), their output value has severely decreased. They often fall back to like 2-3x. (Really nothing to be ashamed of, but...)
Things like this can make company switching challenging :).
It's about making great decisions. That includes using the right tools, using libraries instead of inventing everything yourself, not using libraries when not appropriate and pushing back on a product decision that does not make sense.
Almost seem appropriate given the title.
I personally see my own productivity improve by about 4 fold given the right conditions - i.e. being able to focus on the one task at hand, not jumping between projects and not being interrupted with questions every half hour. Anyway that's my comment having not read the article.
Usually a mix of not knowing how to use docs, google things or just stick to their old ways (the 1/20 miraculously find bugs on well tested software used by lots of people - at least that's what they think)
I have met, hired, and worked with engineers of all stripes and tend to think this idea is just a mental way of covering that "we have a guy our company or team relies on to a high risk degree".
10x engineers are a bad sign because it means she or he probably belongs with a better crew... And someday either they'll realize that or leave for another reason, exposing our over reliance on them.
But I think focusing on this work is wrong-headed. As noted in the article, making 5 other developers twice as efficient is roughly equivalent. The difference is that I can't sustain a 10x rate (I do a lot of "research programming" where I'm probing a domain rather than producing production code), while there's a good chance that training other developers will translate into a 2x (or better) increase in the team's productivity.
a. There are no 10x engineers, just environments where there is a 10x discrepancy in productivity.
b. There are no 10x engineers, just 10x yardsticks.
c. There are no 10x engineers, but plenty of .1x engineers.
Also, I hate the term "10x engineer". Everything follows a normal distribution.
Evidence suggests that technical talent is bimodal.
A normal distribution doesn't preclude the existence of a 10X, just describes the rarity.
Even if people were to use a new term such as "3-Sigma Programmer" instead of "10X Programmer", the ensuing debates would still be the same.
To make peace with the "10x" label, I suggest people just think of it as a figure-of-speech instead of a mathematical term. We don't get hung up when people say "Star Wars IV was ten times better than Phantom Menace" or "I'm not even 1/2 the football player I used to be."
If you put them all on the same team as a 1x engineer, there will be the perception that one engineer is 10x most programmers.
Yes, this is why the 60 wealthiest people have as much wealth as half of the world combined.
The dial on a binary 10x engineer goes to 2.
The dial on a hex 10x engineer goes to 16.
If there are plenty of 0.1x engineers, then an x engineer is actually 10 times better. The units doesn't matter if the ratio keeps being the same.
If you were interviewing and on Monday you have a 1x engineer and 9 .1x engineers, you’d assert you met a 10x engineer. Then on Wednesday if you had 9 1x engineers and one .1x engineer, you’d assert you met a .1x engineer.
If you think about it, there's essentially no physical or finite limit to how much you can get done in a day with software (outside of, like, typing speed), so it boils down to how fast and comprehensively you can think. So you might think, well, nobody is 10x smarter than anyone else, and that's probably true, but you could certainly imagine someone that has learned 10x more and has 10x more experience and given the right context can apply that effectively.
I strongly agree with the no-jerks part. I think, short term, you can be a jerk and still be effective, but long term if you're unpleasant you'll develop blind spots because people don't want to deal with you. Once you have significant blind spots, I suspect it's very hard to maintain the 10x pace. There is of course, a strong counter example here, which would be someone like linus torvalds (who is both extremely effective, and, by his own admission, kind of a jerk), but I think while exceptions like that exist they're not the common case.
You can be 2x smarter and 2x more experienced and have 2x better research skills and 1.25x better administrative skills/support (time management, office layout, etc.) with the net result of 10x effectiveness.
You can be 12.2% better in 20 different but mutually-reinforcing skill areas.
Or, thought of a different way, an ordinary engineer might solve 90 problems easily but get bottlenecked on 10 challenges. You can approach 10x by solving 99 problems easily and only bottlenecking on one. Being an outlier isn't necessarily a matter of one big advantage, but can be about combining a lot of small advantages.
LeBron James, for instance (arguably the greatest basketball player in the world), isn't really 2x better at anything compared to other top basketball players. He can't run twice as fast or jump twice as high. He's just slightly better at everything. Small things can stack to a large degree. Like, how many programmers know the important keyboard shortcuts in their development environment? Obviously it doesn't take a genius to learn keyboard shortcuts, but shaving 5 seconds off operations here and there can have a huge effect when you start thinking about how that multiplies in timescales of weeks or months. (Not that knowing keyboard shortcuts makes you a great developer, just saying, seemingly minor advantages can be huge multipliers)
So yes, similarly minor things can be huge multipliers , like you say.
In my (limited) experience, those that don't learn this tend to do all by themselves "because the others can't do shit", get overworked and are unpleasant to work with. Those who do are able instead to focus on the most important (and interesting) parts while letting the others taking their boring share.
Your computer is extremely complicated, but it can be broken down to parts that are simple to understand in each level. That's pretty much the entire benefit of a good engineer. They know how to make self-contained things whose purpose and interface with the rest of the system is easily understandable.
For example, lets say the 10x engineer wrote fast inverse square root [0]. Most people would look at the code and not understand what's going on. It requires a lot of domain knowledge but provided nice speeedups at the time. Is it more complicated than necessary for some problems? Absolutely. However when used frequently as originally intended that speedup allows for more compute to be spent on higher level components useful to the rest of the team. It would also be a pain to maintain for those unfamiliar with some of the details but can be well encapsulated into a simple function call in a math library.
Thw other case this illustrates is that code evolves and a solution available now to make a system simpler may not have been available in the past. Today the same code for fast inverse square root is outdated in favor of hardware calls, so if observing the code now it is certainly over complicated for the solutions available at hand.
[0] https://en.m.wikipedia.org/wiki/Fast_inverse_square_root
I don't know if I'm a 10x dev, but I've heard this mantra few times.
It's most annoying when it happens because I actually strive to make something simple. Like I once needed to index members of some C++ STL container, so I used std::map<key, container::iterator>. It went like that:
Man, I hate people at times.Containers tend to persist over relatively large blocks of code, whereas iterator invalidation can be very tricky and most people get bitten by it at some point.
I'm inclined to agree with him.
That's why this whole topic is stupid.
Seriously?
It's become politically fashionable to discount the contributions of individuals, because if we think about differences in talent and follow the implications, we're led to crimethink. There was even an article on HN a little while ago suggesting Einstein didn't really do anything important and that his discoveries were just a product of his time.
It's a very easy statement to make but really hard to prove. I will probably never write a solid OS kernel, but I'm also not going to spend 5 years trying to learn all of the concepts and hard-won knowledge just to prove that I can when I really don't want to be doing it in the first place. Especially when you can back out of that original argument by saying "Oh, well you were 10x, you just didn't know it".
I also haven't read too much about career progression for engineers which plays into all of this, i.e., what percentage of 10x should I be after 6 months? 1 year? 5? 10? What skills should I possess on that career timeline? The answer right now is pretty much open-ended.
But what does that proof? I think nobody doubts that the difference between a bad developer and a good one can be a factor of ten or more. Outperforming a good developer by a factor of ten is a totally different story. It is certainly possible if you have some good insight, if you spot some non-obvious structure in the problem that you can exploit to make your life a lot easier. But doing this consistently is probably at least a rear feat.
So the question is to whom do we compare our 10x engineer candidates? The average one maybe, but the average of what? Your team, your company, the entire industry? I would argue that the age respectively experience structure is really important. When you begin you learn a programming language but it takes some time until you really learn programming, until you reach the point that the languages no longer matters and you are able to focus on mapping your problems to more abstract concepts and typing it out in some language becomes the boring but necessary part of your work.
Possibly related - it's interesting that everyone has heard of the 10X developer, but there's no equivalent concept of a 10X company or department, or even of 10X or 0.1X management.
It's not that the concepts aren't obvious once they're mentioned, it's that - unlike the 10X programmer - they're often mentioned.
Is it naive to wonder if management would improve if managers had to worry about getting tagged with the 0.1X label?
Someone working within their field of expertise, with the tools to get it done, and without the typical roadblocks that stand in the way. Hopefully you've been there and know how it feels.
And maybe you've also been at the other side of the spectrum, working with an ever-changing, badly designed and documented piece of technology, with many surprise problems biting you in the ass, ever changing goals, and bad management decisions.
I've been a 10x engineer at times. But I know I've also been a 0.5x engineer. The knowledge on how to solve a problem and how to find an answer doesn't change, but the perceived throughput of a person definitely does.
Every two-bit company is demanding "10x engineers". That is what doesn't exist. There are not tens of thousands of genius software developers in the world.
If you hire a 10x engineer and get him to move a button two pixels left, and then tomorrow someone else tell him to move the button two pixels right, he won't be a 10x engineer, he'll be a 0x engineer. There's a lot more involved and it compounds. An engineer knowing what to do and what not do (a skill often overlooked) can help immensely, but everyone needs plenty of support to be at their 10x.
And I have worked on projects where nobody knew where things should go but a lot of people had a say in what not to do. So we all ended performing at 0.1x.