Wallace, Xavier, and Timothy spent an overwhelming amount of their time in communication tasks. Both attended several meetings and got help from others in dealing with bugs. Wallace had particularly high levels of communication due to the low cost of communicating with his team—he worked in a “bull pen” arrangement with four other developers, where it was customary for them to casually request help by spoken means, or offer to provide it in case of sudden outbursts of frustration.

Figure 26-1. Tasks by time for each subject, normalized by the total time + time where events overlapped in each observation. Total observation time in hours is listed in parentheses after each subject’s name.

Xavier and Yadav also spent the largest amount of their time on communication tasks compared to any others, but both also have strong representation in a second task. Xavier spent a large number of hours in design meetings with his team’s feature lead and a team from another product that was involved in his design process. He also frequently engaged in pair-programming and pair-debugging exercises with other novices in his team. Yadav also spent time communicating in bug triage meetings, but spent a good deal of time coding, which often included utilizing documentation to figure out how to code. In addition, Yadav frequently used instant messaging (IM) to ask and answer coding questions with experienced members of his team.

Much of Radoslaw’s communication was about coordination. Radoslaw’s tasks required him to work with several other teammates to analyze and coordinate test runs of a benchmark, and collect and present test results in a report. The test computers were a limited resource, which required a great deal of coordination, as did the development of the shared test results reports.

Overall, communication was a critical and common activity for novices. They communicated in order to get help and to develop and confirm their understanding of how to do their job in relation to their team. Additionally, our tally of tasks novices do may even underestimate the importance of communication. If novices had spent more time in communication with their colleagues, they might have been able to gather information more productively than they did.

The next most common task for Radoslaw, Timothy, Vadim, and Yadav was documentation. Documentation occurred in conjunction with programming and debugging by searching for documentation and understanding it (often of APIs on the Web) in order to comprehend or create code. Novices would also write documentation in the form of bug reports and specification plans. Finally, novices often kept personal documentation to record project management and tool knowledge or to record information that they would need to present at meetings. Several of the subjects made comments to the researchers that they struggled to keep these personal notes organized and accessible. They had no structure for them and desired some help or scaffolding for managing their personal documentation.

Radoslaw and Vadim spent more time on documentation than anything else. In both cases, their time was spent reading documentation (in a variety of sources: textual documents, on MSDN, on the Web, and in emails) to try to understand their team’s code. This was as a result of flailing in other efforts, either to code something or to install/set up their development environment. Vadim thought this extensive reading was not the best use of his time, but as a very new hire, he felt he had no other resources.

The next most common activities were working on bugs and programming. The frequency of bug fixing varied greatly from one subject to another because it depended on the stage of their development cycle during observation. Yadav and Timothy were observed in bug triage meetings, and Wallace’s team had virtual and physical triage meetings, though none were observed. All subjects were observed reproducing bugs (sometimes their own) and understanding why they occurred. Zach was very focused on debugging, often correlating success with a reduction in bug count. At one time, he was resolving hundreds of bugs a day through pattern-matched changes. Other debugging tasks we observed included testing, navigating, and searching.

Three of our novices spent time implementing features (Umakanth, Yadav, and Zach), an activity that combined programming, specifications, and debugging. Subjects observed writing or understanding code often were jointly engaged in a documentation task (to understand how code or APIs worked or by mimicking online code samples). Especially when programming in support of the debugging process, we observed novices navigating and searching through code—a process often difficult for them to manage effectively. Finally, we observed very conscientious code commenting by novices. Sometimes they commented code that they were reading for a debugging fix, even if they were not changing those exact lines of code. In their struggles to understand and become conversant with a code base, they were in a position to appreciate code comments, and seemed willing to add them.

Umakanth’s first project was to design and implement a wizard dialog box using APIs he had never used before. He spent the majority of his time programming, but mostly because of an inefficient technique of learning a new language by trying everything on his own. He might have been more productive and perhaps less stressed if he had spent more time seeking help and less time flailing on his code alone.

Xavier’s work required recoding a project written the previous summer by an intern who was no longer available to answer questions. Wallace worked on a web service whose development life cycle involved writing many small features and fixing bugs on an ongoing basis. As Wallace was new to the code base, he had many questions for his colleagues to answer. In addition, Wallace worked in the bullpen with four other, more experienced developers all working on similar projects. They would answer questions that Wallace had (and vice versa), even if Wallace had not directly addressed his questions to anyone in particular.

We saw novices doing a wide range of project management and tools tasks, such as using revision control systems, building their project, setting up their project or development environment, running auxiliary tools, and creating tools that they needed to support project management tasks and procedures. Project management and tools seemed to occupy an inordinate amount of the novices’ time. In particular, these tasks tended to interrupt their progress. In the extreme, the newest of our subjects (Vadim) was completely blocked in getting set up in his development environment by project management issues. Zach’s team was in an active bug-fixing phase, and he had been assigned the job of eliminating 1,300 new compiler warnings. He separated each batch of removed warnings into a separate check-in, each requiring coordination with colleagues for code review and submission to the revision control system.

Time spent on design depended heavily on the phase of development that a subject’s team was currently in. Both Xavier and Wallace spent significant time both understanding and writing specifications. Testing came up most notably in specific projects for Zach, but was also seen in small instances across a number of subjects.