I'm Feeling Lucky_ The Confessions of Google Employee Number 59 - Douglas Edwards [45]
The one area in which hygiene was fastidiously maintained was engineering. Not the engineers' physical space—they were apparently all feral children—but their operating principles.
Urs insisted on adopting the best practices he had seen in more industrial settings to things like source control and compiler warnings. "We'd make sure the compiler actually failed if it had a warning, so you couldn't ignore it," he told me. He formalized the most important elements into a style guide, which became a mandate enforced by Craig Silverstein.
"I had no desire for a style guide," Craig noted, "but Urs was really insistent."
The biggest question was which programming language to use. Craig wanted to use C. Urs preferred C++. Urs prevailed, but he agreed to restrict Google coders "from using the bad parts of C++."
"What are the bad parts of C++?" I once asked Craig.
"Most of it," he said with a straight face.
Craig believed Google would need an integrating force to prevent redundant or conflicting efforts, maintain standards, help set priorities, and provide feedback during performance reviews. He made it his goal to be that force, to be "the one who knew what was going on everywhere."
"Until we were about a hundred people," he recalls, "I'd go around and talk to everyone. I'd say, 'How's your work going? Do you need any help?' Some people got really upset about that. 'This guy keeps bothering me. What's he doing?' Urs had to take me aside and tell me to stop." Craig realized that "they didn't need someone to pay that close attention. Everyone was still just one degree away. They knew who to talk to. There was very good communication."
The one thing that did need a high level of attention was the code itself. To look for potential problems, Craig started scanning every automatic alert generated whenever someone checked in a codebase change—no matter how minor. But a lone proofreader couldn't keep up with the growth of engineering's output. So Urs instituted a formal code-review process.
"You get to pick one good engineering practice to be your cultural touchstone," Craig said, "and for us it was code reviews." To initiate a review, a coder would send out a pointer to an online design document. Anyone could respond with comments, but an official reviewer had to sign off on the actual code.
The benefit was obvious. "Finding problems in the beginning," engineer Ron Dolin explained, "was a hundred times more efficient than finding them later on."
Still, as Google grew, not all the programmers subscribed to the idea that their code needed proofing or that it was their responsibility to look over other people's work. As Craig explained it, "We put a process in place to prevent submitting code without review, unless you lied."
To get around the process, people would perform cursory reviews. "I'd send out a big, giant piece of code," Craig said, "and they'd send back, 'Looks good.' I suspect there's more that could have been said about that code."
When new employees started, Craig reviewed their code himself, inculcating them into the system of collaborative authoring. Some people hated it. "paul Bucheit hated it," recalls Craig. "Noam* hated it. But Paul ended up doing a lot of code reviews on his own and being really supportive of that methodology. Noam thought it was a waste of time—he's like Larry and Sergey, a research developer. He'd say, 'I'm spending more time reviewing this code than I spent writing it—how is that a good use of anyone's time?'"
Sanjay Ghemawat did not hate code reviews. Though he had come out of a research lab where looking over others' shoulders was considered