listen I'm currently a grad student at
the University of Michigan School of
Information but I'm also a software
developer and today I'm going to talk
about growing developers or how you can
help junior developers improve and
succeed so I got into development a
little bit by accident so when I first
started there was definitely a lot of
the fake it till you make it mentality
nowadays I like to think I mostly know
what I'm doing
so I'm going to talk about some things
that helped me get from point A to point
B but before that I'll talk a little bit
about my background so back when I was a
young undergrad college student I
actually thought I was going to become
an architect that clearly did not happen
I ended up also at the University of
Michigan doing a program called
informatics which was kind of this weird
hybrid thing I did some programming some
statistics but I was really most
interested in that bottom ring and I
thought I was going to go into user
experience research so about a year
after I graduated from undergrad I did
find a job at a company they were
building this new product and thought it
would be good to do some UX research on
it find out how they could make it
better so I moved to DC to start this
job about two weeks in they come back
and say actually what we really need to
work on is front-end development so I
quickly had to change gears and became a
front-end developer did that for about
six months to the point where I was you
know starting to feel comfortable with
what I was doing they come back to me
again and say well we really needed to
deal with back-end development so in the
span of six months I've kind of switched
from user experience to front-end
development to back-end development and
I've been doing that for the past four
years
so I'm going to talk about a few things
that you know have helped me through
that process so the first thing I would
say is creating a good environment um
when I started this job I was you know I
was just out of school and I definitely
was not experienced in development so it
was interesting to be joining a team
where everyone else had a lot more
experience than I did also in addition
to that I was one of two women on the
team and I was also about ten years
younger than everyone else so you know
when we were sitting into meetings it
was me and a bunch of middle-aged men
um but somehow despite that the team was
super welcoming and they made me feel
like I was just a part just as much a
part of the team as everyone else which
was super important also you know even
though I was newer and was maybe at
first working on some simpler tasks they
still made it clear that they valued my
contributions
you know I say still praise me for you
know even figuring out these smallest
things which was good and made me feel
good about my skills and they also made
an environment where I felt safe to take
risks and fail I know that if I had gone
into the office every day worrying about
you know what my co-workers were
thinking of me and worried that they
were going to be mad at me if I screw
something up I would not have performed
as well as I did so that was very
helpful I know like culture right now I
was kind of a big buzz word but really I
think it is super important and it can
lead to better results
so after that provides support so a
couple ways that I found that we're
helpful is code reviews so obviously one
of the purposes of code reviews is to
make sure that bad code is not getting
into production so from that perspective
it's a good way to you know correct
mistakes and learn from failures but I
also found that it was helpful when my
co-workers would point out any code
reviews if I wrote something that they
really liked so when I first started I
used Ruby on Rails when I first started
coding two of the things that I was
really really bad at was one I never
wrote test for my food I always forgot
to do that and I also put a lot of code
and a lot of logic in the views which
you really shouldn't do so at first when
I would do these things you know other
developers would comment on my code
saying hey like maybe move this out of
the view here's a better place to put
this code or hey I see that you forgot
to write tests can you maybe go back and
add those then on the flipside
when I actually started to you know
ingrain those mentalities and started to
do those things it was just as helpful
to see from them comments like oh this
is a really good method that you
included in this model like this is a
good place to put that or for them to
say I really like this test and you know
it's a very drop of testing that the
code that you wrote and it can be you
know as simple as just putting a
thumbs-up on something you know even
last week I was writing some code and I
added tests and one of the other deaths
put a thumbs-up
you know it's been four years and I
still appreciate it
I think that a lot of times we think of
code reviews as more individual feedback
I'm someone giving feedback just on
something that I wrote and how I can
improve it but another thing that I
found helpful was when one of the other
junior developers did something that
someone thought other people could learn
from they would take that and they would
share it out with everyone else you know
they wouldn't just give individual
feedback to one person and have only
them improve they would take that and
kind of you know get all of us together
and say hey you know this person did
this and they're you know X Y Z is a
better implementation so here's just
something that you guys can all think
about in the future so that was really
helpful
another thing is pair programming the
way that I kind of learned Ruby was I
got thrown into it so I was figuring a
lot of stuff out as I went which is kind
of how I learned best
so I was just plugging away at tickets
almost right away but was really helpful
was when I did get to a point where I
got stuck or stackoverflow couldn't help
me pairing with another one of the
senior developers even if we didn't
finish the ticket together just having
someone to bounce ideas off of or maybe
see where certain files were in our code
based or how things were organized that
was a great resource that kind of helped
me build confidence and learn how to
problem solve from people who had a lot
more experience than I did
and then another thing is to acknowledge
achievements this kind of goes back to
what I was talking about with the code
reviews when someone does something good
I acknowledge them for that it helps
build their confidence and then makes
them you know maybe form better helps
them remember that hey this is a good
thing that I want to do again and
finally mentorship so this is something
that I actually wish I had seen a little
bit more of in my current job you know
coming into the tech world without
having really planned on it you know
it's this whole big community that I you
know had no idea what is out there I had
no plan of like where I wanted to go in
five years ten years and I think it
would have been really beneficial to
have you know someone that was dedicated
to helping me figure that out a little
bit more just that I could get more
involved not only in the work space but
outside of it
and then finally monitoring progress and
goals um so talking about goals more
than once a year I know that this is
something that often comes up like in an
annual performance review you know
talking about what you've accomplished
that year as well as what you want to
accomplish the next year there have been
a lot of times where you know I've
talked about this and then you know two
weeks later you forget about it and you
don't remember again until the next
performance review when you think oh
yeah I wanted to get this done and I
totally forgot about it so talk about
goals keep them in mind so that you can
actually work towards them and I think a
part of that is identifying concrete
ways that you can go about meeting them
you know not just having a broad idea
like you know wanting to get better at
coding or wanting to learn a new skill
identifying specific and actionable ways
that you can go about doing that whether
it's you know going to a conference or
you know working with a certain person
on your team who maybe has those skills
that you want to develop just figuring
out how exactly you're gonna go about
meeting those goals and then finally
just providing the time or funding to
help do that I know a lot of times we
get busy at work so this is kind of one
of the first things that kind of is on
the chopping block
it's like oh you know this would be
great I want to learn this new skill but
I just don't have time so making sure
that you actually provide this space so
that you can go through and meet your
goals
sorry that went a little bit faster than
I thought
um but that is mostly what I had so I
don't know if anyone has any questions
I'd like to argue as you
okay I think the lowest priority and
it's keeping bad code out and it really
is about feedback means your first camp
overview for me it felt like I was
standing making my entire team and they
were ready to point out everything
that's we're going but you know if it's
done well I mean those things you talked
about are what happens writing that you
okay to get the pointers of they go to
that tests all right I'll go do it and
will you do something well it goes out
to the team and a lot of times if you
participated in them you're learning
from what you're seeing up there and
you're learning from what when this
person says oh right that definitely go
ahead as ice you go by my testitude and
they really are feedback Matthew
mechanism more than kind of harsh you're
gonna put bad code into our system fair
enough
but even a code reviews on somebody that
senior putting their code out there so
that the trigger people can say hey why
did you do that that way or could it be
done this way and you say well it could
but it's better this way because of this
so you get more of an understanding of
the phone yes it sucks allies or more
important was
[Music]
and you have say mentioned mentorship
did you have a mentor and I think what
did that look like or what do you think
a mentorship should look like like what
are the activities they could be home
sure I guess in a way I kind of think of
most of my co-workers as mentors just
because they have a lot more experience
than I do
but I kind of wish that I had had a more
you know formalized relationship just
have someone that is there to like
proactively check in kind of a problem
that I was facing when I was just
getting started was that a lot of times
I would be like afraid to ask too many
questions or afraid so you know bother
people that are working on other tasks
because I didn't want to pull them away
from you know what in my mind is some
super important thing that they're
working on so I think it would have been
nice to have someone that was you know
there to kind of be more proactive about
checking in with me as well and just to
have someone to continue to build that
relationship and that comfort with to
know that I could go to them if I had
any problems or you know wanted support
or wanted to learn more about a certain
aspect
just thinking we helpful to have what
does a grieving time have a certain
frequency detective yeah I think it
probably depends a lot on the individual
and it's maybe something that would
happen more frequently when you're just
starting out but can you know be more
sporadic once you kind of get a little
bit more comfortable but you know maybe
starting with something weekly and then
moving out to bi-weekly or monthly
[Music]
you
um I guess for me specifically my
manager has usually been a p.m. so they
weren't necessarily in the same role as
I was so those kind of check-ins tended
to focus more about like the work and
they didn't necessarily understand as
much of like the day-to-day tasks that I
was doing
[Music]
if