hey tech late here and welcome back to
another episode of the tech lead with
the tech leads coffee time we have an
interesting topic today it is about top
things that I wish junior engineers
would know
now for those of you who are new to the
channel I wanted to briefly introduce
myself I am an ex-googler lead which is
amazing absolutely magnificent
so good it's just something to keep in
mind as you're watching my videos why
should you listen to me where is my
authority coming from why do you need to
respect me simple I'm the tech lead and
that's something that you probably
couldn't say about anybody else that you
know not your dad not your mom
not your brother or sister or your
friends and if you can't say this about
somebody then you just need to keep in
mind that they're not necessarily the
tech leader i am the tech lead there can
be only one tech lead and that is me you
can confirm that by checking the user
name on my youtube channel it says tech
lead right there that confirms that i
have taken up that name and that's
really why you should listen to me
that's really the basis for my whole
entire youtube channel so without
further ado let's get into our sponsor
of the day daily coding problem doc comm
slash tech lee check them out they offer
you free coding interview whiteboard
questions male 2 straight every day you
can learn about data structures
algorithms hashmaps q stacks recursion
iteration all sorts of whiteboard and
clothing questions you can read up on
them and think about them throughout
your day studying them when you're bored
I'll be doing them too so check them out
daily coding problems comm slash tech
lead so let's get into the first tip
here we have a junior engineer his name
is Jake and he writes in that he's got a
Software Architect at work disagrees
with the way to software architect is
doing things he sees a way to solve the
past the problem they've been given in a
much simpler way and then meanwhile the
Software Architect left for three weeks
came back with 50,000 lines of code of
sequel code and said that we have to use
that as a framework and meanwhile Jake
just feels that there's just a much
simpler way of doing this thing and Jake
is just thinking that the software
architect is ridiculous now little does
Jake know but this r4 architect is
actually me that's right Jake I am on
your team
I am the software architect that you've
been complaining about I don't actually
look like this in real life I put on the
mask
that people don't actually know who I am
but Jake I know who you are I know
you're complaining about me at work I'm
going to make sure that you get what you
deserve okay so now let me just address
for you Jake what's going on the reason
that I went out and wrote 50,000 lines
of code okay is because Tec is not
necessarily about being right there are
a lot of things about computer science
but being right is not one of them if
you only cared about being right I
recommend that you go become a professor
and you can get into all the academics
about this but computer science
programming specifically is the
application of code and the application
the practical application is messy it's
dirty reality is ugly and there can be
many aspects beyond just being right
when I see somebody go out and write 50
thousand lines of over-engineered
garbage code you have to think about
what their motive is is it simply
because they're stupid is it simply
because you're just trying to over
engineer a bunch of stuff waste a bunch
of time no I don't think so
the reason they're doing this is such
that they can carve out an ownership
area for themselves for their team they
can show that project to management they
can show to everybody and Jake if you
can get on board with the Software
Architect
help that person build out this huge
project that person is already doing the
bulk of the work fifty thousand lines of
code already in there for you free and
you just go help out start building some
of this stuff out you can become part
time owners of just brand-new project
and it can lead to great things for you
and your team so that's the first thing
is that there can be many different
aspects and I might remind you that this
isn't necessarily simply about politics
although politics may play a big part at
work and you just need to keep that in
mind but there could be some very good
reasons for this for example one time I
was working in the company
I saw a far greater easier way to build
something I would just say hey let's
just take this component from
open-source let's just use that ship
this project we're done two days but
this person wanted to spend months
building on this project and I didn't
understand why this person would be
going around trying to do all this work
until later on I realized that there are
a lot of actual benefits real practical
benefits for example having ownership of
something could let you modify the code
more easily you could adapt that however
you wanted to you could really make it
flexible you can support your team your
certain technologies you can make it a
much bigger longer-term project and
stuff just solving one small short-term
goal finishing
shipping the product and moving on maybe
you could actually turn this into a much
bigger framework something that could be
useful and supported and used across
many different teams within your company
and if you have that long-term vision
then you may see that there's really
much more that may be doable sometimes
you don't want to be right it's a lot
like when you're driving and somebody
cuts you off if you continue driving
into this person yeah you're gonna be
right in the eyes of the law you'll be
right but you'll also be dead now the
second thing I want Eugene your
engineers to know is to pick your
battles and this also has to do with not
necessarily being right all the time
because if you take a look at this
junior engineer Jake here the
disagreement with a senior engineer and
what really happens is that these senior
engineers your colleagues they're going
to be the ones writing your peer reviews
and it's just not going to do you any
good if you start causing conflict with
people in your area the best way to
deliver criticism if you're going to do
it is to ask questions ask questions
such that people can think about the
problem think about how to answer that
if they can't find an answer maybe then
you would have shown them the problem
encourage them to the justice solution
and save some face instead of having you
just come in and point out that they're
wrong and embarrass them in front of
everybody the other thing is it's
actually going to be in your best
interest to get this senior engineer
promoted such that it makes space for
you of course if this person doesn't
deserve promotion then fine but it's
often going to be in your interest to
support your tech lead and this is why I
say a lot of people think that I'm
joking when I say that your job is to
support your tech lead but it's going to
be in your interest to just make sure
that the people around you your ho team
everybody is doing well getting promoted
you will rise as a team or you will sink
as a team and as you clear up space
above you then there's going to be more
space for you to grow sanzu in the art
of war he wrote that the supreme art of
war is to subdue your enemies without
fighting supreme excellence consists of
breaking the enemy's resistance without
fighting now tip number three is to
remember that nobody cares about the
details nobody actually reads the code
you're the only one who reads it and so
when you go around complaining that
there's some abstract abstract factory
factory coordinator manager and that is
causing the pixel padding to be off by
two points no one really understands
what you're talking about and no one
really cares it's just like just get it
done right I don't care just get it done
we just want to see this task done and
to be able to move forward and what you
need to do is bring your conversation up
a level such that people can actually
understand what you're talking about
what people care about are the top-line
metrics the product the code meanwhile
would be changing every day whenever I
go into meetings I always see the junior
engineers start diving really deep into
small little grungy details you know
these people they're really boring
everybody they're wasting a bunch of
time what you need to do is set the
proper expectations
instead of making excuses about some
factory factory manager tell people when
your projects being done why it's being
blocked what it's going to look like
just set those expectations and that's
really all anybody really cares about
tip number four is to stop fixing all
those bugs that I've been assigning you
the fact is that there are millions of
bugs and I just pick one or two and I
send them your way and then you suddenly
start thinking that they're so important
and you focus on them all the time and
you just keep talking about these
smaller bugs and yeah you can solve them
and that's great I'll just assign you
some more and there's just going to be
an infinite amount and your real goal is
not to focus so much on all these small
little bugs that you've been assigned
because it's not going to make a dent
and it doesn't really matter what you're
really ought to do is to take on
initiative to take ownership in an area
and by taking on ownership you can build
something that can help expand the
team's roles responsibilities such that
your team can grow get more budget hire
more people and make more impact
everything you do is really for this
broader role the task of solving a few
bugs here and there that's always going
to be there and people can always hire
another junior engineer to be doing that
you won't be looking a little bit
broader than that everything before you
can do that it's going to be training to
get you to that point the last and final
tip for you here is to take in some
feedback you want to get out of your
comfort zone when you're not comfortable
that is when you're learning we are in
difficult situations that you're not
familiar with when you're doing tasks
that you don't know if you can
accomplish or not when you're being
challenged that is when you are growing
and similarly feedback will always make
anybody uncomfortable because that is
when you start understanding where you
messed up where you could have improved
upon feedback is generally something
that you need somebody else to tell you
because when you look at yourself you
won't be able to see your own flaws you
don't know what you don't know which is
why you need a third party somebody
senior somebody like me that
lead to tell you what your flaws are
where you can improve and obtaining the
sort of feedback it's not necessarily
going to be that easy if you show that
you cannot accept the feedback if you
show that you're always challenging the
tech lead trying to come up against them
trying to disrupt their flow then
they're not going to really give you
honest good feedback they'll just say
yeah you're doing fine and you're going
to be left struggling over and over
because people are just not really
willing to provide you good honest
feedback because it doesn't seem like
you're willing and able to accept that
when you can show that you are willing
to learn willing to obey me
word for word I tell you to do something
and you do it then you are going to be
in a state in which you are ready to
accept feedback in which I can tell you
where you need to improve and then you
can go off and improve yourself my first
assignment for you is to subscribe to
this video give it a like and subscribe
okay so let's start with that and then
you will be well on your way to not
becoming a junior software engineer and
without though for me I hope you found
these tips useful if you didn't just
remember that I am the X Go Go tech lead
let me know your thoughts on junior
software engineers if you like the video
give it a like and subscribe I'll see
you next time bye