Ask HN: What's your 10x developer story?
For those of you that have come across the mythical 10x developer, what happened?
I imagine many of you have one (or are one) and I'm curious how you experienced the events as they unfolded.
I imagine many of you have one (or are one) and I'm curious how you experienced the events as they unfolded.
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.
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.
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.
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.
- 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
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.