There are far more open jobs for developers than there are people to fill them. So what is the solution? Here are some strategies for shaping a junior developer into an effective, contributing team member.

1. The Care and Keeping of Your
Junior Developer
Bonnie Mattson @BonMatts

2. Why Junior Developers
- Aren’t enough senior developers
- Hiring picasso to paint your apartment
- Senior developers tend to be set in their ways
- With talented management, and good process, junior
developers can fill some of the talent void

3. Junior Developers are great!
“Helping grow someone into a fully functioning member of
the team makes our team stronger in the long run, and
helps us pass along good process and behavior practice
into the organization.”

4. Overview
1. Survey
2. Positive Company Culture
3. Mentorship/Guidance
4. Clear Expectations
5. Advice for Junior developers

5. Survey Demographics
Gender Identity
women 63%
men 29%
genderqueer 4%
no answer 4%
Experience
< year 22%
1-5 years 40%
10 years 19%
>10 years 19%
Job Level
junior 31%
mid 41%
senior 24%
other 4%

6. You are going to fail.

7. Do you get imposter syndrome?
“Often. Writing about whatever I was doing, and having
other developers bring it up later was a great confidence
boost”
“I finally became comfortable calling myself a software engineer
around the time I became a team lead. Until then it just seemed
too rarified a title for me. Recognizing (or probably more so,
others expressing) how advanced my skills were compared to my
colleagues.”
“Constantly. I started programming late in life compared to most,
and even once I get good at it, I'm not sure it's possible to get fully
caught up with someone who is my age or younger with 5 or more
years of experience on me, or even someone with the same
length of experience who has had the luxury of more learning
time.”
“ [It was frustrating] not knowing if difficulties were because
I didn't understand something or because it was not well
designed, broken, etc.”

8. Positive Company Culture
Combating Imposter syndrome!
- Overall Positive environment
- Diversity
- A culture of sharing knowledge

9. Don’t be this cat.
“[I found it frustrating] when I wouldn't get
something and a team member would say things
like "How are you not getting this?" and becoming
clearly frustrated when I wasn't getting something
right away. This was so discouraging.”
“ [When I had questions, I ] struggled, asked
the internet. Asked senior team members as
a last resort, knowing that the response I'd
get would be rude and condescending.“
“ [When I had questions ] I asked people.
Or, I hid in the stairwell because I was
afraid to ask them, because they clearly
didn't want to be asked. I hid in the
stairwell a lot.”

10. - No Feigning Surprise
- No well-actually's
- No back-seat driving
- No subtle -isms
Hacker School Code of Conduct
https://www.hackerschool.com/manual

11. Culture and Communication
“ [I got over my imposter syndrome through] transparency and
feedback. It's scary and vulnerable to open yourself up, and it
is up to the senior developers and managers to lead by
example and create social norms where it is safe to do so, but
there is no way to get a sense of how well you are doing
relative to others without both of you working out in the open.”
“The most valuable-for-my-career class I took in college was actually a
poetry class, where I learned to think very carefully and systematically
about word choice, metaphor and creative collaborations. “
“ [I found it helpful to ] Just watch people program . . . it helps
make it clear what things are ‘normal’.”
“Communication is far more important than technology skill.
Flat or no hierarchy means it is implicit.”
“ I am lucky though because I have a great co-worker
who is always available to answer anything for me.
Knowing that I have that is very empowering.”

12. Diversity
A comfortable developer is quicker to adapt,
and consequently more productive.

13. Culture of Knowledge
- Project Presentations
- Education Budget
- Company Library
- Experienced programmers given time to share
their knowledge

14. Mentorship/Guidance
- Direct mentorship
- Positive feedback
- Documentation
- Pairing/ Code reviews

15. What makes a good mentor?
“I've not had any good [mentors]. Some were not available enough.
Some assumed that because they were senior they had nothing to
learn from juniors.“
“ [a good mentor is] someone willing to listen and take time
to explain, even if they've got their own deadlines to fight.
I've learned the most from sitting with some of the brightest
people at the company to figure out a problem, and would
consider them an excellent mentor.”
“A good [senior developer] is one who sets a good example by
consistently doing good work and writing good code and do
helpful code reviews.”
“Explaining why a certain approach works. Passion for coding.
Helping think about a problem or approach.”
“I rarely had someone knowledgeable to ask questions. I
had to figure most things out on my own. I would have loved
to have a more senior, knowledgeable person to learn
from.”
“A lack of ego, patience and the ability to trouble-shoot *why* a
junior developer is having a particular problem and address the
underlying problem (ideally while teaching the developer the skills to
do that for themselves in the future.) It's all about that extra step that
the junior developers might not know they should be taking.”

16. Senior Devs = College Professors
Teaching is part of the Job.

17. Time Management
One cannot mentor while also maintaining a full
workload of a senior dev. Productivity will
decrease.

18. Positive Feedback Chart
Positive
Negative
Specific General
It was really smart how
you made that method a
helper and re-used it in
other parts of the code.
That was really DRY!
Nice job!
Looks Good!
Your code looks
really bad.
That was terrible.
This code does not
follow the style guide
for these specific
reasons. Might I
suggest these
revisions?

19. Positive Feedback
Compliment sandwich!
“Thank you for reporting that bug! It would be helpful
if you could let us know which version of the code you
found it in. The detail you did provide on recreating
the bug was excellent!”

20. Thoughts on Feedback
“Having the right manager is really key. My original manager was
great with former interns, but I had another manager come on
and he hadn't worked with programmers as inexperienced as I
was. At some point he gave me feedback, and while I'm usually
super fond of feedback, he gave it in a subpar manner, made me
stress out thinking I was going to get fired. He didn't know how to
give positive comments to push me forward when I was already
really down on myself because the whole experience was
frustrating.”
“Getting the first job with comprehensive code reviews, short,
small projects, rapid iterations and realistic expectations was
amazing. Feedback is the most useful learning tool, second is
the chance to see the code of more experienced developers
and third is trying a bunch of different things to develop
personal experience. But without useful feedback, just trying a
bunch of different things doesn't necessarily lead to progress.”
“[A good mentor has ] patience and solid constructive
criticism of code and other behaviors. Immediate or
quick feedback on issues 1-2 days. Ability to mold
aptitude into ownership and responsibility.”

22. Thoughts on documentation
“I say I found documentation useful - but that's only
true when it was GOOD. Most of it was wrong or
incomplete which was not helpful. People should
write better. “
“The biggest struggle I faced as a junior was a lack of documentation, lack
of process, lack of chain of command, and the rude attitudes of other
developers with 'holier than thou' attitudes.”
“There was a senior person to me on the team,
but he was grouchy and mostly didn't want to
be bothered. I learned a lot on my own, and
wrote documentation for the next people to
come along.”
“People. People, people people. Searchable documentation.”
“Stepping into a new position and not having any documentation for
getting our software up and running. Knowing that there are small
bugs I could be helping with, but not being able to access them.
Bug documentation that doesn't specifically point to the problem. “

23. Documentation!
- Inline
- Internal wiki
- Requirements
- Unit tests

24. Thoughts on Pairing
“I work at a pairing company, and after my first month of
pairing and getting to know the codebase, I did a one
month solo project where I built out some admin tools. It
really helped to have that time to integrate the things I'd
been learning from pairing and find the holes in my
knowledge.”
“Pairing sessions are the most helpful for tracking down
and resolving difficult bugs. Both mentor and mentee will
get the most of the pairing sessions if they had done some
prep work beforehand. Pairing helps the mentee see ways
to be more productive on the command line.”
“Pairing is amazing, but I still have a hard time
driving when I know significantly less than the
person I'm pairing with. (I also find it challenging
to be the senior pair with our new interns — both
sides of junior/senior pairing are pretty
challenging.)”
“Pair programming was both good and bad. I needed
some solo time otherwise I couldn't figure out how to do
the same things that I did yesterday. However, my
questions were more easily answered with pair
programming.”

25. Pairing!
- Mutually beneficial
- Juniors pairing with
juniors
- Set time aside for pairing
-Offer and ask to pair

26. Code reviews
- efficient use of time
- reviewee should explain work
- how requirements were met
- how they came up with the implementation
- reviewer should provide constructive feedback

27. The benefits of mentoring a junior developer
“I really enjoy being able to watch their code improve, their confidence grow and
building a team that shares the vocabulary to collaborate effectively. I'm good at
figuring out why other people are doing what they are doing, which makes me an
effective mentor. Plus they are really impressed when I can remote-diagnose their
bugs: it gives me perspective on how far I have come and highlights the useful skills I
have.”
“They're more willing to try different approach - not stuck in old
patterns.They learn quickly, ramp up - more visible progress
since there's so much to absorb initially”
“That time and energy is an investment which, when it
starts to pay off, is rewarding both in terms of increased
productivity, and having another great person to bounce
ideas around with.”
“I probably learned a different skill set from talking
to a newer developer and finding out [their]
interests and experience... and we were able to
build a working relationship that way.”

28. What do you wish you knew before your first developer job?
“How to tie my very theoretical and abstract
education into actual day to day work. They have
seemed very disconnected until recently.”
“Processes and best practices for certain
programming tasks.”“Knowing how to use tools.”
“More linux, more terminal stuff. How
to cut up text files at a terminal
prompt. More scripting languages.”
“Process workflow. How public and
private keys work.
How to setup a dev environment.”
[I] wish I'd known how much of the development process does not involve
actual programming.
“Wish I knew a little bit more devOps stuff.”

29. Clear Expectations
- Process!
- Reasonable Goals
- Well-written Requirements

30. Process!
- Methodology
- Ownership/responsibility
- Basic DevOps

31. Goal Setting
“ I wish I had a mentor to help me set time goals in
correlation with the size and speed of the project, eg: "If you
get stuck, only let yourself struggle for one hour before
coming to me for help."
“Structure is really important. Need to have clearly defined goals
for learning.”
“[I found] Tasks that are far past my skill level with little support to
complete them [frustrating]. Not being allowed input on my own
estimates.”
“A good mentor give[s] the mentee helpful expectations :
intersection of business needs and tasks where the mentee
stretches himself/herself but is able to finish the task.”
“[I found] projects with clear goals [helpful], or project
management that lead to clear goals.”

32. Reasonable Goals
Do not expect someone new to complete as
many tasks as you would someone
experienced.

33. Thoughts on projects as a junior
“[I found] Very short projects [helpful. It limited
the scope of the implicit project management I
had to do (which is an often-overlooked skill
programmers have to master).”
“hunting for bugs gave me the best experience with
a broad system.”
“I loved when I got a chance to try something
new or got something working that seemed
complicated, like encryption.”
“I love debugging code that mostly works. I need to be able to
see the parts that are working so that I can understand why
they work and solve the problem at hand.”
“Building out our integration testing suite. This really helped me
to learn the system and how it works.”

34. Clear Requirements
- Detail
- What behavior is expected in minute detail
- Implementation Suggestions
- QA test cases written beforehand so the dev
knows what they are up against

35. What qualities does a good junior developer have?
“Willingness to learn, to take on new tasks, go outside their comfort
zone.”
“Openness, willingness to learn, ability to figure things
out when I don't give them all the information.”
“I just get a feeling off certain people that they seem smart and willing to
learn. I'm sure there is something more definable going on, but it's hard to
put my finger on. It may be something about the way they approach things
they don't know or are frustrating.”
“General brightness, not necessarily programming skill. Curiosity,
patience when problem solving, willingness to engage with a problem
by breaking it down into smaller questions and not bringing too many
assumptions that might lead to a quick, but incorrect solution.”

36. Advice to Junior Developers
“Google, read and debug code. Learning to use development tools to
figure out what was going on was massively important, because then I
could bootstrap things.”
“Quickly adaptable is the best [quality]. I don't care if they've
never written a unit test, as long as a month after they are
introduced to the concept there are tests attached to every
project. When I suggest using an enum someplace, I want to
see that the next time that situation comes up they'll use an
enum without prompting. I also want enough curiosity and
independence that they are learning the whys for what they are
doing at the same time they are doing it. Teaching generative
principles is far more efficient than case-based teaching.”
“ [A good junior developer is] stubborn. They've got the right balance of hubris and
humbleness. Like they're willing to tackle the big problems, but also realize they might run
their approach past a senior dev first.
The ability to accept criticism is also important. You have to learn to choke down the urge
to get defensive if someone criticizes your code. If you're code reviewing it's your job to be
tactful about it, though.”
“Everyone has impostor syndrome. Everyone
makes mistakes - they won't get you fired, they're
an opportunity to learn things. People around you
are not programming gods.”

37. TAKEOUT MESSAGE
The tools that can be used to empower junior
developers are useful for the entire
organization, and everyone benefits.

38. thank you.
@BonMatts
“I really wish every computer science program required enough liberal arts classes
that students were all exposed to gender studies, post-modernism and basic social
systems analysis. Also probably enough therapy that everyone was coming in with
basic self-awareness.”