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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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)
It made me sad. I Google everything and always have the documentation open in front of me. Before starting to code I draw a UML and then at each step write down what I think and sometimes draw funny things. Some of 10X engineersβ characteristics in one of the tweets scare me. It somehow makes me feel insecure about my habits knowing there are people who might think I'm bad at what I do because I have pinned documentation pages or pause constantly to think. Also the best programmer I've ever seen was my mentor who was a great mentor. You don't know it well, if you can't articulate it.
There's absolutely nothing wrong with using Google, and reading documentation. I do it all the time, I think most people do it otherwise SO would be a lonely place.
I want to highlight a great comment from James' post:
dev.to/thatjoemoore/comment/d1kj
I commented on that as well, but building a team around someone who actually can magically produce 10x more work than others is a TERRIBLE idea. The bus factor is coming for you haha!
for i in range(0, 10):
print(i, βx Engineerβ)
It is a myth and it is something that I will run away if they are looking for a 10x developer.
How will the company be like if the focus is finding 10x developer.
It might mean that they do not spend anytime to build the team.
Which with the right team, leadership, vision and processes in place could deliver software at faster pace than a 10x engineer.
Look at how special forces is composed. They work in a team as a well oiled machine with very strict process to get the job done.
I would be in that type of team anytime than being around a 10x engineer.
Just found this.
10x.engineers
Really though. This all also reminds me of the painful experience of an old employer/small business looking for "rockstar developers" or "ninja developers" and wondering why nobody ever passed his "test".
As I wrote here some time ago, around the 10X devs there is lots of bullshit and some truth, but in the end the
the real multiplying factor is their attitude of sharing knowledge, fostering growth, being an example of passion and hard work which can have an incredibly positive impact on other co-workers and really boost the performance of a team.
Well so much has been said about it. But overall this shows the generalization that people who are in upper/middle management has of developers. Also, such generalization is toxic for our industry
First I saw that thread it made me cringe
But then I jumped in on the fun
And I even ended up creating a small CLI
Yeah baby, just stand back and let us do our job...
I think 10x is a combination of a person and an ecosystem at a point in time.
It's not necessarily good or bad; it's just something that happens.
Sometimes one human being is in a position in which they can do extraordinary, awe-inspiring things.
Great scientists, engineers, artists, composers, military leaders, philosophers, etc.
If I had the opportunity to be 10x at something, I would go for it.
But I'm not too stressed that I don't at present, as I can still live a pretty nice life without being a super-genius or a great figure in history.
If you can build a lifestyle for yourself that's sustainable and enjoyable, then you're still doing well.
We always oversimplify things. Is a nature of reason to do so. We do it all the time when programming. But, the problem is evident in cases like this. Expectations of solve a complex problem (building a team) with a simple solution: find a 10x engineer.
10x engineers are not real, at least not as they are advertised. And more importantly, a single set of skills Will not solve every team problems. Each project, company, team, or any human endeavor has its own needs. We need to do the hard work of matching a skill set with the evolving nature of projects and teams.
Before we talk of 10 x developers/engineers, it would be interesting, asking what is a 1 x. The underlying presupposition is, that there is even a 1 x developer and in comparison to that 10 sounds much more valuable. Interestingly nobody talks about those 8.5 x developers, obviously a neglected minority.
And what do those 5 x developers all day?
OTOH did you ever meet those poor little fellows called the 0.9 x developers. What a tragic story they must have - being ever so close to 1 but never fully 1.
And what about those .75ers? They have tendencies - they are at least half way to the second half of becoming a 1 x developer and ambitions, but will they ever make it to 1 or get stuck at 0.9?
Our industry is obsessed with numbers and metrics even where it totally makes no sense at all.
The 10.x engineers as a discussion is comical at the same times scary as many managers want devs to exhibit these sort of characteristics. When I started my career I thought these sort of things would make me look cool as a dev, over time i realized that doing things in a planned way is way better and honestly prefer 9 to 5 work.
Robert Glass wrote about the 28x programmer about 30 years ago. I beleive that it is possible in many fields.
However, it can depend upon what you are counting. In many fields the bean counters get it wrong, and the truth about productivity and effectiveness is counter intuitive. The 28x guy may simply be the one to be pig headed and stubborn enough to stick to his guns and make good decisions.
Robert Glass also said that the productivity of those that stuck to an old tried and trusted technology for 10 years was usually as good as, if not a lot better than those who followed the latest fads.
In one company we studied, the production manager requested permission to extend the shop floor to cover the Director's car park. When asked what he wanted to use the extra space for, he replied "nothing", but it will help us double our productivity. Explaining, he said that the space would help them with much needed flexibility in a plant that was already running to capacity 24/7. It takes some pluck to ask the CEO for his parking space, and these are the guys that know something we dont.
In coding there are many factors that can be combined to get your 28x.
Your choice of programming language, one with clear simple rules vs no exceptions or gotchas.
Smalltalk has clear unambiguos rules and everything is an object.
PHP/Javascript have many gotchas. There is a 5x difference right there.
Debugging tools, make a big difference. In Smalltalk if the debugger comes up you can fix the code, and hit continue without stopping the execution. You can even code in the debugger. I would give debugging in smalltalk vs PHP/Ruby another factor of 2-3. (actually in practice its more like 20x better)
Readability and its impact on maintainability is another factor of 2-3. Why all of these Java based languages thing that blah(1,2,3) is a readable format I have no idea. Smalltalk's sentence structure can be genuinely readable. (a between: 2 and: 5)
The ability to write your own abstractions and Domain Specific Languages can win you another factor, sometimes as much as 10x. Just look at all the ways that ruby has been used as a DSL.
Wherever there is a conceptual change or interface, there is another barrier to productivity. For example, having your data in an SQL database introduces another language, interfacing libraries, ORM layers and added complexity.
In an Object Oriented Database, where your objects just save themselves, and persisence is transparent and automatic, schema migration is automatic, and transactions are also supported, you get a 2-10x factor right there.
In the 1990s I was shown a programme in which the UI was emailed to Sweden, and the programme carried on working. Objects messaged each other over the internet, and distribution was built-in and seemless. (Papers on distributed Smalltalk go back to 1990.)
What has happen since is that more and more layers have been added, in 1980 Smalltalk was the operating system, and it was the abstraction for everything. It was all one layer. (Now we are using the Javascript VM for this purpose, web assembly is the new target OS)
Since 1980 we now have, the hardware, the micro-kernel, the kernel, the OS, the container orchestration, container runtime, the container, the kernel, the os in the container, the programming language, the database interface, the database, the api server, the api client, the programming language, the vm, the DOM, the css, the websocket/ajax, the client storage etc etc. Layer upon layer, of different technologies and learning curves. Things have gone backwards in a big way.
In coding there are lots of different hats that can be worn, user, tester, author, builder, programmer, architect. At each level diferent technologies prevail, and there is a learning cliff that you need to climb to move up a level.
Your 28x guy can operate at the level of an architect, and so can build the flexibility in to the architecture if they get it right.
Smalltalk is an environment that allows you to operate with all of the different hats on, at all levels, in the same language. You can script a spreadsheet, or write an object oriented database, or invent TDD, MVC, DCI architectures. ST/X is a smalltalk in which you can program your methods in C if you wish, and they are compiled and dynamically linked in.
So if you take long build times of static languages and put this up against the no build time of ST/X (which is still compiled via C) you win another 2x.
Finally, an environment that captures and displays the knowledge of everyone that has gone before over what is now 40 years (since smalltalk 80) and let you browse it and learn from it, will give you such a leg up, you get to build on the shoulders of giants.
In conclusion, I am saying that in principle tools make a huge difference, so any programmer that can be stubborn enough to stop working on the problem that they have been given, and to build tools and abstractions instead that smooth out complexities in that domain, can if they get the time and the space to work at the best of their ability deliver on the 28x promise.
As tools generally get better, debuggers actually work, and abstractions get simpler, we all get better, we all benefit.
Some have commented that many of us here have never worked with anyone that is 10x. My hypothesis is that this kind of advantage is tools and architecture driven. I presided over a simulator project that was developed in parallel to another project, and we did with one guy, what 7 failed to do with other technologies in several attempts, in weeks rather than years, simulating 1000s of equipment rather than 10s, on one server rather than 10s Many times it is about picking the right tool for the job, and building on these strengths.
Now checkout this guy in argentina: Alejandro Reimondo, he has a single development environment that deploys to .net, javascript vm, android, lua vm, ios, native cocoa, and osx. In theory theres 100x right there.
I think this entire discussion has left in me a burning desire in finding out what type of engineer I am, cause I'm not 10x by any chance.
Yes I hate meetings, but I like colorful wallpapers... what am I?
Mister Shekhar Kirani needs to explain the other 9 categories of this π€!!
It is a very odd post - like an obscure self referential joke. I wish I got it. The points taken in isolation feel almost random but uncomfortably gatekeeper. Things that may be true of some people but not necessarily anything to do with why they succeed or fail at engineering tasks.
Taking just the meetings point, my impression is that many people hate meetings because many meetings are bad at balancing the investment of time attending vs the outcomes, and they often happen at inconvenient times.
Has anyone worked with someone that fit this stereotype and convinced them to change?
I specifically mean the talking to the rest of the team part. I mean yeah, the productivity was awesome, but the decisions made in the code because they weren't communicating were terrible.
I think the discussion has been amusing, but if you've been around awhile you realise that "10 x", "full-stack", "big data" etc are all just catch-phrases, I'm pretty sure you couldn't fully define what any of these are. What's funny is when they appear in job ads. Not sure I've seen any for a "10 x" developer but I'm sure the recruiters will catch on soon.
The whole discussion is a bunch of nonsense.
Skirani speaks to "Founders" (their HR, I guess?) in his first post, so he's trying to give hiring advice. Anyone who's ever put together a team knows better than that. Rockstar attitudes just don't work and besides common sense there are countless examples to prove that.
All I can see is a troll trying to annoy the dev scene. Like most successful trolls, he had his five minutes of fame and will be forgotten next week. And we had a few good laughs and some people who gave him a bigger stage than he deserved.
I have a son, I'm happier with this than some metric that the internet says I should be. But if I must pander, I know that as time goes on I can say without fear that I am damn good at what I do, but there is always room to grow and improve (knowing everything about a language just isn't enough). Be the best you can be but don't forget, there is a world out there, off screen that will probably enhance you as a person.
I totally agree. When I was younger I bought into the whole "rockstar" developer mentality. But life happened: I got married and had children. I much prefer a work-life balance and treasure my time with my family more than work. That's not too say I don't give my all when I'm at work, but I don't let it intrude into my "real" life anymore.
Here are my thoughts:
Honestly, I feel that this thread makes a couple logical errors or assumptions:
Being a developer with a top-tier technical skill set means being at the bottom-tier in all other areas.
Technical skills are not orthogonal to all others. Strong engineers can be strong socially, in leadership, planning, creativity, empathy, business acumen, ect...
Software developers are humans and multi-faceted in their skills. Having more of one skill doesn't require having less of another.
The perspective of the 10x twitter thread is naive in its understanding of individuals.
The technical skills have overwhelming importance in terms of value to a company compared to all other skills.
I can only speak to this anecdotally, but the software developers that had the biggest impact, at the organizations I've worked with, were not the genius 10x midnight hacker engineers. (This can also be said for the developers that had the biggest impact on my career, growth, and feeling of self-fulfillment).
It's always the developers that:
... that have the greatest impact.
Yes, someone with the above qualities could also be a great technical engineer, but having that technical prowess, exclusively, won't bring lasting (I'd almost any) success to a team or organization.
I worked with a couple of 10X developers, in the sense that they produced way more than other developers.
The key difference I saw with a normal senior developer was that they are very aware of what differentiates a product from technology and understood the business side of the software industry and that enabled them to ship products with an overall better quality perception from outside the dev teams.
They also were extremely good at tackling complexity and splitting extremely complex tasks into dozens of more simple ones.
They also took the time to teach how things work and ensure that people, no matter if tech or from business, understood how the solution work and what were the logical steps that guided the decisions that lead to it.
One of them, I knew since childhood and when he was a teen he was immersed in books about IT and then logic and math, to the point that for a couple of years he almost never came outside to play because he was holed up in his room devouring books and articles on the internet. One time I asked him how he does it and he told me: "I read each paragraph until I comprehend it completely, if a word doesn't make sense to me then I put a marker in the book and go search about the topic of that word until I comprehend it in its entirety.".
That Twitter image of 10x developer was completely ridiculous (I think my "favourite" was dark theme. Like, seriously? what kind of measure is that?) - but I welcome the post you linked and overall discussion that some people engaged in.
I do think that a better way of fighting such harmful stereotypes is presenting an alternative - a healthier, sustainable image of what being a great developer truly is. Just saying "10x devs don't exist" is, IMO, not as effective because even very early on in our careers we instinctively feel that we prefer to work with some people than others. If fresh developers come across advice like the one in this Twitter thread, there is a risk they'll buy into it, they'll try to follow the wrong path. I'd much rather they (and all of us) had a clear alternative to aspire to.
I know this post has not come up in context of this discussion, but I loved recent Emma's post with 101 tips - this is what a true 10x dev would be like for me.
10x developers don't exist. It's just another made up concept to make us feel inadequate.
You ask 100 people, you get 100 different answers... It's a myth.
I've read DHH mentioned a 10x environment before thinking about any kind of 10x engineer. That I can buy.
Oh, boy. Here we go again.
Please take your time and look through this.
That "10x engineer" articles are targeted to junior-middle aspiring developers who visit meetups and read articles from the "cool guys" on daily basis, often taking everything they said as the truth.
But the truth is that nobody is obliged to be perfect. I'd rather suggest to focus on building their own vision because this is what makes people want your products in the first place.
You'll always beat the "10x engineers". Go with your own vision and you'll create the product people actually want, raise the money and hire 10x engineers to make it perfect. Go with skills only and you'll create the perfect masterpiece nobody really needs.
Grant Cardone's "10X" is pretty much used in Viral memes and clickbaits. I am not surprised current generation of developers have so much impact on them with such clickbait trends. It's on same lines as of "REAL men", "REAL developers", "Real leaders" type of clickbaits. I don't see much credibility in the 10X trend.
Just skimming the thread, maybe I missed it already stated somewhere but I just want to leave my thought here:
"10x" is a marketing term. Nothing more, nothing less. It is used to market and sell tools/books/materials etc. to target markets for a quick buck, and it works. Take for instance the amount of attention this one post has/is generating already. Tons of free/easy marketing and advertising to rile up people and encourage them to buy a product somewhere so they "can become a 10x engineer", meanwhile hurting good engineers that don't fall under these stereotypes by making them less appealing to potential employers.
Just going to reiterate here 10x === Market Term.
Kthxbye
There are so many problem into this tweet, for me it is obviously it's from someone with no coding background, the problem is that it sets a culture of unicorns, ninjas and programmers moved by caffeine, it enforces this culture of mythical creatures(breed, as he describe) that can save the day and will always be ready for more, always learning, always working, never resting, an truly workaholic.
It's just toxic.
I never want to work with someone who identifies themselves as a 10x engineer. It seems like cooperation would be an impediment to getting 10x work done. Then they probably wouldn't like it when I had questions about whether the work getting done was the most business-impactful work we could be doing.
Personally, I feel like a sub 1x solo developer these days. But on a team, I multiply everyone else's capabilities -- mainly due to experience.
Personally, I'm (half-ironically) in accordance with Venkat
I wouldn't characterize a 2x dev as mediocre at all, but that's a level I want to hit and feel fairly certain I could.
First, if we are going to talk about "10x engineers" then we should start with the 1975 book from Fred Brookes: "The Mythical Man Month". That was the first mention of "super programmers" as a order of magnitude more productive.
Second, I am not going to muck through a Twitter thread. Sorry (not sorry).
Wrote about this before.
bannister.us/weblog/2014/multiplier
bannister.us/weblog/2015/programmi...
Yes, there is a difference. Not just in your individual work, but also in the halo effect of keeping your group on track and unstuck.
I have worked with engineers that are able to unpack a problem, unblock many other (more junior) engineers without ever having to touch a keyboard. This one literally made me laugh
Oof... I resemble that
3.tweet from Shekhar Kirani. :pIt didn't need to be had in the first place. The original post was blatantly silly rhetoric. People beat a dead horse about it like they weren't all repeating the obvious.
10x from binary to decimal is 2x which suddenly doesnβt seem as impressive. And this 2x gets neutralized mostly by pair-programming. So yeah.
why is it "canon" that 10x engineers are assholes? Also why for some reason canon bad/allergic to frontend/UI work whether it be mobile or web apps
4 Ok, So if a 10x know each line of code, it means he/she knew it had a bug?
I think its a load of gatekeeping BS. It makes people feel bad about their jobs in an industry with widespread imposter syndrome
Somebody has been watching too much Grant Cardone.
From "A Philosophy of Software Design" from John Ousterhout:
(Edit: It seems that the site is having issues uploading images :/)
It's been only three days, but feels like a year. Legitimate points and jokes aside, it's getting really old really quickly.
Nobody puts 10x engineer in a corner. Nobody!
Price's law, look it up.
Almost every tweet I've seen on being a "10x {insert}" is exactly what to NOT do to be good at that thing. I thought the trend was a meme.
My thoughts are simple, 10X just became another muted word on Twitter.
Is this a webdev thing again?
TBH, sounds more like ASD or ADHD.
It's a waste of time to indulge in anything related to it (Oh the irony!)