Live data from Hacker News

Busting the 10x software engineer myth

swarmia.com

61–70 of 356 posts

Re: Busting the 10x software engineer myth

#61
I've never seen anyone be 10X better than, say, average consistently over a long period of time.

But I've been 10X better than apparently average a few times a few weeks at a time. Uh, part of the reason for a few weeks at a time is that as part of the 10X I got the work done very quickly!

My 10X cases were all when the planets happened to line up just right and, to use a baseball analogy, the work to be done was like a slow pitch right in my best strike zone.

(1) I was seeing a girl, and she was an intern and working for someone who wanted her to work on some old Fortran code. She couldn't figure out why the code was giving totally garbage results.

I glanced at her code and saw where she passed the constant 2 as an argument to a subroutine. So, sure, that can be dangerous. I glanced at the subroutine and, yup, it was changing the corresponding parameter so for the rest of the execution of the program the constant 2 had the value given it by the subroutine and was not 2.

She worked a day or two on this, and I solved it in about 180 seconds.

Why? I'd seen that in Fortran usage before.

(2) I was in a software house working as a programmer and fast Fourier transform expert at a US Navy lab. Some engineers at the lab needed an extensive software project done and set up a competitive bidding situation. For one of the engineers, part of the work to be done was some power spectral estimation of ocean wave noise, that is, quite low frequency. Due to some earlier experience at GE, I knew the basics of the Wiener-Khinchin theorem and also got the Blackman-Tukey book on the statistics of power spectral estimation, typed in some code to generate synthetic ocean waves and accumulate and display the power spectra estimates, then called the engineer and we met and reviewed my work.

The main point I had for him was that for the very low frequencies he was interested in, he could need dozens of hours of data and with much less data than that would be looking at small sample statistical fluctuations instead of good estimates of the actual power spectrum. Likely I got these results in 10X. Our software house got "sole source" on the work.

(3) I was at Georgetown University consulting in applied math and teaching computer science courses when a friend from college called. He flew up to Georgetown with several other people, and we met. Everything was inconclusive -- no one had any definite, good ideas. The problem was scheduling the fleet for FedEx. That was important because some Members of the BoD questioned if the fleet could be scheduled at all; crucial funding was being held up; the company was at risk of going out of business.

Finally in the meeting I just blurted out that I would solve the problem. Six weeks later I had the software running which was also the end of the semester for my teaching. I flew to Memphis, ran my program, pleased the BoD, pleased the founder F. Smith ("solved the most important problem facing FedEx"), and saved the company. I suspect that in time, that was a 10X effort.

(4) I was working on a Navy project to support both my wife and myself through our Ph.D. degrees when the Navy wanted an evaluation of the survivability of the US SSBN (ballistic missile submarines) under a scenario of global nuclear war limited to sea. They wanted the results in two weeks. That timing just fit -- my wife had a vacation planned for us at Shenandoah just after the two weeks.

From a WWII paper by Koopman's, I saw a continuous time, discrete state space Markov process subordinated to a Poisson progress and wrote and ran the software, Monte Carlo. The software was fast enough that I could generate and average 1000 sample paths quickly.

During a peer-review, an objection was that there was no way I could "fathom the enormous state space". In response I mentioned that after, say, five days, the number of SSBNs left was a random variable; it was bounded and thus had an expectation; the expectation was finite; the random variable had a finite variance; the law of large numbers applied; and averaging 500 sample paths would give quite accurate estimates.

I explained that intuitively Monte Carlo put the effort where the action was, and the reviewer, a well-known probabilist, responded "That's a good way to look at it." My work passed the review.

A second person, actually two people, had been assigned as an independent effort. At the end of the two weeks, they made no progress at all.

The Navy got their results on time, and my wife got her vacation on time.

(5) When I arrived at Georgetown, a prof had just completed a statistics package. One of the routines was polynomial fitting, but on testing the numerical accuracy was poor. The prof had programmed normal equations, and on that problem the normal equations are close to the notoriously ill-conditioned Hilbert matrix. I wrote a replacement routine using some orthogonal polynomial methods and got accurate results.

(6) I was in an AI (artificial intelligence), expert systems, project at IBM's Watson lab, and we were developing IBM's language YES/L1. We wanted rule subroutines. Our code design was to (A) return one call at a time from the whole stack of dynamic descendancy, (B) execute the RETE algorithm run-time code, (C) rebuild the stack of dynamic descendancy. I saw serious semantic problems with this approach and the coding was to take some weeks. I got some dinner, wrote and ran some illustrative code, in effect to call back into the stack of dynamic descendancy, at dawn wrote email to our team, got some sleep, returned at noon, and our programmer on the work was done later that day. I got an IBM award for the work.

There were a few more 10X examples.

I always put my pants on one leg at a time and have never walked on water in warm weather. None of these examples involved high stress. Instead the keys were context, e.g., I had everything I needed and background so that the work was in my strike zone.

I don't achieve 10X all the time. Heck, I don't achieve 1X all the time; e.g., in my startup recently I've been interrupted and slowed by some unpredictable exogenous obstacles. But now it appears that I've circumvented the obstacles and am making good progress again. Back to it.

Net: I don't think anyone can achieve 10X consistently over long time intervals. And I don't believe that very many people can just decide "next week I'll do 10X work." and be able actually to do it. Instead I suspect that most people can have 10X periods given the luck of the right circumstances.

Re: Busting the 10x software engineer myth

#62
post #33

Earlier quoted context omitted.

Yea funnily enough I just added a comment along these lines about restaurants in a different story. Just because an engineer is 10x better in some sense that another one, it doesn't meant that 10 of the lower quality engineers will make up for it, just as eating 10 times at McDonald's isn't going to be as much fun as eating once at a great restaurant (for most people)

But, I think, you should consider that it's 10x at McDonald's vs 1x at a good restaurant and 9 days eating nothing at all.

Yes, this is obviously just considering utility at a higher level of the hierarchy of needs, not pure subsistence. Otherwise everyone should just be slurping Soylent all the time I guess.

Re: Busting the 10x software engineer myth

#63
post #8

This is a silly framing of the 10x engineer issue. That label originally designated someone who had written an unusual amount of excellent software. Recently in the discussions here, people take it to mean someone who cobbles together broken apps at a rapid pace and gets credit from management for being a hero. This is not what 10x engineer means. Please find another label for that phenomenon, for example 10x faker .

I don’t think that’s a fair labeling; from my experience ”cobbled-together, broken apps” are the result of taking the MVP approach to continuous development due to time constraints imposed by management due to contracts sold too cheap by sales directors.

The failure of a software project begins at the contract stage. This gives salespeople a measure of control over the developers, and it is in their interests to increase developer stress by selling more things cheaper.

The worst part is that salespeople are prone to corruption: if they can make a client company pay less for a service, the company may hand over a part of their savings. This is difficult to control, as the kickbacks may come in material or immaterial forms.

The effects of the corruption are very real to the organisation, which now puts undue stress on developers with projects that are designed to fail just enough to trigger contractual clauses in benefit of the buyer.

Re: Busting the 10x software engineer myth

#64
post #55

There may be 10x engineers. But what I know for sure is, that there are engineers (or engineering teams) which make you perform at 1/10x of what you might have, by mis-carefully laying a minefield of: * Build difficulties. * Hidden dependencies. * Multiple and conflicting sources of configuration information. * Lack of documentation * Incorrect/outdated/stone-cold lyin' documentation * Mis-named executables, configur…

More broadly, the 10x engineer makes sure there are no such minefields. They make sure there are nearly zero hurdles to getting in the zone.

Ah, no, quite the contrary.

The person who makes sure there are no such minefields makes a lot less great advances him/herself - they're busy working in a careful, orderly and considerate manner. And then the other engineers perform close to his/her level. That's not the 10x engineer.

However, the person who lays the minefield may only be a 1x person talent-wise, but since he puts his colleagues on 0.1x, s/he is effectively the 10x engineer of that team.

Re: Busting the 10x software engineer myth

#65
post #31
post #3

I know "10x engineers" exist; some people are fakes and put forward things that look like they have high impact but are actually a bit shoddy. Some people like to be present and suck up. But some people really do just work hard, smart and have deep passion for what they're doing- and importantly: pride, which makes the quality of the content great too. Some of the best engineers I know "visit" bits of code or infrast…

> It's not a myth they exist, but you shouldn't depend on them. It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay. Domain knowledge, institutional knowledge, whatever you wanna call it, takes time to acquire and these kinds of companies are equally reluctant/arrogant to spend enough to hire properly…

> It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay.

Stating that a developer is worth 10 times what other developers are worth goes way beyond saying that some people are more valuable than others.

We're not talking about junior/medior/senior distinctions. We're talking about 10x. The myths. The lone gunman who is supposedly so good that is able to replace entire teams and still outproduce them.

Re: Busting the 10x software engineer myth

#66

I can cite many examples of a 10x engineer having an insight that greatly shortened the development time. It's not that they write code faster. It's that they select a path to the solution that is a lot shorter.

> It's not that they write code faster. It's that they select a path to the solution that is a lot shorter.

I know a developer who likes portraying himself as a kind of 10x.

He does not code faster, better, or smarter. His talent is managing his supervisor's expectations. He massages management to revise goals and shave off requirements, he is able to leverage even the smallest bump on the project management road to remove requirements and justify delays, and in the process he is able to put together a MVP that meets a fraction of the initial requirements and in spite of barely working does meet his manager's acceptance bar.

In the end all that is left is the story where he single-handedly delivered a working product, he moves onward to greener pastures, and an unwitting team is left with the architectural problems, myriads of bugs, missing features, and the blame for stuff failing to work in production.

Re: Busting the 10x software engineer myth

#67
post #56
post #46

Earlier quoted context omitted.

I've worked with a few developers who are great - people who get bored of waiting so just build it themselves one evening whilst everybody's arguing over funding/recruiting the team we thought was needed. Within a team, I think 'greatness' comes in all manner of different forms, all of which are needed. The person who holds the whole software model in their head, and can rattle off the precise changes required to imp…

Oof, sadly this sounds like me... It's hard to delegate, and even harder to trust that it's done correctly. I know this will be my undoing someday, it also drives me insane because it puts extra pressure on myself... Any suggestions? (Short of let people do it).

Try another career. You'll never be successful in this one. Sorry its harsh but that's the way it is.

Unless you can change that trait, it's going to be a hell of a bumpy road with no payoff.

Re: Busting the 10x software engineer myth

#68
post #6

> Wrote hard-to-understand procedural code to 5000-line files. Did not actively share knowledge with his peers. The author seems to mean prima donna, not a 10x engineer and then goes on to destroy that strawman. Actively sharing knowledge, mentoring etc... and code and architectural simplicity are a given for someone who's 10x productive. Most of the costs are in maintenance not the initial delivery and a 10xer's out…

This here. I think the author is confusing what a 10x developer is. I took the 10x dev to mean somebody who may work efficiently but also improves all of the devs around them. Improving yourself by 2x is one thing but improving the team around you by 2x is where you get the 10x.

No, the 10x developer is someone who, alone in a room, can ship in y period of time the same thing it would take 10 median developers y units of time to ship, or one median developer 10y units of time to ship.

Because of the mythical man month, the 10 will actually take >y time to do it, due to coordination overhead. The 10xer will still ship the item in 1y. A big part of the leap from 5x to 10x is being able to dodge communication overhead.

Some are also good at boosting their team. Some only work well alone.

Re: Busting the 10x software engineer myth

#69
post #55

Earlier quoted context omitted.

More broadly, the 10x engineer makes sure there are no such minefields. They make sure there are nearly zero hurdles to getting in the zone.

Ah, no, quite the contrary. The person who makes sure there are no such minefields makes a lot less great advances him/herself - they're busy working in a careful, orderly and considerate manner. And then the other engineers perform close to his/her level. That's not the 10x engineer. However, the person who lays the minefield may only be a 1x person talent-wise, but since he puts his colleagues on 0.1x, s/he is effe…

If people can perform so much despite the minefields, then these are not minefields.

If we agree that they are minefields that impede programmer's performance, then by definition someone who does not make sure these mines are never introduced in the first place will outperform those who just leave them all over the place.

> they're busy working in a careful, orderly and considerate manner.

Actually no. It only takes very little initial effort. He spends most of his time producing actual work.

Meanwhile, other people spend a considerable amount of their time fighting against bad tools and bad development environments.

Worse, they might not spend a whole lot of "total" time fighting against the minefields, but their presence ensures they can never get in the zone (flow) and thus they always perform worse than their potential.

Re: Busting the 10x software engineer myth

#70

There are some good points in this article. At the same time, "10x engineers" are not a myth. Anecdotally, I have seen plenty of situations where the most skilled engineers in a group were many times more productive than the least skilled. If anything, "10x" greatly understates how big the difference can be.

I think this is true for any group of engineers - some will be much more productive than others. That isn't because those engineers are better, or "10x" though, it's simply because they're working on a problem they find interesting in an environment where they're thriving. The less productive people aren't enjoying the problem they're solving, or there's something about the company or team that isn't right for them.

Most capable engineers have the potential to be "10x engineers" compared to their peers if they find a problem they're passionate about in a company that works well for them.

The real unicorn engineers are the ones who are able to drop in to any team and be like that.

Post reply on HN