CodeMash 2013 Day 3 Session 4


# Getting Good – Integrating Novice Developers
Elise Worthy @eliseworthy

Elise went through Hungry Academy and has only been a professional developer for the past 6 months.

## How do we address the need for developers?
We could hire by lowering our standards. NOT
Instead, bring in and train willing people
Randomness can help break out of bad habits, too.
A small portion of our time is spent writing code anyway.
A group of similarly trained experts will have similar solutions and you will end up with global maximums.
A group of diverse backgrounds will bring different solutions.
Similar to the theory of hiring consultants (which sometimes works really well, but often ends up in horific places)

## Hungry Academy profiles
### Three profiles
Horace – former architect (REAL architect)
Jan – QA specialist
Mary – Customer Service rep at Living Social

Why beginners? You want novel problem solvers.
How do you find them?
Overcoming selection bias – you want functional diversity
Availability – you’ll look to your friends who are very much like you, usually
Appearance – impacts people’s perception no matter how much we try to avoid them (if you look smart you must be smart)

Pick a well-rounded team, not an expert team.

## Hungry Academy
LivingSocial decided it would be easier to find and train 24 people with potential than to find more ruby devs
24 students
5 months
40 hours classroom per week
20-30 hours homework per week
Took them from nothing to developer (like actually be able to go through the hiring process at LivingSocial)
LivingSocial paid them a salary while they were in training and we offered jobs at the end
No contract – they were expected to work for LS, but it wasn’t required (LS did not expect to hire everyone). They did actually hire all 24, though.
The intensity was such that they actually expected some to wash out (they weren’t trying to wash them out)
After 6 months all of them are still there
You can see a lot of the syllabus online still, too.

## How
Allow them to adapt – have a selection of criteria to grade by and give 1-5 scores. The categories are such that it is impossible for someone to get 5s on everything so they would focus on what they could do well. Also helped place developers at the end of the process.
Also forced students to do things they were bad at just to stretch them out.
Holds attention because they had things they could be good at.
As a teacher don’t spend a lot of time with “the kid that really gets it” because they will learn without you anyway. Focus on the people that aren’t quite getting it instead, even if you could have more fun challenging the overachiever.
Make sure to provide tight feedback loops so that they know how they are doing and can get corrected. Better than springing it on them after 6 months or a year. Just like development.
There is a 6 facets of understanding model – explain, interpret, apply, have perspective, empathize, have self-knowledge
Use that model to determine if someone is learning and understanding.

## In Practice
Autonomy – let individuals control their own destiny
How do you do that for newbies?
Purpose – don’t just throw the crap work at them

Conflict is OK, but you can’t let it get out of control

Liking – you work better with people if you like them. Stupid icebreaker activities actually do help here, believe it or not.
Common Goal/Individual Ownership – so, give feedback so that they can own the project and will work towards the common goal.
Consistency – team leaders and mentors HAVE TO BUY IN – if they are not willing then any efforts to bring in newbies will fail

## Habits
0 – Must have a technical mentor, preferably on the same project
1 – Take nothing for granted and set expectations early
2 – Design a pairing schedule. Beware of the “expert” driving too much
3 – All code reviewed, especially via pull requests
4 – Set dedicated learning time with self-chosen objectives (during the workday)