Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Another Theory to Explain 10X Programmers

beza1e1.tuxen.de

Post reply on HN
Print view View original

91–100 of 105 posts

Re: Another Theory to Explain 10X Programmers

#91

Post by snowwrestler »

bluedino wrote: post #37
alkonaut wrote: post #29

A sports analogy appeared in yesterday's HN thread on this topic: the difference between an average runner and the fastest man alive is less than 50%. The counter argument here is that the measurable variable here isn't really the skill of the programmer but the success of the company (or equivalent). You only have to be best by a small margin to win. If you count wins between me and Usain Bolt he would be more than…

>> the difference between an average runner and the fastest man alive is less than 50%. So that means the average man can run the 100m in 15 seconds? It's a much better comparison to stretch that distance out. How fast (slow?) does your average human take to complete a marathon?

The parent says "average runner" and you said "average man." There might a significant difference there.

Re: Another Theory to Explain 10X Programmers

#92

Post by [deleted] »

jacquesm wrote: post #68

10X programmers are what they are simply because they've already seen a similar problem before. The longer you're at the game, the more exposure you've had the bigger the chance that you'll be 10X as good at something as somebody else. Personally I don't think the 10X moniker is very useful. Imagine we'd be calling the marathon runners of the world 10X people. They may be a bit better at task 'X' (running a marathon)…

[deleted]

Re: Another Theory to Explain 10X Programmers

#93

Post by tux3 »

adekok wrote: post #25
danieltillett wrote: post #13

Do we really know what the average programmer actually produces? We are all biased when deciding what is average as we use those around us to decide what is average - if we are surrounded by great programmers then our average is much higher than if we are surrounded by poor programmers. The other complication is the intellectual energy hurdle that each problem brings. Some problems can only be solved by a small perce…

> Do we really know what the average programmer actually produces? Industry average is 2,000 lines of code per programmer per year. I've regularly produced 10x to 40x that amount. Others I've talked to have done the same. The difference between "low volume" and "high volume" programmers is usually pretty stark. My experience is that it's not so much experience as problem solving skills. If you have a good understandi…

2000 Loc/year. Wow, that's almost hard to believe.

I know people who write that in a day when they start a new project.

Of course LoC isn't the best metric, but still.

Re: Another Theory to Explain 10X Programmers

#94

Post by snowwrestler »

TheOtherHobbes wrote: post #41
sp4ke wrote: post #5

Completely agree on this. I don't believe in innate talent. I believe we are all born with the same willpower to acquire knowledge. Some people will be ok with not mastering any specific skill as long as it does the job. Others who are "passionate" about certain fields or skills will try to learn as much as possible. So "passion" is a better word to define people's skills. I'm in the latter category, many people ask…

> I don't believe in innate talent. I totally believe in innate talent. There are standard breakpoints in math teaching where people simply don't get it. No matter how much time you spend explaining it to them, their brains aren't wired up to handle certain levels of abstraction. At best they remember it briefly, but it never sticks. (The breakpoints are roughly at basic 'manipulate equations to find x' algebra, basi…

Quite a number of scientists are studying how brain development is affected by very early experiences, and so far it seems like it might be more than most people thought. Basic experiences of childhood like breastfeeding, number of words heard per day, amount of music heard, even the number of books in a house, have significant correlations with later metrics of mental success like IQ, grades, career outcomes, etc.

By the time a person is old enough to be taking math classes, their "innate" abilities are a combination of nature and nurture. Hitting a "breakpoint" might be the result of deficiencies in their nurture, rather than truly innate (i.e. genetically determined).

The question is, if you took every person and raised them in the optimal way, how far could they go in math, programming, or any other pursuit? I think it's obvious that there would still be differentiation according to talent, but I also think it's likely that the average would be a lot higher than it is.

Re: Another Theory to Explain 10X Programmers

#95

Post by bstpierre »

kra34 wrote: post #75
jacquesm wrote: post #68

10X programmers are what they are simply because they've already seen a similar problem before. The longer you're at the game, the more exposure you've had the bigger the chance that you'll be 10X as good at something as somebody else. Personally I don't think the 10X moniker is very useful. Imagine we'd be calling the marathon runners of the world 10X people. They may be a bit better at task 'X' (running a marathon)…

That's why all the best programmers are the oldest guys in the room, they've been at the game longest...

That's not even close to true. I've worked in more than one shop where the 19-23yo kid fresh out of high school/college is 10x better than most of the 40-50s. Or, in a few cases, infinitely better than the guys in their 50s who are -100x (it required weeks/months to undo the damage when they finally left).

There's something to be said for experience, but keep in mind the old adage about "10 years of experience versus 1 year of experience repeated 10 times".

Re: Another Theory to Explain 10X Programmers

#96

Post by trentnelson »

indymike wrote: post #61
FLUX-YOU wrote: post #54

Earlier quoted context omitted.

I don't agree, if only because I'm the anecdote. I'm trying to pick up Rust and mess around with app/net security, but at my job, I feel like I'm in the middle of the pack. There are instances when I quickly fix stuff but also take forever to find a simple problem. To be fair, we do have a very extensive app with 15 years of code rot and only 2 members of the original team to guide/teach. But a guy that started a mon…

The attitude you have is the one that eventually drives you to be a 10x. If you think you are awesome at what you do, that is when you probably are not.

> If you think you are awesome at what you do, that is when you probably are not.

Nailed it.

Re: Another Theory to Explain 10X Programmers

#97

Post by trentnelson »

hyperliner wrote: post #89

My theory is that the best programmers are not spitting out too much code fast. They are the ones who thought of how to build the best app. The best "building builder" is not the person who can lay bricks the fastest, but the one who can produce an awesome looking and very functional building. I wonder what the "10x" ratio is for people like Paul Alen, or Marc Andreessen, or Dan Bricklin, or Dave Cutler, or Andries B…

Heh, that was an odd mix of names. I'd love to work with Cutler above everyone else. Also fun would be debugging a kernel page fault or something with Linus.

I don't know what I'd do with Booch. Do some UML diagrams then check in to ClearCase?

Re: Another Theory to Explain 10X Programmers

#98

Post by IvyMike »

There's a story on the front page right now about writing a Haskell compiler from scratch.

I don't mean to be an ass, but I will: there are a lot of programmers that would effectively never be able to do this. We're asking about if 10X programmers exist? I'm saying even infinity X programmers exist.

I think a lot of this depends on the task at hand--some tasks are straightforward, others require a lot of, for lack of a better word, "invention", and that's where the difference lies.

If the task is "web front end to a database", that task is understood and executed on a level that there probably aren't many optimizations an individual can do. It's difficult to imagine someone implementing ten web front ends to databases in the time it takes an average programmer to do one.

On the other hand, if the task is "create a competitive AI to play the game of go", well, I think that there's a ton of invention required there, and an individual could in fact make a 10x difference.

Re: Another Theory to Explain 10X Programmers

#99

Post by zzzcpan »

There was a topic on rude programmers the other day and it got me thinking about all this labeling being the cause. VCs want to manipulate programmers, make them rate each other on artificial meaningless scale, call each other names, they even find new ways for programmers to offend each other, like that blob programmer thingy PG thought of. There is clearly an agenda.

Any programmer is capable of mastering anything in the field and be just as good as the best of the best. And it is very obvious that many tasks can be done much faster by someone with the specific skills these tasks require. It is also obvious that some people have a CS/CE degree and a broad spectrum of skills that are useful for many tasks and some acquired special skills on how to approach new unfamiliar problems more quickly by having and expecting to deal with a lot of different ones. And those things do not make a programmer into a 10x programmer or a blob programmer or whatever, just more or less adapted to some specific tasks.

Re: Another Theory to Explain 10X Programmers

#100

Post by mod »

akx wrote: post #26
7952 wrote: post #16

Earlier quoted context omitted.

Maybe these 10X programmers can quickly solve bugs and problems because they have faced similar issues before and spent the time nesseccary to understand the problem. In that case the important lesson is to limit the amount of novelty in your work so that you are mostly building on technologies you understand well.

In which case you'll probably inevitably end up building something with a suboptimal stack -- and limiting novelty also means you won't learn anything _new_, which sounds more terrible to me.

I think the point was to stay in the same niche, not to avoid new approaches to common problems in your niche.
Post reply on HN