Software developers spend 35%–50% of their time validating and debugging software.1 The cost of debugging, testing, and verification is estimated to account for 50%–75% of the total budget of software development projects, amounting to more than $100 billion annually.11 While tools, languages, and environments have reduced the time spent on individual debugging tasks, they have not significantly reduced the total time spent debugging, nor the cost of doing so. Therefore, a hyperfocus on elimination of bugs during development is counterproductive; programmers should instead embrace debugging as an exercise in problem solving.
It is more appropriate for programmers to focus their efforts on acquiring and encouraging effective learning strategies that reduce the time spent debugging, as well as changing the way they perceive the challenge. This article describes how effective problem-solving skills can be learned, taught, and mentored through applying research on the psychology of problem solving, conducted by Stanford's Carol Dweck and others.
Enjoyed this article and the framing of debugging as general problem-solving and the growth vs fixed mindset. Another interesting aspect is that the mindset for development for most programmers is growth (if they're good), however when it comes to business operations, management, sales and marketing, or even graphic design most programmers are in a fixed mindset and don't see themselves as able to grow their knowledge in those areas.
Unfortunately, this excellent article has a weak point: assuming developers are in a subordinate role.
"For managers, mentors, and educators, this is also true. Explicitly allow colleagues and students time to work on other problems. Students and employees will not usually ask to work on something else, so it is crucial to grant folks the time they need to process information."
Knowledge workers such as programmers, and students who are becoming programers, cannot be in a subordinate role. Because of the nature of the work, there has to be a certain level of autonomy given to them. This is true even of outsourcing shops where the assumption is that the programmers are all in a fixed mindset and can only do tasks according to an exact specification, little creativity.
In the future, I hope that developers will be in a stronger role where they can just take the time to work on other problems without having to ask or having to wait on a kind-hearted manager to take pity on them.
Thank you for the feedback! I completely agree with your points. I can see how you came to that conclusion based on the paragraph, so perhaps some clarification of intent is in order. I certainly did not mean to make an assumption of dominance or subordination in recognizing differences in professional or academic roles. And apologies for the length of the reply -- like Pascal, I'd have written a shorter reply if I'd had the time.
That said, while I agree that knowledge workers benefit from roles that allow for creative autonomy, and that we should promote such environments, many professional and academic institutions aren't set up in this way. It's certainly outside the scope of my article to change that. But assuming that they exist (because they do), my hope for someone in such an institution reading this article might be informed to recognize when they should be allowing for more creativity and varied work. Indeed, to recognize and be cognizant of the fact that it is possible to stifle your developers!
Secondly, power and subordination can be assumed roles. A leader who assumes / asserts power (without first garnering respect) is often surprised to have little actual influence on work output. Similarly, a leader who does not operate this way may be surprised to find that some employees / students respond as if they are in a subordinate position. Since these roles can be assumed (even when no hierarchy is strictly enforced), these sentences hopefully inform individuals in leadership positions to be sensitive to the needs of those they "supervise" (for lack of a better word). It is possible that even given creative autonomy in a collaborative environment, some folks (especially neophytes) simply don't feel empowered to switch tasks without first receiving explicit direction. Furthermore, this isn't necessarily an indicator of a fixed mindset in the employee / student: it could be a cultural thing, a lack of self-awareness, or other things I've not thought of.
Finally, the self-theory research shows that students learn best when both the teacher and student share an incremental self-theory. I see no reason that this shouldn't apply to manager / employee relationships, though I'm not aware of research that states this specifically. Practices like segmented study can be effective at nurturing an incremental self-theory, so I was also hoping to offer effective strategies for moving people to that side of the spectrum. If we can do this with techniques like those I mentioned (and numerous others), hopefully we can help develop a "growth mindset" within the entire organization. (There is some research showing that entire orgs and businesses organizations effectively operate somewhere on the self-theory spectrum.) This might help address some of the things you mentioned regarding bizops, management, sales, and other roles.
Hopefully this clarifies the intent! It sounds to me like we're very much in agreement about the resources, creativity, and autonomy that folks in applied CS (and similar fields) should have in their work and learning environments.
Displaying all 2 comments