4 Years of Software Engineering advice in 14 minutes
Summary
TLDRIn 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
π€ 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.
π 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.
π€ 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.
Mindmap
Keywords
π‘Software Engineer
π‘Promotion
π‘Naruto
π‘Code Promotion Fallacy
π‘Visibility
π‘Responsibility
π‘Help
π‘Proficiency
π‘Documentation
π‘Leverage Work
π‘Advocacy
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
5.0 / 5 (0 votes)