I’ve written before about the challenge it can be for non-engineers to understand engineering work. I’m not the the first to observe that the non-technical need a metaphor to understand invisible and often abstract output an engineer creates. Traditionally, that metaphor has been physical engineering/construction. Others have already, and rightly, criticized the physical labor metaphor.

Instead of ridiculing the wrong metaphor, I offer a substitute. I posit this: To understand engineers, think of them like writers.

to understand engineers, think of them like writers.

Why is this a good analogy? It explains several aspects about engineering that otherwise seem downright unreasonable.

1. Emotional attachment to work
   Like an author, many engineers see a work project as an opportunity to exercise their creativity and build something the take pride in. Like an author, engineers develop a sense of owning what they create. If the project gets cancelled, handed-off, or drastically changed (especially without notice), compromising their artistic vision, the engineer may experience frustration. But this is natural, how would an author feel in such situations?
2. Difficulty in measuring progress and estimation.
   If software were physical construction, it might be reasonable to have an easily-predictable timeline. One might confidently answer “how far along are we?” But like writing, and unlike construction, everything one makes in software is new. And like writing, progress can’t merely be measured in the amount typed, refinement and reduction are actually an important and lengthy part of the process.
3. Ambiguity and subjectivity of excellence
   Every week somebody writes a blog post on how to find out in an interview who’s a good engineer. And every week it gets (rightly) torn to pieces by commentators. The fact of the matter is that there are many independent components that comprise engineering talent and measuring them is very difficult. Even among the very best stylistic difference might mean two greats may not appreciate each others’ virtues, like Faulkner and Hemmingway.
4. Challenges of collaboration
   And on that note, collaborating can be hard. Like writing, there are an indeterminate number of ways to write software, but each engineer has a style. I can tell you from personal experience that writing software with other people is hard. Both want a sense of ownership and freedom to express their creativity, but must now answer to the confines of the project itself as well as their partner (or team’s) creation. Imagine a group of professional writers trying to work together, of varying cultures, varying talents, varying dispositions, and varying skill-levels. With no objective answer to many issues, engineers reviewing one another’s code is a touchy topic.
5. A need for freedom
   As a creative endeavor, software’s workflow can be unpredictable. A creative solution may come at any moment, often in the shower or a dream. Sometimes, when all the factors align, answers comes pouring out at a great pace. During such times, the absolute worst thing that could happen would be an interruption (or a required meeting). Compromising on artistic process will compromise the product.
6. It’s not work
   One of the most persistent and most damaging misunderstandings I have witnessed is the erroneous perception that engineers will avoid work if they can “get away with it.” Perhaps those who feel this way think of engineering as labor, as if it were physical construction. But writing code, like other writing, is a passion that cannot be avoided. When I go on vacation from work I always end up recreationally writing code within a week. I can’t generalize for every engineer, nor every project. Like a writer, if an engineer really doesn’t believe in her work for moral reasons or is so constrained she has no space for creativity then she may lose motivation.
7. Can we rewrite?
   Another commonality is that due to stylistic differences, every individual prefers their own way of writing things. (And to be clear, in software there is a lot of room for styles, styles that are often so unique that one can often tell who wrote code just by reading it). Each considers her own style clearer, cleaner, or better; often because it aligns so directly with her own thought process. Learning to compromise on this a key skill.
8. Some produce more than 10 times another
   Is there any number of E.L. James that could produce the Great Gatsby? For specialized work (e.g. advanced problem solving, revolutionary user experiences) there’s just no substitute for a prodigy. On the other hand, if what you’re making is the software equivalent of a gossip magazine, having Shakespeare on your team might actually be a recipe for failure.

I want it to be clear that I’m not saying all engineers automatically deserve to have any project that they work on adapted to conform to their artistic whims. I am advising all to be sensitive to the pride and passion that people put into work.

But most of all I’m trying to help people understand engineers. It can be hard to relate to an engineer who expresses slight negativity about meetings, blows off people who check-in on them, never knows how long their work will take, doesn’t like standard schedules, might prefer to work alone, gets disappointed when their work is shifted, or thinks they’re amazing. So if you care to understand and relate, I’ve given you the tools.