When you are doing software development on larger projects that has been running for a while, it’s inevitable that the staff will change. These people, no matter how experienced they are, will need some training to understand the project. How to train these people has been a challenge that I’ve never really solved.
I’ve been struggling with this issue for quite a while. I’ve had several lengthy discussions with colleagues, project managers, business analysts etc, but nobody could give me a solution to this. I’ve tried writing simple and complex documentation, a variety of models and diagrams, mentoring and pair programming, self study with follow up, throw-them-in-the-water-and-see-if-they-swim and several other techniques.
I am currently reading a blog post from Scott C Reynolds: On Teaching, Learning, and Being Honest With Ourselves. I say currently reading, because after reading just a few lines, I knew that I had to write down my thought as I read it to be able to reuse them in the future. At this point, I’ve read the wikipedia article about the Dreyfus’ model of skill acquisition, and I realized what I’ve been doing wrong all this time.
Mistake #1 – Introducing a large distributed solution to a novice:
I’ve been taught that everyone needs a map to see where they are in the big picture. I’ve tried to give everyone an overview of the solution before assigning them tasks in a particular subsystem. That way, they should have a better understanding of what their task is contributing to the whole solution.
A few things that resonated with me:
“Beginner casts a very wide net…”
I agree totally; beginners want to learn everything at once. Narrowing the scope to something they can actually grasp in a few hours will make a much better learning experience for them.
“Am I able to sum this up into essentially recipes and step-by-step instructions with defined rules?”
This sounds very much like the question I should have been asking myself, but never did.
Mistake #2 – Believing that an experienced project manager is something else than a novice in distributed systems
Several of my project managers have told me to prepare documentation that a new developer can use to familiarize themselves with the system. Sometimes that has worked, and new developers have started improving the existing codebase from first checkin. Other times this has failed miserably, with developers never getting source ready to check in because they never figured out where it should be added to solve the user story.
“Keep in mind the Dreyfus Model applies atomically to a given skill. ”
An experienced project manager can still be a novice when it comes to compex software systems. Therefore, one need to teach them in the same manner as you teach other novices.
Mistake #3 – Trying to use the same technique for novices as for competent or proficient developers.
Novices have a lot of challenges to solve at once:
- Learning the rules of the project
- 3rd party tools and components
- Coding standards
- Checkin policies
- Unit Testing
- Maintenance procedures: e.g deployment scripts
- Learning the problem domain
Depending on the particular task, this can be quite a challenge
- Learning the tools and platforms in use
- .NET Framework
- ASP.NET
- WCF /WPF
- NHibernate
- SharePoint
- Understanding the task and how to implement it
- Understanding how to commit the implemented task to the solution
- Updating documentation
- Notifying PM or customer
- Writing test descriptions
So what have I learned?
For novices
- Use numbered lists
- Do not try to teach advanced OO or Agile Principles
- Limit the context to the task
- Ease the constraints and rules
- Do frequent code reviews
- Encourage improvement
- Expand rules, context and scope task by task.
For competent or proficient:
- Assign user stories, not tasks
- Encourage talking directly to the customer
- Require the use of advanced OO and Agile Practices
- Require continous improvement of both the code, maintenance procedures and documentation.
