1

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?

Improve this question

4 Answers 4

Reset to default
4

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.

Improve this answer
2

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.

Improve this answer
1

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.

Improve this answer
2
  • What tasks do you believe are suitable for paired programming? +1.
    – w0051977
    Commented Feb 23, 2015 at 16:32
  • Tasks that have a design component, or tasks that teach a new concept to one of the developers are very suitable. Tasks where either one of the developers have to do a lot of research and tasks that include a lot of repetitive work are not suitable. Also tasks that involve large amounts of code at a time may not be very suitable.
    – Jonathan van de Veen
    Commented Feb 24, 2015 at 10:01
0

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.