This document provides advice and guidance for junior developers. It discusses the importance of mentorship, code reviews, testing, pairing, side projects, and diversity/social justice in tech. The author shares their experience of transitioning to become a junior developer, including asking about support during the interview process and dealing with legacy code on their first day.

1. proper care and
feeding for your
junior developer
Eric Stiens
Software for Good
@mutualarising

2. how to be an awesome junior developer
how to mentor junior developers you work with
how i became a junior developer
2 stories and some other stuff

5. (it's not very
technical)

7. THIS
WILL BE BRIEF
(i promise)

8. Background in Sociology and Social Work
15+ years working in non-profit field
Racial Justice researcher

9. Highly Trained and
Professional SJW

10. web coordinator for international
mental health non-profit
drupal without php...whee!
solo consulting company for non-profits
mailchimp, dropbox, listservs, fixing printers, online
donations, social media, networking, hardware
support
And a bunch of Wordpress sites (without php...whee!)

11. Bitmaker Labs
Bootcamp in Toronto

12. GETTING HIRED
mutual meeting not an audition
make sure they want a junior
developer
(not just a sr.developer lite! make use of other skills.
know how to onboard)

13. I ASKED ABOUT
support for my learning, pairing,
mentoring, commitment to
diversity and social justice, when
I'd push production code, testing,
ability to work on front-end and
back-end stuff

14. full stack developer
primarily working
with Ruby and Rails
ask me about it
later

15. MY FIRST DAY! :nervous:

16. model.rb
def method_missing(sym, *args, &block)
if sym == :data || sym == :data=
super
elsif (m = sym.to_s.match(/^([w]+)_before_type_cast$/)) && args.length == 0
send m[1].to_sym
elsif sym.to_s.match(/^[w]+$/) && args.length == 0
if self.class::EAR_ATTRS.include?(sym)
get_dynamic_result(sym)
else
super
end
elsif sym.to_s.match(/^[w]+=/) && args.length == 1
m = sym.to_s.chop.to_sym
if self.class::EAR_ATTRS.include?(m)
set_dynamic_result(m, args.first)
else
super
end
else
super
end
end

17. wtf?

18. schema.rb
t.text "data",:null => false
⬆
(100 attributes live inside me as a giant serialized hash)

19. WTF?

20. YOU ARE IN A LEGACY CODEBASE
-> RUN TESTS
YOU HAVE NO TESTS
-> READ SPEC
YOU HAVE NO SPEC
-> WRITE FIX
YOU ARE EATEN BY AN ELDER CODE HACK

21. TESTING
and
READING CODE

22. “Programs must be written
for people to read, and
only incidentally for
machines to execute.”
- SICP

23. (i haven't actually read SICP yet)

24. (Interestingly,
writing tests for
someone else's code,
is a particularly good
way to read it)

25. MENTORING
Don't hire a junior developer you
can't mentor. It's not fair to them.
It's not fair to your team.
Everybody loses.

26. Some mentoring rules
No feigning surprise
No well-actually's
No back-seat driving
No subtle -isms

27. DON'T USE THEIR
KEYBOARD
(Yes, it will be frustrating. They
will be slow. They will make
typos. They will get flustered.
They will get syntax wrong. They
will stumble. It's okay. Be
patient.)

28. CODE REVIEW
We do code review on pull
requests. You can never merge
your own code into master, no
matter how small the change.

29. BAD CODE REVIEW
writing code for them (too specific)
not being specific
anything mean or too terse
focusing too much on inconsequential style choices

30. GOOD CODE REVIEW
"Great job getting this feature to work, but you could probably
refactor X and Y into another object."
"We probably need some tests on this logic"
"A more idiomatic way of doing this is..."
"You should look into this Rails method here, it does what you
want"
"What will happen if we pass nil into this method?"
Also, nitpicks are good. (Just not all the time).

31. have your juniors do
code reviews as well!

32. www.exercism.io

33. PAIRING
(sadly, we don't do enough of this at SfG...yet! But we are
working on it)

34. LET JUNIORS PAIR
TOGETHER
Rarely have the same strengths.
Builds team cohesion.
Increases productivity

36. A STORY ABOUT A
SIDE PROJECT

40. WHAT DID I LEARN?
how to build an API, lots of stuff about JSON, how to
use RABL, how many people make feature requests to
open source projects and how little people fork and
PR, how to scale an app on Heroku, that timezones
suck and are really hard, nokogiri tricks

41. My company paid me to work on
it and then paid for the hosting
They ended up with a developer that had leveled up in
some skills, some great publicity, and even a few job
inquiries

42. SOME MORE
IMPORTANT THINGS
IN NO PARTICULAR
ORDER

43. DESIGN PATTERNS

44. WATCH OTHER
PEOPLE CODE
(check out peepcode.com! /
pluralsight)

45. READ A BOOK
READ A BOOK

46. Some thoughts on the
pipeline...

47. DIVERSITY ==
SOCIAL JUSTICE
desegregation is not the same as
integration

48. DIVERSITY
♻
SOCIAL JUSTICE

49. thank you buffalo !
@mutualarising
eric stiens

50. Some further reading on diversity and social justice in tech
The Myth of a Magical Future
by Kate Losse
http://www.katelosse.tv/latest/2014/9/12/magical-futures
Etsy’s Trying to Fix Tech’s Women Problem. Why Aren’t
You?
by Ann Friedman
https://medium.com/matter/this-is-the-last-thing-youll-ever-need-
to-read-about-sexism-in-tech-56b9a3a77af0

51. Manufacturing the Talent Shortage
by Dimas Guardado
http://modelviewculture.com/pieces/manufacturing-the-talent-shortage
Even At Highest Level, STEM’s Leaky Pipeline Failing
Women and Black People
by Laura Mandanas
http://www.autostraddle.com/even-at-highest-level-stems-leaky-
pipeline-failing-women-and-black-people-245489/