<div dir="ltr">This is such a great post - would make an excellent blog post ;-)<div><br></div><div>I would love to be involved in something like [†]<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 21, 2014 at 4:30 PM, Najaf Ali <span dir="ltr"><<a href="mailto:ali@happybearsoftware.com" target="_blank">ali@happybearsoftware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class=""><div><i><span style="font-family:arial,sans-serif;font-size:13px">> Seems strange that there's so much talk about skills shortages and yet</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">not many companies seem prepared to train their own. *shrug*</span></i><br></div><div><br></div></div>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.<div>
<br></div><div>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).</div>
<div><div>
<br></div><div>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.</div><div><br></div><div>* 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.</div>
<div><br></div><div>* Encourage (i.e. pay them or give them time off in lieu) senior developers to teach at events like <a href="http://codebar.io/" target="_blank">Codebar</a>. 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.</div>
<div><br></div><div>* 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 <i>much</i> 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).</div>
<div><br></div><div>* For larger teams, have a specified intake and training process for new junior developers. From the outside at least, <a href="http://tech.fundingcircle.com/codecraft/" target="_blank">Funding Circle</a> 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).</div>
<div><br></div><div>* 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).</div>
<div><br></div><div>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 <i>being</i> developers) rather than only dealing with it as and when there's a requirement for "more resource".</div>
<div><br></div><div>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.<br></div><div><br></div><div>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.</div>
<div><br></div><div>-Ali</div><div>
<br></div><div>P.S. Pay them. There are other reasons why paying them (especially in comparison to <i>them</i> paying <i>you</i>) 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>[π]: Many, many developers decry remote working as non-ideal. For them, <i>they're right</i>. 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.</div>
<div><br></div><div>[†]: 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.</div>
</div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>/tooky
</div></div></div>