The article linked above talks about the effects of sleep deprivation ‘causing’ impostor syndrome (the feeling that everyone around you is smarter and more capable, and that you have just faked your way along but will be soon found out). While I’m not disputing that sleep deprivation can cause emotional effects that make impostor syndrome more likely, and certainly not disputing that as a group developers are under pressure to sleep less and simultaneously under pressures that make sleeping decently more difficult, the article fails to look at the fundamental reason impostor syndrome, which occurs to people in every field, is more pervasive and consistent among developers. It also fails to look at how the effects of impostor syndrome tend to be self-reinforcing.
Within a very different world than that of software development there is a strong tendency to see the same issue, and looking at the commonality between roles that in an immediate way have little in common can assist in looking at some of the other major reasons for impostor syndrome. In the world of association football, or soccer in North America, it’s known as striker syndrome. Confidence is both a necessity for a striker to score consistently, but also one of the most difficult things to maintain, and the result is that most strikers go through periods of being ‘in form’, appearing to be able to score almost at will, and then through barren periods where they can’t seem to buy a goal, every aspect of luck appears to go against them. Strikers are among the most superstitious people in an already superstitious sport. Superstition is bound to be common in a situation where it’s difficult to conceptualize how you do what you do, and difficult therefore to understand why it works so well sometimes and not others. It’s generally much worse, though, for strikers (and goalkeepers to some extent) than for those that play other roles on the team. Similarly, impostor syndrome affects developers specifically in a way it doesn’t as pervasively affect project managers, testers etc. on the same development team.
What differentiates the roles of a developer and that of a striker from other members on the same team in their respective fields is simple – results are easily judged while the reasons for positive and negative results difficult to determine. While some people do maintain statistics on defenders in football regarding how many goals are scored while they’re on the pitch, and the for/against ratios for midfielders and wingers, comparatively few people pay attention to such statistics because the reasons behind the statistics are not so easily pinned on that particular player. Even in goalkeeping, which comes closest to goal scoring in terms of mistakes being pinned on one person, good goalkeepers aren’t judged on the number of clean sheets they keep when the defense is known to be porous, or the team is known to be configured to attack and score more than the other team rather than to pay more attention to conceding less. Similar roles in a different sport include pitching and hitting in baseball. A mistake in the field has to be blatant, but results in pitching and hitting are easily determined and judged, and the result is that pitchers and designated hitters are both the most expensive players in the sport, if they’re consistently good, and the most superstitious about what allows them to be that way. Project failures are rarely blamed on management, and virtually never blamed on QA, even though in a ‘team’ situation there’s always talk of success or failure being a result of the team as a whole. Similarly the failure of a striker to score consistently is rarely blamed on poor passing from midfield or the wings (commentators who know the sport well may point that out in defense of a striker struggling to score – but that the striker needs defending already points out where the blame initially and most generally falls). A good tester can find problems early before they get buried in a mass of code, and are therefore more easily fixed, leading to better results from developers, but in a similar way the initial and most general responsibility is already on the developers.
The second point, that it can be difficult to determine the origin of specific successes and failures in software development, is also well known. The high failure rate of software projects in general (around 75%) makes it almost inevitable that, after having done a number of projects, some of them have failed no matter how good you are, and the reason for the high failure rate is itself a difficult question to answer. The corresponding high likelihood of the next project failing means that no matter how successful you have been, the confidence you have in continued success is never all that high, while a number of sequential failures can destroy any confidence you might have had. At the same time without confidence failure becomes more likely, because virtually every development project, while including plenty of rote code writing, exists precisely because nothing available does exactly what’s wanted, and so an element of invention, of creativity is required. We have little understanding of where that invention and creativity originates and why it is there sometimes and not others, but it can be demonstrated fairly easily that it tends to not be there when confidence is low. The ‘scientific’ attitude that developers are supposed to have simultaneously makes it more difficult than for athletes to simply put the blame on luck or fate and use superstitions that supposedly affect luck to create a ‘virtual’ confidence that, while the superstition is not real and often fairly ludicrous even to the person involved, can still have real effects in that the confidence gained by the (partial) self-delusion is still an effective confidence, at least up to a point (that the self-delusion is only partial is demonstrated by the speed at which that effective confidence disappears in the face of actual problems cropping up). Ironically, that software development is in any way ‘scientific’ is itself a baseless superstition, but precisely a negative one in terms of supporting confidence, which simultaneously prevents developers from using ‘positively reinforcing’ superstitions, or at least admitting to them.
The general result is the same, though. Developers can have a successful run of projects, but often also fall into barren runs. Since the barren runs are more self-reinforcing than the successful ones, losses of confidence such as impostor syndrome are far more likely than not. The rather large egos needed to be a good striker are also conspicuous in many of the most successful developers, since a high self assessment to begin with helps ameliorate the negative effects of constant judgement of your performance.
All of this can of course be made worse by things like sleep deprivation, the addition of irrelevant pressures to the already high necessary pressures, and other factors. That development is results-driven in a way that most business roles are not, and fault can effectively be pinned on an individual far more easily than in most business roles, is the major factor that makes impostor syndrome and other confidence losses more likely, and therefore more pervasive and more difficult to overcome for individual developers.