[LRUG] Hiring a pair rather than an individual contractor

Dan Garland dan at dangarland.co.uk
Wed Dec 18 03:08:08 PST 2013


Hi Tim,

I thought I'd chime in on this one since I work with junior developers 
in much the same way that you describe. As you say, its very rewarding 
to work with new recruits and help shape their new careers.

About a year ago, I explored the idea of taking on an apprentice to help 
me with my contract work, gradually training them up to the point that 
they could work on contract work independently. Since then, I've had 
some experience of training with Maker's Academy and General Assembly 
and seen how they get people up to speed. Assuming that the junior 
developer is relatively unversed in Ruby/JS/web development, I do think 
that some amount of devoted time to learning the approaches and 
technology is important. I don't think you can achieve that by looking 
over someone's shoulder.

On the other hand, what I wanted to do differently was combine that 
training with real-world experience working alongside myself, so that I 
could help them apply their skills and knowledge in the workplace. To 
achieve that, I work with SMEs, agencies and start-ups to provide 3 
month contracts where I provide a pair of programmers: one senior, one 
junior, and the senior's primary role is to mentor the junior. So 
overall my trainees work with me for six months: the first 3 months are 
intensive, classroom based learning and the second 3 are working onsite 
with my clients. My job is to help them to continue to learn, without 
stepping on their toes, whilst providing quality assurance for the 
client. By being choosy about who I take on (I have 4 recruits right 
now) and training them myself (I can cover more ground with a smaller, 
aligned group), I now have a team who are full-stack TDD developers. 
With the tools at our disposal to monitor git commits, pair program 
(even remotely) and write effective tests, I can effectively work with 
multiple trainees, in such a way as to support them rather than stifle 
them.

 From the client's perspective, I approach them on the basis of a fixed 
number of hours a week from a pair of programmers, where the senior 
developer's primary role is to mentor, but I guarantee the output of the 
pair. I hire my own trainees and put my money where my mouth is. We are 
both part of the client's team, and in the worst-case scenario I would 
just contribute code directly if I felt my trainee's output was in any 
way lacking.

In answer to your questions, I reckon that working with one mentee 100% 
of the time would be too much. My approach is to work with each of my 
team for up to 2 hours a day. That's enough time to put someone on the 
right track without stepping on their toes and preventing them from 
learning. I think by stepping away for a while, a mentee is encouraged 
to self-diagnose and troubleshoot themselves, but prepare for the 
interaction with their mentor, so that when we sit down together they 
are already telling me about an issue and what they've tried already, or 
discussing a new feature and the best way to go about it.

Let me know how you get on with it.

Best Regards

-- 
Dan Garland

@wegotcoders
wegotcoders.com



More information about the Chat mailing list