KATHERINE WU: OK. Cool. I'll guess I'll go
ahead and get
started, then.
Hi. And, thank you all so much for coming
to my talk here. I'm K Wu, and I
started at New Relic just about eight months
ago.
And it's my first developer job there. And
for
my talk today, I'm going to first give a
bit more context around where I'm coming from
and
my intentions for this talk.
I'll then dive into what I see as the
main challenges for being a junior developer,
and I'll
talk about my tactics for how to overcome
these
challenges.
There is a lot that I want to cover,
but if you're taking notes and happen to miss
something, I have written a post for the New
Relic blog that went up this morning that
you
can reference. And I also have a link to
my slides at the end.
So. How many people here are junior developers?
OK.
Awesome. Cool. And how many people did something
else
professionally before they worked as developers?
Nice. OK. So
we are like amongst our own people here, right.
Very cool.
For me, being a developer is probably, like,
the
fourth or fifth career I've had at this point.
It's hard to keep track. Some of the other
jobs I've had in the past are things like
product specialist, tech support. I used to
work in
a biology research lab and I also did some
copy editing on the side.
So the thing is, compared to people who have
been coding since they were kids, I am literally
decades behind. This makes me just feel like
I
have so much to catch up on. However, something
I've realized is that being a developer is
essentially
about constantly learning new things. And
guess what? I'm
pretty good at that. I'm really practiced
at it
with picking up a new career and starting
over
and over again. And so, despite what my parents
think, I like to think that my previous lack
of direction is now an asset.
The other thing I've realized over the last
few
months is that a lot of it can actually
have nothing to do with coding. If you spent
a lot of time doing something besides computer
science,
that means you have more experience for all
of
the non-coding portions, and that means you
can leverage
those skills from that experience to help
your team
while you get better at the technical aspects.
My thesis is that, just because you switch
careers
doesn't mean you're starting over entirely.
And, in fact,
you can still use those other skills that
you
have. You may already know the different tactics
I'll
be talking about today, so I hope I can
prompt you to consider new angles and get
excited
to apply them as a junior developer.
There will be sections that are actually more
targeted
towards mentors, but, if you have a mentor
but
he or she doesn't happen to be here today,
maybe you can bring some of these ideas back
to them and discuss it.
For senior, any senior developers that might
be in
the audience, I hope to help you remember
what
it feels like to be on that junior side
of the mentoring relationship, and think about
ways that
you can help your proteges feel valued in
a
very concrete kind of way.
I think there are two big reasons for why
it's hard to be a junior developer. First,
there's
a ridiculous amount to learn. How many people
feel
like that? Yeah. Like, pretty much everyone
here. Cool.
Second, I think it's also really hard to know
how you can help your team and not just
feel like this helpless little baby bird here.
I'll talk a little bit about these challenges
and
how to handle each of them in turn.
My three step, fool-proof plan to tackling
the fact
that there's a ridiculous amount to learn,
is really
all about not trying to do it all just
on your own.
Getting people to want to help you in the
first place can be a little bit of a
hurdle sometimes, depending on how supportive
an environment you
happen to be in. I've been really lucky at
New Relic. But I think there are always things
that you can do even if you feel a
bit more isolated.
People, fundamentally, just aren't all that
different wherever you
go. A lot of this boils down to so-called
building relationships. But I prefer to think
about it
as really just getting to know people and
making
friends. Because, of course, friendship is
magic.
I personally find this pretty hard, because
I'm actually
a pretty strong introvert. I fully expect
to spend
most of tonight, like, huddled in a ball,
like,
trying to recover from today. But, you know,
the
thing is, a lot of developers, by and large,
are also pretty introverted as well. And so
sometimes
it can be hard to try to get the
conversation going. You know, even if you,
you know,
both really want to connect.
Luckily, at my last job, I worked with PM
and engineering and came up with a few hacks.
What I do is I try and pay attention
to, to try to remember small details that
people
have told me. Especially about their lives
outside of
work. Sometimes it's actually even easier
for me to
remember these details than peoples' names.
But usually people
are pretty forgiving once I tell them, I do
actually remember talking to them for like
two hours
about their love for, like, antique banjo
collecting or
something like that.
This makes for much better conversations than
your typical
small talk. Another really dorky thing that
I do,
is that I actually sometimes mentally prepare
stories to
get a conversation going. Like, right after
a weekend,
I'll try to think of something interesting
or odd
that I did, so that I'll have a non-generic
answer ready for when someone asks, how was
your
weekend?
Otherwise I just kind of freeze up and just
say, oh, good, which is kind of a boring
answer and doesn't really get conversations
started. Does anybody
else have that knee-jerk reaction sometimes?
Yeah. Totally.
Well, with a story to tell, what I find
is that this can then prompt questions and
get
some back and forth started, which breaks
through any
awkwardness there might be.
Helping break through awkwardness is also
something that mentors
can do a lot to help with. Mentors are
really great for guiding newbies around team
culture and
history. They can help make introductions
and give advice
on how to approach other people. Like, what
the
two of you may have in common, or who's
a good person to ask about what.
Also, I think that if your company has a
support team, you should definitely make some
good friends
there. Support tends to be a little bit chronically
undervalued, but they probably know way more
about the
products than you do. And if you think about
it, they're very practised at explaining the
product to
newbies like your fellow customers.
When I worked in tech support, sometimes they
would
have engineers shadow us so that engineers
could learn
how the customers actually used our product,
and use
it to inform design decisions that they might
have.
And I definitely always really preferred the
engineers that
were really eager to learn from me.
Another key component to getting people to
want to
help you is to demonstrate the time that they're
taking. And so that you took a reasonable
amount
of time to get as far as you could
on your own. Each time someone helps you,
you'll
be able to learn new tactics and push yourself
just a little bit further before the next
time
you have to ask a question again.
When you do ask for help, you can also
ask questions like, if you're busy, who else
could
I talk to about this? When someone does help
you, you can always end with asking something
like,
is there somewhere I could have found this
answer
on my own? And if the answer is no
and there isn't any good reason it doesn't
exist
already, you should add it.
When you do have someone's time, try and think
of ways to sort of push out and extend
what you're learning from them at that point
in
time. That way, you'll be equipped when a
variation
of that same question comes up again.
Lastly, for getting people to want to help
you,
something just as simple as showing your appreciation
really
goes a long way. Great mentors and teachers
would,
of course, probably do it regardless, but
I just
think it never hurts to make people feel extra
good about doing something that helps you.
Making sure
to notice when people have gone out of their
way to help you encourages more of that to
happen.
If you're working somewhere that's big enough,
where not
everyone knows what everyone else is doing,
you can
also do things like, let peoples' managers
know when
they've been particularly helpful. Most managers
like hearing good
things about their reports, and most people
like their
managers to now the good things they've done
for
the team. So it's just a nice thing to
do all around. We've covered step one now
of
getting people to want to help you.
Step two is make it easy for them to
help. Help them help you. There are a few
different ways you can do this. I think actually
that one of the hardest parts to learning
is
just letting people see inside your head and
understand
where you're at right now. But this can be
really hard in a field like programming, where
sometimes
you might not even have the vocabulary to
express
what it is that you don't understand because
you
don't understand it.
Great teachers can draw it out from you, even
when you're asking pretty vague questions.
But most people
that you work with probably aren't highly
trained teachers.
So there are ways that you can make it
easier for others to help you by articulating
the
premises that you're working off of and the
logic
that you're using, so that together, you can
narrow
down what it is that you don't understand
or
are missing.
You can say things like, you had me up
until such and such a point, or I'm confused,
because I thought you said this and then this,
but it doesn't seem to lead to this point.
This is a good general format for describing
problems
that you might have. Say what you're trying
to
do and why, so that someone can jump in
if that's not even actually the right goal
to
be aiming for in the first place.
Also, describe your current problem and what
you've tried
already. Sometimes people might jump in quickly
with their
idea of what the answer to your question is
already, but I think it's still good to be
prepared regardless. And if you're a mentor,
just consider
that you should check to make sure that you
understand the question before you go ahead
and answer
it.
When I worked in tech support, the best clients
actually put all of this information up front
in
their ticket, which saved us a ton of time
on the back and forth from just trying to
even figure out what the question was.
Remember that just having the courage to say
I
don't know is a strength. Exposing your own
ignorance
feels really scary. So I'm always practicing
actually saying
things like, wait, I don't even know what
that
words means. I say this all the time.
But if it's something that's vital to understanding
what
people are talking about, the sooner I tell
people
I don't actually know what's going on, the
sooner
I can get to actually learning and working.
Of all the advice I got when I started
at New Relic, this one is my very favorite.
One of the best things that mentors can do
when junior developers are confused is even
just validating
that feeling. Being honest, and saying, this
is confusing
for me too. It always, without fail, makes
me
feel better when someone I expect to know
the
answer actually says they don't know it either.
And then it becomes this team effort to figure
out how to get out of this hole of
ignorance together. It's also cool because
when you work
with someone that also doesn't know the answer,
you'll
frequently learn new debugging techniques
that you can apply
yourself next time.
Now, I want you to think back to the
last few times you asked someone for help.
OK.
How many of you, after you got help from
someone, heard something from them that was
like, did
that help? A few people. Yeah. I get this
all the time. And I realized that this is
because most of us are really needy and want
validation. That's because, and so, my favorite
feedback that
I get from people is usually people telling
me
that they actually used any advice that I
gave
them.
So when you tell people specifically what
it is
they did that helped you, they'll know what
they
can do more of. For example, it really helped
me when you walked me through how to use
these tools with this example. Or, it really
helps
me to be the driver when we pair program,
because I absorb more than when I'm just shadowing.
One way of looking at mentoring relationships
that I
really like is from the book club that we
had at New Relic when I first started called
Managers as Mentors. The idea there is that
mentoring
should not be about this traditional mindset
of a
one-way transmission of information. And instead,
it's the mentor's
responsibility to create a safe environment
and remove any
barriers to learning, so that their mentees
can speak
up about any fears they might have, and not
be afraid of failing.
This way, they can learn a lot more and
a lot faster.
I know, for me, making the move from just
working on my own projects that no one was
depending on to working on something that
actual people
were paying us actual money for was pretty
terrifying.
Sure, we have this idea of failing fast, but
it's so hard to apply it when you don't
feel secure.
What helped me was all the support that I
got from mentors sharing their stories about
how they'd
messed things up, too, and the idea that it's
not a matter of if you break production, but
when.
And when you do make mistakes, your team should
have processes set up in place to make it
easy to recover quickly and ways to try to
prevent that same mistake from happening again.
If none
of these processes exist already, you should
try to
help establish them. Because if just one person
can
ruin everything, that's a pretty big problem
for the
entire team.
Something I'm a really big fan of, as well,
is just having a direct conversation up front
about
someone's learning style along with the other
person's teaching
style. This way you can try to sync them
up and talk through any mismatches ahead of
time
before there's any conflict. It's great when
mentors show
that they're open to feedback along the way
as
well, so that they can continue iterating
and adapting
their style to match whatever will help the
junior
learn best.
It's also really important to talk about how
you
prefer to be interrupted. My mentor at New
Relic,
David, told me that I could interrupt him
pretty
much any time. And because he was really clear
and direct with me when he couldn't help me
right then, and still always gave me some
other
resource to try, I had that much more confidence
in it being OK to interrupt rather than bottling
it all up and just saving it for our
designated weekly meetings.
When I started, David's desk was right next
to
mine, so that even when I was talking to
other people, he could sort of lightly listen
in
and jump in whenever it was clear to him
that I was missing something fundamental.
As my mentor,
he had a better overall understanding of where
my
knowledge level was at, so he could help others
help me, too.
If, as a mentor, part of your philosophy is
to let people struggle, this is also something
that's
good to make clear up front. It's really good
to talk about this, because that way, you
can
let the juniors know that you are intentionally
doing
this. And it is out of a faith in
them, rather than setting them up to fail
or
having misplaced expectations.
Just being reminded that you expect this to
be
hard goes really far towards dispelling any
sense of
impostor syndrome, where you might have this
sinking feeling
that it should be easier. But that's wrong.
It's
supposed to be hard.
Finally, I think it's ideal if you can push
up responsibility for deadlines. The junior
developer's job is
to keep everyone up to date so that no
one is surprised by how much work is left
to do. On one project, a couple months ago,
when I was freaking out because I felt like
it was taking me forever to learn even just
the basics of D3, one of our project managers
came to me and said that shuffling resources
is
his job, so that I could go back to
learning and struggling. And if at any point
the
project deadline was in danger, the burden
wasn't entirely
on my shoulders.
Now we have covered these first two steps.
We are just a little bit halfway through.
So
I just want to take a real quick break.
Humor me. If you could all just sort of
sit forward in your chairs a little bit. Thank
you. And go ahead and just put your arms
behind your back like this. And just try to
stretch and pull your shoulders down and back
a
little bit. Just try to counteract a little
bit
of the terrible posture a lot of us probably
have over a hunched over computer. OK. Cool.
Feels better. I do this a lot when we
do stand ups actually, because it's like a
good
time as any to stretch and be slightly more
ergonomic.
All right. Back to where we were.
The final step in tackling how much there
is
to learn is much like how you'd approach any
other gnarly technical problem. Narrow your
scope. Mentors are
highly helpful here, too, because they can
help prioritize
what to learn next.
For example, one of my things is that I
still actually need to build a Rails app from
the beginning. Know that it's important to
deliver recommendations
at the right time. If a mentor gets really
excited about yet another new thing to add
to
the junior developer's plate and just sort
of blurts
it out right then, this can sometimes be taken
a little bit like, wow, it must be really
important to be told right away that I need
to know this. Maybe I should know this already?
Which at least, for me, can sometimes lead
to
a little bit of a death spiral of self-doubt.
You also have to match up learning style with
the tutorial style. This is important, because
a lot
of programming tutorials, well, they're kind
of like this.
How to draw an owl. Step one, draw some
circles. Step two, draw the rest of the owl.
How many people have done tutorials that are
like
this? Yeah.
Well, even on more detailed tutorials, there
are differences,
like whether the work is goal-oriented or
not. For
me, it's actually harder to stay motivated
when I
don't have a specific thing that I'm trying
to
accomplish. I like structure and being too
free-form actually
means that I'll get bored. For example, I
took
calculus in high school. And it was fun and
interesting.
But it wasn't until I took physics in college
that I was like, oh, that's what calculus
was
invented for. But that's just me. And other
people
might be similar or very different.
Also, in terms of content, my personal view
is
that the highest value areas are things like
team
processes for code review and version control
like git.
And specific product, product knowledge over
more generalized programming
knowledge.
This might be a bit controversial, but I think
less useful are actually things like getting
too much
into optimizing your tools and environment.
Or even learning
tons of keyboard short cuts. At least to start.
Keyboard short cuts are fun and useful, but
let's
be honest. Right now, how fast I can type
is not the limiting factor in how fast I
can complete a feature.
So that wraps up my ideas for how to
tackle this first challenge of how there's
so much
to learn as a junior developer. Next, I'll
talk
about ways that even junior developers can
help their
team immediately.
Knowing how to help your team is hard because
maybe you feel like you're a drag on your
team's productivity with how much help you
need right
then. How many people have felt like this?
Well, in one of the first conversations that
David
and I had, I actually pretty much just straight
up asked him, how did you get stuck with
me? To his and New Relic's everlasting credit,
he
immediately reassured me that it wasn't that
he got
stuck with me, but that he wanted to learn
to be a good mentor himself. So it was
from there that I realized, ah, even my ignorance
can be helpful for the team when it gives
them opportunities to practice things like
mentoring.
Also, even if you are a junior developer,
your
technical contributions are still important.
Yes, you may be
working on features that someone else may
make faster,
but in a world where there is never enough
junior developers for all of the, you know,
or
just developers in general, for all the developer
jobs
that are out there, it's not actually necessarily
a
choice between a junior developer building
it slowly and
a senior developer building it really quickly.
It's a
choice between having something built and
not having it
at all.
Don't forget, either, that everyone started
out at your
point at some, at some point, and you won't
be at your current stage forever. As my southern
friend likes to drawl, no one comes out of
their mama's womb knowing how to code. Just
think
about that for a minute.
So onwards to some of the other non-technical
ways
you can help your team right away. First,
I
really strongly believe that questions are
basically the junior
developer's super power, and as we all know,
with
great power comes great responsibility. Fresh
eyes are helpful,
but you can specifically figure out how to
be
an extra helpful set of fresh eyes with the
use of skillful questions.
Good questions are invaluable for highlighting
assumptions and helping
the team avoid dead ends, which helps you
all
move faster. Questions like, are we working
on the
right thing? Or, is there a reason we're doing
it this way? This is something that came up
in my old job, too. Because sometimes this
uncovered
an actual misunderstanding about a feature's
requirements, where, like
an offhand comment from a comment email, got
interpreted
as a must-have item.
Getting rid of these kinds of things saves
everyone
a lot of time and disappointment.
Has anyone here ever worked as a consultant
or
product manager at all? So you probably have
similar
stories like that, too. Of course, you do
want
to ask your questions in a way that won't
put people on the defensive. If someone hisses
at
you, that's probably not a good sign.
Try to express humility, since you're asking
these questions
from a place where it's because you want to
learn rather than assuming that you already
know. You
can also think about questions that other
non-engineering people
might ask, like your sales or support teams.
Getting
these answers earlier on gives your team a
jump
start on looping in other teams as needed.
And if the only answers your team has are
pretty vague, that's an opportunity to dig
further for
greater clarity. OK. We're two thirds of the
way
through the outline now.
On the other side from asking questions, providing
constructive
feedback is really important, too. If you've
had another
career before now, this is a skill that I
am sure you have already practiced. Giving
useful feedback
to the right person in the right venue at
the right time is hard for a lot of
people.
For me, when I worked in tech support, we'd
frequently do quality reviews of each others
work to
try to improve the customer support experience.
And we'd
also just do general peer feedback every few
quarters.
Which meant that I got a lot of practice
at phrasing feedback in a way that wouldn't
lose
me any friends, hopefully.
Before offering feedback, I like to spend
some time
thinking about what would be useful to the
person
receiving the feedback. What is it that they
want?
What are they trying to do? You always also
get bonus points for bringing suggestions
for solutions with
you.
It's hard, sometimes, to refrain from nitpicking
just for
the sake of having something to say, but it's
worth it to increase the value that people
get
from listening to you. You just want to have
a really high personal ratio of useful to
not-useful
things to say.
Something else I've been trying lately is
to give
positive feedback whenever there is an opportunity.
I don't
mean, like, fake positive compliments or anything
like that
at all. But just that it's a lot easier
in most cases to complain about something
than to
remember to speak up when there are good things
to talk about.
My hope is that this is helpful in the
longer term, so that I can build up a
general reputation for being a positive person.
And any
negative feedback I have will be taken more
seriously.
On the other hand, sometimes giving good feedback
can
also mean just stating, I don't have an opinion
on this topic, so that you withdraw yourself
from
the pool of people weighing in. It makes life
a lot easier for whoever's in charge of getting
the group to a consensus.
So now we've covered two strategies for helping
your
team. Lastly, there's a lot you can do to
make your team look good to other teams. It
isn't all that hard. It helps your team feel
good and it helps other teams feel good, too,
about working with your team. One of the common
areas this can come up in is in any
demo or review team, meetings your team might
have.
You can give awesome demos just by being thoughtful
and prepared.
Think about why this change matters to your
audience.
Why should they care? And think about how
you
can show the before and after, doing things
like
grabbing screen shots, so you can show new
and
old side by side. Or gathering metrics to
show
why the thing that your team did is actually
a big deal.
Demos are also good for getting full credit
for
your team, for everything that they've done.
Even ones
that aren't easily visible. You can do things
like
talk about corner cases and, you know, choices
that
you either decided to do something about right
now
or have consciously chosen to delay, so that
it
shows other teams, shows these other teams
that you've
been thoughtful about your impact to them,
like the
supportability of a new feature you've released.
I like to over prepare. So I almost always
write a script, which is sometimes a literal
word-for-word
script. But more often, it's just a list of
what I want to show in a particular order
so that it flows well and I don't end
up having to backtrack because I've forgotten
something.
I also like to do a test run through,
so that this way, I'll know everything I need
to get preloaded onto my computer, which makes
the
demo really efficient and less prone to errors.
In general, making an effort to be responsive,
thorough,
and empathetic really goes a long way. I'm
really
proud of the time that someone on our support
team at New Relic told me I was her
favorite engineer to work with, mostly just
because I
was being really responsive. All this just
helps people
feel heard, and knock down any stereotypes
that engineers
don't care about what other people care about.
And
so this way, when your team needs their help,
they'll be there for you too.
That wraps up my ideas for how to tackle
the challenge of figuring out how you can
help
your team even when you're a junior developer.
Before I finish up my talk, I do want
to mention a few caveats and pitfalls to avoid.
I'm hoping that mentors, in particular, will
help out
with watching out for these.
Sometimes, I think there's a bit of an issue
in the tech community of undervaluing non-technical
skills, and
a lot of what I've talked about is essentially
using your non-technical skills to help yourself
move forward.
The thing is, you just don't want to be
assumed to just be the secretary, which I
don't
mean as a diss on secretaries at all. It's
just not the job that I'm working towards.
There's also a phenomenon called the Girl
Scout tax,
which comes about because we have a stereotype
and
expectation that women are helpful. Unfortunately,
this leads to
a lot of women not getting credit for the
help that they provide, because supposedly,
that's just what
women do. They're helpful. This is just one
of
those unconscious things that we probably
all do from
time to time, and so we should all try
to watch out for it so that everyone gets
recognized and appreciated for the work that
they do.
You just don't want to get sidelined or pushed
into a role you're not interested in. Everything
I've
talked about today is from the stand point
that
you're willing to do whatever's best for your
team
in the short term, but you all need to
be doing what's best for everyone longer term
as
well, which is to help you grow as a
developer.
Ultimately, keep focused on whatever your
end goal is.
Whether that's getting better at coding, working
on bigger
features, or learning about the market and
industry. This
way you can consciously choose what things
you'll do
that will bring you closer to the goal, and
not do things that will move you further away
from it.
These are some recommendations for further
reading. The first
two are books that are actually pretty quick
and
easy reads. Teen Geek was written by a couple
of Google engineering managers who actually
co-founded the Google's
engineering office here in Chicago. And that
second book,
the Upside of Down is a good book if
you feel like you're being held back by a
fear of failure.
The other four are blog posts that I also
found really interesting and full of good
career advice
for junior developers.
So here's the full outline of everything I've
talked
about today. I think there are two main challenges
in being a junior developer. For the problem
of
there being so much to learn, the three step
plan is to get people to want to help
you, make it easy for them to help, and
narrow the scope of what you're trying to
cover.
For the problem of not knowing how to help
your team, always remember that good questions
are the
junior developer's super power. You can also
do a
lot by giving good feedback and making your
team
look good in front of other teams.
In conclusion, we talk a lot about the benefits
of diversity, but if you're the one that's
bringing
diversity to your team, that can be hard,
because
the typical narrative won't use your particular
strength set
much, because by definition, they're different.
As my first
boss told me, we can and should work on
our areas for development. But it's really
your strengths
that you can lean on most heavily to get
you where you want to go.
So to all the junior developers and career
searchers
out there, I just want to say, you deserve
to feel confidence in yourself as a person.
Place
your confidence in your proven ability to
learn over
your current level of coding knowledge. It's
only a
matter of time, and I hope I've helped you
shorten that amount of time as a junior developer,
and so someday, when you'll be mentoring junior
developers
yourself.
Thank you.