I've worked with people who could be classed as almost a 10x programmer.
Their code worked, but it was also incomprehensible to everyone else on the team.
I have found that high-speed programmers tend to develop a very personalised workflow style. They do things their way, they code their way and forget that other people may have to maintain that code.
The argument in the above post would not classify those as 10x programmers. antirez is claiming that high quality design and a commitment to simplicity is a big part of what makes some programmers do much more productive.
Oh I agree with the article. Whenever I lead a project I argue that the team should aspire to follow "lowest common denominator" principles. By that I mean they should work in a way that appreciates the abilities of the least skilled on the team or in a manner that would allow someone coming in off the street to get up and running with the project without needing any help from existing developers. That doesn't mean over simplistic code, it just means good simple design, lots of comments and docs and asking around for permission before implementing an obscure or exotic design pattern.
What slows down my productivity more than anything is looking at someones code and thinking "Why did they do that?" Simplicity pay off in the long term.
However in reality, and what my comment was referring to, is that every sizable team has that one dev who rattles off code quicker than anyone else. Yes it works, but it will have a lack of comments, or they don't check in often enough resulting in merge issue or worst of all they implement a design pattern no one else has heard of.
The worst part of working with people like that is that they are usually rewarded, while the rest of us are criticised for not being able to keep up, or lack understanding.
I worked with a guy who was the star of the department, a nice and friendly guy, but holy crap he built some interesting solutions. Example: Our main product could only be debugged if we started up a development environment, consisting of 12 VMs. The 10x guys only problem was that the subnet these thing ran on was a little to small for all us to have a full environment.
You're absolutely right that these people develop tend to develop a very personal style, and often it's harmful to everyone else.
Do they develop a "very personalized workflow", or do they simply use abstractions and techniques that go beyond hashmaps?
I've observed on a number of occasions that very good programmers get accused of writing "incomprehensible" code simply because they use data structures that you learn in the second half of CS 101, e.g. token buckets or bloom filters.
I've worked with some too and they've always needed another 10 junior engineers to clean-up and thoroughly test their code later on. In some big corps, that might not be such a bad thing. If it weren't for them, most projects would be stuck in so called "design-meetings" forever.
> Their code worked, but it was also incomprehensible to everyone else on the team.
It's because the 10x programmer is too fast for the team. Therefore its code is not shared with the team (no time to explain, to time to document, no time to teach), so the team doesn't understand it. But it's not team's fault, nor the 10x programmer's. It's the delta between them.
That is a big part of it. Unfortunately when the department manager looks at lines of code as a measure of productivity, guess who gets a pat on the back....
Their code worked, but it was also incomprehensible to everyone else on the team.
I have found that high-speed programmers tend to develop a very personalised workflow style. They do things their way, they code their way and forget that other people may have to maintain that code.