This misconception is particularly dangerous, especially in large, complex development environments. We saw it mostly in new hires from outside the U.S. The perceived need to “perform” and not “reveal deficiencies” makes for much wasted time. It also seems to contribute to poor communication and a longer acclimatization. Communication suffered both by waiting too long to seek help and by trying to cover up issues that the novice perhaps felt he “should know.” Additionally, novice developers were occasionally seen to continue to work on issues deemed (by teammates) either not worth solving or someone else’s problem. Though our sample size is extremely small, it’s worth noting that this misconception was not evidenced in new hires native to the US.

Over the two months of observation, the subjects in our study became more self-confident, less stressed-out, and gained self-esteem. At the final exit interview, many participants revealed that their early worries and expectations had been unrealistic.

This is one of the most ubiquitous misconceptions, likely driven by the lack of team-based development and the deadline-driven grading system in academia. Novice developers had the perception that anything they found that was “not working” had to be fixed immediately. Even though they had been made aware of established procedures for reporting, triaging, and dealing with bugs, they often sought to work around them. Some novices were chastised when “caught out” in this respect, but it appears to be a very ingrained belief and one that would require time to drill out of them.

Not so much a misconception as a daily plea, the desire for accurate and findable documentation was pervasive. Even though some of the more experienced novices accompanied these pleas with recognition that such documentation becomes stale quickly, they still wished that more existed. More experienced novices desired information about people in their environment, i.e., whom to go talk to about specific issues or code. They recognized that the complexity and timelines of software development limit documentation, and that people are considered the most valuable documentation resource.

Based on explicit statements made by subjects (Umakanth, Timothy, Vadim, Zach) and contrary to explicit observations, it is clear that novices almost always waste time, effort, and money by flailing—and do not recognize that they are stuck. This may not be a surprising result, as explicit instruction in meta-cognitive skills for programming is not common. Although greatly frustrated at these times, novices seem to lack the resources for either recognizing they are stuck or, perhaps more likely, the resources to do something about it. Notably, despite a greater propensity for reflection on their own progress, PhD graduates were just as likely to get stuck and flail when trying to solve a problem as the BS graduates.