There's a meme of sorts heading around Twitter after one regrettable take on "10x engineers" which paints a laughable stereotype.
This is a great post which sums up the complaints and respectfully disagrees:
It seems like everyone weighed in on Twitter, but let's have a discussion that allows for more than 280 characters. As per its usual style, the Twitter trend has been mostly about piling on, more so than necessarily evolving the conversation in an overly useful way.
To be clear, people aren't necessarily ridiculing the notion that engineers may fall on some sort of power law distribution curve. The issue with the thread was more about the hyper-specific, highly stereotypical notion of what "10x" engineers are like.
e.g.
Let's unpack this discussion a bit.
Top comments (99)
I don't see how this one for instance is a good thing to have at all. If you're spending time on what exactly you write instead of understanding the overall design spec then that means you don't have a flexible base at all. That's like a poet focusing more on memorizing the dictionary than conveying the meaning of their poem. I really hope people don't construe this as good advice to emulate π€¦π»ββοΈ
Absolutely.
The Problem With Heroes In Software Development
Beekey Cheung γ» Sep 23 '17 γ» 5 min read
I'm personally trying to gradually loosen my own similar role within the context of the dev.to codebase. It seems that the only times I ever have to request changes to a @rhymes pull request is when I have some deep knowledge of a hack or undocumented decision taken a few years ago when I was solo-hacking on the project.
It's easier said than done, but I pray for the day I don't have this "special role" of just knowing things other people probably don't. If I were a 10x engineer I probably wouldn't have created that role for myself in the first place π (or perhaps 10x engineers aren't a thing).
Yes, your approach is one of servant leadership, which is a much healthier approach (in my opinion). I always hope to raise up my team to a place where Iβve made myself obsolete.
Iv heard this obsolete thing before. I've seen it too, π― agree, but honestly I don't want to be a VHS, I want to be blueray.
Haha I hear you. But if you focus on your technical and soft skills, then you will never have to worry about having a job. Your position might go away but youβre free to focus on a more difficult challenge.
That's a good approach for a leader.
In management courses they teach the topic of "chief vs leader". The leader inspire and the others follow it by mean of good examples. The chief commands and the others obey it by obligation.
If someone delegate tasks, he should trust the one in charge giving only non-mandatory feedback.
The ultimate goal is for a pure management is to delegate everything.
In software engineering it is to divide the complexity of the software and make it flow through persons or group of persons that can fully understand it.
In this book the author treat also the topic of why the industry should not be based in the inspiration of geniuses that could handle all the complexity of the software.
That's why the focus of the Book, and also the software development methodologies of the last decades, has been the "industrial strength software". They define such software as a software that has enough complexity that no person can not fully understand in details.
I don't know if an internet forum can achieve such a level of complexity, but a rule of thumb can fit here:
I would say in practice geniuses are good for a project, as long as they are humble and cooperative. I would hire them, but I would make them part of the design or the quality team. They would be only be able to touch the code by mean of pair programming, so that there is a redundant backup.
Geniuses trend to be a high demand resource, and there is not guarantee that they can be retained forever.
Agreed, I don't really maintain as huge a codebase but it's getting to the point where I'd rather keep track of why something was done than how it was done. Especially when working with other contributors, it is easy to review their approach by comparing it to your design and not the way you may have implemented the same thing.
That #4 probably should be better be stated as "10x engineers know how to find the fault more reliably" as engineering is not about memorizing the line of code.
And also that line doesn't make sense because if 10x engineer knows every line of the code, then s/he wouldn't have put that into production in the first place! (if the engineer did know, then that engineer was either lazy or up to no-good π)
Reminds me of an old joke...
Makes sense, I think the OP has had no real experience work programming and/or leads a team who is feeding him bs.
Despite the fact that humans can only remember 7 things in short term memory at a time. This is Twitter post is toxic, do not listen to such nonsense. You might find people appear to have the eye of sauron pointed towards a particular repo but honestly it's software like Jira and whatever else that allow them to consume information. As for fix in hours, that just means stem the bleading and do the work later.
That's an average, not a maximum (and, according to some recent studies, that average is more like "4" than "7"). Different people have different effective working-memory capabilities ...and, even the ones that are stuck with the average
MAX_ITEMScan increase the effective number of items they can juggle by strategic chunking.There's a lot of interesting articles on short-term, long-term and working memory. Both in how you can improve them or completely undermine them (even to the point of erasing long-term memories with common pharmaceuticals like a couple different kinds of beta-blockers). One can quickly fall into a link-hole by reading about human memory. :)
It would be quite difficult for my to list the memory of every human on earth and in space so I think an average is a lot more efficient in this post, that was my intent. Anyway are you sure you remembered that correctly π.
I'm one of the people afflicted with the "remembers too much" problem.
Yeah, I mean if you're not using the tools you have available just for appearing vainglorious then that's just plain stupid. Driving a nail into a wall using your bare hands when a hammer is available means you literally have no idea what you're doing.
...And you're missing that the engineer in question isn't necessarily doing any of that. Some people simply remember everything they stumble across (whether they want to or not). It's not that they spend all their time crawling code, it's that, as they've been asked to fix things, the cumulative code-crawling to find bugs has resulted in them getting the entire code-base stuck in their head.
Moreover, if you've been working on a project for a while, you'd be able to identify bugs easily. There's nothing special about that.
The part that sold me on him having no idea what he's talking about is him saying that the "i" key is worn on coder's keyboards.
How many times do you actually type i? I autocomplete my loops, and usually give variables descriptive names.
... Besides, worn keys? Pffft. Everyone knows THE BEST 10x developers have mechanical keyboards with doubleshot keys ;)
Maybe he thinks that all 10x coders use Vim?
10x engineers avoid innovative, feature rich editors like VSCode.
They also would never develop on any platform that use custom IDEs like mobile app dev.
And seriously, the notion that great engineers don't communicate with the rest of the team is ridiculous.
On the other hand, I'm feeling like the joke is sort of on all of us for getting so worked up over such a trolling set of tweets (intentional or not)
Beyond ridiculous. I also think is actually for the best, it not only showed that the community is very supportive and responsive but that as a whole most of tech is moving STRONGLY against a lot of these toxic stereotypes, patronizing and pretenses.
I use Vim and I categorise myself as an 11x coder.
I use Java and categorise myself as an
ArithmeticExceptioncoderIs that binary?
Don't they? You have to be some kind of masochistic unicorn to use Vim all day ππ¦
I've seen some people grind out incredible amounts of code in modern, windowed versions of
vim, and myself cranked out tens of thosuands of lines using little more than a pile of xterm windows and elvis, an older, now obsoleteviclone.Now I use Visual Studio Code after a long stint in SublimeText and TextMate, but to each their own.
Gosh, that's even worse.
I don't think
iwould be the most worn out, probablyescbut then again most serious 10X programmers shouldn't have labels on their keys lol.I'll start by mentioning how important that project fit and motivation are to this whole discussion.
Even the most experienced or innately talented coder needs motivation and fulfillment to actually contribute in any especially great way. Nobody just spits out code on command.
Furthermore, ... Actually I'll stop here. I feel like this is the kind of conversation where I could say furthermore, furthermore, furthermore until I'm blue in the face π
Maximum recursion depth exceeded.
Infinite Loop detected π€£ π€£ π€£
Stackoverflow
From Robert L. Glass's book Facts and Fallacies of Software Engineering
It's more of a 28x than 10x. Yes, the book is old, and the sources for this fact is even older. But even with new research you will come up with similar high 'x' numbers.
As for why, Robert has this to say
I am pretty confident this has not changed.
Yes, 10x-ers exist. But moving this 10x-er to a different environment can turn them into a 5x-er. A 1x-er can grow into a 10x-er in the same place. It is not the individual, it is the individual within its environment.
Dolphins are really fast in the water. But on land, they struggle.
Want 10x-ers in your company? Then get rid of things which get into the way of your devs' productivity and hapiness. You have to ask them what these obstructions are, because they are not the same. But generally getting rid of open-floor plans has a boost in productivity. A ping-pong table does not.
As finishing remark, when your whole team goes from 1x to 2x; are they still 1x or 2x? Relatively speaking between peers they are still 1x, but compared to the past they are 2x. π€
This is the best response in this entire discussion.
The tests they used for the original (and subsequent) experiments are controversial. Small sample sizes, reliance on metrics that are easily quantifiable, unrealistic tests. Makes it so any results like this have to be taken with a grain of salt. Despite all the problems I'd love to see more and better tests done on stuff like this.
codingblocks.net/practice/four-rea...
I don't believe it is possible to create a test which objectively measures productivity of a software developer.
There are simply too many variables.
I SEE A LOT OF COMMENTS IN BOLD BUT LET ME TELL YOU THAT ALL OF THEM ARE WRONG
After of few years of experience I can say that I found a definition of the 10x engineer. It has nothing to do with the social weirdness nor the black screens. Those are just symptoms.
10x engineers are the ones with tools. Lots of tools. They know all the layers in the stack from the atom to the UX patterns going through CPU design and webpack fiddling. They are able to assimilate them quick enough to being proficient with them within a lifetime and they can cross fertilize them.
It's all about the tools, all the rest is noise.
BOLD TEXT IS BEST TEXT
THERE IS ONLY ONE WAY TO SCREAM ON THE INTERNET
Yep, this is why there's an emphasis on tools (and documentation to understand those tools).
Knowing all about webpack is a thankless task though.
That's another good point you're pointing here. Nobody will sing your glory for the many tools you learn, it's actually quite a lonely and unglamorous journey.
Yeah, this is why I think Developer Hegemony (great book from daedtech.com/ ) makes a lot of sense, there's a lot to learn from tools and docs but at the end of the day we're paid for the results of knowing all that, which is unfortunately hidden.
I think this whole 10x thing goes back to Steve McConnell's book Rapid Development (published in 1996). He popularized this idea in mentioning some research that suggested that top developers could outperform average developers by as much as 10 times (by some measure of productivity).
I have no idea whether research into software engineering still backs up this claim or not. Certainly there are super talented people out there, and they can seem a bit magical at times. As an example of someone I know, I consider @mortoray to be such a person.
However, I am pretty confident that ascribing all these weird traits to "10x" developers is both wrong and unhelpful. The only context in which I can think of it being at all useful is where you might not consider hiring someone with asperger's syndrome because they don't interview very well. They could have useful skills and talents, but they'd need the right support system to succeed. However, looking specifically for traits like poor communication as if they were the core indicators of programming ability would be much more likely to filter out good candidates than to identify them.
Thanks for providing the origin of the term. Really interesting!
The origin goes back way farther, 1968, and the testing condition were controversial even back then. People have tried to repeat similar experiments but the results are always debatable because of two major sticking points:
I looked into this a while back and wrote up a post about it: codingblocks.net/practice/four-rea...
That tweet storm is a joke. But one thing that hasn't been mentioned yet in this conversation is Brook's Law en.wikipedia.org/wiki/Brooks%27s_law
I'm extrapolating a bit, but there are certainly diminishing returns when adding developers to a project. In other words, the 1st developer on any project is likely to be 10x more "productive" than the 101st (if we measure productivity in features shipped).
I'd be happy to explain this in more detail, if folks are curious. But my point is that the "10x engineer" may have been first imagined by someone who observed a tiny team crank out an incredible MVP in a short period of time. Comparing that team to a huge, stodgy corporation, and failing to recognize the cost of communication overhead and bureaucracy common on enormous teams, the observer might have come to the conclusion that the small, agile team was made up of "10x engineers".
I have a couple of things to say:
Re: #2
Seriously, though. The comment on how the best developers don't look at docs tells me how little the poster understands about development. My mentor at my first job (one of the best programmers I've ever met) recommended to me that I have a prominent link in my browser toolbar to the Java API docs. 11 years later, it's still there, with another shortcut to the docs for String.format (that stuff's black magic). And don't even get me started on how often I find myself staring at Node's 'fs' and 'path' docs.
If I understand properly, that thread is just a description of a 10x developer is an hypothetical superhero, a genius engineer.
Those persons actually exist for specific projects of low and medium complexity. In the majority of the cases they achieve that quality with the years of maintaining the software. In some cases they are the leaders of such projects, in many other cases they are the creators.
They are the ultimate solution for project managers with low managing skills, less people to control and a simplified communication process. They look for 10x engineers but they actually perform like 8x, worth like 15x and they are paid like 2x.
This is just the dream of some low-quality managers. It should not be taken as an strict goal to reach by the engineers.
From my point of view, the key is not about the people itself. It is more important is how the company manages the information. What makes the engineers 10x is the knowledge they have over the business logic, the application and the IT layer. Sharing that information from top to bottom would make regular engineers with a balanced life, to perform more than 10x.
I strongly believe that not body is inherently better than other, it is just a matter of how much information they have acquired and how that information was shaped in their brains.
In some companies the CEOs, CTOs, are paid 100x or 200x and the value is because they worth it. But not because they are super heroes, it is because the information they have over the business logic, the application or the Technology that the companies uses to operate.
Subordinates are intended to do just the little part they are concerned without having an overall view of the context. Some years ago, I was hired by a company that had a complex system, no requirements written, no description of the processes, no comments in the code, ... I had to figure it out everything just by reading the code. I understood soon that was intentional, and my chief was pleased that I did ask everything because that made him feel more valuable.
Instead of explaining the logic, he used to translate the task to explanations like: "You just have to put a button here, a database field here, and make the calculation with this formula". I did quit as soon as possible, because I felt that like blind programming
There is an interesting development paradigm called Domain Driven Design that seems to look for the mechanism of sharing all the knowledge of Business Logic (the problem domain) and quickly broadcast its changes to the engineers (Event Sourcing and Event Storming).
There is also a programming paradigm called Feature Oriented Programming that models the domain features by mean of entities that can automate the software creation or generate part of them. This seems to be an attempt to model reusable structures (which represent the projection of the concepts of the problem domain) and combine them to get the product.
We also have the last advances in Devops, with technologies that aids the build, develop, test, and package into reusable deployment units that can be customized and combined during provisioning by mean of managed configurations.
If one focus on the big picture that is Enterprise Architecture, everything seems like an attempt of cross-sharing information of its layers (Strategy, Business, Application, Technology, Implementation and Migration) in the form of reusable structures of lower complexity that can be combined in different contexts by engineers.
If we keep in mind that engineering is not focused into discovering new knowledge (that is science), just to apply the knowledge for build solutions... then we agree that everything is trending to give more X to the performance of regular engineers.
So please everybody stay quiet, just stay tuned and do not pretend to be a genius or 10x engineers... If we keep us up-to-date with the trends we will soon become all 100x ones.
Personally been struggling with lots of inner thoughts on this. The root of it - I really hate the 10x term, especially the many misunderstood myths around it (along with hero syndrome), and how I strongly believe in 10x being very contextual (anyone can be a 10x given the correct context).
Previously (before the tweet storm) - in a separate article
10x Programmers: Myth Or Reality?
Ashraf Alam γ» Mar 25 γ» 4 min read
I stood by the idea of 10x being a myth, and more the product of large organization having really bad recruitment practices.
To be very frank, crude, and also "In my honest opinion" only (so add lots of salt)
There are a lot of programmers who are really bad. Like 10x or even 100x bad.
So as most pointed out, it ended up as a business term in larger companies. Especially nonengineering companies, who could not know better regarding programming.
Because due to their sheer hiring size - a good chunk of their developers ends up being really bad, or worse, being busy with politics rather than actual work.
So whenever a good programmer, is willing to ditch the political nonsense. Put his job on the line and risk. And get things done...
Suddenly from the average perspective in that company: he is truly 10x (Assuming he succeeded, if he didn't, he would be fired)
I personally witnessed many times as a vendor working for such big companies. Which is interesting to say per least, cause being in an engineering-focused company. We would not consider such individuals 10x. But I guess 2, or 3x technically? I have no idea how to quantify this.
So in that sense, they were 10x not because they were extremely great. But because the average was really bad. And they have the courage to stand up to it.
Also to be clear: For those in such a situation, and made it through. They automatically earn my mark of respect. Cause I will emphasize. It takes real courage to get things done in such an environment. And in development work, cutting through the crap and communication is a good half of the battle.
Personally, I would not stand for it. And send in my resignation letter for a real engineering company... or in my case form my own engineering company.
Ironically the extremely toxic "anti-social" traits mentioned in the tweets - are self-reinforcing behaviors which create situations where the "heroes" constantly look like 10x, or even 100x - because no one else could fix the system (what documentation?).
But, more recently - as I am constantly pondering on how to structure a curriculum/process to bridge the gap between a junior dev, and a senior dev. A gap while not quantifiably a 10x, is huge and visible - completely contradicting in me the idea of 10x being a myth.
Lots of complex thoughts in me related to the topic, including how as an industry (in my country now at least) we seem to have a somewhat toxic "only hire seniors" mindset. Partially due to the perceived "10x" difference between them - a mindset I strongly disagree and slowly trying to fight against.
(I also struggle with a whole other unrelated topic, on how VC's are, and the fact that as a startup founder I am somewhat "reliant" on them)