Why should you care about Developer Experience (DX)

Bond movies teach what talented developers need

Most 007 movies, especially the good ol’ Connery flicks, have a hallmark lab scene with MI6’s R&D director called Q.

The man ensures James is equipped with life-saving gadgets compact enough for a leather jacket or a tailored suit.

Since Bond sticks his neck out for the Queen, he just wants a bit of support on the job.

Imagine how his stories would look like if James had to drift in a rusty Fiat or roam with a loaded hiking backpack. I say he’d quit around 1963.

That’s exactly what your developers can do if they are left unsatisfied with the work environment.

I notice leaders shield themselves by saying their IT team is already too demanding.

They’re unconcerned about the project, technology, or tools they mandate for.

But as programming easily gets rough, frustrated developers that see the project as boring, too hard, or inconvenient might jump overboard really fast.

It’s time to accept your developers need as much care as your customers do.

Buckle up, as we’ll go on an off-road ride across the several management areas every CTO should cover to keep their software team energized, engaged, and ready for action.

What I believe Developer Experience is

The mythical “developer experience” is a management approach based on the question: “How can we make a normal workday better for our developers?”.

As it’s still a young concept, there isn’t a clear definition, but comparing it to UX offers a common-sense explanation.

User experience used to be a low-priority matter. People just needed the software to work at all.

As the internet grew, people discovered the freedom of choice in technology solutions, which raised their demands.

Now, it’s unthinkable for a digital product not to have a full-time UX team.

UX is caring about users. DX is caring about developers.

It’s a never-ending conversation about improving the work environment, where the facts should come from them, as they know best what’s needed to nail the job.

Three key problems developers wrestle with

In meet & greet talks with some potential clients, I get asked, “why should my software project be attractive to programmers?”.

There’s also a popular saying they share — “I’m already paying”.

Cash isn’t enough to make employees productive. Removing the roadblocks they face will.

Spaghetti code that drains the soul

Say your company has a 10-year-old system that has seen little maintenance.

What if you want to rebuild it into microservices?

Adjusting projects with unpredictable, non-documented logic is infuriating. Developers will flee from such at the first chance they get.

The alternative might be to explain why adding a new field crashed the package order form.

Fixing errors from a few years ago? It hurts less to say “bye”.

Working with technology that’s near retirement

Trends fool us, programmers included. They want to work with technologies that sound cool.

Then this happens — your developers come back from a full-stack conference electrified about new solutions.

The CTO says that even though it makes sense, the system is too rigid to implement them anytime soon. 

The vision of being stuck with an inflexible stack for months might push people out of the project just after three months.

Software made of hieroglyphs 

What happens with an app that dozens of developers have worked on? It ends up like a painting shaped by 100 artists.

You can’t figure out what the hell is going on. 

Some difference in programming style is indeed acceptable, but if your employees have to work with 5 different syntaxes used for one component, their productivity will soon burn out.

Remember that talent is hard to replace.

Even in terms of costs and time, it makes more sense to nurture the developers you have right now by understanding what they need to feel empowered.

The long-term benefits of Developer Experience work

Drop the myth that employees need to suck it up and just work.

DX is not a new fad but a reality that leaders can’t ignore if they want to catch and retain top talent.

Yes, it needs investment, but it pays off and CTOs can’t look away because there are plenty of open doors at companies investing in DX.

Count in the “cool brands” like Google, Square, or Booking.

Now if you don’t chip in, your developer’s effectiveness goes into emergency landing mode.

They can’t be motivated with a whip.

Once they start leaving, will you have five months to recruit an equal professional?

The word may spread that your project is unfriendly, which then leads to a barrage of bad reviews on Glassdoor.

By working on developer experience, you in fact work on increasing your team’s morale, productivity, speed, and engagement.

If you need to see the science of that, consider this 2020 study of +440 senior executives on “Developer Velocity” from McKinsey:

According just to their research, good DX directly contributes to market growth, innovation speed, and overall business performance.

“Companies in the top quartile of the Developer Velocity Index (DVI) outperform others in the market by four to five times.”

McKinsey’s 2020 study by Sivrastava, Trehan, Wagle, and Wang

Talk with your seniors over a couple of teas (of course), and you’ll realize that they see perks like pension, healthcare, and remote-work just as welcoming gifts.

What they’re looking for is a sense of impact which comes from working in a supportive environment where processes and tools make their work-life fulfilling.

This is where DX starts

On a scale of 1-10, how happy are your developers?

Every software project has roadblocks. Developer experience work is about getting them out of the way.

In making your development process smoother, you might have to consider two points.

On one side, think about what your software is built with.

On the other, consider what technology partners you integrate with.  Saving pennies on budget-friendly solutions can mean spending more.

Cheaper solutions equal worse DX where development speed drops in time.

You can even hear that your development team “can’t” work on something, where they mean “we don’t want to, because it’s too hard to integrate with this.

If you want to put out your team’s frustration, here’s what you work on.

Internal factors

Factors that shape your software

• Stack choice
• Language choice
• Documenting projects
• Managing a code style book
• Limiting technology debt
• Tool access
• Giving credit
• Providing buffer time for refactoring
• Encouraging initiative

External factors

When your developers integrate with external software

• Easy integrations
• Development FAQs
• Development tutorials
• Providing a sandbox environment

If there’s one thing to meditate on, it’s the stack. The developer’s treasure chest. Is it loaded with gold or dust?

Technology choice is the big deal-maker

Since I’ve been in the field, I feel like our tech stacks change 180° every 3 years or so.

I prefer to have good people on board rather than the latest-gen technology. 

Remember you can transfer the team’s experience between projects. as veteran programmers have the tricks and shortcuts that a 2-year Svelte adept won’t have.

Still, leaders have to keep up with what’s “hot”, as long as it’s usable. So where’s the balance?

React, Node, Symfony, and other technologies we recommend to clients have years of documented support, which makes the developer experience better for both management and programmers. 

Without a rich pool of know-how to source from, coding becomes too much of an experiment, and the point is to make viable solutions that fuel business.

How to improve the developer experience starting now

Ancient Egyptians believed that if you name something, you can control it. How are the discussions on developer experience at your company?

Put your running thoughts about hotfixes, a strategy, or a dedicated DX team aside.

What matters is to introduce a new conversation to the table about the idea.

That already can “wow” your developers who will gladly tell you what they need.

Here’s how that might look in practice.

1. Write up workflows in Confluence

Why does it matter

Explaining the same issue over and over steals precious hours from developers that they desperately need to deliver

To cut down on workflow issues at The Software House, we’re documenting best practices in our Confluence knowledge base.

A project entry might have one document for development documentation and one with DX recommendations. Employees can feedback on any highlighted sentence, so improving the wiki isn’t overwhelming.

The knowledge base saves us from the tremendous effort that project onboarding needs, which lets people focus on delivering sprint tasks.

They feel their voice really matters, because it’s an open book of comments, wishes, and requests.

2. How about a team survey?

Why does it matter

Hear what employees don’t admit to at meetings.

Google forms will do. If there’s tension around mid-project scope changes, start there.

Finger-pointing? Look at that too.

But focus on resolving the problems that frustrate your programmers the most instead of reinventing each process.

3. Your own product must be representative

Why does it matter

Admit to mistakes right away and remember to cherish everything that works.

UX is still what programmers monitor closely even if they’re backend focused.

Say you have an e-commerce platform with a persistent 40% abandonment rate for the total purchasing journey. 

In a time where usage data lets you optimize anything (Booking and Amazon’s bounce is at a low 35%), it means that your Product Team is overlooking something. That’s still fine.

But if your own developers have already flagged a performance issue at least 3 times… You better not block them from fixing it.

Since they do care if what they build is cool to use, treat developers like friends and like customers at once.

4. Straight communication

Why does it matter

Development teams want to get an honest “yes” or “no” answer first.

Studying rows of syntax formulas turned programmers into very observative and selective people.

They want to stay updated but don’t have the time for debates, because there’s always a fire to put out.

In fact, 61.5% of them have only four hours or less to code per day, so how they speak on-point to be efficient — and to recharge the brain.

Honesty in communication with developers pays off because it helps resolve matters faster.

What they really appreciate is the heads-up about matters that affect their workflow.

Also, always be ready to answer “how” your decision contributes to the product’s growth.

They might know better.

5. Professional coding courtesy

Why does it matter

Show your developers how to code like a professional, and you’ll see measurably greater productivity.

Professionals have standards they stick to.

When they’re consistent in following them, other programmers feel more confident as they can expect what happens. So don’t do anything you wouldn’t like.

Help your colleagues learn to follow code, SDK and API guides with the support of your seniors to save countless hours wasted on decryption caused by missing release notes.

To me, code reviews are mandatory.

The irony is, that you need to invest time in quality assurance.

Then, unless the team practices writing clean code now, the debt accumulates until a project needs to be re-architected.

If you’re a CTO, that day might be on your watch.

Unless the team practices writing clean code now, the debt accumulates until a project needs to be re-architected. If you’re a CTO, that day might be on your watch.

In my work with one fintech asset investment platform, we could’ve hardcoded functions in one day.

Their CTO insisted on assigning 2 weeks for each task, believing that quality deliverables help ease developers’ jobs.

Because of this, the project stretched into years of collaboration, but the final product is much more scalable, as the people behind it can tweak it easier.

6. Friction logs

Why does it matter

There are user stories and there should be developer stories for the team lead to help them unblock their workflow.

Aja Hammerly, a Cloud Advocate at Google, revealed the company expects developers to continuously register potential and actual user roadblocks while engineers build.

An example log centers on the action the customer wanted to take, the easiness of use, plus pains and gains.

This philosophy empowers Google’s product simplicity that contributed to its worldwide success. 

The concept isn’t limited to usability testing, as some Developers report work or product friction logs.

They serve as a reference point for the CTO, DevOps, Product, and other key stakeholders who will be able to provide speedier support, as a structured story written once cancels multiple meetings.

Whatever happened during that failed API integration will be clearer in writing.

Do it in Jira, or anything else — just follow the accepted formatting.

7. Easy integration

Why does it matter

Technologies that are too mind-boggling vanish in a blink of an eye.

Consider Stripe for a moment.

On their website, developers have everything served on a plate under three rules: API integration must be fast as thunder; no question stays undocumented; there’s minimum work required.

There’s also a sandbox that works like the production environment, but it’s separate from the API, so you can’t break your code IRL.

Stripe’s early product adoption boomed because systems can connect the gateway in just 2-3 hours thanks to their developer experience philosophy.

If you sell to developers, study their profile carefully.

If you don’t, by creating a developer-first workplace, you can onboard new talent in dozens if not thousands

. They’ll talk about it with their code buddies.

“Let’s talk about DX”

Introduce a new management concept, and you’ll most likely face early rejection.

Explain how that concept affects the entire business, and people will listen closely.

The fact is that optimizing developer experience must be a fundamental goal as it’s directly connected to reducing employee churn.

In the long run, it brings out the best performance from people regardless of the twists and turns on the product roadmap.

Your software project might seem attractive, but is the department employee-friendly?

Remember that Boards already talk about what employees should value.

The conversation about DX only shifts to what our engineers value, why is that, and how can we do better.

Now go ahead, 006, drive your Aston Martin back to the HQ to discuss the matter.