Communications of the ACM
An Academic's Observations from a Sabbatical at Google
Credit: Dreamframer / Shutterstock
I have spent the majority of my computing career in an academic environment, with a Ph.D. in Informatics from the University of Edinburgh (2007), postdoctoral experience at the Universities of Edinburgh, Oxford, and Melbourne (2007–2010), followed by a faculty position at the University of St Andrews in Scotland. However, several questions had always played on my mind: "What is industry really like?", "Am I working on the right problems?", "How can I get people to use my research?" To answer some of these questions I applied to the Google Visiting Faculty program,3 where I spent nine months as a Visiting Scientist in Mountain View, CA, as part of the Borgmaster team. Borg8 is Google's cluster management framework, which runs hundreds of thousands of jobs, across a number of clusters each with up to tens of thousands of machines. This Viewpoint summarizes some of my experiences working in software engineering at Google, with each subsection derived from observations inspiring the core lessons I am bringing back to academia in order to improve both research and teaching.
Production Software Engineering
One of the most useful experiences during my time at Google was writing production-quality code. This is not something I had a great deal of experience with, coming primarily from an academic background, where the output is usually research or prototype code. The differences and motivation for code between academia and industry are stark: in an academic environment, code is primarily written for the purposes of demonstrating a proof of concept and is often of low quality and even disposed of after a paper deadline or project finishes. The reason behind this is not that academics cannot write code, but that the code is often a means to an end. The new knowledge and insights, written up as a research paper, are the artifacts that researchers value. In industry, code is written for a group of end users and developers who must maintain and extend its functionality. It must, therefore, pass rigorous testing and code review before it is checked in and made available to the rest of the company, and eventually the outside world.
No entries found