If I may .... I was considered one for a small while.
It was 1988, I had just attended John Ousterhout's intro to TCL at UC Berkeley, and I was smitten. At that time, the company I worked at was developing network management systems for the big telecoms of that era, and the front and back-end software was a horrendously complex system built atop a proprietary C++ framework and distributed object system (before CORBA). Any change to the system took ages to understand, make and compile.
I realized in that TCL talk that I could wrap every C++ API function of the framework with TCL, and use it for configuration and testing and CLI apps using the framework. In a feverish daze where I lost track of time but later realized was 16 continuous hours, I learnt TCL and wrapped the entire back-end API. I demoed it the next day and the reception was rapturous ... the testers loved it, the marketing people loved it because they could demo changes instantly, the developers found a release from C++. I was the guy who enabled all devs become 10x devs.
It lasted a small time, after which people got tired of the idiosyncrasies of TCL. But the scripting bug had caught on. The entire API was wrapped up in Python, and Python became the primary way to build systems using that framework. Meanwhile, I learnt Perl and wrote a book for O'Reilly (Advanced Perl Prog-- the panther book). I dream about going in that kind of zone again.
When I think about when I was most productive or when I saw people who had gone though a monumental burst of productivity, it was a combination of:
1) They had the raw skills, IE: experience, tech knowledge, etc.
2) They had the domain knowledge, IE: they knew what needed to be built and had a complete mental picture of the functionality / features / pitfalls / tradeoffs.
3) People stayed the eff out of their way. Very few if any meetings, limited if any oversight - they were allowed to go into their cave for weeks / months and just get the job done.
I had a moment in my career where I produced a year+ worth of work for a team, by myself, in just a couple of months. I saw other people do similar feats at different points. But, it all came crashing down as soon as someone on high decided we'd better start having meetings, better add some more people to that team, better get more project / product /program managers involved... I'm not saying that a 10x developer should be anti-social or even anti-process, but I will say that overhead kills productivity. Further, I am convinced that any reasonably skilled, experienced developer can become a 10x when put into the right framework to allow them to be productive.
My story? 10x developers don't exist. I've worked with incredibly smart people -- geniuses, even -- who contributed ideas and value that I never could, but they weren't "worth" or performing at 10 times the rate of an average developer. They were valuable in their own ways, but never irreplaceable, and certainly came with their own problems; e.g. antisocial behaviors, inability to collaborate well, inability to document and explain their code so that others could maintain it.
Don't chase 10x developers; chase people with soft skills who can work as a team. A team of five people working well together is worth far more than any hypothetical 10x dev.
I've worked indirectly with two 10x developers - sequentially. They worked fast and late into the night. They added every feature the product management asked for and more. When the product management team rotated and the new PMs added more feature requests, they obliged whether the feature was really necessary or not and even if the other devs had pushed back on the feature.
They also handled all uptime issues no matter what hour of the day. The rest of the team tried to help out but by that time the code base was too complex for 1x developers to support.
Then after a few years with the company, they each ended up getting tired of doing all the leg work and moved on and the remaining team members figured out the bare minimum to kick the server when needed and promptly started on version 2.0 at a 1x pace with only the core features and more bus factor built in.
That said I do think 10x devs have a sweet spot in a startup thats still trying to find product market fit and overthinking/over documenting can mean the startup never gets off the ground.
I think I agree overall and I'll take it a bit further: developers aren't an anything-x, they are a range based on the task and their current mental/emotional/physical state. I know as programmers/people interested in tech we can fall into the trap of thinking of people like we do machines but it's a deeply flawed approach (one that I've fallen into MANY times).
For years I wanted to slot people into boxes and think of them the same way I might think of a server. I wish I could go back and slap the earlier version of myself. Like you say, the soft skills are 1000x more important to me now. I won't suffer a "10x" developer if they are an ass nor will I dismiss someone just because I have some misguided idea that they should be performing better. Of course, all of this has a number of exceptions, I wouldn't be happy with someone who is not pulling their weight but I've realized there are more important things to optimize for, team cohesion being a top priority.
If I can communicate with you well and you are enjoyable to work with then I'll look past, what a younger me would have considered, "your flaws". I've witnessed in my self and others what I like to call "team multipliers". In that the output of 2 or more people is higher than what either could do individually. Those "multipliers" can result in better output from a bunch of "5x"ers (again, this is a silly measurement) verses the same number of "10x"ers who don't work well with others/together.
I know it's been tried (and it sounds like it kind of failed) but I really love the idea of hiring a group of people instead of individuals. At my current company I've helped get 2 people I previously worked with jobs because I know they are both assets to the team and that they make me better. "As iron sharpens iron", and all that.
I've worked with hundreds of engineers in my career, and was lucky enough to have worked with probably a dozen or so that could qualify as a 10x developer.
The premise of a 10x developer is not that they work at 10x the velocity of a 1x engineer. If the average velocity per engineer on a team is 10 story points per sprint, a 10x developer is not going to complete 100 story points in the same sprint. That's impossible.
Instead, the 10x engineer will increase the overall velocity and code quality of an entire team, which could manifest as an additional 90 story points of velocity in a given sprint (if you can objectively compare story point quality across sprints).
If you pair a decent PM with a team of 8 junior-to-average engineers, the PM will have a roadmap that they can track towards with some level of granularity but will likely not be able to guarantee quality of the product and achieve reasonable timelines.
If you add a single 10x engineer to that team, the entire team will step up because 1) they can learn from someone and are motivated to do a good job, 2) they become more intellectually stimulated because they have someone they can bounce high-level ideas off of and actually get good answers, and 3) there's an implicit trust of having someone who is so much better than you telling you how things should be done and expecting you to step up and do it.
My best experience was working on a team as the sole PM with 15 engineers, 3 of whom were considered 10x engineers. As a result, we brought in engineers from other parts of the company who were considered average at best, and turned them into high-performing "5x" engineers. We did that about a dozen times over the course of 2 years.
> If the average velocity per engineer on a team is 10 story points per sprint, a 10x developer is not going to complete 100 story points in the same sprint. That's impossible.
Is it? We had a sprint in march. Estimated 60 story points, arguably split between 4 people. Around 48(?) points got done, and I did 32 of them. The other 3 people each did around 20% of what I did. 3 of us were only part time on that project (~20 hrs per week).
Now, with that said... it was somewhat an edge case. That differential existed for a long time, and I kept it going for months (close to a year, honestly), but burned out. One of the biggest (expressed) concerns I had was "if we hit all this, they'll just keep adding more". And... that's what happened.
Along the way ... I was growing more and more irritable - the pressure, the meeting pace, the public front to the client vs the under-the-hood realities, the constant feeling of letting everyone else down if I didn't finish everything...
I pulled back my time/commitment some, and that feeling got worse, because no one actually pulled back any goals/commitments, just... more public "yes, things are great, everything will be fine, all goals will be met!" and a growing increase in stuff not getting done.
> If you add a single 10x engineer to that team, the entire team will step up because 1) they can learn from someone and are motivated to do a good job, 2) they become more intellectually stimulated because they have someone they can bounce high-level ideas off of and actually get good answers, and 3) there's an implicit trust of having someone who is so much better than you telling you how things should be done and expecting you to step up and do it.
The team would actually want to learn and get better. Some will and some won't. I've seen it go both ways in the past 20 years. The people have to want it, and the org needs to have an actual plan in place to support that goal.
There was a particular business process that our sales people were preparing manually and one of the engineers thought it would save them a lot more if they simply had a web UI, so he made it. Except the UI replicated all the same, tedious parts of the process, which was basically filling up a bunch of forms.
We had a sales team of 8 who spent 2 ~ 3 hours every morning filling out these forms. And the forms expand as we get more sales so it was a growing problem. So I proposed to use as many re-useable templates and defaults as possible. Most clients essentially came from 3 or 4 categories and wanted more or less the same options. If you're in category A, only options 1, 2 and 3 are eligible, everything else from 4 to 100 is just noise so hide/remove them!
Just one trick managed to reduce the amount of form filling from an entire sales team x 3 hours to 1 junior person x half an hour.
My take away from that experience is 10x anything isn't about writing some amazing piece of code, it's about providing a better process.
I know an objectively measured 500x programmer. He is humble about it because he knows somebody >1000x, who wears out 2 keyboards per year (or did then).
The setting was the early '90s. Siemens and Ericsson started a joint project, Ellemtel. Each assigned 500 engineers. It was a classic Death March: deliver in six months from the starting gun, or all is discarded and the parent companies don't get paid.
After the project ended, on time, one totted up who coded what in the delivered product. Fully half was by this individual. Without him, delivery would not have happened.
He assigned work units on two-week intervals. Any assignment not completed on time, he set aside and did by himself over the weekend.
Something else interesting: they took blood samples and measured stress hormone levels. A year later, levels had not returned to previous baseline. But Mr 500x's level did not go up.
I believe that 10x developer is real, but it's not that a particular person is 10x faster/better than another, it's more that in the right circumstances, when intrinsic motivation, a clear vision, having the right tools for the job and knowing them well, understanding the problem space, having the right fit with methodology and scale, etc.. -- when everything lines up anyone will be 10x as productive as other people who aren't as well aligned. The cases where I've seen (or been) the 10x person have always been because I've been operating with different assumptions and approaches, or using different tools that were a better fit for the problem.
If your development feels 10x slower than it could be, go back and look at where the time is going. I guarantee it won't be actually going to development. A simple example, maybe people are spending 9x writing useless tests and integrations or writing abstract code for things that will only ever be one concrete implementation in the real world. Yet in a different context coders could be spending 9x of their time firefighting and fixing releases because you don't have enough automated testing, or spending time hacking up a monolithic uberclass because it wasn't abstracted enough. It's not that one of those is right and the other is wrong, it's that one is a much better fit for the situation.
Similar with motivation (are people excited to solve the problem?), with having a clear idea of what you're building, etc. Every one of those is a multiplier. It can be a 1.5x or a 0.8x. You stack those up, and a 1.2x motivation * 1.3x "fast deploy mindset" * 2.0x clear vision = 3x, but 0.8x low motivation * 0.7x write a bunch of useless boilerplate * 0.9x "we're all building different things" rapidly turns into a 0.4x productivity.
Dude would write a DSL over a weekend to generate and validate Bind configs. Could invent whole new categories of solutions to problems - if he felt like waking up after 2PM. Never showered. Hard to get him in the office or on the phone. Absolutely no work/project commitments, just what he felt like working on. The rest of us did all the real work and his magic dev rock star pixie dust would occasionally grace us with something really useful but not generating any business value. Glad I saw that early in my career.
I have worked with more than one 10x developer. They didn’t work harder than anybody else. However they consistently made everybody in the company way more productive by simplifying things and resolving issues that nobody else could resolve. One of them single-handedly maintained a very large complex C++ library used by other teams. And he had zero bugs in production for years. His test suite was that good. He spent almost 95% of his time adding features instead of fixing bugs. He ended up maintaining two projects larger and more complex that projects maintained by whole teams and still had time to jump in and help teams that got stuck when needed. Another one unblocked a team that was stuck for 3 months making zero progress in a single meeting. And none of the 10x developers were assholes. Easy to talk to and always eager to learn how to do things better. Respect!
Stressful. If you work faster than your colleagues, you are making them look bad and that pisses them off. If you slow down to their speed, they notice you browsing Hacker News all day and that pisses them off too. If you once push a fix that crashes the live server you'll never hear the end of it even if everyone else does it twice per week. Meetings with project managers get awkward: "You were working on five features this week and have implemented them all? Including test cases? Wow, impressive!" "And how is it going for you, [name redacted]? Still struggling with that bug from three weeks ago?" "Your kid was sick so you haven't had the time to work on it?.... Let's reassign that bug..." Then there are the young and incredibly talented but not very practical developers (5x developers?). Those who spend two years developing their own in-house cms for the company because Joomla didn't have that one specific feature they wanted. Tell them that the feature exists in out-of-the-box Wordpress installations? And don't get me started on the stupid but widespread "if you are that good at coding there must be something wrong with you" prejudice...
Fwiw, I don't think we as a community should use the term 10x developer. It should be "a developer ten times stronger than the average developer." Because any developer can increase their strength tenfold with enough practice.
I worked at my previous organisation with one 10x developer (I was a team lead) and managed to have him follow me to the new company. That person reached that status at the last position because management didn't have capacity to employ quality developers, so this guy was literally able to get work done that other 10 random people from the development team couldn't do in any time frame. He was also the go-to-person for any questions regarding any kind of optimization, Heisenbugs, SQL query tuning and everything in between.
This man was so valuable, that he was the only person that could freely have almost anything on the screen, excluding hard core porn, instead of IDE, and no-one, not even the board members that came to visit our offices from time to time, dared to say anything.
To give you some perspective, we had this ugly system that was bought for several hundreds thousands of usd for the purpose of processing one specific type of information. The system was delivered by the third party and its implementation into our infrastructure took about a year.
The problem with it was, the time it took to process a single xml message, just the message acknowledgement took 1.5 second in the best case scenario, while the whole message processing took around 30-ish seconds.
It came a moment when it was needed for this system to interface with another system outside our organisation. It had a requirement that all messages should be processed end-to-end in less than 10 seconds. Soft deadline was set for two years and in that period only 25% of institutions (us included) managed to get it done, by using full teams of 10+ developers.
On our side, we had this guy and one product owner. He managed to code the proxy that basically did the whole logic of that old system and just inserted the results in db without knowing the inner workings of existing software in three months.
It is useful to add that when interviewing at the new company, were I came before him, they immediately recognized his worth on the screening interview and he was fast tracked to the employment.
I think my fave story isn't particularly technical but had incredible value. I was at a retail Forex company working on the main trading client program. We would always get issues about a trade not executing at the price that was quoted. I knew we had a client-side log that support could get the user to open and read a part out of. I was trying to think of how to make it so that it was tamper-proof some kind of line-digest that the average user wouldn't know to replicate.
Anyway I put that idea off, and started playing with other parts. An interesting idea was trying to recreate the custom-drawn home-grown widget set using Java Swing JPanel's in the ASCII log file. I naively started down the path and got text labels, entry fields, radio buttons, checkboxes. One tricky bit was knowing when to insert a line or not if the baselines were close enough and there was no overwriting of characters. Anyway it worked surprisingly well. I also logged the currency pair and price immediately before sending the order to the server in simple text.
When we got support calls about an order not executing at the quoted price, the user would be asked to open the log and they'd see an ASCII version of their order dialog as well as the same data sent to the server. The number of these calls dropped dramatically. I was shocked by how much authority a crude picture had for the user--it's no different than text lines that capture the same info but showing it in the same layout makes them believe it's true, even if it weren't the case.
I remember, I do have a recent one. An application/service was ported from PostgreSQL to MySQL but there was a particular set of queries that used to run in a 5-10 minutes that wouldn't finish in 6h+. It was due for release so had a set Friday deadline giving us almost a week. The queries were large and complicated having been evolved over the course of app development specific to PostgreSQL. Also complicated by the queries being dynamically built at runtime with various in/out optional parts. If you look at the main slow core, and by comparing query plans on pg vs mysql, we could see that pg did more 'query plan normalization' (or rewriting in a way). After that we rewrote bits and bits of the query adding indexes, and partial subqueries for reuse, de-correlating subqueries, moving functions from SQL to code before/after query, force index hints, etc. By Friday we got it down to under a minute. One tip was recognizing that one of the columns in the tables was a tenant key so its cardinality was useless if already using a higher cardinality index. DBs should really have a representation for this. Writing SQL for MySQL is like writing C vs writing Prolog for PostgreSQL.
Another old one was getting a large OS/2 program to run in DOS 640 KB with overlay segments that swapped out. The trick being that you want to minimize transitions between overlay segments. Parsed a call tree of the entire program and assigned overlay numbers based on some large chunks of subtrees with the most common leaf calls being in segment 99 that always lived within the 640KB. It ran fast enough and shipped without revising the shrink wrap dates.
A friend of mine joined a new company and within one week solved a performance problem that the company hadn’t been able to solve for years. It allowed the company to sell a $10 million solution to a customer. So I guess he delivered way more than 10x in just one week :)
I was considered 10x despite trying my best to explain that i am not. I discovered templating and i generated lot of code using templates this did increased productivity as lot of things that had to be done manually by developers were automated. I tried to educate other developers and management about templating but they just overlooked it and were hellbent to make me look as if i am genius! sometimes i feel it was a conspiracy so that others don't have to deal with templates ;-) sigh.
I met developers who were way more than only 10x. They were so full of fire that they inspired whole departments with their drive. They drove up the productivity of each and every developer by 1.2x or something and in sum that was way more than they ever could have worked on their own. Sadly, management often doesn't recognize this skill and just sees a warrior who doesn't do as many commits as everyone else, finally getting rid of those.
In a five person team one 10x programmer tried to do everything. After some futile resistance everyone else stepped back to let the fool drown. He took every moderately hard task to himself. He was a great and relentless developer with duck tape mentality but deep knowledge and managed to do more than 70% of the project done. The rest of us worked around him. It was miserable.
I much prefer working with lazy 0.7x developers with a healthy relationship to code and people.
I find the concept of "10x" super interesting. I'm an accountant, not a dev, but had never jeard of it before.
Surely, any knowledge profession could have 10x types. I suppose my main question is would a 10x type, get 10x compensation? I see a lot of comments re 10x where that person works late, etc, then suffers burnout or is insufferable. Seems like a pretty high personal cost...
Don't know about 10x or what that even really means but the highest skilled and most important highest achievers that I've worked with have all produced something very good and almost all have burnt out in some manner.
That's generally what happens with high achievers they burnout. Sometimes in crazy fantastical ways.
I don't believe 10x is actually possible as a single developer. In 20 years I haven't met one.
I have however run across people able to lift up entire teams and even surrounding teams. So instead of 1x10 it was maybe more like 15x1.5, so still a huge boost, just not technically from a single person.
I will take a "multiplier" over a 10x any day of the week.
I can write code, having been writing code for nearly 40 years, working in code for 25 years. I could never write most of the stuff Linus, K&R, Gosling etc come up with so maybe x10 is uncommon, but xInfinity isn't impossible.
I contracted at this telecom for years, and a few years after I left the guy I'd reported to told me that they'd actually replaced me with a team of five people. So I guess 5x :-)
I mostly did custom network management, provisioning and automation stuff, the kind of thing that really raises productivity for the teams that manage all that gear.
The 10x developer experience is to me a temporary one. It can exist if the problem being addressed is in my technical "wheelhouse" and their is no impedance caused by the development methodology.
The closest I've seen has been developers that actually write documentation for what they're working on, allowing others to get up to speed on it faster even after they no longer work on the project.
I design the ETL pipelines, customize databases, manage the backend & APIs and do 3D ML research. We are 3 engineers as FTE where the other two are data scientists.
Personally speaking, the biggest bursts of developer contributions I've observed haven't necessarily been technical achievements (though those exist, particularly in crunch-time situations where somebody really busts his ass for a few days/weeks/months), but process and business realizations.
Once a smart developer gets his hands into a domain and really understands how and why things work, they come up with realizations about the business or problem that really needs to be solved. Because they see all of the technical parts of the project, they can see stuff that the business people can't: things like figuring out what tasks might be able to be automated? Or what data can be connected to create new insights? I've seen some genuinely very smart business people working on a particular problem for years who didn't make the mental connections about what was possible to do with a certain kind of data, who smacked his own face in frustration once he was told by the developer what he could do with his data. These kinds of realizations are usually worth more to a project than even the most skilled developer.
Citing a few accomplishments, unsure whether one would call them 10X or not. You decide. :-)
Year 2000. I was a masters student helping a professor's research group. They wanted a complex GUI app for Augmented Reality built using a computer vision library developed by someone else. I was ambiguously described the requirements verbally. I conceptualized the UI/UX, wrote 30K lines of code in C++ for the Windows App, tested everything and showcased to them, all done in about a month. The user experience exceeded their expectations. Practically no bugs ever found. They were impressed and I received research assistant position under them.
Year 2007. I made a proposal that received mostly skepticism on feasibility. One manager supported but could not allocate resources. Later, two managers, both secretly, had two-month interns work on the same, as I discovered during the intern seminars! One 4-5 years experienced person also separately worked on the same. The intern projects worked but did not meet the accuracy needed. The experienced coworker's system worked better, though still did not achieved the performance. That system was taking 40 minutes for one run, and they were reaching out for ways to optimize. Soon, a high-severity issue happened which required the proposed system with high accuracy, and I was in the line of fire. Worked heavily for two days. Came up with a simple idea on how to solve it. Coded.
Problem solved. Had ~15 times higher accuracy. Had real-time processing. I summarized the delivered system's capabilities in an email to a large audience. Those unaware thought it was conclusion of a few month long project. After having learnt that I had done it in two days, someone stopped by my office and said, "I would rather kick my butt than sit in a programming competition with you". The system saw good adoption and continued usage for years without any issues. One single bug discovered over its lifetime, which happened because the code had made an tacit assumption that was invalidated by later devices under test.
2010-11. A group was working on a complex problem for video half-toning. One person had 25 years of experience in image processing and color science. An intern who was pursuing research in the same area was hired to solve the problem under the guidance of the noted expert. I pointed to the intern that he's taking a complicated route to solving without having ruled out a potentially simpler path. He agreed but did not do anything. Two months internship over. Later, the problem came to me as I needed to solve the same for a different type of display system. I thought about it, prototyped, and showed an unambiguously better solution in two days net, applicable to previous system as well. One of the previous owners of the problem happily congratulated me. Resulted in filing of a patent application.
I can cite many more examples.
I had earned #2 spot at university programming competition.
I used to be writing about 600-800 lines of code per work day, with defect density of less than 0.5 bug per thousand lines of code. There have also been times working on difficult research problems when I've been as slow as 200 lines of code in an entire month.
I am no longer all that because of some unfortunate circumstances. I am not actively coding and tend to make more mistakes these days though still am considered exemplary in whatever I produce.
I was working late one night at the office when the main phone line rang. It was a small company so there was a good chance I'd know the caller so I answered it (with the phone on my desk with all those light-up buttons for lines). If was from RnD support engineers on the west coast working on an IBM project. One of the dev machines hard drives got wiped out. They didn't have distributed source control (it was the 90s) and this particular machine had a lot of new code on it. The machine was running OS/2 with the HPFS filesystem.
Sometimes, I'd read various books and documents on the office bookshelves late at night. One particular one that I'd read recently was co-incidentally about the HPFS filesystem in those 'IBM red books'. I figured they have nothing more to lose so I came up with a plan.
- connect by dial-up modem to transfer the DOS 'nu' Norton utility @9600 bps.
- boot DOS and copy select sectors and ranges of sectors from another machine
- boot DOS and plaster those select sectors and ranges to the damaged machine
- boot OS/2 safe-mode and run the HPFS chkdsk with the option to build file entries for anything that looks like filesystem data structures
- reboot
The magical sectors were the MBR and superblock boot sectors + backup copy, the central directory in the middle of the disk (for lower average seek time) and the main allocation tables. There are also bands of locally allocated ranges on the disk but I didn't try to do anything with those.
Long story, medium-length, it all worked. He bought me beer and mongolian bbq when I came to visit.
There was another story about recovering a NetWare LAN partition when it got corrupted and all the file entries got deleted. That was easier, it required dinner first chicken-club with lots of mayo--can't think well on an empty stomach--then figuring out that there's a 'trash can' file area. And manually undeleting everything we could find with the help of others that were in the office. I don't remember exactly how many 10k+ files we undeleted but it took a while. Some people were annoyed that files they deleted were back the next day.
I have another story about a group project that used up all timeshare credits and couldn't access the group assignment program. I pulled an all-nighter talking to a sr who knew a lot about CMS features, so I co-incidentally liked all our drive allocations across accounts. Worked like magic elves.
My best contributions code-wise is not writing it and instead getting people to think in a way that by re-arranging what we already have in slight ways that if you look at it funny will do what you want.
It was 1988, I had just attended John Ousterhout's intro to TCL at UC Berkeley, and I was smitten. At that time, the company I worked at was developing network management systems for the big telecoms of that era, and the front and back-end software was a horrendously complex system built atop a proprietary C++ framework and distributed object system (before CORBA). Any change to the system took ages to understand, make and compile.
I realized in that TCL talk that I could wrap every C++ API function of the framework with TCL, and use it for configuration and testing and CLI apps using the framework. In a feverish daze where I lost track of time but later realized was 16 continuous hours, I learnt TCL and wrapped the entire back-end API. I demoed it the next day and the reception was rapturous ... the testers loved it, the marketing people loved it because they could demo changes instantly, the developers found a release from C++. I was the guy who enabled all devs become 10x devs.
It lasted a small time, after which people got tired of the idiosyncrasies of TCL. But the scripting bug had caught on. The entire API was wrapped up in Python, and Python became the primary way to build systems using that framework. Meanwhile, I learnt Perl and wrote a book for O'Reilly (Advanced Perl Prog-- the panther book). I dream about going in that kind of zone again.
1) They had the raw skills, IE: experience, tech knowledge, etc. 2) They had the domain knowledge, IE: they knew what needed to be built and had a complete mental picture of the functionality / features / pitfalls / tradeoffs. 3) People stayed the eff out of their way. Very few if any meetings, limited if any oversight - they were allowed to go into their cave for weeks / months and just get the job done.
I had a moment in my career where I produced a year+ worth of work for a team, by myself, in just a couple of months. I saw other people do similar feats at different points. But, it all came crashing down as soon as someone on high decided we'd better start having meetings, better add some more people to that team, better get more project / product /program managers involved... I'm not saying that a 10x developer should be anti-social or even anti-process, but I will say that overhead kills productivity. Further, I am convinced that any reasonably skilled, experienced developer can become a 10x when put into the right framework to allow them to be productive.
Don't chase 10x developers; chase people with soft skills who can work as a team. A team of five people working well together is worth far more than any hypothetical 10x dev.
They also handled all uptime issues no matter what hour of the day. The rest of the team tried to help out but by that time the code base was too complex for 1x developers to support.
Then after a few years with the company, they each ended up getting tired of doing all the leg work and moved on and the remaining team members figured out the bare minimum to kick the server when needed and promptly started on version 2.0 at a 1x pace with only the core features and more bus factor built in.
That said I do think 10x devs have a sweet spot in a startup thats still trying to find product market fit and overthinking/over documenting can mean the startup never gets off the ground.
For years I wanted to slot people into boxes and think of them the same way I might think of a server. I wish I could go back and slap the earlier version of myself. Like you say, the soft skills are 1000x more important to me now. I won't suffer a "10x" developer if they are an ass nor will I dismiss someone just because I have some misguided idea that they should be performing better. Of course, all of this has a number of exceptions, I wouldn't be happy with someone who is not pulling their weight but I've realized there are more important things to optimize for, team cohesion being a top priority.
If I can communicate with you well and you are enjoyable to work with then I'll look past, what a younger me would have considered, "your flaws". I've witnessed in my self and others what I like to call "team multipliers". In that the output of 2 or more people is higher than what either could do individually. Those "multipliers" can result in better output from a bunch of "5x"ers (again, this is a silly measurement) verses the same number of "10x"ers who don't work well with others/together.
I know it's been tried (and it sounds like it kind of failed) but I really love the idea of hiring a group of people instead of individuals. At my current company I've helped get 2 people I previously worked with jobs because I know they are both assets to the team and that they make me better. "As iron sharpens iron", and all that.
The premise of a 10x developer is not that they work at 10x the velocity of a 1x engineer. If the average velocity per engineer on a team is 10 story points per sprint, a 10x developer is not going to complete 100 story points in the same sprint. That's impossible.
Instead, the 10x engineer will increase the overall velocity and code quality of an entire team, which could manifest as an additional 90 story points of velocity in a given sprint (if you can objectively compare story point quality across sprints).
If you pair a decent PM with a team of 8 junior-to-average engineers, the PM will have a roadmap that they can track towards with some level of granularity but will likely not be able to guarantee quality of the product and achieve reasonable timelines.
If you add a single 10x engineer to that team, the entire team will step up because 1) they can learn from someone and are motivated to do a good job, 2) they become more intellectually stimulated because they have someone they can bounce high-level ideas off of and actually get good answers, and 3) there's an implicit trust of having someone who is so much better than you telling you how things should be done and expecting you to step up and do it.
My best experience was working on a team as the sole PM with 15 engineers, 3 of whom were considered 10x engineers. As a result, we brought in engineers from other parts of the company who were considered average at best, and turned them into high-performing "5x" engineers. We did that about a dozen times over the course of 2 years.
Is it? We had a sprint in march. Estimated 60 story points, arguably split between 4 people. Around 48(?) points got done, and I did 32 of them. The other 3 people each did around 20% of what I did. 3 of us were only part time on that project (~20 hrs per week).
Now, with that said... it was somewhat an edge case. That differential existed for a long time, and I kept it going for months (close to a year, honestly), but burned out. One of the biggest (expressed) concerns I had was "if we hit all this, they'll just keep adding more". And... that's what happened.
Along the way ... I was growing more and more irritable - the pressure, the meeting pace, the public front to the client vs the under-the-hood realities, the constant feeling of letting everyone else down if I didn't finish everything...
I pulled back my time/commitment some, and that feeling got worse, because no one actually pulled back any goals/commitments, just... more public "yes, things are great, everything will be fine, all goals will be met!" and a growing increase in stuff not getting done.
> If you add a single 10x engineer to that team, the entire team will step up because 1) they can learn from someone and are motivated to do a good job, 2) they become more intellectually stimulated because they have someone they can bounce high-level ideas off of and actually get good answers, and 3) there's an implicit trust of having someone who is so much better than you telling you how things should be done and expecting you to step up and do it.
The team would actually want to learn and get better. Some will and some won't. I've seen it go both ways in the past 20 years. The people have to want it, and the org needs to have an actual plan in place to support that goal.
There was a particular business process that our sales people were preparing manually and one of the engineers thought it would save them a lot more if they simply had a web UI, so he made it. Except the UI replicated all the same, tedious parts of the process, which was basically filling up a bunch of forms.
We had a sales team of 8 who spent 2 ~ 3 hours every morning filling out these forms. And the forms expand as we get more sales so it was a growing problem. So I proposed to use as many re-useable templates and defaults as possible. Most clients essentially came from 3 or 4 categories and wanted more or less the same options. If you're in category A, only options 1, 2 and 3 are eligible, everything else from 4 to 100 is just noise so hide/remove them!
Just one trick managed to reduce the amount of form filling from an entire sales team x 3 hours to 1 junior person x half an hour.
My take away from that experience is 10x anything isn't about writing some amazing piece of code, it's about providing a better process.
The setting was the early '90s. Siemens and Ericsson started a joint project, Ellemtel. Each assigned 500 engineers. It was a classic Death March: deliver in six months from the starting gun, or all is discarded and the parent companies don't get paid.
After the project ended, on time, one totted up who coded what in the delivered product. Fully half was by this individual. Without him, delivery would not have happened.
He assigned work units on two-week intervals. Any assignment not completed on time, he set aside and did by himself over the weekend.
Something else interesting: they took blood samples and measured stress hormone levels. A year later, levels had not returned to previous baseline. But Mr 500x's level did not go up.
If your development feels 10x slower than it could be, go back and look at where the time is going. I guarantee it won't be actually going to development. A simple example, maybe people are spending 9x writing useless tests and integrations or writing abstract code for things that will only ever be one concrete implementation in the real world. Yet in a different context coders could be spending 9x of their time firefighting and fixing releases because you don't have enough automated testing, or spending time hacking up a monolithic uberclass because it wasn't abstracted enough. It's not that one of those is right and the other is wrong, it's that one is a much better fit for the situation.
Similar with motivation (are people excited to solve the problem?), with having a clear idea of what you're building, etc. Every one of those is a multiplier. It can be a 1.5x or a 0.8x. You stack those up, and a 1.2x motivation * 1.3x "fast deploy mindset" * 2.0x clear vision = 3x, but 0.8x low motivation * 0.7x write a bunch of useless boilerplate * 0.9x "we're all building different things" rapidly turns into a 0.4x productivity.
Fwiw, I don't think we as a community should use the term 10x developer. It should be "a developer ten times stronger than the average developer." Because any developer can increase their strength tenfold with enough practice.
the median programmer struggles with fizbuzz
This man was so valuable, that he was the only person that could freely have almost anything on the screen, excluding hard core porn, instead of IDE, and no-one, not even the board members that came to visit our offices from time to time, dared to say anything.
To give you some perspective, we had this ugly system that was bought for several hundreds thousands of usd for the purpose of processing one specific type of information. The system was delivered by the third party and its implementation into our infrastructure took about a year.
The problem with it was, the time it took to process a single xml message, just the message acknowledgement took 1.5 second in the best case scenario, while the whole message processing took around 30-ish seconds.
It came a moment when it was needed for this system to interface with another system outside our organisation. It had a requirement that all messages should be processed end-to-end in less than 10 seconds. Soft deadline was set for two years and in that period only 25% of institutions (us included) managed to get it done, by using full teams of 10+ developers.
On our side, we had this guy and one product owner. He managed to code the proxy that basically did the whole logic of that old system and just inserted the results in db without knowing the inner workings of existing software in three months.
It is useful to add that when interviewing at the new company, were I came before him, they immediately recognized his worth on the screening interview and he was fast tracked to the employment.
Anyway I put that idea off, and started playing with other parts. An interesting idea was trying to recreate the custom-drawn home-grown widget set using Java Swing JPanel's in the ASCII log file. I naively started down the path and got text labels, entry fields, radio buttons, checkboxes. One tricky bit was knowing when to insert a line or not if the baselines were close enough and there was no overwriting of characters. Anyway it worked surprisingly well. I also logged the currency pair and price immediately before sending the order to the server in simple text.
When we got support calls about an order not executing at the quoted price, the user would be asked to open the log and they'd see an ASCII version of their order dialog as well as the same data sent to the server. The number of these calls dropped dramatically. I was shocked by how much authority a crude picture had for the user--it's no different than text lines that capture the same info but showing it in the same layout makes them believe it's true, even if it weren't the case.
Another old one was getting a large OS/2 program to run in DOS 640 KB with overlay segments that swapped out. The trick being that you want to minimize transitions between overlay segments. Parsed a call tree of the entire program and assigned overlay numbers based on some large chunks of subtrees with the most common leaf calls being in segment 99 that always lived within the 640KB. It ran fast enough and shipped without revising the shrink wrap dates.
I much prefer working with lazy 0.7x developers with a healthy relationship to code and people.
Surely, any knowledge profession could have 10x types. I suppose my main question is would a 10x type, get 10x compensation? I see a lot of comments re 10x where that person works late, etc, then suffers burnout or is insufferable. Seems like a pretty high personal cost...
That's generally what happens with high achievers they burnout. Sometimes in crazy fantastical ways.
I have however run across people able to lift up entire teams and even surrounding teams. So instead of 1x10 it was maybe more like 15x1.5, so still a huge boost, just not technically from a single person.
I will take a "multiplier" over a 10x any day of the week.
I mostly did custom network management, provisioning and automation stuff, the kind of thing that really raises productivity for the teams that manage all that gear.
I design the ETL pipelines, customize databases, manage the backend & APIs and do 3D ML research. We are 3 engineers as FTE where the other two are data scientists.
Once a smart developer gets his hands into a domain and really understands how and why things work, they come up with realizations about the business or problem that really needs to be solved. Because they see all of the technical parts of the project, they can see stuff that the business people can't: things like figuring out what tasks might be able to be automated? Or what data can be connected to create new insights? I've seen some genuinely very smart business people working on a particular problem for years who didn't make the mental connections about what was possible to do with a certain kind of data, who smacked his own face in frustration once he was told by the developer what he could do with his data. These kinds of realizations are usually worth more to a project than even the most skilled developer.
Year 2000. I was a masters student helping a professor's research group. They wanted a complex GUI app for Augmented Reality built using a computer vision library developed by someone else. I was ambiguously described the requirements verbally. I conceptualized the UI/UX, wrote 30K lines of code in C++ for the Windows App, tested everything and showcased to them, all done in about a month. The user experience exceeded their expectations. Practically no bugs ever found. They were impressed and I received research assistant position under them.
Year 2007. I made a proposal that received mostly skepticism on feasibility. One manager supported but could not allocate resources. Later, two managers, both secretly, had two-month interns work on the same, as I discovered during the intern seminars! One 4-5 years experienced person also separately worked on the same. The intern projects worked but did not meet the accuracy needed. The experienced coworker's system worked better, though still did not achieved the performance. That system was taking 40 minutes for one run, and they were reaching out for ways to optimize. Soon, a high-severity issue happened which required the proposed system with high accuracy, and I was in the line of fire. Worked heavily for two days. Came up with a simple idea on how to solve it. Coded. Problem solved. Had ~15 times higher accuracy. Had real-time processing. I summarized the delivered system's capabilities in an email to a large audience. Those unaware thought it was conclusion of a few month long project. After having learnt that I had done it in two days, someone stopped by my office and said, "I would rather kick my butt than sit in a programming competition with you". The system saw good adoption and continued usage for years without any issues. One single bug discovered over its lifetime, which happened because the code had made an tacit assumption that was invalidated by later devices under test.
2010-11. A group was working on a complex problem for video half-toning. One person had 25 years of experience in image processing and color science. An intern who was pursuing research in the same area was hired to solve the problem under the guidance of the noted expert. I pointed to the intern that he's taking a complicated route to solving without having ruled out a potentially simpler path. He agreed but did not do anything. Two months internship over. Later, the problem came to me as I needed to solve the same for a different type of display system. I thought about it, prototyped, and showed an unambiguously better solution in two days net, applicable to previous system as well. One of the previous owners of the problem happily congratulated me. Resulted in filing of a patent application.
I can cite many more examples.
I had earned #2 spot at university programming competition.
I used to be writing about 600-800 lines of code per work day, with defect density of less than 0.5 bug per thousand lines of code. There have also been times working on difficult research problems when I've been as slow as 200 lines of code in an entire month.
I am no longer all that because of some unfortunate circumstances. I am not actively coding and tend to make more mistakes these days though still am considered exemplary in whatever I produce.
I was working late one night at the office when the main phone line rang. It was a small company so there was a good chance I'd know the caller so I answered it (with the phone on my desk with all those light-up buttons for lines). If was from RnD support engineers on the west coast working on an IBM project. One of the dev machines hard drives got wiped out. They didn't have distributed source control (it was the 90s) and this particular machine had a lot of new code on it. The machine was running OS/2 with the HPFS filesystem.
Sometimes, I'd read various books and documents on the office bookshelves late at night. One particular one that I'd read recently was co-incidentally about the HPFS filesystem in those 'IBM red books'. I figured they have nothing more to lose so I came up with a plan.
The magical sectors were the MBR and superblock boot sectors + backup copy, the central directory in the middle of the disk (for lower average seek time) and the main allocation tables. There are also bands of locally allocated ranges on the disk but I didn't try to do anything with those.Long story, medium-length, it all worked. He bought me beer and mongolian bbq when I came to visit.
There was another story about recovering a NetWare LAN partition when it got corrupted and all the file entries got deleted. That was easier, it required dinner first chicken-club with lots of mayo--can't think well on an empty stomach--then figuring out that there's a 'trash can' file area. And manually undeleting everything we could find with the help of others that were in the office. I don't remember exactly how many 10k+ files we undeleted but it took a while. Some people were annoyed that files they deleted were back the next day.
I have another story about a group project that used up all timeshare credits and couldn't access the group assignment program. I pulled an all-nighter talking to a sr who knew a lot about CMS features, so I co-incidentally liked all our drive allocations across accounts. Worked like magic elves.
My best contributions code-wise is not writing it and instead getting people to think in a way that by re-arranging what we already have in slight ways that if you look at it funny will do what you want.