[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