How Larry Page learned Java

Woah there. Be careful with that quick dismissal of what you term 'code beauty'.

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.

> 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.

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.

I think so to. In 1996, was "Programming for the Internet" (or the equivalent) actually taught in college?

Yeah, I'm having trouble seeing any problem with it.

He wanted to do things the right way, made an effort to figure it out by himself, and then asked in the appropriate forum.

Grr I've seen many posts like this recently jumping on the slightest stuff - at the risk of being down-voted, what the hell people? I expected better, pretending like we can just hack together pieces of crap and pretend like it doesn't matter is exactly how we end up with 99% of software out there sucking and the few who bother trying for more cleaning up, in fact that's how google won out in the first place.

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.