I recently switched roles from a full time developer to a full time mentor. It was actually not much of a shift given my work environment. My team has 6 full time developers who pair program full time. Pair programming is a highly effective method of developing software and can be, at times, similar to mentoring. In an ideal pairing environment both developers are of similar ability. This ensures that both individuals can be equally engaged and equally contributing. When used as a mentoring tool it can be exhausting for each party. Pairing can be exhausting for the mentee because of a constant flood of new information and exhausting to the mentor for constantly providing the flood of information. This can, however, be a highly productive development and mentoring environment.

It is very important that each individual – the mentor and mentee, knows their roles in this situation. While you both may be working on a feature, the primary goal of the mentee is to learn and the primary goal of the mentor is to teach. When either party loses sight of their primary goal, things may fall apart. As with everything Agile, verbal (preferably face-to-face) communication is paramount. The mentor should give plenty of feedback to the mentee, and the mentee should be encouraged to ask questions and talk about the current feature, the tools, development methodology, etc. Remember, the primary goal in mentoring is to teach, not to write features.

If the mentor is too focused on completing the feature they may neglect their mentoring responsibilities which may cause the mentee may become lost, confused, or frustrated. The mentor may monopolize the keyboard and not allow the mentee to drive. The mentee may be intimidated and not feel comfortable asking questions with their lack of knowledge about the technology, the tools being used, or the task at hand. The mentor may become frustrated with the lack of their pair’s participation or their lack of input into the solution.

I have experienced some of these pitfalls in a mentor/mentee pair programming situation, and it is not good for anyone. It is also no one’s fault in particular. All parties involved have to know what they are getting into and have a common goal. There are some good tools and techniques that have proven very useful to me and hopefully they will also prove helpful to others as well.

Pairing Station

The setup of a pairing station is important. I have written in the past about my preferred pairing setup so I won’t go into detail here.

Ping Pong

Equal time typing is extremely important. It is very easy for a mentor to overwhelm a mentee by jumping around to a bunch of different files, using a bunch of commands that the mentee is not aware of to navigate the code extremely quickly. Giving the mentee equal time at the keyboard is important. When a mentor monopolizes the keyboard the mentee can get lost. When a mentee monopolizes the keyboard the mentor will get bored or frustrated with their speed. Ping pong is a fantastic method where the pair uses TDD and alternates with writing a test and making it pass. The mentor will typically write the first failing test and coach the mentee (with the mentor’s hands off of the keyboard) into making the test pass. The mentor will then coach the mentee to write the next failing test for the mentor to make pass. As the mentor is implementing the code to make the test pass they should do their best to explain why they are doing what they are doing and also the shortcuts and commands that they are using to navigate code, run tests, etc.

TDD

At this point, I feel like this goes without saying, but I’m going to say it again: I honestly can not fathom building serious software without using TDD. I also feel like when I am in a mentoring role this is even more true. Getting into a work flow with a tight feedback loop is extremely valuable in a mentoring situation. TDD provides a very structured work flow that helps provide a consistent cadence and also helps to guide the direction of the code being written. It also provides a safety net that will allow a newer developer to be more confident in making changes because they know if they change some code that will cause something to break a test will most likely let them know about it immediately.

Pair-tro

Have a retro of your pairing session. After each pairing session, take 5 minutes to talk about your experience with your pair. Talk about the things that worked, the things that did not work, and come up with something to try different next time. This can help the next pairing session to be more productive for both people. I personally have found pair-tros to be extremely effective.

Hopefully, some of that information will prove helpful the next time you find yourself in a mentor or mentee position.