Hacker News new | ask | show | jobs
by crazygringo 4647 days ago
The 10x is a huge simplification, but it doesn't make it any less true. Obviously there's a huge range.

I'd go so far as to say there are 100x engineers -- but it's not that they personally achieve 100x more than another programmer sitting in front of the computer. It's that they have the vision and talent to set a project up the right way from the start, so that the normal programmers can be productive. They're the difference between a project being delivered in 2 mos with a new batch of properly-working features coming 1 mo after, or a project taking 2 years with 8x more programmers, crashing half the time, and further features becoming impossible.

And then there are -2x engineers, who mess up things in the code base so bad that every hour of their work takes two hours for other programmers to fix or undo.

Then there are engineers that accomplish things that other engineers simply cannot. Call these infinity-x engineers.

No matter how much people want to call the 10x engineer a myth, there is a truly gigantic variation in productivity levels, which is especially magnified at architecture-level roles (where productivity can have a multiplier-effect on other engineers, for better or worse).

2 comments

Even the 100x is a simplification, of course.

One example (out of an infinite set of them) would be if you need a software system that deals with massive amounts of signal processing on a power constrained real-time DSP chip. There are lots of people out there who are "Senior Software Engineers" at whatever company they work at currently (because they can create website solutions by stacking existing JavaScript frameworks with some glue code) who may never be capable of delivering that system to you. Not 10x later than someone who can, not 100x later than someone who can, not 1000x later than someone who can, but not within their lifetime and thus certainly not within a useful time-frame for your project.

And I don't mean to pick on web developers here, that's just used for example. There are plenty of people out there doing web development who could adapt to embedded system programming, or who already do both adeptly, but there are also plenty of "web programmers" who are really actually designers or glorified project management people with little to no aptitude for programming at all.

Also, I don't think this is unique to programmers. I wouldn't expect a general practitioner doctor to be able to perform neurosurgery and just have him take 10x longer to do it, he may just never have the "hands" for it.

but the criteria to which you ascribe to is one of education and training.

A GP is certainly not a neurosurgeon, and therefore cannot possibly do the same job. Ditto with embedded programming vs a "front-end" developer.

But, if you consider only embedded programmers, would there be a 100x programmer out there?

"A GP is certainly not a neurosurgeon, and therefore cannot possibly do the same job. Ditto with embedded programming vs a "front-end" developer."

Cannot possibly do the same job? Really?

I've done embedded programming, front-end web programming, back-end web programming, desktop app programming for Win32, Qt/Linux, game programming, OS system level programming and currently do mobile app programming, among other types of programming. And I'm not particularly special, I know quite a few other people personally who have done various combinations of these jobs and others at a high level of skill in each specialization. That's sort of my basic point is that really good and flexible programmers are not fungible products you can really ascribe any productively multiplier to.

i didn't say a person can't be both a front-end and an embedded developer. I merely said that a front-end developer (who is not trained in embedded programming) cannot do it. That you (or that there exists people) who are both doesn't have any relevance.
Bingo!

As problems get more complex, the amount of time to complete them can go exponential for some developers. I've been forced to work with people like that; it really can be the case that some developers (who are otherwise competent) would simply never finish tasks that involve a crucial level of complexity.

And EVEN at just about any nontrivial level of complexity, where the time spent is only in the 1.5x-2x realm, the code written by the awesome programmer will likely be easier to understand, shorter, and easier to maintain.

Huge articles like the one linked are simply written by (and for!) the average competent programmer, to make them feel better. If you haven't worked with developers with a huge range of productivity, then you either haven't worked with a really good developer, or you've somehow lucked out and never worked with a poor developer. Statistically, it's likely the former.