[LRUG] Juniors

Steve Tooke steve.tooke at gmail.com
Wed May 21 09:03:27 PDT 2014


This is such a great post - would make an excellent blog post ;-)

I would love to be involved in something like [†]


On Wed, May 21, 2014 at 4:30 PM, Najaf Ali <ali at happybearsoftware.com>wrote:

>
> *> Seems strange that there's so much talk about skills shortages and yet
> not 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.
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>


-- 
/tooky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140521/e6863c89/attachment-0003.html>


More information about the Chat mailing list