PTSD: Post-Traumatic Software Design
Engineering Insights
In your career as an engineer, you are going to occasionally work on a project that ends in failure. When you do, then it’s important to remember two things:
- This is an extremely valuable learning experience for you; cherish it.
- It’s important to take away the right lessons from the failure and not the wrong ones.
Anyone who works in this field for a decade or more is going to acquire their share of battle scars, metaphorically at least. Software engineering in particular tends to operate at the edge of what’s possible, because all of the easy stuff has already been done and there’s no need to build it again. In other words, there’s a high level of risk, and failure is always a possibility.
There are many reasons why a project can fail. The company you are working for might simply have run out of seed capital, or have misjudged the market by making a product that nobody wants. These kinds of things are outside of your control.
More galling are the technical failures — despite having a room full of extremely bright, highly skilled people, there was some critical obstacle or early design decision that prevented the product from performing adequately. Perhaps the early prototype showed promise, but proved to be impossible to scale up. Perhaps the code base became so complex and incomprehensible as to collapse under its own weight.
Whatever the cause, this is a situation potentially fraught with disappointment, acrimony and shame — powerful feelings. And those feelings can profoundly affect your future approach to technical problems.
There’s a syndrome I call “Post-Traumatic Software Design” (my friend Paul Pedriana calls it “scar-tissue design”) where a software engineer’s design sensibilities are permanently warped by some traumatic experience in their past.
Human beings naturally tend to overgeneralize when reasoning about failure. There’s an evolutionary explanation for this. When you get hurt badly, it makes sense to avoid any situations that are even remotely similar to the one in which you took injury.
“I worked at this startup one time, and we had this database and it was horribly slow — I’m never using a database again.”
The problem is that in the modern, scientifically-based world, success often requires getting a large number of factors right. Many successful ideas closely resemble ideas that have previously failed.
As an example, the Wright brothers weren’t the first people to come up with a viable design for a powered aircraft. The reason they succeeded where others failed was that they were the first to cross a performance threshold. If all you looked at were the previous failures, then you’d never risk spending resources trying yet again.
Another example: the World Wide Web probably would never have been invented if people had simply said “Yeah, but isn’t this HTML just a stripped down version of Project Xanadu? And they’ve been touting that for over a decade, and yet it’s gone nowhere!”
There’s a tendency to dismiss potentially successful ideas, to strangle them with doubt before they are ever born, by comparing them to historical failures. Beware of this trap.
(This is why successful startups are often founded by young people. They don’t have the life experience to know what they can’t do.)
I find that past trauma is one of the most powerful influences on software engineers. And not always in a negative way — sometimes it can be the source of great passion, a powerful desire to go out and fix the damned problem once and for all.
Here’s an example from my own experience: I’d been developing user interfaces for several decades, but I’d never actually watched a visually-impaired or motor-impaired user struggle with a bad user interface. I’d known about “accessibility” in a kind of intellectual, abstract way, but watching that user’s frustration and pain was an entirely different experience.
Since then, I’ve never been able to look at user interfaces in the same way. And I accomplished a lot of positive things because of that outlook (many accessibility features in Google Plus and other Google products are the result of work that I started on my own initiative while working in the JavaScript tools group).
Occasionally when interviewing an engineering candidate, I will ask them to describe some of the traumatic experiences that they have had in past jobs. I find that the answers to the question are often a good predictor of what motivates that person.
Unfortunately, memories of trauma are often unconscious, and we are unaware of how they shape our behavior. It can be a valuable skill to train yourself to look for the signs of bias in your thinking. That doesn’t necessarily mean that your thinking is wrong, but if there’s an aversion to doing things a certain way it’s useful to know the source of it.
At the very least, it will help you form compelling arguments to your co-workers as to why things should be done your way.
Read more in the Engineering Insights series.
