The Impact Of A New Developer
The following is a series of observations and considerations about on-boarding new programmers to a team:
- Without the proper guidance, structure, and talent, junior developers can distract and degrade the output of any team.
- Regardless of ability, new team members unknowingly create technical debt as they work through new software and processes. Be sure to complete code reviews on all initial output. The formal or informal nature of that process depends on the individual and department.
- Embrace realistic expectations about a new member's impact. When new people start, plan to complete less work. Before a member can add to the collective output he/she will temporarily pull the team down while getting up to speed.
- Set up and communicate a grace period where expectations are reasonably lower. For instance, do not plan for productive output during the first week. Any work completed during that period should be considered a bonus. After the grace period, review his/her progress.
- Regardless of ability, do not assume a programmer has all the knowledge or training required to complete a job/task. Actively discuss deficient areas and provide a path to increase those skills.
- Pay close attention to junior developers new to the industry. They can have many preconceived notions about programming. It's important to make sure they do not get frustrated.
- Don't forget about the stages of group dynamics: Forming, Norming, Storming, and Performing. Teams will go through these stages each time personnel changes. Foster team cohesion by actively engaging new team members in all work and non-work related activities.
- New team members can provide excellent outsider feedback about a company, team, or processes. They can bring a fresh set of eyes and provide unbiased opinions.
- Continuously solicit feedback from a team about the progress of a new developer. This discussion should span from aptitude to attitude. Sometimes new members bring unintended baggage from another team/company.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)