When employees first arrive at a company, they face an immediate quandary. They feel the need to prove to their managers that they are smart, productive, and infallible, but they do not know any of the functional aspects of their role yet. Thus, stress and anxiety increase as new employees attempt to master immense amounts of material in a short amount of time, all the while trying to take on tasks that have an impact on the team. Our subjects reflected on this and often regretted their speedy ramp-up. Timothy said, “You don’t need a very deep understanding of one component, but you need a broad knowledge of everything—you don’t want to go deeply in one hole. It will take you longer time and it will delay your progress.” Vadim remarked that he should have spent more time learning: “Put up some extra time and effort (apart from work time) to learn some new technologies, to learn about the product in much more depth...the very first year.” Wallace reflected on his high stress: “I would probably tell myself to not get so stressed about things and take things in stride because it’s no use getting yourself stressed about something. You’re learning, I’m learning, I don’t want to get myself stressed out over these little things....” Xavier mentioned a strategy that most felt reluctant to engage in at the beginning of their careers: “Ask questions of the other devs.” “You can figure out something in five minutes by asking someone instead of spending a day of looking through code and design docs,” said Vadim. Asking questions, however, reveals to your coworkers and managers that you are not knowledgeable, an exposure that most new developers felt might cause their manager to reevaluate why they were hired in the first place.

Perkins et al. classified novice programmers into “stoppers” and “movers” [Perkins et al. 1989]. Stoppers get stuck easily and give up. Movers experiment, tinker, and keep going until a problem is solved. All of our subjects noted the importance of persistence, likely making them movers. Wallace, in particular, noted “the attitude of not giving up here at MS...if I am given a problem I am expected to solve it. There’s no going to my supervisor and saying, ‘I can’t figure this out’.... Ultimately it’s my responsibility.”

Perkins proposed uncertainty and a lack of self-efficacy as the reasons why students became stoppers. However, we see these uncertainty and self-efficacy issues in our movers’ observation logs, even though they are very persistent. When asked, our subjects never admitted to having stopper characteristics: Wallace admitted, “I often don’t know when I am stuck. [But] I try to persevere and find a solution no matter what.” Apparently, being a mover does not imply success, nor is it an attitude that always leads to success, as evidenced by Xavier’s quote on being stuck: “I know I’m stuck when I’ve exhausted the known ways of solving the problem.” A better strategy for getting oneself unstuck is to ask someone else, a strategy hindered by the power inequality and social anxiety of newcomers. Some of our subjects did, in fact, ask others questions. Timothy said, “[When] I am stuck, I go to a more senior teammate and see if they have encountered this kind of problem or situation before.” Often, however, this was only after flailing for a long time and spending many hours ineffectually trying to solve a problem. Consequently, one might propose that these traits of uncertainty and lack of self-efficacy are more applicable to the notion of “noviceness” than to the task of learning to program. Indeed, the organizational management literature finds that uncertainty and lack of self-efficacy are characteristic of any newcomer to an organization [Bauer et al. 2007].

The subjects’ reflections indicate that their technical/functional preparation for their software development jobs was adequate: Zach said, “I don’t think I need a lot more technical skills.” However, subjects indicated they were ill-prepared for the degree of social interaction required: Vadim said that “in university you are focusing on individual projects or 2–3 man team projects. The first thing that anyone is not prepared for and I was not prepared for is collaborating in a team of 75 people, which was 35 developers and similar amount of testers, and [having to] collaborate with all of them.” The consequences of poor interactions are dire (continuing with the same quote): “In [the] fashion that you don’t break any of the part of the core or affect anyone else.” Xavier remarked: “Even if you think something is simple, it’s not. If you think something is a minor change, it’s probably not. There’s lots of interesting consequences, side effects, things that you didn’t think about when you are working on something.” Working closely with teammates was one way to improve the likelihood of success: Wallace said, “What I think I need to improve on is being a team player....When my teammates have a success, or when they need help, I want to be more willing to make their goals my goals as well. Because their success is the success of the team and I want to help the team to be successful.” Finally, regardless of whether it was possible in his university, Xavier expressed a desire to have worked on larger projects with more people. “[I should] get a lot of experience working on a team project with people...not just some stupid homework assignment that only lasts one week.”