I’m Nico and I joined Shutl in September 2014 after attending a 12 week programming bootcamp, before which I had no significant prior experience in developing software.

My onboarding process with Shutl relies heavily on pair programming. Here are some of my observations, experiences and opinions on it and what can be done to have a junior engineer not feel like the image below…

Inexperienced vs. Experienced Engineers

Differences

A key difference is the baseline level of experience and knowledge you can expect between the two. An inexperienced engineer may not know about things you may consider as very basic technologies or practices. When pairing there has to be awareness of this gap and a readiness to cater for it. This means being prepared to step away from the problem at hand and move into coaching and teaching.

How the more experienced pairing partner handles this situation is essential to successful pair programming. Will they feel like time spent explaining something in detail is time that could have been spent coding? The experienced engineer might know how to solve the task at hand in five minutes however the same work performed while pairing with the less experienced engineer could take much longer.

The approach used depends on personalities and company culture. To use pairing to onboard an inexperienced engineer it has to be clear that these kind of tangents are expected. The team must understand the value of collaboration and working as a team rather than as individuals, and be bought into the priorities of onboarding. Both the experienced and the inexperienced pairing partner have to feel free in their usage of time and in how they interact.

Similarities

I imagine acquainting yourself with the practices within a company is a similar process regardless of experience. Key questions could be:

• What is being paid attention to?
• How is good code supposed be written?
• How is version control realised?
• What does the deployment process look like?

Basically learning the whole journey from a user story to deployment.

Advice to junior hires

As a new engineer you may feel like a dummy when you first start pairing and driving**, but it’s important to understand your actions are part of the process. You should always speak up when something is not understood, ask any and every question that comes to mind. In my case especially this has made me more confident and intensified the learning experience a lot. Driving as much as possible is important as well. Put yourself right into the development and thinking processes!

For me this came down to steps like:

• What happens when the feature has been added and is working?
• When do you decide to push, do you just merge or does someone else do it.
• If so – what’s a good way to go about merging?
• Do you just put it out there or should you discuss if the test coverage is good enough?
• Is there coupling in your unit tests?

Of course these will differ from company to company or maybe even from pairing partner to pairing partner; but where, if not in pairing, could internalising and gaining a deep knowledge of these processes and practices be quicker and more effective?

** We’re assuming that at any time during pairing, one person, the ‘driver’, is actively controlling the keyboard/mouse while the ‘navigator’ is conversing and observing. 

What can Pairing not do?

In my case there were some technologies that I had never previously touched. This made me feel like there was a black hole in my knowledge and prevented me from properly following some of the suggestions I posted above. I therefore stepped out of active pairing for two or three days to immerse myself in these new fields by building a little app. This helped me tremendously.

It is often difficult for me to say that I need to step away from a problem and spend some dedicated time getting my head around it alone. There are learning opportunities everywhere around me and I don’t want to miss out. Being open and direct is the most important part here. Explain your concerns and also express your desire to have some time alone to consolidate what you’ve learned so far.

Reading is also something that should naturally be done on your own. From personal experience however, this is most effective when combining this with discussions with the team about what you’ve read/learnt.

Conclusion

At the point of writing this article I have been at the company for a month and I’ve only been programming on a serious level for a little longer than half a year. Yet I feel like I have a good idea of most of the general processes described above.

I’m already becoming comfortable with making changes in code and committing them. In fact we had decided that I would attempt to implement some of our smaller stories by myself, and then get them reviewed. And guess what, I was able to do it just the way it’s done by the rest of the engineering team at Shutl, including getting it deployed to production!

I’m aware that I still have a long road in front of me but pairing has given me a feeling of security and optimism that whatever obstacle I face – I will overcome it.

(CC image by Pascal)