What is developer experience (DevEx, DX)?

Developer experience is a new persona constructed in many organizations to ensure developers’ agility—Learn everything you need to know about DX.

October 11, 2022

Ready to start?

What is developer experience (DevEx, DX)?

Introduction

Developer Experience is important for every organization to ensure velocity, quality, and retention of a good engineering workforce. As organizations get larger and more technologically advanced, expanding their tech stacks, Developer Experience is usually undermined. Developers can become overwhelmed by this growth, negatively impacting their performance. To solve this, organizations have begun hiring teams responsible for maintaining high DevEx standards.

Whether the developer is tasked with a simple or difficult feature, the velocity of development depends on the developer’s familiarity with the DevOps processes and tools available to him as a developer, and there are hundreds of them. DevOps can be an intimidating set of processes for some, so if a developer feels overwhelmed by them, they won’t be as productive or satisfied. This is where Developer Experience is paramount – organizations should actively think about how to provide developers with everything they need in one simplified place  so they can focus on what’s most important.

Developer Experience is a new persona being constructed in many organizations. Their key performance indicator is to ensure agility that was originally undermined due to the extra cognitive load developers had to take on in light of modern DevOps practices. DevEx professionals execute their key responsibility by providing developers with a self-service layer that allows them to interact with everything they need through a Developer Portal.

As demonstrated in the chart above, the unique DevEx Engineer role is a combination of 3 key qualifications:

  1. Developer: To implement this self-service platform, a DevEx engineer must understand full stack development with strong backend and frontend experience. Building for developers requires a developer state of mind.
  2. DevOps: A DevEx professional should also be a DevOps expert to connect the dots between underlying infrastructure and the simplified experience desired by developers.
  3. Technical Product Manager: To provide a positive and enriching experience for developers, a DevEx engineer should understand how product managers think. They need to be able to deeply understand the requirements of their client (in this case, the dev team) and offer them the best solutions.

Due to its name – Developer Experience – it’s natural to compare it to User Experience. Consider DevEx to be the developer counterpart of UX. When we talk about User Experience (UX), we are referring to how external people engage with our software or website and their experiences around simplicity of use, intuitiveness of the product, and the ease of comprehension. With DevEx, instead of basic users, we are talking about software engineers and their interactions and processes within their team and company. It’s about the entire ecosystem of tech stacks within the company, and how developers can best interact without bureaucratic interference or delays or confusions.

Here’s an example: when a developer needs to implement a new feature, they need to know a few things beforehand. Which microservice APIs do they need to interact with? Who owns those microservices? How can they add a new cloud resource with Terraform or Pulumi, how would they roll out a new version, and what environments are involved in the process? In a regular organization with DevOps innovation and advancement but no DevEx team, the process of finding this information can be cumbersome. In a DevEx-forward organization, the developer portal would make this information easily accessible.

{{cta_4}}

Importance of a Successful DevEx

The old way of thinking is out – businesses care more and more about their developer teams and their experience rather than churning out subpar products quickly and burning out their team. The importance of value, rather than cost, is increasing. For this, objective setting becomes an integral part of creating a successful and positive Developer Experience.

The most important objectives and outcomes are revenue growth, improved end-user experience, increased quality of releases, and efficiency. For developers, increased quality of releases and efficiency have direct correlation with their DevEx. They should feel ownership and responsibility over the code they create – businesses need their dev teams to constantly think about coding in a stable environment and in a way that breeds innovation. 

Additionally, they shouldn’t feel overburdened and confused by processes that make their job harder – the complexity of modern tech infrastructures for software development can be intimidating, and successful DevEx managers are focused on optimizing the experience so that developer teams can do their job easily and efficiently.

Poor DevEx can be recognized as bad communication between Research and Development teams. As many people own different aspects of the software within the organization, the lack of a single source of truth that is always up-to-date and synced across all teams will cause unnecessary back-and-forth communication between various R&D personas. The developer has to ping-pong with other developers, DevOps professionals, and site reliability engineers amongst more to get basic ownership information. Therefore, bad DevEx can lead to frustration and churn of developers.

{{gitops}}

Benefits of Positive Developer Experience

1 Stop Instead of 1000

One of the mainstays of a positive Developer Experience is the presence of a developer portal. A well-designed developer portal simplifies multiple different processes into simple self-service clicks, thereby getting rid of the confusion that comes with complex high-level DevOps processes. 

One of the biggest benefits of a developer portal is the transparency it creates between developers and the infrastructure they want to consume. There’s no need for sub-sub-sub-sub tasks for every ticket raised – instead, developers can simply reconfigure into the self-service framework and raise streamlined tickets and requests.

Developers Work with Efficiency

With great Developer Experience and the ease of developer portals, agility can be truly achieved. As developers don’t have to deal with long, tedious processes anymore and can lean into self-service, they’re able to bring back the agility that was lost during the sprint towards DevOps innovation. 

DevEx by Design

The DevOps maturity model is meant to describe and relay an organization’s standing in their DevOps journey in addition to determining what more must be done to achieve desired results. As DevOps is a continuous process, organizations have to make sure they’re consistently keeping up with DevOps processes and goal markers.

As demonstrated in the graphs above, a company without a DevEx team will see Developer Experience suffer as DevOps practices get more advanced. However, companies with DevEx teams will be able to innovate while maintaining great Developer Experience. At its core, the DevEx team decouples the experience developers have from the underlying tooling and infrastructure managed by DevOps.

How to Design Good Developer Experience in Your Workspace

Designing good Developer Experience is a crucial undertaking because it involves a large number of people and moving parts. A DevEx engineer needs to make cumbersome DevOps processes easy for developers so innovation doesn’t come at the cost of great DevEx. 

{{cyberark}}

Implement a Developer Portal

When we design products, we conduct a thorough examination of the impact on customers, the features that they will find useful, and how we can make them even better. For developers, we may apply the same strategies that we use when developing products for them. The goal of DevEx teams determining products is to make sure they are easy-to-use for developers and are suited best to their abilities, as well as the information most relevant to them.

A developer portal is a crucial piece of infrastructure for good DevEx. As mentioned earlier, a dev portal can consolidate all processes into a simple self-service model for developers so that they can easily make requests and raise tickets to help with their work without having to have constant back-and-forth communication with multiple touchpoints. 

Shorten Developer Feedback Loops to Enhance Workflow

The goal of Agile development is to increase velocity of development without sacrificing quality. In this framework, a feedback loop refers to mechanisms that are put in place to validate and receive feedback about the software development process. This includes code profiling and tracing, pull requests and code reviews, continuous integration and deployment, performance validation in pre-production environments, unit testing, and performance monitoring in production.

Altogether, integrated well into DevEx, this process can be very efficient for developers and reduce the cognitive load of getting feedback through tedious processes. For example, code profiling and tracing involves getting immediate feedback about the performance of code. These are done by application performance management (APM) tools as well as monitoring tools. 

Promoting Mutual Understanding and Collaboration

When a company can nurture good Developer Experience, each team is acutely aware of their responsibilities and objectives and to whom they provide service. Each team therefore also has a comfortable place to present their needs and requirements for features that will help them work better. 

Implementing this in your organization is simple. Start by creating opportunity and space for employees to actively share information by conducting lightning presentations and internal conferences where employees from different teams and departments may come together and learn from one another. This will help establish a positive environment in which the team can operate, which will enhance productivity. Developer portals, as mentioned before, can also be a great way to promote understanding and collaboration.

Problems DevEx Can Solve

Great Developer Experience can solve multiple developer-centric problems related to code quality, coordination, fatigue, and demotivation in an organization.

Code Quality

An excellent Developer Experience leads to exceptional efficiency. As mentioned above, when developers receive critiques of their code in a shorter period of time and can access required permissions and data quickly, it allows them to work on their code in a more thorough manner. Most importantly, with quick feedback loops, the developer has more time to concentrate on writing code instead of waiting for permissions and access to data.

Team Coordination

Culture is a large part of a DevEx team’s job. They are meant to improve the culture within dev teams so that everyone feels comfortable within the company. This can be two-fold: improving team coordination through interpersonal initiatives, and also working on projects and tools that can assist with better coordination and collaboration between developers that doesn’t involve complex tech stacks.

Fatigue

Many individuals believe that working overtime will increase productivity. However, this is not true. This fosters a negative work environment, creating an overwork culture and discouraging collaboration within the business. As a result, the employees always feel pressured. However, when there’s positive Developer Experience, the developer has a toolbox of all the things that can enable them to do their work well, thereby reducing pressure. When there’s less pressure, there’s less fatigue, and everyone is more efficient. 

Demotivation

We often hear the term "demotivation" used in reference to developers who are working on new technologies and are unable to grasp concepts correctly. This can also happen when someone is working on a well-known technology but is unable to accomplish the assignment owing to a lack of clear instructions or documentation. DevEx professionals can step in here and gain feedback on what would make the documentation and instructional process easier without having the developer jump through multiple hoops. 

Conclusion

Creating a positive Developer Experience helps developers overcome a variety of problems. It inspires developers and alleviates unnecessary issues that may be affecting their work. It will ultimately save a significant amount of money and foster trust among employees. When employees have faith in the organization, they are more likely to carry out their responsibilities, resulting in significant growth for the organization.

{{cta}}

{{cta_1}}

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}

Open a free Port account. No credit card required

Let’s start
{{cta_4}}

Watch Port live coding videos - setting up an internal developer portal & platform

{{cta_5}}

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

Watch Port live coding videos - setting up an internal developer portal & platform

{{cta-demo}}
{{reading-box-backstage-vs-port}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Starting with Port is simple, fast and free.

Let’s start