[LRUG] Juniors

[James Billingham]

Speaking a developer who has only been working commercially for about 3 years - I actually found it very easy to get my first 'real' job (at Code Computerlove, Manchester - a web agency).

The reason for this is because I did my work experience there, then did work in the summer for a couple of years. When I first went there, they put me on a very simple PHP project just to get a feel for my capability. After they saw that I was competent, they integrated me into one of their core teams where I functioned as an equivalent to a junior developer.

They covered all my expenses, then threw in a little extra bonus as a thank you. This worked out really well for both Code and me: they got reasonable quality work at low cost; I learned a lot, gained brilliant experience, and made connections which have helped paved the way for my full time career.

This started when I was in year 10 of high school (15-yo), then I went full time with them as a non-junior developer on a standard graduate salary when I was 17. After being there for a little under a year, I started contracting remotely for SenseLabs/Neurotopia in CA, USA. Been there for over a year now.

I think this process should happen more often - when developers are still in school. Taking someone on for 2 weeks is low risk with regards to business impact, but allows you to get a feel for their potential. If it is working well, you can take them on for 6 weeks over the summer holidays to help you out in a bigger way.

Potentially, this culminates into a situation where you have a great developer, straight out of school, who is loyal to you & is very cost effective.

I did have to get a couple of people to pull some strings for me to get them to consider taking me on for a couple of weeks. I think that companies need to do this more & actively show their openness to such possibilities.

James

-- 
James Billingham
Sent with Airmail

On May 21, 2014 at 4:30:40 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. 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 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  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140521/1d005fbf/attachment-0003.html>