ProgrammerMythologies

One of the major problems with the software industry is that the people who make software lack a healthy Mythology that tells them who they are and what they are doing.

There are programmer mythologies, because mythology is unavoidable—but the myths are all unhealthy. Here are a few of the myths people tell about programmers:

1. The myth of the solitary hacker. The great programmer is a wizard/hacker/genius who understands the machine so deeply that with a few inscrutable keystrokes they can make it do anything. They work alone, writing monolithic solitary code that solves a single, well-defined problem. Often the code may only run on a single machine, because it is written on that machine and never moved: the programmer writes it "in production". A great programmer solves problems once and then walks away. Their programs are perfect at conception, so rigid and crystalline in their beauty that any attempts to modify them result in bugs.
2. The myth of the scrappy team. Programs are written by teams of people who need few special qualities other than above-average intelligence, youthful exuberance, and a knowledge of the syntax and common libraries of one or two programming languages. The most important goal of coding is to build things fast, and it's okay if the code has a few bugs because 99% of users product managers will never see them. It is fine to deploy buggy code to users without obtaining their consent or offering them a choice of whether to upgrade, because that's the only way to find the bugs. All code has bugs, and that's just the way things are. Of course, you want to minimize the number of bugs. That's why you use libraries whenever you possibly can—because code written by a random person on the internet is generally bug-free. Writing code takes more time than any other activity in software development (well, debugging takes more time, but it doesn't count because it happens after the code is deployed) so it is wrong to spend time refactoring or writing many tests, since that would require writing more code. It is also a waste of precious time—and therefore a sin—to deeply investigate the systems on which you depend when simply copy-pasting example code produces software that works well enough 99% of the time. (editorial note: yes, I know this is inconsistent, bordering on incoherent. But this is the way the majority of silicon valley programmers appear to see the world)
3. The myth of the Borg drone. Programmers are an oppressed underclass who, in exchange for what amounts to subsistence wages given Silicon Valley housing prices, must prostitute themselves to the arbitrary cruelty of management. Managers can dictate what one works on, when and for how long, what tools one may use, and whom one may talk to. Rituals and requirements are imposed for no apparent purpose other than hazing: the daily humiliation of interviewing for one's own job at standup, the dreadful annual review, the cyclical futility of retrospectives and postmortems that result in no improvement, and to top it all off the inhospitable Jira backlog filled with incoherent, garbled "requirements". Certain programmers seem to thrive, or at least survive, in this environment, but if you look into their eyes you realize with a sinking horror that they are dead inside—they are going through the motions, gripped by fear, because the alternative is being fired and left to starve. They are now one with the Borg, caught inside the whirl of the giant capitalist machine, whose program is to gnaw and gnaw the world until there is nothing it has not consumed. What makes a good programmer, or a bad one? The question is nonsensical. One cannot be good or bad at programming—one can only obey or disobey.
4. The twin myths of the senior architect.
   1. Good programming is all about abstraction, and at some point you get so good at programming that the code simply disappears. You don't even see the curly braces anymore, you just think in terms of pure abstraction. Great programmers thus get promoted to the role of architect, where instead of writing code, they draw UML diagrams that describe the code other people will write. A stroke of the architect's whiteboard marker can be worth millions of dollars. Unfortunately, ordinary programmers often lack the design vocabulary to even understand the architect's advice, and so the implementation usually falls far short of what was designed. The architect can thus blame the programmers for any deficiencies in the deployed system.
   2. From the working-class programmer's perspective, the architect role looks very different. Architects are ivory-tower idealists whose designs overlook basic practical constraints and often can't be implemented without major modification. Design patterns and object-oriented programming have the scent of architecture on them and should also be viewed with suspicion. In fact, any such hifalutin' ideas are best ignored. Programming is functions, variables, loops, and conditionals. That was good enough for my daddy, and it's good enough for me. However, for political reasons one must appease the architects and try to implement their designs even if they don't make any sense. Programmers can thus blame architects for any deficiencies in the deployed system.

These myths are not untrue, but they are optional. We can decide what kind of culture we want to create. Personally, I want none of these.

One of the problems, I think, is that healthy role models—that is, examples of knowledgeable practitioners engaged in absorbed, collaborative work—are almost completely absent from our cultural vocabulary, and probably have been since our ancestors abandoned the hunter-gatherer lifestyle in favor of agriculturalism. We are attempting to recover a part of ourselves that has been very deeply buried for a very long time.

Here is my attempt at a better myth—with the caveat that it is neither complete nor really an accurate depiction of my ideals:

A good programmer begins by simply noticing things. Occurrences of frustration, anger, slowness, difficulty, and grief are particularly interesting to them, because these point to places where the System of people and machines they inhabit is at odds with itself, generating friction as different parts strain toward conflicting ends. Systems that are locked in inner conflict like this grind the programmer's gears, because such systems generate discontent, and the programmer is an empathetic person.

The programmer, therefore, heals and nurtures the human/machine systems they encounter into a better state. This is a rather difficult intellectual and social task that requires an enormous array of skills. Mastering all these skills as an individual would take several lifetimes, so programmers travel in groups—twos, threes, and fours—to share expertise. This is called "pairing" or "mobbing" depending on how many programmers there are.

A good programmer says "I don't know" a lot, especially when confronted with a large, complex problem. When the code itself is confusing and the documentation is murky, how could they say otherwise? The programmer isn't bothered by this, though. They just look for smaller things to improve. They go on fixing the little problems, until suddenly the right solution for the whole becomes obvious. Then they implement it. It doesn't take long. The pieces fall into place, swish, click. Serenity.

To someone who is watching from a distance, a great programmer appears to deliberate long and act decisively. Their actions and words pierce directly to the heart of things like skillfully-aimed arrows. But this does not mean that everything they do is perfect at the start. When they go public with an idea it is usually the culmination of a lot of solitary experimentation and trial and error. This habit of reticence is maintained partly out of politeness—it avoids wasting other people's time—but also simply because it is more efficient. If programmers shared every little thing they were doing, they would have to issue a lot of retractions and corrections, and that takes time.

One strange side effect of the programmer's habit of reticence is that you cannot learn to be a great programmer simply by watching what great programmers do publicly, because all of the interesting, difficult work happens behind the scenes. The only way to improve one's skills, aside from laborious trial and error, is to work side-by-side with an expert and see what they actually do all day.

The other strange side effect is that management tends to think that the most disciplined, effective programmers always think first and act second, and that therefore the way to prevent problems during software development is to mandate planning phases for everything. Planning for projects, planning for features, weekly planning, daily planning, plans everywhere. This makes no sense, as one can't effectively plan changes to a complex system without making those changes (in a safe sandbox) and seeing if they work. You have to experiment: form a hypothesis, test it, and refine it.

In spite of management's misconceptions about what programmers do, the programmers sometimes find a way to do a good job anyway. They accept the ensuing accolades humbly, because they know they are only a conduit for the system's internally-generated urge to heal itself. When the programmers fall short of their goals, they are not too dismayed, no matter how upset the managers are, because they know that in a complex system there truly is no one to blame. If they fail to heal a system, and it withers and dies (or goes on being awful), they are not discouraged, because they know that all systems arise and die within the greater human/nature system whose inexhaustible drive to heal itself the ancient programmers called the Tao. The Tao is like gravity: it can't be used up, so why worry about failure? Another interesting problem is just around the corner.

The ancient Masters were profound and subtle.
Their wisdom was unfathomable.
There is no way to describe it;
all we can describe is their appearance.

They were careful
as someone crossing an iced-over stream.
Alert as a warrior in enemy territory.
Courteous as a guest.
Fluid as melting ice.
Shapable as a block of wood.
Receptive as a valley.
Clear as a glass of water.

Do you have the patience to wait
till your mud settles and the water is clear?
Can you remain unmoving
till the right action arises by itself?

The Master doesn't seek fulfillment.
Not seeking, not expecting,
she is present, and can welcome all things.

In pursuit of knowledge,
every day something is added.
In the practice of the Tao,
every day something is dropped.
Less and less do you need to force things,
until finally you arrive at non-action.
When nothing is [being] done,
nothing is left undone.

Act without doing;
work without effort.
Think of the small as large
and the few as many.
Confront the difficult
while it is still easy;
accomplish the great task
by a series of small acts.

The Master never reaches for the great;
thus she achieves greatness.
When she runs into a difficulty,
she stops and gives herself to it.
She doesn't cling to her own comfort;
thus problems are no problem for her.

What is rooted is easy to nourish.
What is recent is easy to correct.
What is brittle is easy to break.
What is small is easy to scatter.

Prevent trouble before it arises.
Put things in order before they exist.
The giant pine tree
grows from a tiny sprout.
The journey of a thousand miles
starts from beneath your feet.

Rushing into action, you fail.
Trying to grasp things, you lose them.
Forcing a project to completion,
you ruin what was almost ripe.

Therefore the Master takes action
by letting things take their course.
He remains as calm
at the end as at the beginning.

When he makes a mistake, he realizes it.
Having realized it, he admits it.
Having admitted it, he corrects it.
He considers those who point out his faults
as his most benevolent teachers.
He thinks of his enemy
as the shadow that he himself casts.

The ancient Masters
didn't try to educate the people,
but kindly taught them to not-know.

When they think that they know the answers,
people are difficult to guide.
When they know that they don't know,
people can find their own way.

If a country is governed wisely,
its inhabitants will be content.
They enjoy the labor of their hands
and don't waste time inventing
labor-saving machines.
Since they dearly love their homes,
they aren't interested in travel.
There may be a few wagons and boats,
but these don't go anywhere.
There may be an arsenal of weapons,
but nobody ever uses them.
People enjoy their food,
take pleasure in being with their families,
spend weekends working in their gardens,
delight in the doings of the neighborhood.
And even though the next country is so close
that people can hear its roosters crowing and its dogs barking,
they are content to die of old age
without ever having gone to see it.

—Tao Te Ching, trans. Stephen Mitchell