Sergey and Larry didn't code much though. This one's hilarious:
In the book, early Google engineering boss Craig Silverstein says "I didn't trust Larry and Sergey as coders."
"I had to deal with their legacy code from the Stanford days and it had a lot of problems. They're research coders: more interested in writing code that works than code that's maintainable."
One Google engineer from back then says the most remarkable thing about the co-founders' code was that when it broke, users would see funny error message: "Whoa, horsey!"
It turns out the developers most responsible for building the Google that quickly became the Web's most powerful company are two guys you've probably never heard of.
The first is Urs Hözle. According to one early Googler quoted by Edwards, Hözle was "the key" to Google's early success.
Edwards writes, "Enough engineers sang his praises that this book could have been written entirely as a hagiography of Saint Urs, Keeper of the Blessed Code."
The second is Jeff Dean. Edwards writes that "Jeff pumped out elegant code like a champagne fountain at a wedding."
"It seemed to pour from him effortlessly in endless streams that flowed together to form sparkling programs that did remarkable things. He once wrote a two-hundred-thousand-line application to help the Centers for Disease Control manage specialized statistics for epidemiologists. It's still in use and garners more peer citations than any of the dozens of patented programs he has produced in a decade at Google. He wrote it as a summer intern in high school."
Urs Hölzle, not Hözle. (Obviously, I heard of him.)
In 1994, Urs Hölzle and Lars Bak (yes, the one who wrote V8) co-founded a startup that wrote the fastest implementation of Smalltalk in the world. In 1997, Sun bought it and based HotSpot JVM on it. In 1999, Urs Hölzle joined Google as an employee #8.
The best source of the early Google codebase is a talk given by Jeff Dean himself. The talk describes Google1997, Google1999, Google2001, Google2004, Google2007 in some considerable details, from architectural diagrams to low-level bit packing tricks.
It's an overview of highly-optimized solutions to difficult problems, I am more interested in elegant code (beautiful + maintainable) - this is why I asked. Something makes me skeptical there could be any at such stage, when shipping is most important.
And yes, it seems there's a split between the algorithm creators and the code maintainers, unfortunatelly research code is good for that usually (research), but bad in memory usage, readability, speed, maintainability, etc.
Just asking. Does YC value the IITs(Indian Institute of Technology) as much as they value Harv, Stan, etc. Lots of other people do value it quite a lot. How does YC see them?
Apply and show them how you will make things work out no matter what. Also, the idea shouldn't be a 'barbershop' idea like PG says. It should have a large TAM. I think that is all that really matters.
Will you fund multiple startups working on the same idea?
Yes. If you fund as many companies as we do it's unavoidable you'll end up with some overlap. Even if you tried not to accept competing companies, you'd still get overlap because startups' ideas morph so much. The way we deal with it is that when two startups are working on related stuff, we don't talk to one about what the other's doing.
In practice it has not turned out to be a problem, because most big markets have room for several slightly different solutions, and it's unlikely that two startups would do precisely the same thing.
That's a start but the GP wasn't asking about competing entrants in the same batch but about a theoretical entrant that would compete with an established YC partner.
Umm I think that was a more general comment. And the reason that makes up the later part of the answer sounds very general and applies to the GP's question.
"The way we deal with it is that when two startups are working on related stuff, we don't talk to one about what the other's doing."
This seems easier to do with two startups in the same batch than with a new startup and an existing YC partner, although I suppose they could use the same approach.
In the book, early Google engineering boss Craig Silverstein says "I didn't trust Larry and Sergey as coders." "I had to deal with their legacy code from the Stanford days and it had a lot of problems. They're research coders: more interested in writing code that works than code that's maintainable." One Google engineer from back then says the most remarkable thing about the co-founders' code was that when it broke, users would see funny error message: "Whoa, horsey!" It turns out the developers most responsible for building the Google that quickly became the Web's most powerful company are two guys you've probably never heard of. The first is Urs Hözle. According to one early Googler quoted by Edwards, Hözle was "the key" to Google's early success. Edwards writes, "Enough engineers sang his praises that this book could have been written entirely as a hagiography of Saint Urs, Keeper of the Blessed Code." The second is Jeff Dean. Edwards writes that "Jeff pumped out elegant code like a champagne fountain at a wedding." "It seemed to pour from him effortlessly in endless streams that flowed together to form sparkling programs that did remarkable things. He once wrote a two-hundred-thousand-line application to help the Centers for Disease Control manage specialized statistics for epidemiologists. It's still in use and garners more peer citations than any of the dozens of patented programs he has produced in a decade at Google. He wrote it as a summer intern in high school."