Live data from Hacker News

The 10x developer is not a myth (2013)

ybrikman.com

141–150 of 248 posts

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

#141
It is not the developer that is 10X. It is the environment they work in that is an enabler of 10X productivity. If that environment is also relatively stable, a smart developer can learn all the levers that the environment/company provides to them, and start achieving hyper productivity. But move that developer to a different company and they could be a dud. Even just an increase in the instability of the environment can thwart hyper productivity.

The focus here is on entirely the wrong thing. It is the development environment provided by the company that enables above average developers to surge into hyper productivity. Good programming practices. Competently prepared requirements. A collegial atmosphere that encourages frank and open communication between departments.

Searching for 10X developers is like looking for a silver bullet. Silver bullets do exist in the real world but ask a shooter whether they provide results any better than the common kind of ammo. Mythical stories can be fun but in the real world we have real work to to, real problems to solve, and while you can find shortcuts generally you don't find them by looking from them. But dive into the messy chaos of creating order out of nothing, and from time to time you will come across real honest to goodness shortcut opportunities that may provide up to a 10X increase in productivity. Use them if you can, but don't waste a lot of energy in chasing them.

Also, the idea of a 10X rocket scientist is rather glamourous. But the fact is that there are real opportunities for productivity improvements that are in the boring details, slogging through improvements in processes, making small incremental improvements continuously and consistently. There is more to learn from refactoring than from chasing clouds.

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

#142

Earlier quoted context omitted.

> inconsistent data fields being returned by various queries, resulting in inconsistent api endpoint data returned to the client and thus inability to safely abstract without significant hacks/nebulous data model state. You are coding against actual queries? Why not functions to hide the table abstractions: https://www.postgresql.org/docs/current/static/sql-createfun... https://dev.mysql.com/doc/refman/5.7/en/create-…

That's essentially building an ORM (well, a data mapping layer) out of PL/SQL functions rather than your main language. Why would that be better?

To play devil's advocate - PL/SQL is much closer to SQL than Java/C#/C++/....

The impedance mismatch between relational and OO is much bigger.

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

#143
I've never seen a 10x productivity, or even a 2x. I'd like to see one, show me a scrum where one programmer takes 10 stories on the board, and the others just did one, and he successfully finishes all 10, where the team estimated all stories to be of a full scrum length. I doubt this exist.

Now, I've seen 10x quality, though sometimes they're a little slower, but never 10x slower. So maybe 1.2x to 3x times slower for something on the order of 5x to 20x quality.

That higher quality might pay off long term for the buisness in hard to measure ways, such as faster future extenssion, better customer experience, less work required on bug fixing, etc. If that's what people mean by 10x, I agree, they definitly exist, in fact, compared to the worst there's probably infinite x as people are saying, some programmers can't ever get certain things to work at all.

P.S.: Actually, I've seen maybe 2x or 3x productivity on teams with uneven standards, generally lacking code reviews. In those cases though, the 2x or 3x productivity programmers always had similarly lower quality code.

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

#144
post #103

I had a boss 25 years ago (smart guy, did compiler work, etc. for new computer architectures) who claimed that there was really a 100x factor difference from the best to the worse. I believe this: would you rather have one day of work from Daphne Koller, Peter Norvig, or Jeff Dean - or 100 days from an average developer? Well, the answer is that "it depends." There is a ton of work that can be effectively done by non…

Well the worst (or even simply "kinda bad") are so much worse that it's not hard to believe and even bigger gap exists.

I once spoke to a guy that literally did not understand the lifetime scope of local variables nor how simple field assignment worked (a.x = y). I don't mean this in an esoteric, edge-case, way, but quite literally. I asked him why he didn't hire some devs to do the work for him, and his answer was "most devs are terrible and I've not found people that are as good as me".

The downward range goes very, very deep. And that's of people that actually do end up shipping something that "works", somehow.

I've personally rewritten an app in less than a week that had two devs on it for over 6 months. Their deliverable didn't really work at all, even after the 1+ minute loading time (Win32 app).

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

#147

The reason for pushback on the idea 10x programmers isn't the real gradient of skill, it's the labor aspect. Lots of companies want to hire 10x without paying 10x dollars, and they've figured out that blowing smoke up the ass of young people (though it works better on young men than women) is a way to squeeze blood from that stone. Especially if you're working in a small company, you're going to hit a point when ther…

> The skills you need to actually handle that situation are going to be more in the vein of basic professionalism than technical talent.

What a wonderful observation. This is true in fields other than software development, too.

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

#148

The natural follow-on questions are: What are the decision-making habits that make someone significantly more productive on a software engineering team? What are ways to imbue a team with these habits?

It's hard to explain without having concrete examples to work with. I would say it is all about recognizing when the trade-offs will pay off. Like, knowing when a quick fix will do and when a whole system rewrite is necessary.

Good fundamentals are also good, like being attentive to details and never letting crasher bugs remain unfixed.

I don't think you can imbue good habits on people who don't want to be imbued. So that's what you need to ensure first.

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

#149
post #115

After doing an extraordinary number of technical interviews of people, I began to think of it as a Gaussian curve with a normal distribution. Despite headhunter filtering, resume filtering, and short phone interviews, one out of six people slips through those filters without knowing much. On the other hand, one out of six can answer pretty much every question, clearly and in some depth. These are the people, the unpr…

And yet there is no real scientific evidence that performance on technical interviews actually correlates with job performance.

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

#150
post #90

Earlier quoted context omitted.

Also I think in the 60s there were analysts, the people who solved the problem and programmers, the people who converted the solution to code. Anyway, in the 60s the profession was in its infancy, so I'm not sure how much studies from this era matter today.

I also wonder how the productivity gap has been affected by modern development technology, or even the languages themselves.

It definitely affects your ability to compare studies over a long period of time – e.g. there was a huge shift in what programming work looked like during the progression from submitting code as batch jobs with a turnaround time measured in hours, to having a terminal on a shared system (where compilation was still a slow process), to individual workstations. That changes some of the skills significantly – i.e. reasoning about code on a whiteboard isn't useless but it's not a critical skill the way it was before everyone had an editor running code checks continuously, interactive debugger, etc.

I think Fred Brooks was right to argue[1] that we're not going to see dramatic further improvements because we're at the point of diminishing returns on overhead and most of the remaining work is actually inherent to whatever problem is being solved. The closest we've probably come to a change on that scale was the rise of cloud technology shrinking the feedback cycle for testing but I don't think that's been an order-of-magnitude change for most people.

1. https://en.wikipedia.org/wiki/No_Silver_Bullet

Post reply on HN