Help
- Programming
- Reading and writing specifications
- Debugging (persistence and hypothesis generation)
Weaknesses include:
- Communications
- Cognition
- Orientation (engaging with a large code base and preexisting software team)
Strengths
From our observations, we could see that novice software developers were very well prepared by their universities for programming, design, and debugging. They were capable of using IDEs to code, command-line tools to analyze files, and online documentation to learn about unfamiliar APIs. They tried not just to complete their tasks, but to understand why the code change was the right one to make. Several of them practiced copy-paste coding, either from documentation or from other sections of their team’s codebase. When debugging, all of the novices demonstrated prolific hypothesis generation and persistence in trying all possibilities before contemplating giving up if nothing worked. Most took these incremental failures to solve problems in stride, and though complaints about unfamiliar and undocumented tools pervaded their self-commentary, they seldom reported this to others.
One subject had to review design specifications for two software features. This led to frequent discussions with the head of the team, leading to further clarifications of the design and outlining specific use cases to be considered. This experience led to his relative comfort in his second month, during which he wrote his own structured, lengthy development specification document. Notable here was the team lead’s skill in mentoring, being very open in asking for and guiding his subordinate’s input, sprinkling in background information on the code and design decisions that stemmed from his historical knowledge, and in providing advice about appropriate level of detail for the current design stage.
Weaknesses
The novices in our study experienced numerous problems with communication, collaboration, cognition, and orientation.
An overarching theme of new developers’ communication problems is knowing how and when to ask questions of others. In general, novices do not ask questions soon enough, and often struggle to ask questions at an appropriate level. Sometimes they would go into too much detail in design meetings. At other times, they would not provide enough detail, nor push for enough detail in a response from others, which often led to miscommunication.
The social issues we observed focused on working in large teams, working in conjunction with multiple teams, and working with a large preexisting code base. Many times, novices were explicitly told that there was little written documentation on a feature, and that the original developers had left the team or the company. This was often stated with the emphasis “you are on your own here [with regard to documentation]” and “life will be more difficult because there is no one to go ask about this.”
Understanding how team norms differ from those in academic settings confused some subjects. Timothy learned about his team’s software process the hard way. He had fixed a bug and submitted it for check-in. However, his bug fix was rejected and omitted from the shipped product, not due to code quality, as he had expected, but instead because managers (in other groups) had not yet had time to approve it. Timothy believed he had addressed the customer’s bug, but obediently accepted the decision of the managers so as “not to rock the boat.” He learned that developers are not just programmers, but in some situations, must be their own best advocates at moving their code and ideas through the software development process. A month later, Timothy faced this issue again, but was better prepared. In the bug triage meeting, he described his bug’s status efficiently and spoke in great detail about his efforts to get another group to approve it.
Novices struggled to collect, organize, and document the wide range of information that they needed to absorb. One subject reflected that he usually takes notes in a paper notebook, but “it’s always very scattered, I can’t usually understand them. I wish I had a better way to take notes.” Often, an impromptu teaching session on revision control or the bug database was not necessarily well organized or stated in terms or in a context with which the developer was familiar. In these cases, the developer may not always interrupt for full information, out of concern for using the time of the experienced developer or because the “teacher” barrels through the instruction without stopping. As such, some of their knowledge is built haphazardly in an unstructured and piecemeal fashion.
Novices had difficulty orienting themselves in the low-information environments presented by their project team, code base, and resources. However, this was sometimes coupled with confusing and poorly organized documentation, which was difficult for a novice to navigate or engage with effectively. Novices also struggle to know “when they don’t know” something. Because there is so much new infrastructure to learn, it becomes the norm to have only partial knowledge of a tool or some code. While this is their reality, it also leads many novices to fail to recognize when they are truly stuck and should ask for help. The most recently hired subject exhibited this on a frequent basis. Even after asking for help on some code and getting a very specific answer that the specification was ambiguous, he kept on trying to reason through it.
Some novices felt woefully isolated from their teams, sometimes not even knowing all the members of their team, and rarely knowing who to talk to about certain issues (or where that person’s office was). This impacted both their productivity and frustration greatly. There was a large variation among subjects in their degree of isolation. One subject chose to seek other forms of information and (somewhat fruitlessly) spent much time reading high-level documents in an attempt to gather any information on his team’s work. Another learned early on that all knowledge was most easily discovered through people. Instead of searching for specifications online, he would roam the hallway looking for colleagues to ask. If the first person was not there or did not know the answer, he moved on to the next person down the hall. Only when the person who knew the answer was out of office did he fall back to less efficient forms of knowledge acquisition, such as reading code and debugging through test cases.
Learn more about this topic from Making Software.
Many claims are made about how certain tools, technologies, and practices improve software development. But which claims are verifiable, and which are merely wishful thinking? In this book, leading thinkers such as Steve McConnell, Barry Boehm, and Barbara Kitchenham offer essays that uncover the truth and unmask myths commonly held among the software development community. Their insights may surprise you.
