[LRUG] Juniors

[Najaf Ali]

*> Seems strange that there's so much talk about skills shortages and
yetnot many companies seem prepared to train their own. *shrug**

That would be because training your own is, unsurprisingly, a lot of work
that many development teams aren't currently equipped for. Taking a junior
up to the standard where you can actually trust them to ship production
code that you care about is a two-three year investment that can only pay
off exactly when they're ready to be poached by someone else at a higher
salary.

This is compounded by the fact that by default, there's no evidence to
suggest that your existing developers are all that good at teaching. The
massive skills gap between current teams, typically comprised mostly of
seniors, and juniors fresh into the industry doesn't help things (my old
Kendo instructors used to say that sparring with someone 0.5-1 dan grade
above you is the best way to improve).

There are a number of ways one could go about making this situation better,
for both employers and juniors who want to work with them.

* Stipulate a minimum employment term for the junior (e.g. three years).
That way, if they make a loss on the first year the company (assuming the
developer does indeed level up their skills) has some opportunity to make
good on the investment in the following two. You don't have to have actual
terms that enforce this in any way in your contract, as long as the
candidate understands the implicit obligation and feels bad about leaving
part way through. This is a great deal more important for smaller
companies, especially fledgling consultancies, than it is for larger teams
that have revenue and development time somewhat better decoupled.

* Encourage (i.e. pay them or give them time off in lieu) senior developers
to teach at events like Codebar <http://codebar.io/>. That will give them
an appreciation for what they know and practice at transferring knowledge.
Events like these are great because they're volunteer run so there's no
real pressure to perform like you might have with a paid training session
or a talk at a meetup/conference.

* Take other steps to reduce turnover in general. Well-trodden ground here:
remote or hybrid remote working[π], ROWE, open allocation, automatic
pay-raises timed to beat whatever offers are arriving in their inbox,
unlimited book budget, time set aside for everyone for training/writing/OSS
contribution, encouragement to speak at meetups/conferences etc. You're
aiming for velvet-lined, diamond encrusted, 24-karat gold handcuffs. If
someone had offered me this sort of deal it would have been *much* harder
to make the decision to go out on my own. New Bamboo are a company that
gets dangerously close to this (and last I heard, are hiring/training the
odd junior developer).

* For larger teams, have a specified intake and training process for new
junior developers. From the outside at least, Funding
Circle<http://tech.fundingcircle.com/codecraft/> appear
to be doing this exceptionally well. The syllabus has to cover basic
programming[†] (i.e. here's how to open a file in Ruby, now here are three
exercises that have you doing that in different contexts, let me know if
you get stuck, see you in a week) and company specific stuff (we have
haproxy in front of nginx in front of haproxy in front of three rails app
servers, can't change it because if we do dark clouds gather, the wolf lies
with the lamb, cthulu manifests and the CMS goes down).

* Aim for a good mix of experience levels on the team. The goal here is to
make knowledge transfer easier, as it's much simpler to explain something
you've mastered recently than it is to unpack intuitive knowledge (e.g.
someone asks you how you just did that thing in vim and it took you more
than a hundred times longer to explain it than to do it).

I could go on for a while, but the general strategy I think will serve
development teams well is one of making hiring and training a core internal
competence (i.e. you should be as good at hiring/training developers as you
are at *being* developers) rather than only dealing with it as and when
there's a requirement for "more resource".

There numerous other long-term benefits that starburst out of adopting such
a strategy, both for the the company itself and for everyone involved in
implementing it.

The typical career progression of juniors is to work at shitty companies
("They don't even let us use version control, help!") until they can spin
their CV into saying the magic words "three years experience". This is not
ideal. If a talent shortage is the central problem in our industry, it
strikes me as a problem we should tackle head on with all of our creative
and intellectual faculties, rather than leave it to recruiters
(seriously!?) to handle for us.

-Ali

P.S. Pay them. There are other reasons why paying them (especially in
comparison to *them* paying *you*) I feel is better in terms of training
but I could write a couple of thousand words on that alone, and the
ridiculously cheap fillet steaks aren't going to eat themselves here in
Montevideo.

P.P.S. "Internship" in general isn't a great word (Hi Rob!). You get
interned in a grave or, well, an internment camp. I much prefer
"Apprenticeship", but I've never watched The Apprentice, so you might have
all sorts of funny associations with that word.

[π]: Many, many developers decry remote working as non-ideal. For
them, *they're
right*. Many others try it on a team that does it well and there's no money
you could pay them to go back to working in an office. Since doing remote
working well is a rarity at the moment, you can exploit these facts for
better turnover.

[†]: I think if people who have experience training juniors (Hi again
Codebar!) put their heads together and made an open-source syllabus and
exercise workbook (with flavours for different languages) for the basic
programming part, it would make life easier for a lot of employers wanting
to dip their toes into hiring and training a junior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140521/7d27c76b/attachment-0003.html>