Takeaways from Google Software Engineers
07 Feb 2022
Google is one of the most well known companies in the world. Their growing team of software engineers over the decades have collaboratively created one of the largest codebases ever. On February 3rd, 2022, Google senior software engineers gave an ACM Tech Talk titled “Software Engineering at Google”, which discussed Google’s practices for maintaining their codebase. The main points in their talk, time, scale, and tradeoffs, are reviewed below.
The senior software engineers emphasized knowing the length of time a certain code will be used for. That this knowledge greatly affects the outcome of the code. Certainly, if knowing that the code will only be used for several hours, the quality of the code is significantly less than code that will be used for years, or even decades. Code developed to be used for long periods of time will be reviewed many more times by more software engineers and made to be sustainable. Sustainable meaning that the code is easy to understand and safely adaptable, for future modifications. The google engineers mentioned the difficulty of upgrading old code and I fully agree with this. From my experience, I forget the code of a project after I’ve finished the project. This makes it difficult to revisit the code months later to make modifications. The practice of creating sustainable code, though difficult to achieve, makes the process of revising old code easier not only for those who fabricated the code themselves, but for future developers who join the project at a later time. In the future, I will put more effort into writing comments so that interpretation of the code is easier for anyone looking at it, including myself, at a future time.
Another key point mentioned was the scale of the code corresponds to expense. The more scaled a project is, the more hardware, software, and human resources are required. One example given was on methods to deal with outdated software. Allowing users to continue using outdated software requires resources, so this creates a dilemma of how to transition users to newer software. One option is to slowly transition into the new software and the other option is to force all users to update by a certain date, in which the old version will be discontinued. From my experience, both methods are valid given the circumstances. An update with new features can be rolled out more slowly, whereas a bug fix for something that can break the program should be a forced update. Regarding development, the Google software engineers stated the advantages and disadvantages of weekly merge meetings. From my experience at my current software development job, merges are better if they are not weekly. Each of the developers’ tasks are only merged when they are functional, and development usually takes more than a week. However, I can see that if assigned tasks are accomplished in less than a week, then there’s nothing wrong with merging on a weekly basis. There’s fewer long-lived development branches, leading to fewer merge conflicts.
Trade offs affect the code design and can change over time. The decision on whether a certain trade off should be made should always be based on evidence. In the logic heavy field of computer science, I would agree with this statement. At work, my team is always asking one another their reasons for implementing something a certain way if it is unclear or if there is a better solution. As I become a better software developer, I will improve my ability to deduce the best solution for a problem. The best solution is important because it leads to better sustainability in the long run and optimizing the code early on saves resources. Over time, circumstances change, so it is also important to re-evaluate decisions accordingly and make trade offs if needed.
The Google software engineers offered meaningful insight into how Google handles their large codebase and most, if not all, software developers/engineers should be in agreement with their methods. Understanding the impact of time, being mindful of scale, and making evidence-based decisions are critical to the success of any coding project. These topics are known by everyone, but likely not fully understood. I personally did not fully understand the impact of these various topics beforehand, but now I am more mindful and aware. In the future, I will code with more consideration to time, scale, and trade offs.