Creating Great Developers: Shadowing

Earlier posts in this series: “Introduction“, “Hiring“, “Orientation“, “Training“, “Planning“, and “Production“.

Once the new hire has successfully delivered their internal project, they are ready to move to the next phase of training: project shadowing.

We pair the new hire up with one of our senior developers, and have them work on the same project and tasks in parallel. At the start of each week, the senior developer will sit down with the new hire to outline the goals for the week, help prepare micro-deadlines (ie. production targets for each day), and provide some guidance on architecture and approach.

Throughout the week, the new hire works towards the assigned goals, and is free to ask their mentor for help or advice in an appropriate, organized manner. We schedule time for the senior developer to account for this, so that it does not create a burden on them.

At the end of the week, the trainee is provided with the mentor’s source code and given some time to compare it to their own efforts. They then sit down with their mentor to review their code quality, communication, and productivity. This also gives the trainee an opportunity to ask additional questions that arose during development or (more critically) while they were comparing their efforts to the senior developer’s work.

Besides being another great learning opportunity, it also provides the trainee and the senior staff with applied benchmarks as to how they are performing on a real project, without the risk associated with actually placing them on a client project. An important factor is that shadowing is treated as a serious project by both the trainee and the team, with a project manager, deadlines, and testing / quality control.

We repeat this process for 3-5 weeks, depending on the trainee’s performance. Most weeks we will switch mentors, so that the trainee is exposed to a variety of working / coding styles.

At the conclusion of shadowing, the trainee has been with us for between eight to twelve weeks, and is ready for their three month review, which will is the subject of the next article, available here.

Grant Skinner

The "g" in gskinner. Also the "skinner".


One Comment

  1. Thank you for these insights in your training process. I do agree that your review process certainly creates a great learning opportunity for the new developer, but I’d be quite worried about the time/costs involved and a “lack of trust”:

    In my view this process might be highly frustrating for the senior developers, once you are not able to only recruit above-average trainees. While this might not be the case for your company, any company operating on a tight budget will sooner or later run into the trouble of finding good people at reasonable wages. On the other hand it may be rather frustrating for a new trainee to be first bound to a virtual project, only to continue to be assigned work that will never go live.

    Why not have a competition between several apprentices on a real project and have the best one presented to the customer (of course, only if it meets company standards and/or is amended by a senior developer)?

Comments are closed.