I’ve done a lot of stuff in software—plain old dev work, tech writing, DevRel, plenty of “glue work”—but when pressed for a single designation for what I do I usually say that I specialize in developer experience (or DevEx for short). While I have an intuitive sense of what DevEx is, I’ve often struggled to explain it, not just to friends and family who don’t know much about technology but even to other industry insiders. Then a few months ago, right in the middle of a job interview, I came up with an analogy that’s stuck with me and that I’ll probably use until the end of my days in the industry.

The core/membrane analogy

I think of DevEx as ownership and stewardship over the membrane layer that separates core software systems from the developers who need to use that system to deliver value.

The core systems I’m referring to come in many flavors, such as databases like PostgreSQL, messaging systems like Pulsar, cloud platforms like AWS, and SaaS platforms like Netlify and Fly. These are systems that can deliver enormous value—as attested to by their great popularity—but they all have an absolutely daunting surface area. Think about how much developers need to understand to use these systems profitably:

• Configuration, including general system configuration and sometimes configuration at the app/project level
• An array of tools, like CLI tools and web interfaces
• Client libraries and SDKs for using those systems programmatically
• In some cases whole languages, like querying languages or DSLs

In many cases, platforms are built on top of technology that is itself pretty complex. Think about a company like Apollo GraphQL. In order to use Apollo’s platform, you need to have a solid understanding of GraphQL, and so the “core” system can really be understood as GraphQL itself plus the capabilities that Apollo layers on top.

I might even venture a rule of thumb that the more powerful and valuable the core system, the more potentially vast and multi-faceted the membrane layer that developers need to contend with. I say potentially here for a reason: our job in DevEx is precisely to impose the smallest possible usability tax by making that layer as intuitive and approachable as possible. It’s a multi-pronged task that extends across a variety of domains: documentation, multimedia instruction, API design, blog content, technical diagrams, DevRel (like support and conference talks), and more.

Membrane layer case study: MongoDB

To illustrate this a bit more concretely, let’s take MongoDB as an example (I selected this pretty randomly; any number of platforms would illustrate the point). The core technology behind MongoDB is, of course, the distributed document storage system itself. But let’s face it: that core technology, no matter how fast, reliable, well built, and so on, is of little use without its multi-faceted memrane layer, which includes things like:

• Mongo’s JavaScript-based querying interface
• Database drivers in a variety of popular languages
• A suite of helper tools for things like data import/export and observability
• A Kubernetes Operator for running Mongo on your own
• Data connectors for systems like Kafka and Spark
• Charting tools for data stored in Mongo

That’s a lot of surface area, folks! And each component of the layer needs to have at least all of these:

• Solid conceptual and practical documentation
• Example code snippets and even entire example projects when applicable
• Appropriate channels through which devs can receive help

And every time MongoDB adds a shiny new feature, it adds more surface area that requires a correspondingly broad membrane.

A two-way street

TODO

Just an analogy for now; more to come later

The membrane layer can be quite the many-headed hydra, and effective stewardship over that layer usually requires mastery of all of these:

• The core platform itself. Are you in a DevEx role for a data engineering platform? Then you better have a way-above-average understanding of data engineering.
• The domains that comprise the membrane layer itself, including documentation, DevRel, API design, and technical content.
• Understanding the developers that interact with the membrane layer, how they think, work, understand, search, experiment, poke and prod.

I have a lot more to say about DevEx than this, of course, but I think that this analogy is a useful for lever for conceptually prying open the DevEx space. Analogies like this aren’t just for funsies; they come in handy when you need to encapsulate your day-to-work in an interview or a board meeting or a 1:1 with your CEO. When you work in an evolving field like DevEx, pithy explanations can build bridges and even draw others into the field.

In a future post, I’ll dig deeper and say more about what I believe unifies and subtends the membrane layer: cognition. Until next time!