In one sense, this is the classic path trodden by people who listen to all the good advice available here. The idea of page rank was worth very little. What Larry did was learn enough programming chops to build a prototype, then used then prototype to prove the idea worked, then iterated better and better versions as the requirements became more clear and as the bottlenecks became apparent.
This is exactly the sort of advice I'd give today to anyone with "an idea" - learn enough to code up a quick prototype. If you're starting from scratch, choose a modern fashionable language since it'll probably give you an enthusiastic community of people prepared to give advice and help when you get stuck. (right now, my choice would probably be between Ruby and Haskell). Don't worry too much about code beauty or scaleability or efficiency yet - there's a very high chance your idea will turn out to be not such a great one, and you'll either pivot a few times to find a variation on the idea that is great, or drop it altogether for the next "great idea", so don't fall into the trap of investing more effort than required too early. Have a plan for how you'll do it "properly" if you get traction, but first just get something running quickly to see if anybody is likely to pay you for it...
Sure, constructing quick and dirty prototypes is necessary, especially if you want to assess whether the idea is actually worthwhile, but this 'well, hey, even Larry Page didn't seem to know much early on so obviously code quality is overrated, blah blah' attitude is a bit dangerous and something of a stretch (we're basing this discussion on him not knowing one small aspect of a then-beta language, c'mon).
Sure, write something quick and dirty, and seek to refactor it later, but keep in mind that doesn't justify not having the chops to be able to write reasonable code first time.
I really think this 'none of this stuff matters, it's just aesthetics' idea is really pernicious - what is this 'aesthetic' stuff? To my mind it's writing code which is clear + understandable to you and other human beings - that is all that good code is. I believe that, with discipline, you can learn to do that quickly and efficiently and scale it accordingly from prototype -> critical library without ever just totally letting loose and writing crap (where crap is defined as being difficult to understand). That's before you even begin to consider the quality of the software perf-wise if you make naive algorithm choices.
Note that prototypes very often become core systems way more often than you would expect, so these 'throwaway' systems are often not as throwaway as you first thought.
This stuff isn't aesthetic, irrelevant or subjective nicety (all ideas 'code beauty' brings to mind), this stuff is the very means by which we construct our products and core to everything we do. Can we please stop pretending otherwise?
And, though it's something of an appeal to authority, I do think it's relevant in this particular case - keep in mind when google interview people, they themselves actually seem to think this stuff you're down-playing is important. I doubt an appeal to 'well I'll learn algorithms and so on later once I've got stuff working' would really prove sufficient.
To a hacker ( or a progrMmer, or the guy who's going to have to maintain the code, possibly when it's scaled to 40,000 servers), code beauty is critical.
To "an ideas guy", a prototype is _way__ more important.
But I hope the ideas guy partners with or hires someone like you, or like Tom Christiansen - the guy who got the "write it at least twice. always throw the first version away" meme firmly stuck in my head back in comp.Lang.perl.misc in the mid 90s.
Modern startup techniques, particularly the "fail fast" mantra, strongly suggest that quick prototypes, even if they are crappily coded prototypes, are often a great idea - and are often within reach of inexperienced or non technical founders.
(and yeah, I know what you mean by throwaway code ending up as critical production systems, just this morning I got mail from a cron job trying to run a crappy perl script I wrote over 10 years ago - it's monitoring critical infrastructure for a project I did for a company I haven't been in touch with since 08, and from the grapevine I hear they got sold in 09 or 2010 and I've never even met the new owners...)
I think the term 'code beauty' is a poor choice though; that seems to me to implies something subjective, when in fact I fundamentally believe code quality dictacts product quality.
Yes, he had to build a prototype, prove the idea worked, and iterate and address bottlenecks. But take the page rank idea away, and Google would not have been anywhere near what they are today. I don't see how the idea can be dismissed as being worth very little.
Ideas are really really common. Sme of them are great, some of them are just OK, lots of them are bad ideas. Mostly, you can't reliably tell a truly great idea without a working example. My contention, and the view that I see expressed all the time in here, is that the idea _without_ the execution would have been worthless (and I suspect Larry wasn't the first only person to have the same idea, but much like the Winklevosses, anybody else who thought of it got out executed by Larry, and Larry succeeded I. The execution, not the idea.)
Yeah, you need an idea. But ideas are not that hard to come by. Execution requires some work, and as Einstein said "opportunity is missed by most people because it's dressed in overalls and looks like work."
He wanted to do things the right way, made an effort to figure it out by himself, and then asked in the appropriate forum.
"How do I learn to program?" "Pick a language, start building something, ask around (with good, detailed enough questions) when you're stuck." Larry's message could have been written by anyone posting on StackOverflow.
The quality of software is not unrelated to how its implemented. The quality of software is defined by how it's implemented.
The user might not care about the details of how you got there but they sure do care about the quality of the software itself only they don't see it in terms of the underlying details, only what the product does for them and how it does it.
Now can we stop denigrating our craft, please.
Oh... that was before the inception of Google.
This was Larry Page! 1996 is perfect and then he decides to use Python after the Java mess ;)
Like I said recently http://twitter.com/#!/timetabling/status/59909520436117505