Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Our team recently joined up with a few smaller teams, and as we had some direction and standards to our development it was decided that it would be best to train those up in our chosen languages and methodologies.

Some members take years to achieve an acceptable level of competence, and I've noticed that there seems to be this assumption that a developer with less knowledge requires almost 50% of a more knowledgable persons time.

When I started devloping several years ago I had no mentor, I had a project in front of me, a good book, and later on I had the internet, and that's pretty much paved my learning approach over the years, as a result of that I can taken on a language or methodology and learn very quickly, the only time I need to seek advice from colleagues is for design work, code reviews and standards discussions.

The staff who have this allocated time to mentors appear to be constrained, and I strongly feel that when it comes to technology, you shouldn't need much human interaction, if you rely on someone to walk you through technologies I fear that they will only remember that and therefore be constrained in the learning.

So my question is, how do you deal with training up staff? My way has always been to not find out the solution but to find out how to achieve the solution. I don't quite understand the whole spending time shadowing another developer, maybe that's just me, but there must be a standard approach to this.

Would like to some input please.

share|improve this question

5 Answers 5

You're going to have to take this on a person by person basis - everyone has a different learning style that works best for them.

Some things that can help are an early emphasis on:

  • How to use any available help files
  • Training on good places to find sample code and examples of commonly used code
  • Providing a good list of external resources to draw upon
share|improve this answer
+1 for 'everyone has a different learning style'. My own limited experience has shown me that many devs have, for one reason or another, a lot of difficulty ramping up on a given technology with nothing but Google and books for help. –  Joshua Smith Jul 12 '11 at 13:40
It's also much harder if you are an existing employee versus coming in new. The new guy is not going to have people constantly interrupting them while they try to focus on learning. –  DKnight Jul 12 '11 at 13:56

"Pair programming" is much faster way than learning from a book - particularly because no book describes the specific system you work with at your company, with its intricacies and specifics, and tutoring a person on live examples will take less time than writing a book for them...

It's also not quite a correct estimate that the other person takes away 50% of the useful time. While sure, answering questions and giving examples will take time, the young programmer can write trivial code while the expert thinks about a hard problem (he'd have to do both in sequence otherwise), time spent trying to spot that one trivial typo is cut by 90%, and maybe, just maybe the guy will spot right solutions and learn them instead of repeating all the mistakes you made and learning from them later just like you did.

So - while yes, it cuts into time of more advanced programmers, it gets the newbies up to speed much faster.

Of course sitting behind the guru's back, fiddling with fingers while the guru types black magic without uttering a word is not much of use...

share|improve this answer
The junior guy should be coding half the time, maybe more. The senior should just give hints if the junior guy gets stuck. –  kevin cline Jul 12 '11 at 14:59
...or does something stupid. –  SF. Jul 12 '11 at 18:37

There is nothing like learning under fire. When you are forced to go in and learn a system, you learn it fastest - you know - break it, and then learn how to get yourself out of it. Well...I'm not saying to break anything, but I'm sure you have a list of enhancements and bugs that need working. I would throw them into working those items - that will force them to learn the inner workings and small caveats of the system. The good developers will pick it up fairly quickly.

That is how I have learned many systems in the past as a consultant. I've been asked to go in and help out with fixes and/or enhancements. They CANNOT be afraid to ask questions, and be prepared to spend some time with them and all of the queries that they will have. If you don't get questions from someone, then they are probably floundering a bit and need help - go and seek them out.

share|improve this answer

To add to DKnight's answer regarding approaching training on a person-by-person basis, devs have to want to learn. Forcing the issue is often counterproductive. I work in a .NET shop where some of the older devs write a ton of Fortran-esque procedural code because that's how they've always done it. Efforts to move away from that paradigm have proven fruitless.

share|improve this answer
+1 for 'devs have to want to learn', very true. –  Mantorok Jul 12 '11 at 13:45

The old saying goes you learn 10% of what you read, 20% of what you hear, 50% of what you do and 90% of what you teach.

In my opinion this old addage has ringed true for me. You give somebody a book and their retention will be low. If you teach them and walk them through code examples it will likely benefit YOU as the teacher more than the student as it STRONGLY reinforces knowledge to you and gives you a deeper and more intuitive understanding of what it is you are teaching. The student may only retain important points here.

Students learn best by DO'ing. I found that by giving them a simple prototype assignment to work at their desk or a hello world app they will be forced to look in the book or search Google for the answers. When they are done with the training exercise, sit down with them and review their design and code and correct them where they are wrong, show them what could be done better and ask them to explain their correct assertions.

This way you get the BEST of BOTH methodologies.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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