In a People of ACM interview with Sanjay Ghemawat, a Google Fellow in the Systems Infrastructure Group (MapReduce, BigTable, Spanner, GFS, etc), talks about a few interesting aspects of Google's culture.
What Made Google Google
Progress is a modern idea. The conviction that future can be changed for the better through individual advancement and action has over hundreds of years driven an exponential growth in the technome.
What drives progress? Challenges. Individuals finding and defeating a challenge. There's usually something someone wants to do so badly that they put in the effort, the thought, and the money into solving all the problems. The results are often something new and amazing.
And so it was for Google:
The main motivation behind the development of much of Google's infrastructure was the challenge of keeping up with ever-growing data sets. For example, at the same time Google's web search was gaining usage very quickly, we were also scaling up the size of our index dramatically and rebuilding it more often. This implied that we had to be able to process a larger amount of data efficiently in a smaller amount of time. This need directly led to the development of many of our infrastructure systems.
And about MapReduce:
The solution was motivated by practical issues we had been running into when trying to solve such problems at Google.
This is a pattern I see over and over again on HighScalability. Leading edge projects generate the most innovation, following a sort of power law distribution for change. Perhaps it's because in tight focussed groups there's an interdependence that generates positive feedback loops that amplify innovations. Your typical cube farm will follow a Gaussian distribution where people are independent of each other thus cutting off any chance of positive feedback loops developing. One also wonders if particular organizational structures like stacked ranking also strangle positive feedback loops at inception.
Great Big Data Career Advice
Sanjay's awesome advice on how to learn stuff is also grounded in the practical world of challenge driven progress:
- learn by doing; build systems
- read about existing systems, in particular papers from systems and database conferences
- practice back-of-the-envelope calculations; some simple modeling can be an effective way to pick between different system designs.
A maker culture ethic if ever there was one. Though I'm not quite sure how this jives with Google's Byzantine and academically oriented hiring process.