Best way to pass on the problem solving experience

Question

In my workplace, my team (working both on a ASP.Net MVC ecommerce and a C++ client) had a recent addition of two young members. One is a fresh graduate and the other worked as PHP programmer for some time. They're both kind of new to the ASP.Net world, along with all advanced concepts of ORM mapping, IIS configuration, performance issues and tricky-to-spot bugs. I'm the owner of the C++ side, and the other team member owns the ASP.Net side (on which I can work a little bit).

We, as senior team members, are expected to carry out our duties efficiently, and at the same time support the young ones in their gradual growth. They're doing their best, and our company allowed me a bit of dedicated time to spend for their education.

I collected my colleague's impression that the basis are already kind-of covered and what they really need to grow is to start thinking in a "professional" way (e.g. understanding the life cycle of a web application or HTTP request, or face a problem without relying entirely on the "senior" side). I think these skills come naturally by spending time on the particular project / language / framework and only if one accepts (or is forced) to take responsibilities.

Are there ways to efficiently pass one's "experience" and "problem solving attitude"? Does sitting beside the young ones and working together on the same problem (almost always splitting the work like 70/30) help or hinder their growth?

Thank you for your time.

Answer 1

In places that use the ideas of agile software development, the usual way is to just let the newcomers pair with the more experienced members in all tasks. In your case it would consist of a lot of pair programming. But you would need to do it correctly. It isn't one person programming and the other person watching. Both participate, but in different ways. See Pair Programming Illuminated for a specific description or Extreme Programming Explained for a more complete description of the whole process.

The experience of agile shops is that pairs produce about as much as people working individually (there is research to that effect) but with higher quality. (Specifically, the hypothesis that individuals produce more in total is not supported).

But more so, the newcomer is immediately introduced to the local process in an active way and can start to be productive much sooner. However, the experienced member of the pair will need to turn the keyboard over to the novice frequently (roles switch every several minutes, not hours), and both will need to learn to adopt to the individual roles of "driver" and "navigator".

Pairing combined with faithful use of test first development is especially productive of high quality software, but you need to actually practice the skills, not just talk about them.

Answer 2

As well as pair programming, look at other agile/lean techniques.

• Test Driven Development.
• What does done look like? / definition of done (scrum).
• Short release cycles (scrum).
• Minimise work in progress (scrum/kanban).
• Shared ownership (scrum/XP/lean).
• Local product owner (XP/scrum).

To teach Test Driven Development, you can start by writing the tests yourself (you probably will need to do the whole lot, including writing the production code, and then deleting it), and then pass this to the trainee to code, one test at a time. After this they can start creating their own tests.

If you are new to any of this, then take advantage. This will make you more equal, so take the journey with the trainee.

Answer 3

I will have to disagree with Buffy that the pair programing is a bad idea in your case. As a matter of fact I think the pair programing is a bad idea in general and I never see it work in real situation but that is another big topic.

My suggestion is to let them update/write the team's technical document, be it high level design documents, technical spec or even good/up-to-date code comments. If you are those "agile teams" that we don't really have a decent document then let them make one.

I believe the document is always a technical debt for any fast moving team. Let the newcomers update/write technical documents to explain how the system works, how a piece of codes work, make the existing document up to date.

To write a good document they need to get their hands dirty, consult with the old guys etc to understand how things work. Writing a good document that people actually will read and refer to is also a challenge to the newcomer and benefit the whole team in the end.

This article So You're A New Grad Software Engineer resonates with me.

Another answer mentioned test driven development, which I am not so sure about either. Of course test drive development is another big topic like pair programming. Personally I tend to agree with the points Test-Driven Development is Fundamentally Wrong made, writing tests afterward (not beforehand) makes much more sense. "Were I to follow the TDD architecture I would have to constantly revisit my tests, review all of them, revising them to match my discoveries." because there will be always things that I didn’t think of until I really implement them and "Because the same blind spots that I had in design will appear in my tests."

I don't mean to provide an answer just to argue/disagree the existing answers. One of reasons I answer the question is that I would like to know 4 years later, when looking back, does the pair programming/test drive development really help you bring up the newcomers? (if the OP would answer it) If yes it will also change (a little bit) my attitude towards pair programming and test-driven development.