Also I feel what usually happens is that requirements change over time, and things get repurposed as "hacks" because ain't nobody got time to rewrite the entire thing.

But at some point the effort to rewrite is worth it and at that point even the same engineers who did the original implementation should be able to write a much cleaner and faster version.

When I was new I thought I was so awesome when I saw how I could write better code than I read. It was only way later I realized people usually had good reasons for writing it that way originally but those reasons disappeared.

One of many Bill Joy legends: BBN had a big contract to implement TCP/IP, but their stuff didn't work, and grad student Joy's stuff worked. So they had this big meeting and this grad student in a T-shirt shows up, and they said, "How did you do this?" And Bill said, "It's very simple — you read the protocol and write the code"

http://norvig.com/

When you have 10 people in a project there's way too much friction. Every decision is stalled, people code defensively rather than proactively. Everyone is trying so hard to get to the lowest common denominator that they can never do anything actually good.

That's not to say that better or worse engineers exist. They do. But I feel like a team's context and environment has a much higher impact on the quality of the output. You take away people's autonomy, the result will undoubtedly be shit. You give people autonomy, you can get bombs but you can also get brilliance.

The end result still depends on experience, but even the best programmers slow to a crawl when they work in an enterprise environment (obviously not always true, but as a general rule)

You can tell there wasn't a winer equivalent on the windows 95/98/ME teams

But yea, now he's doing cloud stuff. I'm pretty sure it's no coincidence that that is now their best performing product line either. Satya can thank him for his promotion to CEO.

My timing was atrocious; every single month my home was worth less and less and less.

I absolutely bent over backwards to keep my job. Worked sixteen hour days, worked weekends.

My employer kept trying to replace me, because my rate was fairly high. First they tried to hire three people in India to replace me, but a third of the Indians quit, a third were gobbled up by another team, leaving one Indian who wasn't that great.

Then they brought in a couple of consultants. They basically phoned it in for a year, and were eventually sent back.

I think the reason that I weathered all this is that I simply didn't have a Plan B. I couldn't fail, if I did, I'd lose my house. I was willing to do whatever it takes to stay employed, and though they kept trying to replace me, they couldn't find anyone that was that invested in succeeding.

This isn't to say I was smart, or talented. But I was tenacious and I was relentless.

John Carmack

Dennis Ritchie

Ken Thompson

Bill Gates

Donald Knuth

Jeff Dean

Brian Kernighan

They did not develop BASIC by flipping switches.

[1] This is documented by Noam Cohen in The Know-It Alls. [2] https://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists

From the source code itself:

  PAUL ALLEN WROTE THE NON-RUNTIME STUFF.
  BILL GATES WROTE THE RUNTIME STUFF.
  MONTE DAVIDOFF WROTE THE MATH PACKAGE.

Fortunately the quality of his software had nothing to do with his success. It was about marketing and business timing.

From the article: "And [Bret Taylor] rewrote the entire thing, making it 10 times as fast and a third of the size."

I don't think those are generally good examples of 10x engineers. Most people don't get to have a large impact by making the most of something specific. I think in the wild it is more as described in the article. That 10x engineers are people who raise the standard for whatever is in front of them and save themselves, and their companies, thousands and thousands of man hours by doing so. It is really really hard to be better at people at hard things, it is a lot easier to be better than people at things that are supposedly easy, but people consistently fail at.

Basically: brilliant, but very quirky.

On the other hand, if your problem is to simply produce more of something no 1000x genius will get you far enough. Farer than the mediocre resource, but even for these people a day has only 24 hours.

Ivan Sutherland

L. Peter Deutsch