HN user
Pair programming is good for UI/HCIish code and so so for other types of code. Studies have shown that human are not good at multitasking even though it makes them feel productive.
Personally I think pair programming is overrated while code review is still underrated.
Most web designers don't grok <your_favorite_langauages>, but some limited template languages/tags. A web framework without template doesn't scale in terms of development resource unless you figure out a way to automatically translate a template delivered by a designer to your Smalltalk code.
Good lessons, except for 1, without doing that there'd be no Google map-reduce and Hadoop. Of course, this means you should be using Hadoop now.
Short summary: he thinks that every line of code is design because the final code is the precise spec.
This is an interesting but narrow POV. What if you "design" an algorithm in Haskell and what to "translate" to another language? Calling the "translation" process design would be a bit of stretch. Implementation seems to be an appropriate word here.
Retrieving data to process and storing back to some giant "storage units" are becoming more and more obsolete. The future is google style: data is replicated and backed up at all times and you push computation to data to explore data locality.
If you want to compare repository sizes you should compare the size of .git directory only.
-d'<tab>'
The singularity is near!
Paxos and consistent hashing on top of BerkeleyDB? This is getting old. 3-way replication levels at 12MB/s? Have they heard of replication pipelining?
PostSQL is better than NoSQL
Then your point is moot. The context is startup. Eric does a good job for a post-startup, which is already very profitable with a revenue of $86m in 2001 (http://investor.google.com/fin_data2003.html). As a matter of fact, many think that Eric is more "lucky" than "good", given his track record at Novell.