This was originally titled more broadly “What Does A DevEx Engineer Do”, but that made it into a far too tedious and long-winding etymological exploration of the discipline. Instead, I’m going to tell you what this particular instantiation of the entity does 😄

Let’s Define DevEx first…

Developer Experience (a.k.a. DevEx, DevX) is fundamentally about making the experience for developers a good, nay, positively joyful, one.

It’s about removing the “if you just read the first five chapters of the manual then you can use this … calculator” and instead making software behave as one would instinctively expect it to.

It’s pre-populating fields that can be pre-populated, opening APIs that can be opened, removing barriers and lifting developers up.

It’s about shipping that MVP but with the sharp edges rounded off and plotting a happy path for users so that the cringe-worthy mission statement of companies that “we build software that people love” can actually seem credible.

In a crowded market-place where alternative software is a click away making your software not just functional but also damned easy and enjoyable to use is vital. Developers are no longer chained to their workstations, doomed to use whatever piece of crap the IT director bought on the golf course from some salesman looking to hit their quarterly target.

Developers are empowered to use the software that not only works but which gets the job done efficiently, painlessly, and is easy to use. Don’t confuse easy with simple—complicated software can have a great developer experience - and simple software can unfortuntely also have a bloody awful developer experience.

But Hang On, I thought DevEx Was… $DifferentThing

Developer Experience (DevEx, also DevX) has taken on a similar-but-dual meaning in the last year or two. Both relate to developers and their experience, but one’s audience is developers within a company, and the other’s outside the company.

My familiarity with DevEx is based on the latter - working to improve the experience of developers external to the company, and specifically, those to whom the company is building and hopefully selling a product. Just like the broader discipline of Developer Relations as a whole—of which this version of DevEx is a part—there is no selling to be done here. DevRel, DevEx, and whatever other term you come up with, do not sell. Period. They educate, inform, and entertain the developer base, with a view to the developer then having such a great time with the software that they subsequently decide to open their cheque books and buy the software of their own volition.

The other DevEx which I’ve noticed more and more of recently is that serving the developers within a company. A good example of this angle is the wonderfully-named WTF is DevEx from Container Solutions. Microsoft have a good page on DevEx, and the DevX Community has sprung up to provide a place for DevX practitioners to support each other.

OK, so we’re talking about the DevRel-y DevEx

Both kinds of DevX are important, and there is huge overlap between them - but there are some significant differences. DevX done under the DevRel banner will often include:

In a nutshell, it’s activities that enhance the experience of a developer not only when they’re just using software, but on their entire journey with it - from becoming aware of it, trying it, learning it, and so on.

So… What Does This DevEx Engineer Do?

Isn’t this the same as Developer Advocacy?

To an extent, yes. I’m not interested in a discussion about job titles really, short to say that most people assume a Developer Advocate travels and does conference talks with other activities fitting around it. For me a DevX Engineer is more focussed on the building and writing, than speaking.