Handling learning curve for new developers

Question

Our company likes to hire new developers, with no experience. We have a core set of skills that we try to get them up to speed with, like ASP.NET and WinForms - to teach basic programming, the .NET languages, and the things they'll need to maintain and write. We also try and mentor them through early projects, so they can learn from someone more experienced.

Recently, we've been seeing the benefits of new frameworks like MVC and ideas like Unit Testing and TDD (by extension, dependancy injection and IoC), and we'd like to start using these in the team. However, this increases the time that a junior would have before they can get started on a new project - because doing something like unit tests wrong could cause major headaches months or years later in maintenance, especially if we believe unit tests to be comprehensive.

How do you handle the huge amount of things that a junior will need to take on, acknowledging that the business wants them working independantly as soon as possible? Is it acceptable to tell them not to unit test till a while after they are independant (and give them small, simpler projects in the meantime) before taking them to 'level 2' of the core skills?

Answer 1

TDD, imho cannot be learnt without making initial mistakes. But, why not have a senior developer guiding a group of jr. developers? Someone who can provide them guidance and also do their code reviews.

Answer 2

Unit testing is probably a good thing to have them doing early on, but invest in a code coverage tool so that you can tell them to produce tests that cover all the code being tested. Once they've done that for a bit, they'll have a lot better appreciation of what the code is actually doing (and just how abstruse some error cases are) and be far better at being good programmers. Note also that this does not reduce the need for mentoring, and you probably need to do code reviews on what they do before letting it anywhere near production.

Answer 3

Where I work, we pair program on all production code, and we've got new developers coming in, they just pair with established team members from day one. The pairing dynamic eliminates any mistakes they might make, and in my experience talented but inexperienced developers can get up to speed very quickly this way.

This could be tough to implement if your team isn't used to pairing all the time as it's a bit of a culture change. It's a culture change well worth making IMO.