5 Years @Google: Learnings as a Software Engineer

Summary

The speaker reflects on their five-year journey at Google, sharing anecdotes and key learnings from their experience as a software engineer. They emphasize the value of over-communication, wise discussion participation, taking responsibility, and increasing one's 'bus factor'. The speaker also discusses engineering-specific insights, such as designing for the future, the importance of upgradability, and the Google culture that promotes blaming processes over individuals, discouraging heroics, and advocating for readable code. The talk concludes with a look forward to future learnings, especially in leadership and AI.

Takeaways

• 🌟 Over communication is beneficial; it's better to keep all stakeholders informed.
• 🧐 Choose discussions wisely to allocate time effectively and avoid trivial debates.
• 🔧 Take responsibility and ownership for the code you write, including addressing technical debt.
• 🚀 Increase your bus factor by spreading knowledge about your project among team members.
• 📈 Aim for a balance between skills and challenges to promote growth and reduce anxiety.
• 🔍 Keep code configurations limited to necessary combinations to simplify testing and maintenance.
• 🛠 Design with 10% extra consideration for the future to ensure extensibility.
• 🐞 Fix small issues when addressing bugs to gradually improve code quality.
• ✅ Make implicit rules explicit to improve code clarity and facilitate learning during code reviews.
• 🚦 Prioritize long-term solutions over quick fixes, especially for major products.
• 📚 Embrace Google's culture of blaming processes, not individuals, for failures.

Q & A

What was the speaker's initial dream related to Google?

The speaker initially dreamt of working at Google in the Android framework team around seven or eight years down the line.

How did the speaker describe their journey from a non-CS background to becoming a tech lead at Google?

The speaker came from an industrial engineering course background, was not enrolled in a computer science degree, and had been rejected from an internship opportunity. Despite these setbacks, they eventually became a tech lead at Google, highlighting a remarkable journey.

What is the 'g15' theory mentioned in the script?

The 'g15' theory humorously suggests that a new Google employee's weight will increase by 15 pounds within the first 30 days of joining the company, and then it stays relatively constant for the next month. After realizing this weight gain, the employee might join the Google gym, leading to a potential weight loss or maintenance.

What are the core learnings the speaker wants to share from their experience at Google?

The core learnings include over-communication, picking discussions wisely, taking up responsibility and ownership, increasing the bus factor, listening more than speaking, and balancing skills with challenges.

How does the speaker approach feature flags and configuration parameters in their code?

The speaker advises to limit the possible combinations of feature flags and configuration parameters to a fixed set that makes sense, preventing the creation of an excessive number of combinations that would be impossible to test.

What is the 'boy C rule' and how does it apply to code changes?

The 'boy C rule' suggests that when fixing a bug or making a small code change, one should also look at the surrounding code and make improvements there. Over time, this can lead to a comprehensive improvement of the code without dedicating specific cycles to it.

How does Google handle process failures?

At Google, when a process fails, the blame is placed on the process itself, not on individuals. The focus is on identifying flaws in the process and improving it, rather than blaming any specific person.

What is the 'readability program' at Google?

The 'readability program' requires that any code submitted for review must receive readability approval for the specific programming language. This ensures consistency across Google's products and saves engineering bandwidth in the long run by making code easier to read and understand.

What is the concept of 'mono' in Google's development culture?

'Mono' refers to the practice of having a single repository for code instead of feature branches. This allows for common tooling across all products, large-scale changes, and high code reusability.

What advice does the speaker have for those looking to advance their careers at Google?

The speaker advises to always think about the attributes of the levels above (L+1 and L+2) and ensure that one's work is aligned with those attributes. It's also important to provide visibility into one's work for those levels.

Which book does the speaker recommend for a deeper understanding of Google's software engineering practices?

The speaker recommends the book 'Software Engineering at Google' for a more in-depth understanding of the practices and principles discussed in the script.