They are rare, but definitely out there. I've worked with one, managed one, never been one. One charateristic I observed over these 2, they'd take a manual home and read it over a day or two. They'd retain most of it. They tend to be touch typist not needing to look at the keyboard often. This reduces context switching and lets them flow when they are being creative. They know and remember syntax, library routines and interfaces so they aren't stopping to look things up. They "try on the fly", fail fast and often, and move to alternatives when blocked. The ones I know I'd love to start a company with. But I would be the bottleneck...
The Myth of the Myth of the 10x Programmer
211–220 of 227 posts
Re: The Myth of the Myth of the 10x Programmer
#212Earlier quoted context omitted.
It's pretty obvious that there are coders who can do the work of - all of the work of, and better than - a team of 50 talented programmers. For example when Linus wrote git he singlehandedly outprogrammed every team of version control vendors. He was a 50x programmer. (If not more.) This is a real literal example without exaggeration.
That's not an example of a 50x programmer, though. That's coming up with a truly great idea. If there is a new device that needs a driver for Linux, I can guarantee that Linus can't implement it 50x faster than a talented Linux driver developer. I think even Linus himself would agree. He's not a magical creature capable of 50x faster software development, over, say, Junio Hamano. As Linus himself said, "Junio really…
I think at this point we are debating the semantics of '10x programmer'. I would say that coming up with good designs and using proper algorithms is what makes people 10x.
I suppose I am saying that if Linus/Junio/whoever can make git in 6 months whereas a regular dev would take 5 years, then he is a 10x--it doesn't matter why he is 10x faster.
Re: The Myth of the Myth of the 10x Programmer
#21310X programmers DO exist. They aren't just a myth, and they aren't just about knowing when to buy vs build, or when to use a particular framework or toolkit, or how to "mentor" other developers. Chris Sawyer wrote 99% of the code for RollerCoaster Tycoon in x86 assembly language, with the remaining one percent written in C. RollerCoaster Tycoon was a beautiful game which still stands the test of time to this day. The…
You are right, they do exist... but they are probably not producing what you expect. I have had the privileged of coming into companies that had a programmer who wrote 10x more code than everyone else at the organization. Unfortunately, the vast majority of this code was not maintainable, riddled with bugs and had several critical security vulnerabilities in it. Good programmers are not programmers that create 1000s of lines of code an hour with no thought to maintainability. If that were the case, we would have 500 million programmers in India cranking out the worlds best code. Any time I hear an organization talk about a 10x/Rockstar/1% developer, I run the other way as fast as possible.
Re: The Myth of the Myth of the 10x Programmer
#214As a 10x programmer myself (NOT TO BRAG) I will tell you we definitely exist. My greatest annoyance is watching the rest of you peons crawl along at a snails pace while I am inventing the next groundbreaking technology that will completely flip your existence upside down. Perhaps the only person who could even understand my level of motivation is Elon Musk, but I'm not even sure if I would have the patience to explai…
This guy is so 10X his/her user didn't exist before this response. And he's been 10X and productive talking about it!
Re: The Myth of the Myth of the 10x Programmer
#215Re: The Myth of the Myth of the 10x Programmer
#216Earlier quoted context omitted.
Communication overhead is expensive. All else being equal, it’s much better to build a small elite team that can operate successfully with less structure and process, rather than a large average one.
Right. But you can't build a functioning team that works together and can rely on each other by fostering a culture of competition and hiring only the "predestined" 10x engineers. If the team culture is to help each other, forgive mistakes and learn from each other without measuring who's the best the team will automatically build itself without the need to hire only "10x engineers". Or so I suppose. I'm not an HR pe…
Where I’ve seen teams with high concentrations of unusually smart people, they gelled and collaborated at least as well as anyone else. In fact the bandwidth and fidelity of their idea transfers is part of what made them impressive. It’s like they had their own little language to describe the codebase and what to do with it.
These were mature and soft-spoken people; might be different with brash young hotshots.
Re: The Myth of the Myth of the 10x Programmer
#217Earlier quoted context omitted.
These engineers end up with much more experience in a shorter time span. The guy that worked 40 hours for the last 5 years is going to have far less experience than the guy who worked 60 hours for the last 5. More experience tends to lead to better decision making and better code. That said I'm the 40 hour guy. I want to work to live not live to work. That will make me less of a developer than others but I think I st…
Glad to hear that you don't buy into the myth that longer hours are better for their own sake - I agree. Realistically, I've never met any programmer who has more than 4 to 6 (on a really good day) hours of solidly useful work in them per day. Time spent above that, and those 20+ hours above 40, are invariably spent spinning wheels and making mistakes from fatigue, etc. and I think ought to be discouraged in sensibly…
Making mistakes from fatigue is the tip of the iceberg. As designers and implementers of software, we don't just have to redo the few minutes of work that making the mistake took. The consequences can be much worse:
* Missing key insights which would shave a large percentage of work off of the project.
* Making mistakes in architectural decisions, which require hours of extra mundane boilerplate work.
* Introducing difficult-to-reproduce bugs which require hours, days or weeks debugging
* Destroying key hardware which needs to be re-acquired (if that's the kind of thing you work on).
At this point in my career I'm of the opinion that asking teams to pull late nights and weekends is actually detrimental to project timelines, over anything longer than a single day. All it does is reassure PHBs that maximum effort is being made.
Re: The Myth of the Myth of the 10x Programmer
#21810X programmers DO exist. They aren't just a myth, and they aren't just about knowing when to buy vs build, or when to use a particular framework or toolkit, or how to "mentor" other developers. Chris Sawyer wrote 99% of the code for RollerCoaster Tycoon in x86 assembly language, with the remaining one percent written in C. RollerCoaster Tycoon was a beautiful game which still stands the test of time to this day. The…
> It's about being FUCKING SMART It's not always about being FUCKING SMART, sometimes just having a different attitude helps. I've worked with testers who refused to write code but would rather test everything manually (and fall behind on every sprint!), while stupid (yes), you could easily come in and be a 100X more productive by just writing tests as code. For one company I worked for we had an old legacy system (r…
[deleted]
Re: The Myth of the Myth of the 10x Programmer
#21910X programmers DO exist. They aren't just a myth, and they aren't just about knowing when to buy vs build, or when to use a particular framework or toolkit, or how to "mentor" other developers. Chris Sawyer wrote 99% of the code for RollerCoaster Tycoon in x86 assembly language, with the remaining one percent written in C. RollerCoaster Tycoon was a beautiful game which still stands the test of time to this day. The…
> It's about being FUCKING SMART It's not always about being FUCKING SMART, sometimes just having a different attitude helps. I've worked with testers who refused to write code but would rather test everything manually (and fall behind on every sprint!), while stupid (yes), you could easily come in and be a 100X more productive by just writing tests as code. For one company I worked for we had an old legacy system (r…
I agree and have a similar story to yours about improving an old system. At a previous company we had a deployment process that took 1 developer 6 hours to complete. There was a 6 page run-sheet of manual instructions (create Windows image; log in and set these parameters; install this software; etc.)
I took a couple of days to automate the process and reduced the deploy time to something that could be done multiple times a day and didn't require a developer. Am I FUCKING SMART? No, but I was able to see the bigger picture and realize that there are tools that could be applied to this problem.
Re: The Myth of the Myth of the 10x Programmer
#220Earlier quoted context omitted.
Joel Spolsky's "Hitting the high notes" always comes to mind for me when this debate arises.
Spolsky is a 10x blogger. Neither he nor any of his employees were ever 10x programmers. There was nothing algorithmically clever about FogBugz or CityDesk or whatever.
Did you miss how they cross-compiled Vbscript to PHP? I'd say for a lot of programmers this would have been quite the challenge, algorithmically speaking. And I would classify it as clever. With both the positive and negative connotations of the word.