Engineer-centrism

It can be pretty easy for software engineers to get a big head these days. The unique combination of:

• Communication, enabled by technology, becoming even more important during a global pandemic;
• The most valuable and powerful companies in the world consisting of tech giants, propping up stock market indices for most of 2020;
• Software engineers being core to the technology which drives these businesses;
• Software engineers continuing to be in high demand for over a decade.

And you can imagine how engineers think of ourselves as not just lucky, but fully deserving of the current renaissance. Note that it was only a few scant years ago when folks insisted that software development is wholly meritocratic, where intrinsic ability and motivation are the primary factors of success1. Add discussion forums like Hacker news, plus decades of Silicon Valley culture, and this narrative of exceptionalism persists.

I call it engineering-centrism.

In particular, I’ve noticed a reoccurring theme: that engineers, in our ability to model and—therefore make sense of—real-world systems, has an elevated instinct in how it really works, irregardless of what has come before. At times, this sense of superiority comes off as mild disdain for folks who can’t sling code2. Occasionally, it manifests as a strong opinion on how other people should do their jobs, and maybe they should start emulating how the engineers work.

Near and dear to my heart, of course, is when those opinions land on the foibles of people management—which happens a fair amount, since engineers do have to report to some kind of manager at some point. Notoriously, Google tried to do away with management altogether in its early days, only to revert quickly after when the structure proved ineffective. More recently, I found this article which claims that the dual career tracks commonly found in tech companies—one for individual contributors (engineers) and a parallel one for managers—exist primarily to keep the engineers from getting too powerful, as they need to be kept in check from the owners and executives. Did I mention that the engineering-centric worldview is oftentimes profoundly cynical?

In a way, I see this inclination as another manifestation of not invented here, meta-applied to the engineering discipline itself. It runs into some of the same fallacies: underestimating the complexity of the problem; assuming that people and teams and processes equivocate completely to deterministic software systems; dismissing existing solutions as imperfect or flawed3. It’s easier to stand aloof and critique everyone else, particularly if you believe you’re only one doing real work, and deserving to stay atop the corporate status hierarchy.

So it’s not a surprise that I’ve never been a proponent of this…engineer-centrism. It was one of the reasons I felt uncomfortable when I worked for Google a decade ago—they were and still seem to be an engineer’s playground, but at the cost of other functions needed to ultimately build great products and businesses4. There are certainly aspects of software development and its practitioners that are unique to our field and deserve special consideration, but we should probably spend more time learning from other fields—many that have been around for much longer.