Psychological Deformation of Programmers: A View from Both Sides of the Barricades

The very existence of psychological deformation in any profession is typically a rather debatable point, since it manifests differently in different people. However, a general trend can be identified, and perhaps the time has come when we can say with reasonable confidence that programmers do indeed have their own distinctive psychological profile shaped by their professional work.

I've encountered this opinion quite often and didn't pay much attention to it, but when the female staff at our company congratulated the programmers on February 23rd (Defender of the Fatherland Day), affectionately calling them "space troops," I decided to place certain emphases on this matter, since one of my professions is directly related to psychoanalysis.

It's worth noting right away that a programmer spends a lot of time at a computer, so many of the points listed below apply not only specifically to programmers but to "computer people" in general.

Hyperconcentration

Every programmer knows that good, quality work on code requires an extremely high degree of immersion. Some try to isolate themselves with headphones, others set timers, turn off all external stimuli, and so on. The degree of concentration required for a programmer's work is comparable to working at a nuclear power plant. Accordingly, all of this breeds heightened irritability when the process is interrupted, which outsiders perceive as being "obsessed with work" and the like.

In real life, this can also produce its own effects — for example, household chores also tend to be performed in hyperconcentration mode out of habit. For instance, while cleaning the apartment, a programmer won't simultaneously think about a million things or chat endlessly on the phone. More likely, they'll immerse themselves in some task (possibly the cleaning itself) and simply engage in the process. You shouldn't "demand external attention" from a programmer when they're deep in code or some task.

Immersion in Internal Images and Constructs

A programmer's work has its own specifics, which in analogous form is most similar to the profession of an engineer-inventor. If you're familiar with the works of Nikola Tesla, you may recall how he described what happened in his head. In short, Tesla could build a mechanism in his mind, run it, and even "fast-forward it through time" to understand which parts would wear out and where problems might arise in the future. No less complex constructs arise during a programmer's professional work as well. This effect is figuratively called sensory-imaginative construction. If a layperson sees only sets of symbols on the screen, in a programmer's mind this code transforms into entire parts of a world. Just as reading a book creates images and experiences in a person, code is capable of doing the same thing to a programmer. This is precisely why programmers "feel" code, know when it's "beautiful," when it's "dirty," whether it will work, and so on. In some sense, a good programmer is comparable to a fiction writer.

In real life, this manifests as excessive immersion within oneself, especially when the programmer is trying to understand something. If the deformation is significant, the programmer may start building an entire schema of what's currently happening. This is precisely why "constructed schemas of social interactions" — politics, for example — often give programmers a sense of "dirty code" and rejection. In everyday life, this can sometimes be partially perceived as a mild form of autism, although it actually isn't. The person is perfectly adequate and open to interaction with the outside world, but the mechanisms of interaction themselves have this particular specificity.

Low Level of Social Interaction and Its Diversity in Everyday Work

This point is not "de facto," but it does periodically occur and can play a certain role in psychological deformation. Since a programmer spends most of their working time in the world of code, and the only "conversational partners" in it are "methods, functions, objects, modules, packages, and so on," the level of social interaction among programmers is typically lower than in most professions. This is related not so much to how many people are involved in the work, but to whether the person is thinking about other people at that moment. While it's hard to call a janitor's work "actively social," the janitor can still be thinking about their spouse, children, friends, and so on at that moment. But for a programmer, this option doesn't exist — they must be immersed in code. And while there's often a work team, the team typically consists of the same kind of programmers. Programmers sometimes find it difficult to work alongside people from other professions. So if the degree of deformation in the team is high, it only exacerbates this factor (of social diversity in relationships).

Heightened Perception of Cause-and-Effect Relationships

All code must work, but to write working code, you need to understand the structure of cause-and-effect relationships in that code. Simply put: "what, why, and how something happens," as well as "what will happen if something doesn't happen as expected." All of this leaves its mark on a person's thinking. This way of thinking is commonly called a "technical mindset" — when a person tries to find a rational explanation for everything and understand the cause-and-effect chain. Some programmers, in addition to writing code, often get drawn into technical aspects, such as developing hardware for their own needs (hello, "soldering iron people"). Sometimes this can reach unique cognitive constructs. For example, when the complicated clasp of a girl's bra generates just as much interest as what that bra conceals.

From the outside, this can often be perceived as "overthinking the small stuff." What doesn't spark interest for most people can generate enormous streams of thought in a programmer. Accordingly, since the volumes of mental effort applied are disproportionate, the conclusions a programmer draws about real-world effects can sometimes seem "eccentric" and be met with a certain surprise. But surprisingly, if you ask a programmer why they came to that conclusion, you'll most likely receive an entire chain of cause-and-effect relationships, and almost always perfectly reasonable ones. In general, this happens in everyone's head, but in programmers this aspect is often sharpened, and sometimes they're able to bring in analogies for analysis that would never occur to an ordinary person.

Habituation to Formalized Task Specifications

Since a programmer must create code that must work exactly as the task requires, the habit of doing what was said gradually bleeds into other areas of life. But since most social interactions involve nonverbal perception, "guessing," and "filling in the blanks," programmers develop a heightened sense of specificity.

It's not that programmers can't read minds or predict other people's actions, but rather that they prefer to ask one extra question than to "redo everything from scratch" later. Sending a programmer to the store? Say one extra sentence, but spare them and yourself unnecessary questions. For example, not "buy eggs," but "buy a dozen first-grade eggs, the freshest ones." And don't perceive them as a "robot" if in response to your question you receive a detailed instruction with a bunch of "unnecessary details." They're trying to do everything right. If for most people "keep it simple" means "say less," for programmers "keep it simple" often means "say it more precisely."

Victims of "Engineering Glamour"

I risk being "eaten alive," but this point still needs to be covered within this article. This is about not so much programmers as "computer people" in general. Glamour is a normal and natural product of human needs; in short, the motto of glamour could be called "Who's cooler," and accordingly in real life it's "cars, clothes, money, and so on." In the sphere of "engineering glamour," the same principle of "Who's cooler" applies, but with different criteria. Since the main focus of a "computer person" is directed not at other people, as in "real-world glamour," but at their own internal world of images and cause-and-effect relationships, the goals here are also pursued from the domain of this world. The latest smartphone with the best specs; a powerful PC/server/laptop so everything runs even faster; new software that makes autocomplete 32 milliseconds faster; new apps with smoother scrolling and a trendy voice recognizer; knowledge of secret features in the new version of the compiler, and so on.

Just as in "real glamour," "engineering glamour" has its own "icons" — for example, a recent article about the U.S. Robotics modem is a clear example.

So don't ask "why does he need the same phone" and don't be surprised by the answer "it's not the same one — this one has a 500 MHz faster processor."

An interesting point: in some cases, "engineering glamour" can be suppressed by a heightened demand for cause-and-effect relationships. That is, a new computer won't be purchased until its power is actually needed.

Conclusion

Essentially, the entire TV series "The Big Bang Theory" is built on hyperboles of the phenomena described above. If you don't exaggerate what's shown in TBBT quite as much, then broadly speaking, this is exactly the kind of picture you'd observe in a person who was significantly subject to all the listed effects of being a programmer.

Given everything described, it's not without reason that programmers are perceived as "space cadets," but in my subjective opinion, I want to say that if it weren't for the voluntary choice of those who enter the ranks of programmers, they should be given "hazard pay milk" — but in this case, of the psychological variety.

Nevertheless, every person builds their own life, and the actual degree of psychological deformation among "code workers" isn't that great yet. Most have families, friends, and interests beyond code and computers. So don't buy into the cliched "oh, he's a programmer." It's not a diagnosis — it's just a style of thinking :)

Evgeny Leksunin,
"Reducing Entropy in Development"