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.