The making of a good Developer Experience (DX)

7 min readSep 23, 2022

🏷 #dev #softwareengineer #dx #developerexperience #scaleteam

Table of Contents

- What is DX?
- The Bad DX culture
- Good Developer Experience
  - Build Strong Culture
  - 80:20
  - Physical Safety
  - Stability and Reliable
  - Automation
  - Process
  - Documentation and On-boarding
  - Ease of Use
  - Self-Service
  - Knowledge Management
- Benefits

What is DX?

The term “DX” is a combination of the phrases “developer” and “experience” it represents how a software developer experienced when they began to design a system, product, implement a piece of code, how easily to delivery the product and how effortlessly the user will get the software.

The feeling may be associated with either positive or negative experience.

A simple way to tell whether a new hire is feeling positive or negative is really to look at how they feel throughout their first week on the team. It seems to be pretty simple, right? The term “first impression” also applied to software development.

Finding the best tools for your team is just one of the objectives of DX; it’s also important to create the best development experiences culture in your company.

There is no one best practice or uniform norm that applies to every team, therefore it is up to you to choose whether your experience will be positive or negative.

The Bad DX culture

Poor dx can have an impact on engineers and businesses. Here is the result of poor DX.

high turn over rate
high effort, but low return
blame each other when found poor work
low velocity, and low agility
low output, and low outcome
mini-silo workplace
no flow state, and not funny workplace

Good Developer Experience

A good DX can lead result in the same number of developers, but they can do the task more quickly, with higher quality, and with a lower turnover rate.

Similar to UX, where a great experience results in a quality outcome, DX enables your staff to have quality time to concentrate on tasks at hand while still being productive.

Build Strong Culture

Poor recruiting practices will create a poisonous culture. You are not required to hire the individual right away. The AAA player has excellent hard skills as well as soft skills and behavior that is appropriate for your working culture. If you are a manager or team leader, one thing you must do is hire and dismiss individuals. Take your time to carefully choose the best candidates and act swiftly to terminate anyone who does not fit in with your team.

Team work is build from strong culture. A good culture can help team to have positive energy. When team members encourage difficult things, but feel that always received good energy from the team, always feel supportive team so no matter what problems they have, they are ready to fight with it, and want to make it successful as intended.

Be aware massive energy drainer to your team. You want to stay with someone who is comfortable, inspire you so your team needed it too.

Don’t let toxic culture pulled down your team momentum and cracking the culture.

80:20

In addition to the main task, 20% of the time should be reserved for team activities such as knowledge sharing, hackathons, ice-breakers, retrospectives, remote game activities, research, or discovering something new together.

Physical Safety

Every software developer need to have area of experiment, learning something new, and space for failure. Risk occurs everywhere and at all times, but we can calculate it. and deal with it by learning from past mistakes.

Stability and Reliable

The essentials that ought to be included are listed below. To perform day-to-day work effectively.

software development tools such as good CI/CD, pipeline, great productivity tools
working tools and equipment
service, system and product
life stability e.g., company support, benefit, team, friendliness and honesty

Without stability and reliability, there might be dramatic differences between engineering and product, all the way up to the customer.

Automation

Automate where possible. Repetitive tasks like routine, duplication tasks your team should focus configuration where it configurable.

if you sent a configuration in sheet and sent to sre to config it, please don’t do that anymore. You should invest one-time to automate it.

You should respect about “Quality of time”.

Process

Make a process to standardize and cut stages that will reduce your agility. Do not create a process that overwhelms your team, and have not more context switching when need to delivery a software.

Documentation and On-boarding

A good documentation like you have a map in a large world. This is a engineering practice that I encourage to my team all the time.

you document, your own service
keep it up-to-date
update document is one of team sub-task, if have a new service, or enhancement
technical document is one of presentation skill
and lastly, keep in mind that if you take a vacation without worries anything, please provide quality of documents 🤗

Centralized Portal / Organize your document space

Define the clearly documentation structure and where to keep it. Here is my simple guideline.

==================================
Brain Writing / Drafting the idea
==================================
- Miro (online collaboration board)
- Physical board / Post-it=================
Services Document
=================Wiki
<my-service-name> <- briefly the service is
|_ 00 - High-Level Architecture. <-- child-page
|_ 01 - Product
  |_ ...
|_ 02 - Database
  |_ Schema
  |_ Estimation
|_ 03 - Redis
  |_ ...
|_ 04 - Kafka
  |_ ...
|_ 05 - Infrastructure
|_ 06 - Design System
|_ ....
|_ 99 - Production Readiness Review===========
Great Tools
===========
- portal for design system of client side
- swagger / redoc
- zeplin, figma
- storybook
- https://backstage.io/
- ...=========
README.md
=========
- getting started guide e.g., how to run the service
- testing guide
- describe service briefly, and place the link to fully info in wiki
- ...

High-Level Architecture

All services should have high-level design describe the service it is. This one can help team member see big picture of the service, overall, components, etc.

A good experience is when you have story to enhance the service, you can take an architecture diagram spreading in a meeting, so everyone can see the same page that if you have to implement new feature, or fixing where to adjust easily in the system. It can help team to productive and don’t waste time explaining.

Services Documentation

service documentation are includes technical part and product part that consolidate the content together. grab it into same space or close where the team easy to find it and don’t switching the context from many places. define the standard structure of your services documentation.

Ease of Use

Some company limit to access from developer so it pretty hard to investigate the application when dealing with the issues and some time the process need many steps to request and slow to approve. This approach affecting the quality of work to be worse.

quickly to navigate to tools, and jumping to anything of what you need a at all stages efficiently.
The product team should be self-contained to ensure end-to-end delivery, including software development, debugging, and ease of shipping items to production, and accessing easily.

You build it, you run it — Amazon CTO Werner Vogels

I recommend to see this video https://youtu.be/j9fC4raB-bA?t=267

Self-Service

xxx-as-a-servicedid you seen this before? Would it be better if we could serve ourselves at all? without having to wait for someone to make it.

kafka-as-a-service
data-mesh-as-a-service
mongodb-as-a-service
…

They should all switch to the platform’s self-serve mode from manual operations that are restricted by SRE or the infrastructure team. This benefits the team greatly.

There are 2 factors of Platform Engineering. it’s about engineering and governance.

In general, a platform engineer's role is to help developers get software out the door more quickly and with security in mind.https://about.gitlab.com/topics/devops/what-is-a-devops-platform-engineer/

standard CI/CD. once you have new microservice the CI/CD should manual create and config ti your service as well. You can adopt https://earthly.dev/ or write your own hook shell script
provides standard observability tools
provides a channel to access kubernetes cluster via rancher
provide self-service tools and process to request new provisioning
provide infra-structure-as-a-code system
support governance about security
help product team about productivity, or destroy any cloud orchestratio n roadblock

Knowledge Management

great knowledge management can destroy the knowledge silo. You will be a cross-function fully when the knowledge can spreading out to whole team.

Bad knowledge management can lead to silo team that no one can rotate or help others team because of knowledge stuck with some team. Also developer experience gap can lead to feelings of pressure, not keeping up with the team, or being alone, and feel not useful to the team.

Benefits

Since the developer experience is the responsibility of the entire team, not just the engineering manager, team lead, or senior member, I don’t think there is an ideal site that has outstanding DX from day one.

Hopefully, this blog will help you to see the big picture of DX and key benefit that reflect to tech and business perspective 😄