Why Developer Experience Proves an Effective Engineering Culture

What happens if we categorize it as second-class quality?

“DX should not be focused on; we need to focus on what is best for the user.”

It is a notion I hear often lately. That is wrong in many ways.

If we have a bad DX or don’t take care of it, we will most likely have severe underlying issues in our process and culture. I can’t understand how technical managers can consider setting Developer Experience as a less important requirement.

What determines the final quality of our product? Or its acceptance by the users or clients? Many factors, of course, but one specific driving aspect is the human being working on the product and its outcome—the Software Developer.

After personally employing many developers and working with external teams in Fellowships and mentorings, I see a concerning concordance:

👉 The DX is also bad in companies where Software Development is treated as isolated fulfillment cost centers.

Based on that, I can say that the distance between Business and Development is dangerously large, especially in these companies.

The Disconnect between business and Development

There are two general types of companies I met so far

A: Focused on improving process, product, and culture. ✅

B: Trying to save a tech organization from a dire situation. ❌

There is not much between those, but what I see in (B) concerns me. DX is an apparent factor in this case since, in (B), DX is neither a focus nor a form of NFR (Non-Functional-Requirement) anyone cares for. Instead, we have the following:

• Deadlines, deadlines, deadlines (or shall I say miscommunicated Milestones to invoke “motivation”?)

• Blameful Environment; Business vs. Engineers vs. Engineers.

• Development Shortcuts lead to the Broken Window Effect and severe technical debt.

• Burnout, or close-to-burnout states. (See: Overcome burnout with

  Richard Donovan
  )

• Mistrust & pressure