It's a bad myth that "speed" has anything to do with the 10x or 100x programmer. The thing that sets great programmers apart is their ability to instinctively and intuitively design elegant and correct solutions to a given problem while introducing minimal bugs. A great programmer whose code will stand the test of time without needing a total rewrite 6 months later and without a horrendous maintenance and complexity overhead could write their code at 10 words a minute and still be worth their weight in gold.
Personally I think "great" programmers are really just "good" programmers - those that understand the problem domain, have expertise in their tools and know how to minimize complexity - this should not be some white albatross but rather a level we should all aspire too. I think it is more useful to identify bad programmers - those that rage in like a bull in a china shop, adding layers of complexity and abstraction to cover up their lack of knowledge and expertise, who flippantly choose bad designs for a given problem because they believe in some universal "right way" and spend half their time on premature optimizations before their buggy product is even in a testable state.
I have come across numerous bad programmers in my time, and if they were nipped in the bud early before they could leave reams of damage in their wake, I can testify to many man-months in effort rectifying their mistakes.
I don't think this gets nearly enough praise when assessing people. I've worked at a few different software companies with a raft of different programmers and among those who were deemed "superstars" there were certainly a few who I wouldn't want to work with (or inherit code from) given the choice due to the hideously complex nature of their output.
Despite their ability to produce major functionality with incredible speed, which is often what led to them being seen as superstars by management, code that is so complex that it is virtually unmaintainable is a huge ongoing burden. Its great that you rescued a late project when everyone said it could not be done but some poor sucker is going to have to maintain that mess.
I'm currently working for a company where "Move Fast" means "Write lots of code". As a result, there's a lot of sloppiness, duplication, and pieces that don't quite fit together right. I'm having difficulty explaining the importance of reductionism; In the words of Antoine de Saint Exupéry: "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."
Interestingly I think that the propensity to create complex systems is a sign of inexperience (but aptitude nonetheless). I used to create the most hideously "enterprise" architectures in my projects that even I have problems grokking after years of not touching them. I've reached the stage of moderately complex and out of sheer love of the concept, actively work toward simpler solutions.
Ultimately a "10x hire" who overcomplicates things can probably be toned down through some mentoring.
I guess the "work smart, not hard" truism can be reworded to "solve smart, not complex" in this case.
> some poor sucker is going to have to maintain that mess.
Although complex is not the same thing as a mess, it merely might as well be.
> ability to instinctively and intuitively design elegant and correct solutions to a given problem while introducing minimal bugs.
That is very important. Code that is not written is just as important importat (maybe more important) than code that is written. What I mean is good programmers will find way to solve something using less code. That is very imporant for understandability, maintenance, and long term support.
That is hard to convey to an outsider. Say a manager who has never programed that is in charge of evaluating programmers they are managing. They will usually value more code, more nights spent at the office and more churn fixing bugs vs less code, less nights spent at the office, no churn or "putting out fires". Heck to them it looks like the 10x programmers is a 0.1x programmer compared to others.
>What I mean is good programmers will find way to solve something using less code. That is very imporant for understandability, maintenance, and long term support.
It's not about less code, it's about simplicity of code. I have known people who have played code golf with production code, either out of bordom or a desire to generate job security. That's not actually solving the core problem of making it easier for someone to port to a new version of an OS in 5 years time, it only looks that way if you aren't paying attention. Short code can be just as confusing as long code.
Your code should, in all places where it is not necessary to do crazy speed optimisations, be understandable by the average intern. Yes, that means comments, and yes, sometimes it means doing something in one line that is more commonly done in 20 lines and yes, sometimes it means taking 20 lines to do something you could do in one line.
Great programmers use source control, integrate often, and communicate with their team. They basically do all the the things we know we're supposed to do, but most only give lip service to it.
It's a bad myth that "speed" has anything to do with the 10x or 100x programmer. The thing that sets great programmers apart is their ability to instinctively and intuitively design elegant and correct solutions to a given problem while introducing minimal bugs. A great programmer whose code will stand the test of time without needing a total rewrite 6 months later and without a horrendous maintenance and complexity overhead could write their code at 10 words a minute and still be worth their weight in gold.
Personally I think "great" programmers are really just "good" programmers - those that understand the problem domain, have expertise in their tools and know how to minimize complexity - this should not be some white albatross but rather a level we should all aspire too. I think it is more useful to identify bad programmers - those that rage in like a bull in a china shop, adding layers of complexity and abstraction to cover up their lack of knowledge and expertise, who flippantly choose bad designs for a given problem because they believe in some universal "right way" and spend half their time on premature optimizations before their buggy product is even in a testable state.
I have come across numerous bad programmers in my time, and if they were nipped in the bud early before they could leave reams of damage in their wake, I can testify to many man-months in effort rectifying their mistakes.