Live data from Hacker News

The 10x developer is not a myth (2013)

ybrikman.com

201–210 of 248 posts

Re: The 10x developer is not a myth (2013)

#201

The problem here is that the concept got off on the wrong foot and has stayed on the wrong foot since then. The conceptualization of software developers as some sort of industrial worker who churns out widgets all day long is simply ludicrous. In the days back when a lot of software development involved just doing the same thing repeatedly for hire the measurement of "productivity" based on "output" at least had some…

Back in the day, the concept started out very well as a way of trying to convince Muggle bosses (etc) that coding wasn't pretty much the same as bricklaying, with most bricklayers being about the same in precision and productivity.

Re: The 10x developer is not a myth (2013)

#202
post #135
post #133

The area that I see this really come into play is with problems that the developer initially doesn't know how to solve. Some developers learn and adapt 10x faster than the average developer, and it seems like they're never blocked.

IME a more common case is overengineering. Not only does this slow someone down initially, but the extra complexity often continues to slow them (and anybody else in the same codebase) into the future.

Yeah, that's part of what I meant. If the path is totally clear; "add API to existing codebase, write tests, do CR, commit" then I don't think you see as much 10x behavior. If it's a new technology that the team isn't familiar with, or a tricky API for some reason, then solutions can start getting totally overengineered, and it can spiral out of control.

Re: The 10x developer is not a myth (2013)

#203
post #22

This completely misses the point. Nobody is denying that they exist; it's that they are completely irrelevant to software engineering because software engineering is delivering consistent (not necessarily "outstanding" or "very good") results with the fat part of the bell curve. Yes, you can deliver a project with the right person with 100th of the effort, but this is not repeatable (the person will move on or very l…

Look at the number of massive outright software project failures (no delivery, ever.) I think there are many times when you'll cheerfully pay at least ten times for the one guy who could actually get you to the finish line.

Re: The 10x developer is not a myth (2013)

#204

It's all about domain knowledge. Duh. The value of a software development team is their ability to create new intellectual property similar to things they've made before. (Or maintain an existing system, of course.)

It's a big part of it, but careful about what you mean by "domain knowledge." Look at Richard Feynman's stint as an analyst for Kurzwiel as parallel-programming got underway; in theory Feynman had no significant domain knowledge but in fact the immense range of mathematical knowledge he brought with him turned out to be extremely valuable, perhaps irreplaceable for that particular project (given how creative he was.) He really was a (more than) ten times guy, there.

Re: The 10x developer is not a myth (2013)

#205
post #2

just like the 10x CEO. They just make the right decisions and hence are compensated accordingly. Companies like MS and google have sufficient data to tell us whether the 10x programmer is a meaningful term.

> just like the 10x CEO. They just make the right decisions and hence are compensated accordingly. A lot of being a successful CEO is being at the right place at the right time (of course: in addition to actual qualities). Anecdote time: I once was a franchisee of a major (services) franchise that some time ago decided to expand to Germany (I sold my franchise years ago). I'll only talk about one person, but this hap…

Right. Survivorship bias. Totally a thing.

Re: The 10x developer is not a myth (2013)

#206

These things make my blood boil. I'm going to allow the assumption that 10x programmers even exist. First, it's elitist. This isn't a professional athletics team, this is the workplace focused on engineering. Most places are not chock-full of the 10x'ers; I need to depend on other people to do things for me, and them on me; not all of us are 10x'ers, and it behooves all of us to work as a team . The 10x discussion di…

Controlled experiments are in order. The article cites "Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000" I'm sorry the links don't work, but that still sounds like a traceable bibliography to me. I just tested Google on one study, and found it (paywalled I assume) - "A summary of software measurement experiences in the Software Engineering Laboratory Article in Journal of Systems and Software 9(2):137-148 · February 1989 with 19 Reads DOI: 10.1016/0164-1212(89)90016-2 · Source: DBLP"

Re: The 10x developer is not a myth (2013)

#207
post #110

Earlier quoted context omitted.

In addition not being able to measure 10x just makes things hairy. Am I a 10x, probably if you ask me to pump a couple of CRUD pages. Am I a 10x in adding features to a compiler. Probably not. If a business hires me thinking I am a 10x-er they have high hopes that I can't satisfy for their dimension of X. There are good programmers, great programmers and dangerous programmers. But that's all relative to what work nee…

If you're capable of both pumping out CRUD pages and adding features to a compiler, then you may be a 10x developer. I consider myself to be a 10x developer, but I'm not 10x all of the time for all tasks. Things that set me apart are the quality of my code vs other developer's code for a given amount of development time, the higher probability of my code being bug-free or nearly so before I've even run it, my skill a…

you realize that the tests are primarily for other developers (on your team, in the future) and not yourself, right?

Re: The 10x developer is not a myth (2013)

#208

Earlier quoted context omitted.

Turning 1x performance into 2x performance is people management.

What about writing code which the 1x programmers can easily understand and extend with 2x productivity?

I'd argue that writing a lot of code that is intended for frequent extension is a good way to 1/10x an entire team over time.

Re: The 10x developer is not a myth (2013)

#209
post #3

[...] They studied professional programmers with an average of 7 years' experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1 I thought the perceived idea about the 10x developer was that he/she is 10x better than the average programmer, not the worst. So even this scientific study (from the 60s) says that there aren't 10x developers according to this defi…

I thought the perceived idea about the 10x developer was that he/she is 10x better than the average programmer, not the worst That could well be what people perceive. It's not what the studies said. While the article has some good references, I might as well quote Peopleware again just for the fun of it. I churn this out every so often: A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but…

> you can rely on the best outperforming the median by a factor of 2.5

This is roughly what I estimate the productivity improvement a good developer gets when they're working on a task that fascinates them and that they choose for themselves, and without too many dependencies on productivity killing things (like builds and flaky external libraries and services).

The most productive people I knew tended to the people who didn't do as they were told. They were amazingly productive at producing the things that fascinated them, much less productive at the drudge that the organisation demanded of them. Sometimes the organisation was able to recognise that they were doing useful stuff (despite the fact that they weren't always pulling their weight on the things they were supposed to be doing) and they became rockstars, sometimes it wasn't and they became pariahs.

Re: The 10x developer is not a myth (2013)

#210
post #110

Earlier quoted context omitted.

In addition not being able to measure 10x just makes things hairy. Am I a 10x, probably if you ask me to pump a couple of CRUD pages. Am I a 10x in adding features to a compiler. Probably not. If a business hires me thinking I am a 10x-er they have high hopes that I can't satisfy for their dimension of X. There are good programmers, great programmers and dangerous programmers. But that's all relative to what work nee…

If you're capable of both pumping out CRUD pages and adding features to a compiler, then you may be a 10x developer. I consider myself to be a 10x developer, but I'm not 10x all of the time for all tasks. Things that set me apart are the quality of my code vs other developer's code for a given amount of development time, the higher probability of my code being bug-free or nearly so before I've even run it, my skill a…

> If you're capable of both pumping out CRUD pages and adding features to a compiler, then you may be a 10x developer.

This is a valuable point; many of the most productive people I know are breadth first not depth first. Being able to glue disparate systems together without having to stop and iterate with someone else saves a ton of time.

> Things that set me apart are... the higher probability of my code being bug-free or nearly so before I've even run it

I totally applaud your self confidence, and kudos if you're writing big chunks of nearly bug-free software before ever running it. My personal experience has been that even when I've been at my most productive, is that the probability of code of any nontrivial size being anywhere near bug free before running it is exactly zero. I'm scared of people who believe otherwise (I've never met someone who could prove it), and much of the success and productivity I've enjoyed in my code and management career have rested on the strategies to avoid assuming that code is nearly bug free.

The very best programmers and the very smartest people I know are people that came to the same conclusion - that every line of code is another bug - and then used that information to decide and inform how they're going to write software. They consciously avoid using fancy language features or playing code golf, they refactor often when architecture gets crusty, they spend a lot of time making sure other people can read their code, and they test and test and test.

Post reply on HN