There is a new developer starting soon. This person is at an entry level but has worked in app support for a couple of years.
I asked this question some time ago just before I started training someone else: Is Pair Programming also used to train less experienced developers and bring them up to speed?. However, they were moved onto another project so it did not really go ahead.
My question is: How often should these sessions go ahead? From answers to my previous question I believe there are two approaches:
1) Spend one week training the person and come up with some objectives. Then three months later have another one week session and set some more objectives.
2) Spend one morning per week on paired programming. This would give me time to spend elsewhere.
Also this developer is “green” (term I took from an answer to my previous question), whereas I have worked as a developer for my current employer for seven years. Unfortunately I am the only developer. Is there any other approaches to knowledge transfer that work when the learner is “green” and the teacher is more experienced?
I was in a similar position once where I was bringing several developers up to speed. The most important thing that we did were constant code reviews, meaning that every commit was reviewed and commented on by everyone. After about one or two months they were not only picking up good practices but also felt confident with the codebase.
Also you could try and let your new developer write some test cases first for your project, so he gets a feel for the codebase without breaking anything.
Despite the “science” in “computer science” and the “engineering” in “software engineering” evoking the idea of having rules, guidelines, and some “correct” method, my experience is you need to trust your gut. Software engineering tells us that the process of paired programming works: your gut feeling tells you how to apply it. This is a human issue, not a technology issue.
I would gather metrics, even if informally. If you had to provide an official rating for this junior member in the “technical ability” box on his annual review, what would it be and what would you say based on the pair programming sessions?
If the feedback would be “his code needs to be constantly reviewed and he consistently makes rookie mistakes” then you need to continue paired programming. If the feedback is “paired programming sessions put the other programmer to sleep” then dial them back a bit. This is inherently subjective, but that is not necessarily a bad thing.
In both cases, code reviews are a must. Everyone makes mistakes and everyone has something to learn regardless of experience level.
I’ve done my share of pair programming and training rookies. First of all, it really depends on actual talent. Some developers will never grasp abstract thinking and are most happy developing basic features or executing basic programming tasks.
Others will want to dive into the full code base of the applications you’re building and contribute to architecture.
If you’re dealing with the first type of developer, you probably want to keep relatively short sessions and have them often (maybe even every day for an hour or so). If you have the latter, you want to have longer sessions, but include whiteboard sessions for design as well. Keep in mind that the task you’re trying to get accomplished has to be suitable to a pair programming session.
2
Co-location and pair programming are amazing techniques for bringing new people up to speed on the project and share knowledge.
Answer this question, when do you expect a new hire to do the first check in that goes to production?
The answer with a pair programming is “On his first day” 🙂
If you just plug someone in and start working on real feature of your project in pair (doing ping pong TDD for example) your newbie will learn a huge amount of how you do the development and will write the real tests and code the very first day. It will definitely reduce your productivity in the beginning because you will have to explain and make an effort of “transferring the knowledge” – but that’s the price to pay anyway.
Recommended reading on pair programming from Arlo Belshee