Without good DX pressure can mount within a team. But what does good look like and – if you need to improve – where do you start?
.webp)
Developer Experience (DX) is about how developers experience a positive sense of flow and enablement from technical products and processes. It is akin to User Experience but from the perspective of developers and engineers on the job.
However, whilst DX is primarily focused on workflow, it doesn't exclude non-tooling factors around their working experience. It encompasses how all company interaction with engineers and demands align to their workflow.
The more integrated these factors are with the delivery tooling they use day-to-day the better...
Today, deploying quality code quickly that is compliant, tested and secure, without support from tooling 'guardrails' can be an anxiety-inducing exercise. Especially with increasingly higher performance expectations.
These guardrails can (and should) be provided by test, security and deployment automation tooling, that is integrated into their workflow processes. Without good DX, provided by automation, pressure can mount within a team.
Pushing for higher performance expectations without good DX is firmly at odds with a viable people strategy for retaining and attracting quality talent, in a highly competitive talent market.
Simply put, if business pressures becomes too great, and investment in the quality of experience for a developer isn't proportionate, there has never been more demand elsewhere for their skills.
Given this, there are very few incentives for talented individuals to put up with a sub-par experience. This is why many organisations are now dedicating entire DX teams to innovate and ensure developers have an ever more positive experience on the job.
As it's becoming a key focus for organisations... what does 'bad' or 'good' DX look like?
and, if you need to improve... where do you start?
When developers are required to constantly switch between tools or processes, the workflow isn’t providing them with a positive experience.
This is because context switching can create headaches arising from decision fatigue.
A poor developer experience is detrimental on an individual level, by making you less efficient while coding.
The same is true for collaboration, as everyone has different tolerances and specialisms with unique working demands.
Those that are disproportionately effected by poor developer experience, or have unique demands to juggle are likely to be most impacted. This may be more senior engineers with other management duties, or indeed junior engineers who are working through a learning curve.
Ultimately, developers work best when they are ‘in the zone’, blocking out all distractions and finding a ‘flow’ in there working focus.
By creating 'good DX' this is what we are trying to enable and protect
Good DX leverages tools in the right way to minimise complexity, context switching and decision fatigue.
Working with minimal interruptions and reduced mental load is possible. This can be achieved by optimising tooling to provide guidance and quality checks on their work before allowing deployment.
The Integrated nature of the tooling to typical delivery tooling (such as Azure DevOps or Octopus Deploy, etc) is key to aligning support to the process of development.
In bringing support to where the delivery workflow happens, automation tooling enables developers to build a rhythm of activity and reduce switching.
Reliable automation also promotes creativity. By de-risking and introducing objective quality parameters, this helps to enable a culture of psychological safety for engineers and increase focus on problem solving where it adds value, instead of where it prevents error.
In many cases, this can also help to reduce the knowledge threshold required for engineers to contribute to a given task as testing and security automation can help prevent bad deployments and provide instant feedback to engineers.
Essentially, if you want to provide a great developer experience, it starts with reducing context switching and decision fatigue. To do so, you need highly usable software and platforms to help them get ideas off the ground quickly.
In return, this benefits organisations by enabling higher quality development at a higher speed.
Ultimately good providing DX helps keep teams focused on the long-term goals whilst keeping them happy! It's a win, win, win!
%20(5).jpg)
Really, this should be treated like any other improvement or transformation project that takes place in parallel to key deliverables and, as such, requires brilliant basics and an iterative approach.
Start by learning more about your developers. Interview and observe some of them, then map out their journey to understand what they need from you as a company.
From there, take steps towards shortening feedback cycles by providing excellent service. Simultaneously, build trust among potential adopters, so when something does go wrong within developed software ecosystems, everyone has less trouble adapting.
Adapting to change only happens quickly when all parties involved feel invested in making things work this time around, rather than letting previous mistakes repeat themselves over again.
%20(1).gif)
Our team have seen the good, bad and ugly in Developer Experience, and we're always happy to have a chat and offer free advice where we can.
If you're having difficulty, reach out!
Developer Experience (DX) is about how developers experience a positive sense of flow and enablement from technical products and processes. It is akin to User Experience but from the perspective of developers and engineers on the job.
However, whilst DX is primarily focused on workflow, it doesn't exclude non-tooling factors around their working experience. It encompasses how all company interaction with engineers and demands align to their workflow.
The more integrated these factors are with the delivery tooling they use day-to-day the better...
Today, deploying quality code quickly that is compliant, tested and secure, without support from tooling 'guardrails' can be an anxiety-inducing exercise. Especially with increasingly higher performance expectations.
These guardrails can (and should) be provided by test, security and deployment automation tooling, that is integrated into their workflow processes. Without good DX, provided by automation, pressure can mount within a team.
Pushing for higher performance expectations without good DX is firmly at odds with a viable people strategy for retaining and attracting quality talent, in a highly competitive talent market.
Simply put, if business pressures becomes too great, and investment in the quality of experience for a developer isn't proportionate, there has never been more demand elsewhere for their skills.
Given this, there are very few incentives for talented individuals to put up with a sub-par experience. This is why many organisations are now dedicating entire DX teams to innovate and ensure developers have an ever more positive experience on the job.
As it's becoming a key focus for organisations... what does 'bad' or 'good' DX look like?
and, if you need to improve... where do you start?
When developers are required to constantly switch between tools or processes, the workflow isn’t providing them with a positive experience.
This is because context switching can create headaches arising from decision fatigue.
A poor developer experience is detrimental on an individual level, by making you less efficient while coding.
The same is true for collaboration, as everyone has different tolerances and specialisms with unique working demands.
Those that are disproportionately effected by poor developer experience, or have unique demands to juggle are likely to be most impacted. This may be more senior engineers with other management duties, or indeed junior engineers who are working through a learning curve.
Ultimately, developers work best when they are ‘in the zone’, blocking out all distractions and finding a ‘flow’ in there working focus.
By creating 'good DX' this is what we are trying to enable and protect
Good DX leverages tools in the right way to minimise complexity, context switching and decision fatigue.
Working with minimal interruptions and reduced mental load is possible. This can be achieved by optimising tooling to provide guidance and quality checks on their work before allowing deployment.
The Integrated nature of the tooling to typical delivery tooling (such as Azure DevOps or Octopus Deploy, etc) is key to aligning support to the process of development.
In bringing support to where the delivery workflow happens, automation tooling enables developers to build a rhythm of activity and reduce switching.
Reliable automation also promotes creativity. By de-risking and introducing objective quality parameters, this helps to enable a culture of psychological safety for engineers and increase focus on problem solving where it adds value, instead of where it prevents error.
In many cases, this can also help to reduce the knowledge threshold required for engineers to contribute to a given task as testing and security automation can help prevent bad deployments and provide instant feedback to engineers.
Essentially, if you want to provide a great developer experience, it starts with reducing context switching and decision fatigue. To do so, you need highly usable software and platforms to help them get ideas off the ground quickly.
In return, this benefits organisations by enabling higher quality development at a higher speed.
Ultimately good providing DX helps keep teams focused on the long-term goals whilst keeping them happy! It's a win, win, win!
Really, this should be treated like any other improvement or transformation project that takes place in parallel to key deliverables and, as such, requires brilliant basics and an iterative approach.
Start by learning more about your developers. Interview and observe some of them, then map out their journey to understand what they need from you as a company.
From there, take steps towards shortening feedback cycles by providing excellent service. Simultaneously, build trust among potential adopters, so when something does go wrong within developed software ecosystems, everyone has less trouble adapting.
Adapting to change only happens quickly when all parties involved feel invested in making things work this time around, rather than letting previous mistakes repeat themselves over again.
Our team have seen the good, bad and ugly in Developer Experience, and we're always happy to have a chat and offer free advice where we can.
If you're having difficulty, reach out!
.webp)
.webp)
Take your business to the next level with our experienced team and network of consultants.
.png){kind=small}
