Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up (Category Management)

This is another review. articles A human approach to developer productivity. This article focuses on the critical aspects of onboarding and increasing the speed of engineers.

The highlights of this article are as follows:

1. The issue of onboarding is very important - it is the process of transitioning a new engineer from a beginner to a productive member of the team. It is important for both individual success and team-wide performance. Effective onboarding can reduce overclocking time and improve long-term productivity
2. But engineers’ adaptations are often hampered by standard problems: insufficient documentation, lack of mentoring, unclear expectations from the engineer, and complex project source code. These factors can delay a developer’s ability to contribute effectively to a team’s work.
3. To assess the quality of onboarding, you need to be able to measure it. In fact, this measurement refers to measuring the productivity of engineers, but since we are only interested in the results of changes in approaches to onboarding, the authors decided to measure not the productivity itself, but changes in it.
4. Previous approaches to ramp-up-time metrics have included comparing the parameters of beginners with experienced engineers, but the authors of this study went their own way, in which they needed to avoid comparisons between beginner engineers themselves. (Otherwise, they would be motivated to play the metrics and show how great they are.). In the end, they decided to validate candidate metrics regarding engineers’ perceptions of how well they got into standard engineering tasks.
5. The authors investigated 9 candidate metrics and selected for further analysis 3In which there is progress over time and reach some stable level. These are metrics.

• Active coding time per line of code (LOC)
• Reviewed LOC
• Submitted LOC Next, the authors aggregated new engineers by weekly cohorts, and then began tracking how many weeks it would take for these metrics to reach a stable level and stay there at least. 4 weeks.

6. Then the authors launched surveys for engineers. (worked less 40 weeks). This survey was conducted by about 3K engineers. The questions were all around. 17 Writing code, reviewing other people's code, running build and tests, finding examples of API use by others at Googe, and so on. Questions have been asked about the experience surrounding these tasks in the past week and 5 The answer ranges from “I didn’t perform these tasks” to “I’m already performing these tasks at the most effective level I expected.”
7. The authors found a significant negative correlation between “Active coding time per LOC” and self-evaluation of performance. 15 from 17 tasks. And 6 from 17 The stats were significantly related to the submitted LOC. The authors took this metric as a ramp-ut-time.
8. The authors described the results of COVID-19 for ramp-up-time, as their data began to be collected before the whole parsley.

• For engineers before COVID--19 The average cruise speed was 2.5 times higher than the initial. And for those coming out of COVID, she became everything. 1.5x
• Before COVID. 19 Engineers came up with a stable submitted LOC 12 weeks, and then 18 weeks

9. The authors think they can use the findings to help colleagues who run educational initiatives and trainings for engineers within the company.

The authors offer the following recommendations for improving onboarding Provide comprehensive documentation and clear guidelines. Assign mentors or “buddies” to help new developers. Implement structured adaptation programs with specific stages. Encourage feedback from new employees to improve adaptation processes. Invest in tools and systems that make it easier to navigate source and workflows.

P.S. A diluted post with reviews of all articles in the series is available here.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes