Many new hires at Microsoft are assigned a mentor for their first few months on the job; we believe that the best outcomes are associated with intensive mentoring in the first month. A good mentor does not simply provide pointers to extant information on tools, processes, and people, but also models proper behavior and actions. For example, when Vadim came to someone in his team (incidentally, not his official mentor) with a bug reproduction problem, this person mentored him by looking at the bug report with him, figured out that it was inherently ambiguous (which was causing the new developer his reproduction problems), looked up the people who had written the bug report, and composed, with Vadim, an email to the bug report author asking about the ambiguity. He then looked up the author in the corporate address book, found out that he was in the building, and asked Vadim if he wanted to go visit the author in person. This process viscerally demonstrated to the new hire how the social norms of Microsoft worked, in a way that merely telling him would not have done. In contrast, Vadim’s official mentor was quite busy, which limited his availability. He often simply pointed Vadim at resources and documentation—sometimes incorrectly.

In addition to training managers and mentors and giving them time and permission to increasing their effectiveness and proactivity, we should do the same for the new developers themselves. Helping newcomers find others with similar experiences of whom they can ask questions—for example, on a new hire mailing list and/or chat room, per software team—could alleviate anxiety and foster a community of questions and answers about topics deemed too “simple” to ask a more experienced colleague. A similar practice to this kind of cohort mentoring is to have slightly more experienced colleagues mentor new hires. They have a similar outlook on their job since they are still beginners, and have additional related experience with which to offer advice and career mentoring in a way that much more experienced colleagues cannot relate.

Learning who team members are and how their projects are structured is an important activity often left to new hires to figure out for themselves. We propose feature interviews to make the process more explicit. A new developer will make appointments each week with a different developer on their team; in this appointment, she will interview the developer to learn about the features that the developer owns, the features’ overall architecture and place within the larger system, the design and implementation challenges faced, the developer’s job philosophy, and what the developer finds personally interesting or meaningful about his work. Hopefully, this would teach the new developer about the software system as it exists (rather than as its specification presents it) slowly, over time, giving the novice time to assimilate the information. It should also help to spread the value system and culture of the workplace more deliberately than now, which would help novices identify which values are held by all and which should not be held by anyone.

How do managers measure the performance of new developers? They will not be as productive as experienced developers, and their learning process is an important aspect of their development. We feel that the right set of metrics would judge new hires on time spent learning, risk-taking, and cooperation with others. Additionally, mentors would be judged on how fast the new hire came up to speed, rather than being assigned a novice as an unvalued side project. Many of the new hires we spoke to mentioned that they wished they had taken more time in the first few months to simply learn the system in breadth and depth, rather than jumping straight into a project and trying to work like an experienced developer. They said their managers did not expect them to be productive from day one, but later in their tenure, they had too much “real work” to do to spend much time learning. We are developing a framework for teams and mentors to create a set of benchmark guidelines that list a series of personal development milestones, e.g., when to write one’s first feature, or review someone else’s code, or be assigned a bug, or write one’s first bug report. Each procedure can be written down and made part of a “curriculum” for new developers, so that their progress can be monitored. This monitoring would also enable companies to measure the effects of any changes they make to the onboarding process, in order to see whether it improves the status quo.

Personal software processes can be used to help novices reflect on their progress through a task, and provide an artifact to share with mentors, managers, and other helpful colleagues early on to illustrate process mistakes and potential for improvement. New developers should be encouraged to think about how to figure out what to do next at any moment, when they should ask for help, and when they are stuck or making progress. One could adapt performance-monitoring techniques from intelligent tutoring systems to understand developer activities and help notify novice developers to get up and ask someone for help at the moment they really need it.

In many universities, “greenfield” software engineering capstone courses expose students to a full design, implementation, and test cycle, and in doing so teach students how to work on a team of many people on a relatively large piece of software while remaining in a pedagogically supportive setting. These students take on roles such as requirements engineer, developer, tester, and documenter, and work together to deliver software to a customer, usually in an egalitarian fashion. The de facto leader of most of these teams is the teaching assistant or course instructor. But our study reveals realistic work situations that differ considerably from the artificial experience provided by greenfield courses. Many of the social and communication problems we found, especially with Xavier and Wallace, were rooted in the anxieties of working on a large team with a large legacy code base. The anxiety of being the most junior member of a team incurs the need to impress everyone. The anxiety of not knowing the code at all requires “wasting” time to learn it. They feel anxiety in taking too long to solve problems. Courses that incorporate teamwork typically do not address these insecurities.

Instead of a greenfield project, a more constructive experience might provide students a large preexisting code base for which they must fix bugs (injected or real) and write additional features. Incorporating a management component would be valuable, where students must interact with more experienced colleagues (students who have taken the class previously, who can act as mentors) or project managers (teaching assistants) who teach them about the code base or challenge them to solve bugs several times until the “right” fix is found. During the development process, students could be asked to log bugs in a bug database, develop bug reproduction steps, and/or triage the importance of the bugs given some planned release schedule.

In large software projects, bug fixes are not just code changes. There are many possible fixes for any particular bug, and each proposed fix has to pass a social bar in addition to a technical one. Simulate some possibilities: how “big” is the bug fix? How many lines of code does it touch? The more lines of code changed, the more likely you have introduced a new bug. Does the fix touch code that is frozen at this point in the development cycle? If so, find another fix that masks the bug in unfrozen code. Instead of grading students on fixing all bugs in their assignments, have them document the bugs and prioritize just the 25% that are most worth fixing, and have them justify their reasoning.

Instructors should take time in class to model meta-cognitive skills for students. How do you know if you are making progress? How should you organize your thoughts when asking a colleague a question or bringing them up to speed? How do you get the most out of interactions with a teacher or mentor? How do you take notes when the person giving you instruction is ill-trained as a teacher (and may be your manager)? Students who are well-trained in these arts will make better peer mentors for a new class of software engineers in future software development positions.