The Developer Experience (DX) centric Organization structure

How are we defining it today?

New ways of working such as globally distributed developer networks will require a better understanding of developers’ feelings, perceptions, motivations, and identification with their tasks in their respective project environments. User experience is a concept that captures how persons feel about products, systems, and services. It evolved from disciplines such as interaction design and usability to a much richer scope that includes feelings, motivations, and satisfaction. Similarly, developer experience could be defined as a means for capturing how developers think and feel about their activities within their working environments leading to an improvement on team management and project performance.

Is DX restricted to documentation?

Everybody thinks good docs are important. There is no such thing as a technology that is better than another but has much worse docs. The one with the better docs is better overall because it has better docs. That’s not the technology itself; that’s the world around it. For instance, technology might be “good” already. Say it has an API that developers like. Then it starts offering a CLI. That’s (generally) a DX improvement because it opens up doors for developers who prefer working in that world and who build processes around it. Have you ever seen a developer product with an API, and when you view the docs for the API while logged in, it uses API keys and data and settings from your own account to demonstrate? That’s extraordinary to me. That feels like DX to me.

Is Technology the context to define DX?

Developer experience so far has been a comparative term to describe the product differentiation between two companies. They might be talking about things like APIs, features or might be speaking about the feeling around the tools surrounding the core technologies. Technologies that make things easy are technologies with good DX. In usage as well as in understanding. How easily (and quickly) can I understand what your technology does and what I can do with it? What the technology does is often only half of the story. I think of Apollo and GraphQL here in my own experience. It’s such a great technology, but the error reporting feels horrendous in that it’s very difficult to track down even stuff like typos triggering errors in development. These things are fundamental DX issues.

Is DX only related to coding?

There is nothing more directly DX than the experience of typing code into code editing software and running it. That’s what “coding” is and that’s what developers do. It’s no wonder that developers take that experience seriously and are constantly trying to improve it for themselves and their teams. The difference between a poor developer environment (no IDE help, slow saves, manual refreshes, slow pipelines) and a great developer environment (fancy editor assistance, hot reloading, fast everything) is startling. A good developer environment, good DX, makes you a better and more productive programmer.


There is a strong negative connotation to DX sometimes. It happens when people blame it for it existing at the cost of user experience. User Experience (UX) covers “a person’s perceptions and responses that result from the use or anticipated use of a product, system, or service” . .The definition of UX is still evolving.

Customer experience occurs over time when a customer interacts with a supplier of goods or services. It includes the experience of both a product or service and the process during which the customer interacts with.

Brand experience. In marketing, a brand is a “name, term, design, symbol, or any other feature that identifies one seller’s good or service as distinct from those of other sellers”. In creating a brand experience, the goal is to develop or align the expectations behind the brand experience to create an impression that the brand has qualities and characteristics that make it unique or special. A brand is therefore one of the most valuable elements in an advertising theme.

People don’t want to think about DX.

The best DX is that you never notice the tools or the technology because they just work. For the everyday, average manager, company leadership developer experience is of the least of priorities. “Why we are paying you a lot, so shut up and code,” they say since there are no hard numbers, nor deep thought behind why a company should invest in it.

But developer experience is also productivity and productivity means cold hard cash usually.

The other ramification is the adaptability of certain technologies. For example, I never succeeded to install Java and fire up a repo in Java without extensive googling the error messages. Personally, I would never choose it for my own projects. Compare it with the ease of installing node and running create-react-app…

So the next revolution is taking DX seriously. It will make and break languages and platforms and infrastructure.

Good DX is just being able to do your job rather than fight with tools. Good DX should make the “right thing” default or extremely easy and make the “wrong thing” difficult or impossible, and I think we as developers should accept no less.

Have Fun

Developers, like everyone like to have fun. Keep all your interactions light-hearted and enjoyable for both sides. Remember: If they’re using your product, you’re on the same team. You’re just two people working together to solve a problem. Use your teamwork skills to make the interaction positive and enjoyable.

Thank You

Phani Marpaka

Product Marketing- Technology Writer - Business Development Professional - LinkedIn -

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store