Hacker Mythologies and Mismanagement

We think of ourselves as introverted: we retreat to a cave when we need to do work.

We think of ourselves as socially awkward: we self-characterize as “hav[ing] poor person-to-person communication skills.” We “don’t realize that it takes work to be popular.” Sometimes, we attempt to justify rudeness by calling it “an annoyingly efficient relevancy engine.”

We think of ourselves as having elevated intellects and intellectual preoccupations: as uniquely picky about working on “interesting” problems. We self-aggrandize. We tell ourselves that we are intellectually superior to everyone else, and that raw intellect — directed to the right places — is the most important thing. We believe that “the most obvious common ‘personality’ characteristics of hackers are high intelligence, consuming curiosity, and facility with intellectual abstractions.”

Within the hacker community, it’s an article of faith that hackers who line up with the Canonical Hacker Personality have developed those attributes in a vacuum. We believe that “the combination of personality traits that makes a hacker so conditions one’s outlook on life that one tends to end up being like other hackers whether one wants to or not.”

But these beliefs about who we are are actually about what makes us feel special.

In other words, software engineers are humans.

As humans, we lie to ourselves. We lie to ourselves about who we are. (We’re smarter than you.) We lie to ourselves about what we do. (We are changing the world, one photo-sharing app at a time.) We lie to ourselves about how best to do it. (In caves.)

These lies pile atop each other and twine into intractable knots. At best, this hampers our ability to do work well. At worst, it creates destructive or abusive work environments.

The Hacker Mythos and Engineering Myths

Photo CC-BY Christine Warner Hawks, filtered.

The myth of the 10x engineer is derived from a game of telephone: a 1968 study by Sackman, Erikson, and Grant, briefly quoted in one chapter of Frederick Brooks’s The Mythical Man-Month. This study found order-of-magnitude differences in programmer productivity on some narrow measures, but was also methodologically flawed. Brooks handwaves past these flaws, and generalizes narrow results, to justify what Brooks terms a “surgical team.” He suggests that engineering management orient itself around supporting and enabling superstar programmers, once they’re recognized — a Great Man theory of programming. To be fair to my profession, the exact team structure Brooks advocates for is increasingly seen as a Waterfall relic. However, the belief underlying his recommendations — that software is best built through a servile anticipation of 10x engineers’ needs — has taken on its own life.

It’s done so, of course, because it plays to the hacker ego. Real True Hackers — the kind of Real True Hackers who think of themselves as some day inventing radically new tech — naturally identify themselves as 10x engineers amidst a sea of unimaginative clock-punching proles.

Another myth, one also sourced from Brooks, concerns engineer ramp-up time and communication overhead within projects, and is derived from his reasonable observation that adding engineers to a late software project makes it later. It can take time to get situated within a codebase and a problem, and it is difficult to do meaningful “new” work when one’s primary job becomes understanding others’ work or explaining one’s work to them. Brooks’ direct conclusions (prefer small teams; respond to schedule slippage with scope cuts and/or reestimation) remain valid. However, popular interpretation of these conclusions has led some to conclude that 1-3 developer silos are the most efficient unit of engineering.

This is done to reduce the need for communication between engineers, lest it unduly burden time better spent coding. Interestingly, Brooks does not devalue communication in this myth’s source material — he characterizes it as legitimate work, just inefficient. However, the hacker mythos simultaneously elevates “communication” to the status of “arcane mystery” and devalues it as a “soft skill” that is less important than technical talent. As such, work practices that require it are considered both impossibly difficult and woefully unnecessary.

“Communication” with “other people” also breaks the flow states that many believe are a prerequisite for writing meaningful code. Engineering flow states are held to be uniquely productive and uniquely fragile, because engineering is special. This myth — one usually deployed to avoid boring meetings — also has its roots in the belief that hackers’ introversion gives them superpowers. The belief, crudely put, is that the ur-Hacker will go into their cave with five gallons of Mountain Dew. Then, after three days’ ritual period of sleep deprivation and muttered curses, they will emerge having birthed memcached.

In some offices, this belief has merely led to an overflowing soda and beer fridge. In others, the perks grow more extravagant. Laundry services, on-site gourmet cafeterias, and other manifestations of Silicon Valley perk culture are all justified under the banner of “minimizing distraction” — in other words, preventing these eggshell-fragile and all-important flow states from ever being disrupted. Even though other departments’ work benefits from “flow” — it’s a universally recognized psychological phenomenon — it’s only the hackers’ “unique” flow that is deemed worthy of preserving at all costs.

Myths as Pressure Source

Photo CC-BY Zach Dischner, filtered.

These myths about engineering management harm projects. In itself, this makes them annoying and expensive. However, they also harm people. This makes them dangerous.

The myth of the 10x engineer creates an industry-wide expectation that competence is not enough — that real programmers are superhuman. It accelerates the industry-wide tendency — one present in all demographics, though it’s disproportionately concentrated in underrepresented groups — towards impostor syndrome, and the self-esteem problems that result are leading indicators for depression and anxiety. It creates an environment in which programmers are pressured to prove themselves through hyperproductivity, leading to burnout and other mental health issues. The myth of the passionate programmer — one related to the myth of the 10x engineer, and derived from the expectation that hackers are irrationally devoted to their intellectual preoccupations — creates similar pressures, accelerating the pressures of the 10x engineer myth.

A healthy industry should not be governed by false beliefs that harm employees and ultimately lower productivity. The net productivity of those who fake 10x performance until they burn out tends to be lower than the net productivity of those who believe that slow and steady wins the race. Also, code that’s written to prove its author’s cleverness is usually bad code.

These myths become truly toxic, though, when they’re used as a management bludgeon, employed to justify vague or impossible management expectations. This is usually silent, nonetheless clear: culture, after all, lies in the things no one needs to say. Myths about 10x engineers are used to make employees feel guilty or incompetent when they ask co-workers for help; truly qualified engineers don’t need help. They are also used to make employees set artificially gruelling paces for themselves — would DHH really need a week on this ticket, or could he do it in two days?

The worst part about the “passion” or “10x” hammer, when it’s wielded — whether it’s with a “do you need me to reassign this ticket?” or merely a disapproving look — is that the programmer it’s brought down upon usually believes they deserve it. A key part of any abusive dynamic is convincing the target that they deserve maltreatment. Usually, this is the hard part — people don’t like believing that they’re terrible, so abusers need to tell them so a lot. Setting impossible expectations is one classic way of “justifying” later abuse; the trick is that the target needs to believe that impossible expectations are reasonable. The 10x engineer myth is a great gift to abusive managers because it sets up an impossible expectation as the “scientifically justified” norm. And managers who wish to use the 10x myth to cow their employees get this tool for free.

Myth and Favoritism

Photo CC-BY Sarah-Rose.

The other side of the 10x hammer is what happens when a manager believes they’ve got one (and only one) of these magical unicorns on their hands. The myth of the 10x engineer provides a natural justification for managerial favoritism, whether this favoritism arises from actual performance, a collegial attitude during meetings, or some other factor that the manager “can’t quite place, but I know it when I see it.” Of course, these conclusions often arise from conscious or unconscious bias on the manager’s part.

Favoritism within teams, especially when it becomes overt, inevitably has a destructive effect on team dynamics and particularly on disfavored employees within a team. Many engineering managers believe that “10x engineering” requires a superhuman concentration that’s easily shattered to uselessness by crosschat, stray houseflies, or co-workers’ requests for a second pair of eyes on a weird stacktrace. When favoritism comes into play, differential enforcement of “quiet time” rules becomes near-inevitable. It quickly becomes clear who gets to talk, who doesn’t, and whether that correlates with any other indicators of preferential treatment.

Favored employees are typically given plum projects — say, those with architectural implications. Coding projects which focus on cross-cutting concerns should, in healthy environments, require accountability to the rest of the team so that other programmers’ work is not adversely affected. However, when these projects are preferentially assigned, that accountability is often discarded out of a belief that the favored “10x” engineer will naturally make superior architectural decisions. In these cases, other coders disproportionately bear the brunt of the ramp-up burden for working within a new architecture.

The flexible nature of many modern tech offices also offers many sites for differential treatment of employees. Whose requests for remote work days are treated as routine, and whose are greeted with suspicion and surveillance? Who has the biggest conference budget, and why? Who has a standing desk, and did they pay for it? Whose code reviews are listened to, and whose are dismissed as pointless nitpicks?

Most of these forms of differential treatment are public, and as such pointedly communicate who is in favor… and who is not.

Myth vs Support Structures

Central to the myth of the Hacker is the myth of the Hacker as a Lone Hero, coding away in a basement with an ascetic disregard for bodily needs. This aspect of hacker mythology combines with the small-teams recommendations Brooks makes in The Mythical Man-Month to produce an abiding belief that a very small number of developers — often just one, and rarely more than two or three — should produce a major feature, or own a given piece of code. When everything goes right, there’s nothing wrong with this belief.

No plan, however, survives contact with reality. When things inevitably go wrong within one of these developer silos, bad managers recall Brooks’ aphorism that “adding [people] to a late software project makes it later” and, instead of asking their employees if they need support, assume that adding other developers to the project would merely increase ramp-up and communication overhead to a point that will do nothing but slow the project down.

This assumption is dangerous. While there are some cases in which more developers would hinder progress, modern development methodologies such as pair programming can be used to make extra hands and eyes more useful. A second pair of eyes, unhampered by earlier assumptions, is often better at spotting potential scope cuts — and cutting scope is the only bulletproof way to erase a schedule slippage.

Most importantly, though, is the effect that help — or even the offer of it — can have on isolation and burnout. As a developer, there’s no worse feeling than being mired in a project whose complexity you underestimated, or staring at an error that stubbornly refuses to yield debug information. Managers who leave these employees to struggle on their own risk burning them out, which carries both business and moral costs. Unfortunately, engineers pervasively believe that communication is harder than it’s worth — that “adding [engineers] to a late project makes it later.” This belief leads managers — and other employees — to try to “help” struggling coders by leaving them alone and stranded when they most need active support.

Of course, if an abusive manager chooses to silo employees to deliberately burn them out, this choice is indistinguishable from that manager merely estimating poorly.

Just Another Day in the Office

Photo CC-BY Lucy Hill.

There’s nothing wrong with recognizing that some software engineers conform to nerd and/or hacker stereotypes. There’s also nothing wrong with recognizing that engineering is a discipline that requires concentration, or a creative profession in which work may sometimes come in difficult fits and starts. But the idea that engineering culture should map one-to-one to the existing and coherent nerd subculture is dangerous. Our myths about engineering become excuses for why someone is struggling. They discourage teamwork as a drag on productivity, rather than seeing it as a multiplier. They encourage coders to Other disfavored employees as “not real engineers,” creating clearly defined in- and out-groups. They encourage everyone to view coding ability as an innate orientation rather than as a trained capacity, which corrupts both hiring and professional development practices.

They isolate everyone — if someone is struggling, they don’t “deserve” a hand up, or a hand in. If someone is excelling, they’re a brilliant uberhacker 10x engineer who should be left alone for their own good and the good of the profession.

Bad management and abusive management, while different, can look remarkably similar. Both bad management and abusive management create isolation, and isolation is the key ingredient that allows abuse on the job — either from a manager or between same-level employees — to flourish. Isolated employees blame themselves. They don’t know where to turn for help. They don’t know where to turn to understand what is happening to them, or why, or why it’s not okay. They just know that something is wrong. They’ll see a manager belittle them in team chat and think that no one cared, when in reality no one noticed. They’ll be undercut in a one-on-one, or put on a project they hate deliberately. From the outside, it may merely seem that those team members are a “poor culture fit” — another myth we can use to disguise and hide abuse.

We have cultural frameworks for recognizing domestic abuse. They’re limited, but they exist. We don’t have many for recognizing workplace abuse. Not when it happens to others, and not when it happens to us. We second-guess ourselves — “Occam’s razor says it’s probably just bad management, right?” It’s hard to assume evil when incompetence will do.

But the greatest gift you can give an abuser is the continued ability to operate unrecognized. The hacker mythologies of lone-heroism, of hypercompetence or irrelevance, of glamorized isolation — these can all make abuse look, to the casual observer, like just another day at the office.