RailsConf 2014 - How to be a Better Junior Developer by Katherine Wu

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.