4 Years of Software Engineering advice in 14 minutes

Summary

In this insightful video, a software engineer at Google shares the unexpected advice that led to their promotion: teamwork and collaboration are key, not just coding skills. They discuss the 'code promotion fallacy' and emphasize the importance of asking for help, writing documents, and choosing impactful work to advance in your career.

Takeaways

• 😀 The speaker struggled with promotion to senior engineer and learned that it's not just about coding skills, but also about teamwork and collaboration.
• 📺 The manager compared the journey to the anime 'Naruto', emphasizing the importance of working with others and gaining support from the community.
• 💡 The 'code promotion fallacy' is debunked, suggesting that merely coding more does not necessarily lead to promotion.
• 👀 The speaker advises that after a certain point, doing more code changes does not impress colleagues or managers, as it becomes expected.
• 🔍 To progress, one must take on more responsibility and gain trust from teammates, which often involves more than just coding.
• 📝 Writing documents and sharing knowledge is crucial for visibility and recognition, as it reaches a wider audience than code reviews.
• 🤔 Asking for help is a key skill in software engineering, and it's important to do so in a way that shows you've made an effort to solve the problem yourself.
• 📈 To be above average, one should do more than just the expected tasks, by optimizing daily workflows and learning tools more effectively.
• 📚 Documenting problems and solutions is more impactful than just coding, as it can be shared and discussed by many, establishing you as a subject matter expert.
• 🏆 The speaker emphasizes the importance of choosing work that has high leverage, meaning it has low effort, high impact, and high visibility.
• 🤝 Helping others and being recognized for your work are essential for career growth, and advocating for yourself is crucial in a competitive work environment.

Q & A

What was the speaker's struggle in their career as a software engineer?

The speaker was struggling to get promoted to a senior engineer position despite writing code day in and day out. They were unsure what they were doing wrong and sought advice from a manager.

What advice did the manager give the speaker using the analogy of the show 'Naruto'?

The manager advised that becoming a senior engineer is not about being on your own but about working with others. He compared it to Naruto's journey from being lonely to being supported by the entire village, emphasizing the importance of teamwork and collaboration.

What is the 'code promotion fallacy' mentioned in the script?

The 'code promotion fallacy' is the misconception that spending more time coding will necessarily lead to a promotion. The speaker explains that simply doing more code changes is not impressive after a certain point and that other skills and responsibilities are needed for advancement.

Why does the speaker believe that writing code alone won't lead to promotion?

The speaker argues that writing code limits visibility and network. Code changes are often only seen by a few reviewers, and not shared widely within the company. This limits the recognition and impact of one's work, which are crucial for promotion.

What is the most important skill the speaker suggests a software engineer should learn?

The speaker suggests that the most important skill a software engineer should learn is to ask for help. This is because software engineering is complex, and collaboration and support from others are essential for success.

How should one ask for help effectively according to the speaker?

The speaker advises first trying to solve the problem independently by using Google search, internal tools, and thinking about it for a reasonable amount of time. If still stuck, then it's time to ask for help, making sure to show the effort put in and making it easy for others to assist by clearly stating the problem and what has been tried.

What is the speaker's view on writing documents in a software engineering role?

The speaker believes that writing documents is crucial for visibility and recognition. Documents can be shared and circulated, leading to broader recognition of one's work and expertise. This is more impactful than code, which is often only seen by a few reviewers.

What does the speaker mean by 'above average' in the context of software engineering?

The speaker defines 'above average' as doing what everyone else is doing and then doing a little bit more. This means going beyond the basic expectations and making improvements to one's daily workflow to stand out.

What is the concept of 'Leverage work' as described by the speaker?

'Leverage work' refers to tasks that have low effort, high impact, and high visibility. The speaker advises focusing on solving problems that affect many people and have significant consequences, as this can lead to greater recognition and career advancement.

How does the speaker suggest advocating for oneself in the workplace?

The speaker suggests understanding one's system thoroughly, making significant contributions, and then letting everyone know about these contributions. This can be done through standup meetings, group chats, or even sending out emails to highlight one's work and its impact.

What is the book 'Give and Take' by Adam Grant about, as mentioned in the script?

The book 'Give and Take' discusses the different philosophies of helping others in the workplace. It contrasts the transactional approach, where help is given with the expectation of reciprocation, with the benevolent approach, where helping others is seen as a good deed in itself.

Outlines

00:00

🤔 The Struggle for Promotion and the Importance of Teamwork

The speaker reflects on their journey as a software engineer at Google, highlighting the challenges they faced in getting promoted to a senior role. They recount a conversation with a manager who compared their situation to the anime character Naruto, emphasizing the importance of teamwork and collaboration over solitary effort. The manager suggests that being a senior engineer is not about individual coding prowess but about working with others. The speaker also introduces the concept of the 'code promotion fallacy,' which is the misconception that more coding leads to promotion. They argue that after a certain point, additional code changes do not impress colleagues or managers, and that building relationships and expanding one's network are crucial for career advancement.

05:00

📚 The Power of Documentation and Visibility in Engineering

The speaker discusses the importance of proficiency in one's current role to achieve promotion, explaining that being 'above average' involves doing a little more than what everyone else is doing. They stress the value of learning tools and improving daily workflows to stand out. The speaker then highlights the importance of writing documents, as they can be shared and circulated, providing more visibility than code. They advise writing documents on problems that affect many people and starting with all the necessary information upfront. The speaker also introduces the concept of 'leverage work,' which involves tasks that are low effort, high impact, and high visibility. They caution that not all problems are worth solving and encourage engineers to focus on work that matters, using the example of snack hoarding in tech companies as a trivial problem that doesn't need a solution.

10:02

🤝 Advocating for Yourself and the Benefits of Helping Others

The speaker shares a five-step process for career advancement, which includes understanding your system, making significant contributions, and ensuring that everyone is aware of your work. They emphasize the importance of self-advocacy and making your work visible to others. The speaker also discusses the benefits of helping others, drawing on the book 'Give and Take' by Adam Grant. They differentiate between transactional and benevolent helping, suggesting that both approaches can be beneficial. The speaker encourages engineers to help their colleagues, as it not only aids those in need but also builds goodwill and a supportive work environment. They conclude by urging viewers to be proactive in their career development and to support their peers, using the analogy of Naruto's journey to illustrate the value of community and collaboration.

Keywords

💡Software Engineer

A software engineer is a professional who applies the principles of software engineering to the design, development, maintenance, testing, and evaluation of computer software. In the video, the speaker is a software engineer who has been working at Google and is reflecting on their career progression and the challenges they faced in getting promoted to a senior position.

💡Promotion

Promotion in the context of the video refers to the advancement in job rank or title, typically from a junior to a senior position. The speaker discusses their struggle with promotion and the realization that simply writing more code is not the key to being promoted, highlighting the importance of collaboration and visibility in the workplace.

💡Naruto

Naruto is a reference to a popular anime and manga series, used in the video as a metaphor for personal growth and teamwork. The speaker compares their career journey to the character Naruto, who starts as a lonely child and eventually gains the support of his village. This analogy is used to emphasize the importance of working with others and gaining support for career advancement.

💡Code Promotion Fallacy

The 'Code Promotion Fallacy' is a concept introduced in the video, suggesting that spending more time coding does not necessarily lead to promotion. The speaker argues that being a great programmer is not solely about coding but also about collaboration, visibility, and taking on more responsibility, which are crucial for career growth.

💡Visibility

Visibility in the video refers to the recognition and awareness of one's work by others in the organization. The speaker emphasizes that writing code alone limits one's visibility, as only a few reviewers see the work. Instead, sharing documents, proposals, and solutions can increase visibility and recognition, which is essential for promotion.

💡Responsibility

Responsibility in this context means the tasks, duties, and obligations assigned to an individual. The speaker mentions that to be promoted, one must take on more responsibility and demonstrate trustworthiness to teammates. This involves not just coding but also contributing to the team's goals and projects in a more significant way.

💡Help

Asking for help is a key theme in the video, where the speaker advises that software engineers should not hesitate to seek assistance when needed. The speaker shares their experience of feeling embarrassed to ask for help but ultimately learning that it is a critical skill for success. The right way to ask for help involves showing effort and making it easy for others to assist.

💡Proficiency

Proficiency in the video is used to describe the level of skill and expertise one must have in their current role to be considered for promotion. The speaker explains that being above average involves doing more than what is expected and mastering the tools and processes used daily in software engineering.

💡Documentation

Documentation in the video refers to the act of writing down problems, solutions, and proposals, which is emphasized as a crucial skill for software engineers. The speaker argues that documents have a longer lifespan and greater visibility than code, helping engineers become recognized as subject matter experts and gain recognition for their work.

💡Leverage Work

Leverage work, as discussed in the video, refers to tasks that require low effort but have high impact and visibility. The speaker advises that engineers should focus on solving problems that affect many people, as this can lead to greater recognition and career advancement. It involves assessing the effort, impact, and visibility of potential projects to prioritize work effectively.

💡Advocacy

Advocacy in the video is about promoting oneself and one's work to gain recognition. The speaker shares a five-step process for self-advocacy, emphasizing the importance of understanding and contributing to the system, and then making those contributions known. This self-promotion is crucial for being noticed and considered for promotion.

Highlights

The speaker was struggling with promotion to a senior engineer role at Google.

A manager advised the speaker by referencing the show Naruto, emphasizing the importance of teamwork and community support.

The concept of the 'code promotion fallacy' was introduced, challenging the idea that more coding leads to promotion.

It was highlighted that after a thousand code changes, additional ones are expected and not impressive.

The speaker learned that promotion requires taking on more responsibility and gaining trust from teammates, not just coding.

Visibility and network are limited if one only focuses on coding and sends code to the same reviewers repeatedly.

The speaker emphasized that code snippets are not widely shared, limiting exposure and recognition.

The importance of asking for help in software engineering was underscored, countering the fear of appearing weak or unintelligent.

A proper way to ask for help was outlined, involving self-research and clear communication of the problem and efforts made.

Being proficient in one's current role is crucial for promotion, which involves going beyond the average.

Writing documents on problems and solutions was suggested as a way to gain visibility and recognition.

The speaker shared advice on writing impactful documents by frontloading information and focusing on problems affecting many people.

Not all problems are worth solving, and the concept of 'leverage work' was introduced to prioritize tasks with low effort, high impact, and visibility.

The speaker warned about competition for good work and suggested claiming tasks by writing proposals to avoid others taking them.

Advocating for oneself was deemed necessary, as no one will do it unless you do.

A five-step process for success was shared, involving understanding the system, making contributions, and letting others know about them.

The speaker discussed the importance of helping others and how it can reciprocally benefit one's career.

The book 'Give and Take' by Adam Grant was mentioned, discussing the philosophies of transactional and benevolent helping.

The speaker concluded by encouraging viewers to help others, as it can lead to personal and professional growth.

Transcripts

all right so back in March 2024 I was

just finishing up my fourth year as a

software engineer now I've been working

at Google for a little bit and I was

writing code day in and day out but I

started to struggle a little bit when I

was trying to get promoted to be a

senior engineer I didn't know what I was

doing wrong so I had to ask a manager

about what I could be doing better he

thinks about it a little bit and asks me

if I've ever seen the show Naruto it's

about this little lonely kid um in the

beginning and then everything works out

for him to be a ninja yeah he was really

lonely in the beginning but he started

to work with teammates he didn't

necessarily get along with it takes him

some time but then he gets along with

them and they go on missions and figure

things out after that then he starts to

meet teams from the rest of the village

now they're not competitors but it takes

him some time to learn how to get along

with them too and after that he goes

from being one of the loneliest kids to

being supported by the entire Village to

be a senior engineer you don't get there

by being on your own you get there by

being with everyone else with working

with everyone else and that was one of

the best pieces of advice I've ever

gotten as a software

engineer that was really surprising to

me because a lot of people imagine a

great programmer by someone who can just

kind of fix a bug by just staring at it

just looking at it a little

intensely people should be writing dogs

not code if they really want to to get

promoted which feels really weird

because we spend so many years trying to

study and learn code um whether we're

going to a boot camp or a university

this makes me want to explain a concept

called the code promotion fallacy which

is the idea that if you spend more time

coding you're not going to necessarily

get promoted which feels weird but if

you've ever been working you might be

used to this idea of fixing bugs and

solving Sprint tasks but if I could tell

you something a senior engineer told to

me once it's that after you do a

thousand code changes nobody gets

impressed if you do another one

it's just kind of expected now it's

people are used to it that's because

you're doing what you're expected to do

nobody's impressed if the garbage man

takes out the garbage and I made this

mistake too I spent years thinking that

if I just write more code then that next

promotion is going to be coming soon but

what got me to my current level isn't

what's going to get me to the next level

and that's something you just have to

learn the hard way so you're going to

have to do something that gives you more

responsibility and more trust with your

teammates to give you something that's a

little bit more important and to be

honest that doesn't always happen

through coding when you write code and

you make this code change you're sending

it off to maybe one or two reviewers and

the issue with this is that you're

probably sending it to the same one or

two reviewers every time for a feature

you're getting a work done but it's only

these two people who know what you're

doing you're limiting your visibility

you're limiting your network the other

issue with writing code is that people

don't really share code Snippets um in

the group chats people don't pass around

code Snippets every time you do one

there's probably a small percentage but

from all the code changes that you've

done maybe only a handful get like

circulated around everyone else the last

point is that only engineers get to see

your code the same two Engineers not

your manager not your product manager

not your ux designers you're really

limiting yourself if all you do is focus

on the code it was one of the hardest

lessons I had to

learn and I'm ready to share everything

I've learned over the past four years as

a software engineer so this is going to

be the most important skill you can

learn as a software engineer and I don't

care if you don't watch the rest of the

video but listen to this one and that

skill is to ask for

help software engineering is freakishly

hard and nobody has all the answers

you're only going to get by if you get

along with people and they're willing to

help you and I know a lot of people are

going to tell me that asking for help is

hard and I get it we're scared that

people don't want to help us or that we

come off as weak or not independent or

not that smart if you let yourself be

alone like Naruto you're going to

struggle a lot and I I struggled with

this too I I remember asking everyone a

question about this bug that I was

working on and this senior engineer just

DMS me a a Google search link right and

it's something I could figure out myself

too but I just felt so embarrassed that

I just didn't do that so what I learned

as an engineer over these years is that

there is a right way to ask for help and

the way you do that is by first trying

to figure it out on your own trying to

look up the Google search yourself

trying to use the the internal tools

yourself trying to think about it a

little bit more over maybe a few hours

or at most a day then if you're really

that stuck it's time to phone a friend

you have to figure this out quicker

because you don't have more days or a

week to figure out a 15-minute bug that

you could solve by just asking someone

else for help that's going to set your

career back and that's going to set back

any projects that you're working on

there's just no time for this even if

you don't feel comfortable doing this it

is a skill that you have to learn and

one of the easier ways to get people to

help you is just

to really show them that you did try

that you did do these Google search

links that you did try reading the

documents and they still don't make

sense that you did try like playing

around with the code a little bit and

you still couldn't figure it out people

are more willing to help you if they can

see that there's actually some effort

that you put in there the other thing

that you have to do is you have to make

it easy for people to help you what's

the problem that you're looking at why

are you trying to solve this problem and

what have you tried it's just this

three-step framework that you all you

have to to do is just repeat this

anytime you want to reach out to someone

and I guarantee you people are more

willing to help you after you kind of

like lay it out for them like that

learning the skill is going to help you

a lot in your software engineering

career but you're going to have to be a

lot more proficient if you want to get

promoted Beyond just being a junior

engineer so you're probably not going to

be surprised if I tell you that to get

to the next role you have to be

proficient in your current role I know

shocking isn't it I think something that

we kind of Overlook is like why this

matters and how to you actually be a

little bit more proficient and I like to

explain this to people by explaining

what it means to be above average you

just do what everyone else is doing

literally what the average is and then

you just do a little bit more than that

that's all it is that's literally the

definition of above average so if you

want to do a little bit more as a

software engineer how do you do that

well you can do that by learning the

tools that you're using every day make

the debugging flows a little bit more

efficient make your processes that

you're following every day a little bit

better once you have this mindset shift

and you make your day-to-day workflow a

little bit better than someone else's

you'll be surprised by how well you're

performing at work and you'll get so

good at coding that it'll actually start

to hold you back the truth is that for

every engineer you grow your career by

doing other things besides coding one of

the most important things you could be

doing is writing things down this is

going to help you more than anything

else because people share documents you

could write a document on a bug or a

proposal on how to write some code on

something and people will still

circulate this and share this month

later you get to write the impact of any

problems that you're solving and you get

to share this with your manager so

people know why the work that you're

doing matters new hires are going to

pick up your documents and try to read

it for historical context people share

documents and gather around in a meeting

to read and talk about your documents

they don't do this with code you're

getting visibility and you're getting

noticed by other people beyond the same

two code reviewers that you would have

in your code reviews you're literally

getting more visibility in sharing what

you know as an engineer if you keep

writing documents on the same problems

people will start associating you with

that area and you'll become the subject

matter expert that's how you get

visibility and that matters because when

people think about that area or that

problem or that feature they're going to

reference you that like you know

everything in and out about that area it

just gets a little scary because nobody

teaches you how to write a document um

you don't learn this in school and you

don't learn this in boot camp and or

anywhere else it's just something that

you just have to learn on the job now

writing a document is a video itself but

if I could share my advice as a software

engineer it's that you want to write

documents on problems that are affecting

a lot of people and what your proposal

or your solution to solving those

problems are when you write one of these

you have to start off by frontloading

all the information and that feels weird

because we're so used to saving the best

for last but you really want to just

save a lot of time for people to just

learn everything about this document

like why this thing exists what the

problem is what the impact of this

document is and what you actually ended

up implementing or doing to solve this

problem I guarant that if you do that

your document is going to get circulated

and talked about and it's going to live

a lot longer than any code that you're

going to write but something you have to

keep in mind is that not all problems

need a document and not all problems

need to be solved one of the hardest

things I had to do as a software

engineer was picking work that actually

matters you're probably not going to be

surprised if I tell you that not all

work matters not all work is created

equal if you've ever seen one of those

Day in the Life videos you'll notice

that there's a ton of snacks at all

these tech companies and something I'm

going to tell you after being inside one

of the those type companies is that they

know that people are hoarding and

stealing snacks now this is a problem

and they could solve it with just using

a vending machine or making people badge

in with their badges to get the snacks

but it's not a problem worth solving so

they kind of just let it happen like

everyone knows this happens but there's

more important things to do besides fix

a snack problem so something you're

going to learn as a software engineer is

this concept of Leverage work which is

something that has low effort high

impact and high visib ibility so the low

effort really means is it really worth

the visibility and impact of solving

this problem you'll have to ask yourself

is it worth the time is it going to take

days or weeks to solve this and are you

going to have to coordinate with a lot

of people to figure this out it might be

worth it but you'll only know by

comparing it to visibility now the

visibility component is trying to figure

out if this problem is affecting more

than just yourself is it affecting other

people because the cool thing about this

is that if you solve this problem all

those other people will know that you

solved this problem and that's how you

get yourself known and recognized for

the problems that you're solving lastly

the impact does it have high impact and

impact is really measured if it's a

problem for people outside your company

so you can think of the customers or the

people who don't work on your projects

but you're still helping them out for

some reason that's how you measure

impact of what you're doing so you want

to hit work that hits all three words

low effort high impact and high

visibility but the one thing I'm going

to warn you about is that a lot of these

opportunities is being noticed by other

people too if this work has high visib

ability it means other people are

affected by it and other people notice

it and other people will be willing to

solve it and I hate office politics and

it feels really weird to be competing

for good work between your co-workers

but if you want a strategy that works

for you it's to write the first page or

a proposal on how to solve this problem

or even what this problem is just so

people will know that this work is yours

and you've claimed it and you're working

on it if you do that no one else is

going to be looking into it and they all

trust that you're going to follow

through and fix this problem

if you do this no one else is going to

compete with you and everyone will trust

that you're going to finish this through

man it can get really wild out there at

some of these tech companies but the

truth is that no one is going to

advocate for you unless you advocate for

yourself a while ago I was complaining

about this to another senior engineer

and he sells me a five-step process so

first you have to understand the hell

out of your system let everyone know you

understand the hell out of your system

make an awesome contribution to your

system and let everyone know you made an

awesome contribution to your system and

then you

profit I don't like this any better than

you do but this is just how it is if you

spend a ton of hours working on

something you have to let other people

know why it matters and why it's

important people need to recognize the

work that you're doing and to some

people it feels like bragging but I'm

going to tell you that it's not you're

making yourself known as a subject

matter expert so letting everyone know

about the work you're doing can get a

little tricky but the way that you can

get around this is knowing when people

are kind of gathered together one

example is like if you try to do this

during standup you know that those

little 15 minutes that you hate waking

up for you can actually just talk about

the impact of some of the work that you

had if there's some metrics or you

reduce latency you got to let everyone

know about it another way to do that is

in a group chat you can actually just

drop a dashboard or drop a link to

something that actually shows like the

awesome work that you've done so the

third way of doing it is something

that's a little scary for people but

it's definitely something that works and

I didn't learn this until I got to

Google it's that if you want to really

let people know you can actually send

people an email and just tag everyone

all the results and the work that you've

done to do it it's really rare to see

people do this and I get scared doing

this too but I think a lot of people

kind of appreciate the good news and

people really look forward to getting

emails from you if you actually want to

establish yourself like that you got to

get recognized for what you're doing at

the same time you have to help other

people get recognized too so I used to

have this really fixed mindset that I

wouldn't want to help people because

nobody helped me when I was struggling

other reasons why I wouldn't want to

help someone is that I'm doing my own

things I don't have time to help someone

and they should learn how to be

independent I think a lot about how much

I struggled and how there's going to be

a junior engineer that needs some help

and there's going to be a senior

engineer that can like kind of unblock

the way for them it's a lot like how

Naruto got support from everyone in the

village and how helping people is going

to help you too whatever the reason I

want to tell you about this book by Adam

grant called give and take which talks

about two schools of thoughts about

helping people on one side you have the

transactional side and the other side

you have the benevolent side so the

transactional side is like I'll do this

for you because I know you'll help me

out it's I scratch your back you scratch

my back and I I get it like that's kind

of like the transaction between helping

someone the other benevolent side is

that helping people is just a good thing

to do it's just helping someone out in

need and if it's not going out of your

way then you're helping a lot more

people by just taking a little bit of

time out of your day whatever the reason

is helping people is just a good thing

in general and it's going to help your

career the more often you do it because

we all know that asking people for help

is really scary so we have to make it

easier for them spend time with these

co-workers notice when people are

struggling get to know what they're

working on and if there's anything that

you've done that can help them out think

about something that you know that they

don't it's the entire reason I was

inspired to make this

video thanks for watching and I'll see

youall in the next one