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.

Outlines

00:00

🤝 Encounters at Google and Personal Growth

The speaker recounts their experience at Google, starting with a chance encounter with a new employee at the Google Cafe in Bangalore, who turned out to be Shat Balusu from Menra. This story illustrates the unexpected connections one can make at Google. The speaker reflects on completing five years at the company and shares insights gained as a software engineer. They mention an article they wrote about their learnings over the past three years, which received a great response internally and was eventually published publicly. The speaker also discusses their initial dream of working at Google's Android framework team and the journey from a non-CS degree background to becoming a tech lead at Google.

05:01

📈 Core Learnings and Engineering Practices at Google

The speaker delves into the core learnings from their time at Google, emphasizing the importance of over-communication, picking discussions wisely, and taking responsibility for one's work. They introduce the 'bus factor' concept, which highlights the need to spread project knowledge among team members. The speaker advises listening more than speaking to balance skills and challenges, drawing from their transition from working on Google Pay to the Android framework. They also share engineering-specific learnings, such as minimizing configuration combinations, designing for future extensibility, and the importance of code reviews and process improvements.

10:01

🚀 Google Culture and Future Aspirations

The speaker discusses unique aspects of Google's culture, including blaming processes rather than individuals for failures, discouraging heroics in favor of systemic solutions, and the readability program that emphasizes code consistency. They explain the benefits of monorepos and the importance of promotion considerations. The speaker recommends the book 'Software Engineering at Google' for deeper insights and shares personal opinions on career progression. They conclude by expressing excitement for the next five years, anticipating learnings in leadership and the impact of AI, and encourage viewers to engage with their content.

Keywords

💡Google

Google is a multinational technology company that specializes in Internet-related services and products, and is known for its search engine, Android operating system, and various online tools and platforms. In the video, the speaker shares their personal experiences and learnings from working at Google, highlighting the company's culture and engineering practices.

💡Software Engineering

Software engineering is the application of engineering principles to software design, development, testing, and maintenance. In the context of the video, the speaker, as a software engineer at Google, discusses the learnings and challenges they faced in their role, emphasizing the importance of code quality, communication, and continuous learning.

💡Communication

Communication in a professional setting refers to the exchange of information, ideas, or feedback among team members. The speaker emphasizes the importance of over-communication in their experience at Google, suggesting that keeping all stakeholders informed is beneficial and can prevent misunderstandings.

💡Responsibility and Ownership

In the context of software engineering, responsibility and ownership refer to the accountability and initiative taken by an individual or team to manage and improve a project or codebase. The speaker highlights the need for software engineers to take responsibility for their work, including addressing technical debt and ensuring the longevity and maintainability of their code.

💡Bus Factor

The bus factor, a term used in software development, refers to the number of team members who would need to be suddenly unavailable (like being hit by a bus) before a project is considered doomed. It is a measure of the risk associated with the loss of key knowledge or skills within a team. The speaker uses this concept to emphasize the importance of spreading knowledge among team members to ensure project resilience.

💡Code Readability

Code readability refers to the ease with which a human reader can understand the code. It is a critical aspect of software development as it affects maintainability and the ability for others to understand, modify, and debug the code. In the video, the speaker values the readability program at Google, which requires code to be reviewed for clarity before it can be merged, promoting consistency and long-term maintainability.

💡YAGNI

You Ain't Gonna Need It (YAGNI) is a principle of extreme programming that advises developers to avoid adding functionality until it is required. The speaker, however, suggests a slight modification to this principle by advocating for designing with an additional 10% consideration for future needs without over-engineering, thus balancing current requirements with potential future extensions.

💡Blame the Process, Not the Individuals

This concept from Google's culture emphasizes that when failures occur, the focus should be on improving the processes rather than blaming individuals. It encourages a systemic approach to problem-solving, where the aim is to identify and fix flaws in processes to prevent future issues.

💡Monorepo

Monorepo is a software development practice where all of an organization's codebases and projects are stored in a single, central repository. This approach allows for common tooling, easier large-scale changes, and increased code reusability across different projects. The speaker mentions this as a unique aspect of Google's development culture, highlighting its benefits.

💡Leadership

Leadership refers to the ability to guide, inspire, and influence a team or organization towards achieving goals. In the video, the speaker reflects on their past experiences and looks forward to the next five years, anticipating learning more about leadership, especially in the context of rapidly evolving technologies like AI.

Highlights

The speaker's chance encounter with a new Google employee who turned out to be Shat Balusu from Menlo, as narrated in the beginning of the transcript.

The completion of the fifth year at Google and the decision to share learnings and experiences through a LinkedIn article and video.

The speaker's initial dream of working at Google in the Android framework team, despite not having a computer science degree and being rejected from an internship.

The realization of the 'g15' theory, which humorously suggests that new Google employees gain 15 pounds in the first 30 days, highlighting the company's culture and lifestyle.

The importance of over-communication in ensuring clarity and keeping all stakeholders informed within the organization.

The advice to pick discussions wisely, focusing on meaningful conversations and avoiding trivial debates such as tabs versus spaces.

The emphasis on taking up responsibility and ownership, which goes beyond coding to include addressing technical debt and creating sub-projects.

The concept of increasing the 'bus factor' to spread knowledge and skills across the team, reducing the risk of project failure due to the loss of key team members.

The balance between skills and challenges, advocating for personal growth through tackling projects that are slightly beyond one's current capabilities.

The approach to code flag management, suggesting to limit the number of possible configurations to prevent excessive combinations that are hard to test.

The philosophy of designing for today with an additional 10% consideration for the future, ensuring extensibility and flexibility in solutions.

The 'Boy Scout' rule, which encourages developers to improve the codebase around their changes, contributing to the long-term health of the project.

The importance of making implicit rules and guidelines explicit, especially during code reviews, to improve clarity and consistency.

The unique Google culture of 'blame the process, not the individuals', which focuses on systemic improvements rather than individual blame.

The discouragement of 'heroics' or individual weekend fixes, promoting a systemic approach to solving problems rather than quick, temporary solutions.

The 'readability program' at Google, which emphasizes code consistency and maintainability across all products, saving significant engineering time in the long run.

The concept of 'monorepo', a single repository for all code, which facilitates common tooling and large-scale changes across products.

The advice on promotion and visibility, encouraging individuals to align their work with the expectations and visibility requirements of their superiors.

Transcripts

2019 was my second year at Google on a

fine Monday I was having lunch in the

Google Cafe in Google Bangalore and a

Gentleman comes and sits next to me he

his speaking skills were really nice he

told me that it's his first day at

Google we talked a little and then I

just went back to my desk that's it and

the next day I see my mobile phone and

from the news app that I was using I see

this notification that says shat balusu

from menra joins Google and I was like

oh this is the same guy who I met with

yesterday so this is like so this is

like one of the crazy stories a lot of

googlers experience every single day

mostly around the like the kind of

people you meet here at Google so with

the completion of the fifth year at

Google I have a lot of stuff to share

and uh lots of good learnings as well as

a software engineer this is what we're

going to talk about in this

video I wrote this amazing uh article on

LinkedIn I actually published this

article internally to my team it's about

all the learnings and everything that I

could compile within the last 3 years

about the Last 5 Years at Google like it

got an overwhelming uh response

internally and then I decided to publish

it uh in the public domain as well we'll

talk about that like in a moment before

that let's roll back a little so back in

college which was around 2013 a friend

of mine asked me that what is my dream

and I just randomly said maybe I I I see

myself working at Google in the Android

framework Team U seven or eight years

down the line and surrounded by some

really good problems so that dream was

really far-fetched I didn't I was not

enrolled in a computer science degree

and um I was already rejected then in

the internship opportunity and by by the

way I I I was enrolled in an industrial

engineering course so coming from a no

CS degree background uh and finally

being a tech lead at Google it's quite a

story there we'll keep that for some

other video so stay tuned well Les I

knew that I will be joining Google uh in

Just 4 years after the college and I

will be spending most of my formative

engineering time over there uh but let

me tell you one thing that Google is

this past of a company where every

person you meet is highly intelligent

extremely knowledgeable very humble as

well and sometimes industry renowned let

me tell you another story so one of my

previous teammates uh is like a Rubik's

Cube Prodigy so just search this name

burnner Orlando and you'll see that this

guy was giving Ted Talks when he was I

guess 11 so yeah this is kind of the

people you work with every single day at

Google so it it kind of wakes an

imposter in me every single day or maybe

I am I don't know but anyway let's get

to the core learnings before the

learnings so you should know about this

term g15 okay what is this all about

let's take an engineering approach to

understand it so if you plot a graph and

we have weight of a person on the y axis

and on the x-axis we have time where t

equal 0 is like your first day at Google

so there is this g15 Theory which says

that within the first 30 days your

weight will increase by 15 lb and then

kind of stays the same for the next

month and that's when you realize that

oh you put on some weight and then after

60th day after this realization you join

uh the Google gym and eventually it

starts coming down sometimes it does

come back to normal and sometimes it

kind of stays in the middle yeah that's

that's pretty much all about g15 all

right so here are the code learnings

that I developed in the last 5 years of

working here at Google I was ear working

in the Google pay team in the bangal

office and then I joined Android

framework earlier it was all like all my

code was internal to Google it still is

but it's more like it eventually becomes

open source within the next release of

Android let's come to the general uh

learnings the first one I have is the

over communication doesn't hurt that's

what I realized that even if you send a

lot of emails lot of updates to uh all

the stakeholders it's fine it's totally

fine and it's actually better the next

one is pick up the discussions wisely so

it's more about like realizing where you

should spend your time on as far as the

discussions are concerned explicitly

here at Google we have resolved a lot of

things like tabs versus spaces protos

versus auto values like The Ordering of

the import style guide and everything

all of that is resolved and if you're

still spending time on those discussions

maybe it's not worth it take up the

responsibility and ownership so this is

like the first important thing here as

you progress as software Engineers you

will eventually realize that it's not

just about writing code if we talk about

the complete ownership it's more like

making sure that once you have written

the code what's next what were the

trade-offs that you made is there any

technical debt that is generated and how

will you address it uh in the future how

will you create sub projects out of

addressing that technical debt and

that's that's really what actually

closes the project or maybe the project

is never closed in theory anyway so the

other one is increasing your bus Factor

so this bus factor is a funny term this

says that how many people in your team

need to get hit by a bus before your

project is doomed this is learning that

says that you should try to expand the

knowledge of your project to as many

people as you can so it kind of helps in

your visibility and it also increases

the skill set of the team listen more

than you speak is generic you can read

about it this one is an other like the

second important thing here uh which is

like you should strive for a balance

between the skills and the challenges

when I when I moved from like the

internal Google code which is Google pay

to open source which is Android

framework I didn't have like the

required skills as such and the

challenge was pretty high which led to

mild anxiety eventually I started

learning and then I started taking a

bigger projects as well so that my CH

challenge is also Rising this is where

the real fun lies and that's what you

should strive for for so by the way this

is taken from the book flow from mihi

chick and mihi let's come to the

engineering specific learnings well the

first one is also quite important so

quite a lot of times in our code we we

have like maybe a list of flags and the

flags could be on or off those could be

like string values or config parameters

or whatever and we what we do is we we

keep them as Loose as possible in the

sense they can be configured in any way

which is like 2 ra to power n

combinations and just imagine writing

tests for those two raised to power and

combinations it's it's not possible and

that's what happens you don't write the

test the code fails somewhere in the

future down the line and everything is a

mess so what we should try to do is

instead of like allowing the users to

have these two raised to power and

combinations you should just try to have

those fixed set of combinations or modes

which are just possible so let's say you

have five parameters and it may be a

case that only four types of

combinations are really reasonable so

write write the code in a way that only

those four are possible for all the

other states you throw some illegal

State exception or something just don't

allow that it makes life much easier and

the next one is designed for today 10%

of what you think for the future so this

is this is kind of against yagy so yag

is like you ain't going to need it uh

it's more like designed Just For Today

My Philosophy is that you should

definitely add that 10% a very simple

example I've taken is let's say you

trying to model article let's say this

article you're trying to model this

article data like as a data database or

a serialized object either in your

client or server and you have this is

published Boolean as a parameter that

says whether this article has been

published or not it kind of works now if

you just spend 10% more thinking on this

uh It'll point you towards using an enum

which is the status of the article which

in the future could be dirty draft

pending review or whatever so you see

what we did there we are able to address

the current requirement but we are

ensuring that our design is still

extensible in the future that is what

you should strive for the boy C rule

this is very simple as in whenever you

are let's say fixing a bug or having a

small code change just try to look at

the code in the vicinity and maybe fix

that as well the underlying thing is

that if you do it over a course of time

you end up maybe fixing everything in

the class without spending real Cycles

on it make implicit explicit this is

especially important for cases uh like

when you are reviewing the code so quite

a lot of times what happens is you you

put a comment on the code review because

of your personal preference like an

example that I've taken is you should

use this verb phrase for the Java dog

because it sounds better that's a good

reasoning but on the author side maybe

it's not that author might feel why the

thing is that there is this implicit

thing here which you're kind of missing

which is like you're kind of trying to

adhere to the style guide Make That

explicit that is more objective sounds

better and the author gets to learn

something thing and that's the goal of

the codee review that's like part of the

goal of the code review then the

importance of up upgrades or The

NeverEnding software so this is very

unique thing about especially about the

big Tech where like for Google if you if

you talk about the lifespan of Google

search YouTube or Android operating

system we practically don't know whether

these products are even going to end so

the learning I have over here is that

short-term solutions for these products

are really bad like especially for

Android which is open source which is

not cloud-based you have lots of Legacy

code which is there since the first

version of Android which which was like

20 years back if you put anything as a

short-term solution it's going to be

there for the next years to come and

you're going to maintain that so it's

always better to spend a little more

time and do it as nicely as possible I

think this one is also straightforward

you can just go through it there are a

few unique Google culture bits that I

strongly value these these are like

amazing first one is blame the process

not the individuals I've talked about

this in my my like early set of videos

so the thing is that whenever something

fails over here the blame is never given

to an individual the blame always goes

to a process while the the owner still

has to write like a root cause analysis

document which we say postmodem but the

focus of the postmortem is what was the

flaw in the process and how we can

improve it I have an example over here

which you can uh go through it's pretty

like simple and it's kind of a real

story semi-real I don't know so the

another thing is that the heroics are

discouraged at Google so heroic is where

uh there was some weird error and you

spent the weekend and you eventually

fixed it this is the thing which is kind

of discouraged what we actually strive

for is we should let it break figure out

a systemic issue and then try to address

that systemic issue instead of just

trying to address that particular

failure okay next we have the

readability program here at Google so

whenever you're sending a cal for review

you need to get a readability approval

for for that particular language I have

been reviewing CS like I'm a readability

approver for two languages at Google

Java and typescript and I practically

seen code from all the products at

Google and I really value the

consistency it brings along so the

ideology over here is the code is

written once but it is read multiple

times maybe thousands or hundred

thousands of times for like a long-term

product so the underlying idea is that

if I try to spend maybe 15 20 minutes to

write a more readable code I would

eventually end up saving tons of

bandwidth in the future for a lot of

like tons of engineering bandwidth in

the future and that's all so mono is a

concept that I could have never like I

could have never wrapped my head around

uh before joining Google it's like we

don't have any feature branches it's

just one repository we keep working on

that well the benefits are huge like

think about a company where we have

common tooling across all our products

we do large scale changes across all our

products highly reusable codes again all

our products s like not even just like

just the client part client and server

both are using the same everyone is

using the same thing and by the way if

you want to read read about all of this

in detail you should refer to the

software engineering at Google book it

goes deeper into each one of these

benefits then m genen i mean of course

uh I don't need to say anything here so

promotion for promotion I've got some

opinionated stuff which is more or less

just like just one thing you should

always be thinking about l+1 and l+ 2

make sure the existing l+1 and L plus2

folks they have good visibility into

your work and for all the attributes of

l+1 and L plus2 make sure that your work

is somehow addressing those and you

should be good and actually folks that's

all I have put a lot of good references

and kind of like the appendix section

here at the end of the article the

primary one is the Google s book and

then the other two books that I referred

as one is the flow and the other one is

thinking fast and slow I still can't

believe it's it's been 5 years now I'm

not sure what the next 5 years hold

especially with AI and everything let's

hope for the best but I'm pretty sure

I'm going to be having lots of good

learnings about leadership in the next 5

years let's hope for the best and thanks

for watching this video I mean the

regular drill don't forget to hit the

like button and subscribe to the channel

if you haven't already and subscribe to

my LinkedIn newsletter as well I I I'll

try to put like some stuff by-weekly

starting with this article so yeah I

will see you in the next one bye

so I wrote this amazing uh I didn't

understand oh come on I'm probably I

should probably just disable it I'm

going to say

Google anyway this was not in the

[Music]

script