Over the past year I’ve received a crash-course in Pathological Demand Avoidance (PDA). PDA is an expression of autism, but in some ways it differs radically from what people usually think of when they think about autism.

Most of the autism parents I’m in touch with struggle with how to help their kids cope with unaccustomed experiences: new foods, new schools, family trips. With PDA on the other hand, the novel experiences are the easy ones. Where things get fraught are with rote, mundane, “required” activities like putting on shoes. Even putting on shoes to go somewhere the kid wants to go, like McDonald’s. The need to put on shoes is a “demand”, and with PDA, demands come with innate resistance. The more accustomed the demand, the worse the resistance.

Even without PDA though, adult programmers can have their own kind of resistance to mundane actions.

Wax on, wax off

Years ago I had the honor of TA-ing for a few of Sandi Metz’ Practical Object-Oriented Design (POOD) courses. A lot of people who take the POOD courses are surprised by the format. In particular, they are surprised by the emphasis on extremely disciplined refactoring in order to achieve emergent design epiphanies. The disciplines are strongly influenced by Katrina Owen’s approach, and if you’ve ever watched her refactor code, you have an idea of the level of rigor I’m talking about.

At the end, class attendees always express amazement at the results achieved by dogged commitment to rote, prescriptive steps. But along the way, there’s usually resistance.

Here’s what the resistance looks like: after a few minutes, students start to speed up. They feel like they “get it now”, and they begin to combine steps, or skip steps.

Counter-intuitively, the more they “speed up”, the more likely it is they’ll still be fighting test failures while the rest of the class has finished the exercise successfully.

Programmers aren’t special

I understand why they do it. I’ve done it myself, over and over, for years.

Because this is what we do, right? We’re smart people, programmers. We absorb new skills quickly. And then we accelerate.

But there’s a sort of developer-exceptionalism reflected in this perspective.

Programming is often described as a craft. Think of the other crafts you know:

• You might expect an apprentice bricklayer to practice laying mortar over and over, brick upon brick, for months or years, before being judged consistent enough to be called a master.
• You know that musicians can expect to practice simple scales and arpeggios thousands of times before they are said to be professionals.
• When my grandfather taught me to use a jigsaw, he told me to draw simple curves on bits of scrapwood. And then follow the curves with the jigsaw. Over. And over. And over.

In every other skilled craft I can think of, years of rote, repetitive practice plays a major role.

And yet, as programmers, we often expect to absorb every new skill in a matter of hours if not minutes. Consequently, we often decide that if we don’t see returns on a practice in the first few hours or days of using it, it must have no value for us. Insert a list here of all the “I tried TDD and it was dumb and stupid” articles I’ve read over the years.

There’s a certain amount of impatience reflected in this, I think. And perhaps some hubris.

Fear of growth

But I think it also goes deeper than that. I think this reluctance to practice rote skills also reflects fear.

In The Now Habit, author Niel Fiore explains how procrastination isn’t simply a character failing. It’s a rational reaction to unconscious fear. It’s a choice to avoid an emotionally threatening situation by replacing it with a less-threatening distraction.

For instance, for a doctoral student, finishing her thesis might mean dealing with the even scarier prospect of defending the thesis, and then the far more overwhelming prospect of figuring out what to do next in her life.

The Expert Beginner

I’m going to explain how this fear plays into avoidance of discipline. But first I need to talk about Expert Beginners. The Expert Beginner is a term introduced by Erik Dietrich. Let me paint you a quick picture of a stereotypical Expert Beginner:

Meet Gene. Gene manages the IT department, such as it is, at a successful RV sales company. When Gene was 15, the company’s owner (a family friend) paid him to create the dealership’s first website. Ever since then he’s been managing anything software-related at the company.

Just about everything Gene knows about code, he learned from googling and Stack Overflow. Gene has practices that work for him. Gene remembers all the changes he’s made to the company’s codebases, so he doesn’t see why he should use a revision control system. Or why anyone else bothers with one, for that matter. Typical Enterprise overkill.

Gene has a 28-step checklist for manually updating the website. When he hires new helpers for the IT department, Gene indoctrinates them into the checklist. If they make noise about automating any part of it, Gene explains why it would be impossible and/or a pointless waste of time because REASONS.

Gene is an Expert Beginner. He is the local maxima in technical acuity, and because he has always been able to solve hard problems that no one else understands, he thinks of himself as an expert.

Yes, Gene is a bit of a caricature. But I also think that as developers, we all have a little bit of Gene in us.

The exciting thing about hard things

Because here’s the thing: wherever we’re at in programming, we have certain types of problems we work on which are excitingly hard. These are the problems which justify our being paid the Big Bucks.

If every time the site goes down, we spend hours poring over inscrutable log output, correlating time series and dropping tracers in just the right obscure code points, we feel like we’ve done a serious day of work.

If we spend three days agonizing over an ideal object model, and finally come up with something everyone agrees is an elegant and novel approach, we feel like we’ve justified our existence.

And if someone comes along with a set of practices, or a rote discipline, that promises to reduce one of these tasks to a mechanical, nearly brainless chore, that’s a little bit scary.

Not because it threatens our job! But because once the “hard stuff” isn’t hard anymore, that means we have to grow. With the time and brainpower it frees up, we have to face the prospect of solving bigger problems on a whole new level of abstraction. We might even find that with our software problems no longer as excitingly hard, we have to graduate to solving human problems.

Perspective is scary

I’m not mocking anyone here. This kind of transition is legitimately terrifying.

I remember, as a younger programmer, how I used to accept the dictation of requirements as interpreted by management. And sure, I’d complain about how nonsensical the requirements might seem sometimes. But there was something essentially safe about the arrangement. Management would talk to the customer, and then tell me what to implement. And I’d tell the how it was much harder than it sounded. Then I’d deliver anyway, and they’d be happy, and I’d feel useful. And if it turned out the customer hated it, that was somebody else’s problem.

The idea of ever graduating to a level where I was responsible for keeping the customer happy was scary. Much easier to make sure the technical problems stayed hard and interesting and engrossing. With my time and energy consumed by the essential difficulty of my job, I would always require a buffer between me and the higher-level business concerns.

Pathological discipline avoidance

At the beginning of this article I talked about Pathological Demand Avoidance, and how it makes rote activities feel threatening. At the core of PDA isn’t contrariness or defiance. PDA is all about anxiety and fear, because the brain inaccurately senses demands as mortal threats warranting a fight-or-flight response.

I’m not suggesting that the “programming discipline avoidance” programmers are prone to is actually related to PDA. But I think it is equally rooted in fear. The fear of not being “special” anymore, and the linked fear of progressing to the next, wider context of hard things. The resistance to boring, rote, simplifying disciplines in software development isn’t just about hubris or exceptionalism. It’s an anxiety response to shifting modes and increased responsibility.

[This article was adapted from a SIGAVDI email first published in 2016].