Hacker News Reader

Comment by DannyBee | Hacker News Reader

There is no offer of proof for the claim that there are no 10x developers past claiming "they've not seen it in practice"

I have seen them with my own eyes. They are in fact, able to do things 10x faster than others. There are not a huge number of them, but they exist. At Google, folks like Jeff Dean and Sanjay Ghemawat are easily 10x more productive than "the baseline proficient engineer". Any proficient engineer who has worked with them can tell you the same.

Again, i won't claim there are many of these kinds of folks, but they definitely exist.

(This also doesn't mean 1/10th developers don't exist, and aren't common, but ...)

View on HN

For those who work inside Google, it's well worth it to look at Jeff & Sanjay's commit history and code review dashboard. They aren't actually all that much more productive in terms of code written than a decent SWE3 who knows his codebase.

The reason they have a reputation as rockstars is that they can apply this productivity to things that really matter; they're able to pick out the really important parts of the problem and then focus their efforts there, so that the end result ends up being much more impactful than what the SWE3 wrote. The SWE3 may spend his time writing a bunch of unit tests that catch bugs that wouldn't really have happened anyway, or migrating from one system to another that isn't really a large improvement, or going down an architectural dead end that'll just have to be rewritten later. Jeff or Sanjay (or any of the other folks operating at that level) will spend their time running a proposed API by clients to ensure it meets their needs, or measuring the performance of subsystems so they fully understand their building blocks, or mentally simulating the operation of the system before building it so they rapidly test out alternatives. They don't actually write more code than a junior developer (oftentimes, they write less), but the code they do write gives them more information, which makes them ensure that they write the right code.

I feel like this point needs to be stressed a whole lot more than it is, as there's a whole mythology that's grown up around 10x developers that's not all that helpful. In particular, people need to realize that these developers rapidly become 1x developers (or worse) if you don't let them make their own architectural choices - the reason they're excellent in the first place is because they know how to determine if certain work is going to be useless and avoid doing it in the first place. If you dictate that they do it anyway, they're going to be just as slow as any other developer.

What I learn from this is, they key to being a 10x developer is to work on problems that have 10x impact and not necessarily writing 10x more code.

That's the right lesson. The difference is actually even more stark than that: if you extend it out to picking the right project in the right company in the right industry, there're positions where you can be easily 1000x more productive. Project selection probably determines more of your productivity than almost any day-to-day coding decision.

I'm sure Larry and Sergey would agree.

The what-to-build skill trumps the how-to-build-it skill every time!

And in fact, writing scads of dumb code is often the sign of a poor developer. It often follows from the "never turn back" mentality, that leads them to follow an initial poor choice of solution through to the bitter end.

> The reason they have a reputation as rockstars is that they can apply this productivity to things that really matter; they're able to pick out the really important parts

That is the same thing as saying that they are, in fact, more productive.

Productivity is improved by one's ability to synthesize technical concepts and experience; to market (internally, amongst peers) one's ideas; to communicate; to convince; to adapt; to select; and to balance all of these tensions.

> They don't actually write more code

The "10x developer" meme was never a claim on LOC. At least I hope not.

> the code they do write gives them more information, which makes them ensure that they write the right code.

That is productivity optimization.

You've really hit the nail on the head here, and my response to the article was along the same lines:

Solving the right problem in the right way is the key of programmer productivity. Every programmer in existence who has a baseline of critical thinking has written the wrong code before, and then reflected on it and improved it. You can do this at any level of abstraction from the details of bit flipping all the way up to whole systems architectures. The very best programmers are the ones who are able to think about the gestalt most effectively. This is a tremendously difficult task give our limited conscious brain capacity, and I constantly feel myself bumping up against the edges of it when I work on a big project.

One example of a programmer I really look up to is Yehuda Katz because of his work on Bundler. Rubygems had an awful lot of pain points for large projects, and worse, it had a culture of borderline denial about the existence of these pain points. Yehuda and Carl Lerche worked relentlessly to come up with a solution that addressed 99% of all the recurring projects across a wide variety of scenarios. Then they powered through over a year or more to hammer it into a reliable solution built independently and only loosely coupled with Rubygems. Sure it took months and months and untold hours of hard work, but in the end they effected in a sea change in Ruby dependency management which would have been impossible without the ability to see all sides of a very multi-faceted problem. To me that goes beyond 10x because you could have 1000 good engineers and still not be able to design Bundler.

You've just described a two magnitude spread between an incompetent programmer and a "rockstar" (I hate that term), with the average being a 1x programmer. I tend to believe that's true because I've seen a few 10x programmers (and I think I've had days where I have been one), but I've definitely seen 1/10x programmers. This sounds about right.

Eh the thing of it is, everyone can have 10x days, as a developer's output variability is high, the trick is to hit that consistently, and to do that you basically have to have 100x days at least once in a while.

I can believe 10x. Though, when people start throwing around numbers like, "A great developer is literally 1,000x more productive than an average developer!" I raise an eyebrow.

Depending on what you mean by the average developer, 1000x is plausible. If you think in terms of reliability, it's the difference between a four nines engineer and a one nine. That guy who pushes untested code that brings the site down for a day vs. the woman who has to roll back her code once in five years because she made a fencepost error is an example of how such variances in developer "productivity" can be measured by an organization, especially one that does not consider itself a technology company.

Think of floor personnel in stores. There are some who start off several steps behind because they have a lot of sick days, come in right at the start of their shift (so end up starting "late"), and take dozens of smoke breaks throughout the day without clocking out. They may chisel a minute or two extra from every break even when the store is busy. On top of this, they may drag their way through their workday. You may need 3-5 of this person to do the job of one, then you need someone to manage them.

They're going to be significantly less productive than the scarily chipper go-getter who wants to be store director, gets in early to start work on time, skips breaks or takes them only when things are slow, is very upbeat and engages customers, and offers to take extra shifts to help out. You can leave this person alone in the store and they'll keep things moving along.

Measuring productivity is a difficult science. In some environments, it's screwing up less than other people. In some, it's a simple measure of something silly, such as function points. Scientific Management has seeded a lot of bad ideas in managers' minds about measuring the value of individual contributors.

I'm skeptical that any engineer can independently be responsible for four nines. HA is a big-picture deal. One engineer can break it, but one engineer can't make it.

Put differently, a good HA organization does not need 1000x engineers- a good system ensures even garden variety engineers will deliver.

There are lenses through which you can look and say "Engineer A was 1000x as productive as Engineer B", but those lenses are things like leveraged work, which is not what people are thinking of when they talk about "rockstar programmers".

When you say someone is 1000x as productive, that means that they sit down and do 3 years of work in 8 hours. (Unless the average developer contributes negative net productivity)

"When you say someone is 1000x as productive, that means that they sit down and do 3 years of work in 8 hours. (Unless the average developer contributes negative net productivity)"

Productivity is value to the organization. If it is an ecommerce entity, Mr. one nine cost the company 1000x in sales vs. Ms. four nines.

Your skepticism is noted. As I've said, sometimes productivity is measured as not screwing up.

Would you claim a developer who replaced 1,000 lines of messy, poorly written code with a 10-line implementation of a more efficient algorithm is less productive than the person who wrote the 1,000 line mess?

sometimes productivity is measured as not screwing up

At which point I guess we get down to what is an average developer. Does the average developer make such big screw-ups that simply not screwing up is 100x increase in performance?

I guess when I think "average", I'm not thinking about what is actually the measured average, but more like "acceptable competency". Never destroys shit, but also never advances the project a month with something clever. The sort of standard grade you would hope your rank-and-file would be made of.

What does lines of code really mean? If the messy code has a lower bug rate and is easier to debug, which is entirely possible if the 10-line solution is painfully elegant, it is the more productive of the two. Remember that old quote about how it takes twice the cleverness to debug code as it does to write it...

The average developer, in my mind, is a person right in the middle of the group of people who can maintain a position as a "programmer" or "developer" or any equivalent terms.

You've made a number of assumptions that I was trying to squash.

Most developers do not work on "projects". They're not doing startups or even working for software companies. They're anyone from the guy maintaining a FoxPro database for a dry cleaning chain to a jedi ninja who poops better, tighter, inventive code than the rest of us can dream of.

How do you measure someone's productivity in an environment where they write or patch code based on their manager coming around and asking them to do make tiny changes or write reports? As an analogy, how would you measure the productivity of the "hero" of Office Space? He turns two character dates into four character dates. He's a programmer, but he's not actually "producing" anything. He's keeping the world from ending in 2000! His manager would probably count his productivity as how many lines/files/whatever he updates in a given period of time.

The lines of code metric was an attempt to illustrate that productivity is a difficult task to measure without a goal-oriented context. You see that measuring productivity is not just "lines of code," but you also missed that the developer spent time refactoring 1,000 lines of code. Is that productive? Measured on that day, the work done was zero, or negative, and productivity can only be measured in the medium to long term. Yet I hope we would both agree that it was a productive effort.

In regards to 1,000 LOC vs. 10 LOC, I still maintain that I'd have to see it. Most of the time you'll be right, but that refactoring is not necessarily productive as a rule.

"a good system ensures even garden variety engineers will deliver."

I assume this points to the idea that test procedures can replace individual expertise ? My experience is that testing systems get bypassed by "garden variety" engineers (mostly with PM/Manager support), usually in exactly the cases where you wouldn't want them to do that.

Even when this is not the case, tests, no matter the coverage, don't cover everything. The 100% test coverage demands that are in vogue these days make sure tests are usually written specifically to minimize interactions between pieces of code, which is of course exactly what a good engineer would test for.

Of course with tests testing interaction, there are pieces of code (the ones that worry me) that get tested 1000x (in one case literally iterating over all possible calls and verifying constraints afterwards, almost fuzzing), and there's pieces of code that just don't get attention (usually an if out_of_range check at the beginning of functions, since I would just test for the same range, with potentially the same mistake in both the used number and the tested number, but other things happen too. If the consequences of the function screwing up is a slight UI aberration ... well I barely test UI code at all, really. MVC for the app MC for the tests). Also there's pieces of code where I know they're potentially not thread safe and so, just to make sure big screwups get caught, I test firing off the same test 1000x in parallel. If the function works entirely based of the stack and return values, no such test is done.

Good points.

Most requirements do not include error or exception handling requirements, so when developers write their test cases (in the very few cases when they do so), they usually do not write negative test cases.

Obviously, NFRs need to cover those, but in many organizations, they're seen as being "in the way of getting work done," just like comprehensive automated tests.

Reply on news.ycombinator.com