Developers’ Learned Helplessness

In the 1960s, psychologists experimenting on dogs found that subjects given electric shocks with no hope of relief learned to be helpless. Even in subsequent experiments that did provide a means of escaping the pain, the dogs passively submitted without trying to help themselves. They had been trained not to learn. Some software developers are similar to dogs who’ve been tortured by sadistic psychologists- in the face of new challenges, they’re just helpless.

Why? Where do they learn that? Writing software consists mostly of solving problems, being confronted with puzzles to figure out. Why would you choose this kind of career if you didn’t enjoy learning new things?

One answer is that developers are trained to be helpless. For some shops, their entire code base is a big ball of mud floating in a toxic pool of backbiting and finger-pointing. When you try to fix some bad code, you own it. Then you get blamed for it. You inherit new responsibilities without getting the time or resources to fulfill them. Developers are rewarded for keeping their heads down.

Or, some shops are extraordinarily territorial. Even well-meaning, diplomatic attempts to take on issues outside of prescribed boundaries are punished. Either way, enough negative reinforcement teaches developers to stop trying.

Learned helplessness also comes up in the context of children with development challenges, especially an inability to communicate. Parents may anticipate a child’s needs too much, doing everything for them without trying to get their input to such an extent that they inadvertently teach them to be passive.

Most developers who are uninterested in learning new things seem more like this to me. They accept help too easily without making an effort to learn things themselves. They settle into a pattern of expecting others to be responsible for issues that they don’t currently know, so they never learn anything new.

In really large shops, you may also have very narrowly prescribed responsibilities on a very big project that make it difficult to break out. I once worked on a six-person team that was tasked with querying data from five (and only five) database tables and making it available to other system components. Even for that small task, we were required to use frameworks developed by other teams. Our exposure to different technologies and problems was painfully small and it took real extra effort to learn something new at work.

But whether your work duties are limited or you’re just lazy, learning to be helpless as a software developer is a game-ender. There aren’t many professions that demand constant re-training in the same way that programming does. If you learn to be passive and not take on new challenges, you’ve set the boundaries of your career. You will last as long as the technology you’re currently familiar with lasts. Who knows, that might be a long time. More often though, you might as well find yourself a new line of work.

This entry was posted in ruminations, software and tagged . Bookmark the permalink.

5 Responses to Developers’ Learned Helplessness

  1. Ian says:

    I like this, Tom. It resonates with a lot of things I’ve been puzzling about and suggests some ways to (maybe) help people dig themselves out of this situation that I hadn’t considered.

  2. TERACytE says:

    Here-here. I can relate to your story. Some developers I have met are satisfied to learn about a new technology, but rarely make any effort to improve the products work with daily. I suspect it is a combination of helplessness & ‘broken windows’.

  3. BlackWasp says:

    Interesting and thought provoking. Especially:

    “They accept help too easily without making an effort to learn things themselves. They settle into a pattern of expecting others to be responsible for issues that they don’t currently know, so they never learn anything new.”

    I wonder if Googling for an answer comes into this category? If so, Google becomes the over-eager parent trying to solve the problems without imparting understanding. (For Google, please read any search engine)

  4. fsilber says:

    One reason for reluctance to learn about new tools is crappy learning materials, which makes learning unnecessarily frustrating and confusing. This was especially bad in the days before we could go to Amazon.com and read reviews of all the books about another technology to find the few decent ones. (For some new technologies, decent books don’t even exist.)

    Most technical writing in our field is infuriatingly incompetent, by authors who seem to be utterly ignorant of these few basic writing principles:

    !! Do not use terms or concepts which you have not yet explained, unless you are pretty sure that your audience is already familiar with them. (Hint: If the terms were coined or the concepts developed specifically for this tool, then your audience is NOT familiar with them.) If you number your sentences from 1 to N, any reader who understands sentences 1 through K ought to be able to fully understand sentence K + 1 without additional reading. That means thinking _hard_ about the order in which to present your topics and definitions.

    !! Do not explain how to do something until you have first explained why someone might want or need to do it. If there are many ways to do something, explain how to determine the best way of doing it in any given situation, or how to distinguish when the choice does or does not matter.

    !! Avoid sentences which are difficult or ambigous to parse. A common blunder is the use of strings of nouns as adjectives. Consider the phrase: “failover messaging database” — is it the database for failover messaging, or is it the messaging database for failover? Don’t make the reader guess.

    !! Give enough intuitive understanding of the implementation so that when the learner observes a program failure he can deduce the kinds of errors that might carry such a consequence.

    I love learning new things — but not if I have to solve riddles and puzzles to do so.

    • BlackWasp says:

      @fsilber. I totally agree. The number of times I have purchased a book and found it lacking are far too high. Even more annoying is when a technology is released, hyped and people want to use it but find that there are no books at all. I found this lately with F#. It was months before any good materials were available.

Leave a Reply

Your email address will not be published. Required fields are marked *