Developer Experience is the idea of ensuring that developers’ tools, practices and working environment are as good as they can be to support their job.

It emerged from considering User Experience (UX) for developer-focused products. Some companies use these ideas to assess their internal platforms and processes. It’s an idea that shouldn’t seem radical — improving developers’ experience increases the speed and quality of their work.

In this article, I’ll look at some things I think should come under Developer Experience. Many of these are things that every company should already be doing. However, developer Experience is about making these needs explicit for everyone involved with software development. While many of the items are under the control of companies, developers need to be able to ask for what they need.

Developers want to develop

I still remember the first time someone showed me how to compile a C program. Of course, all it did was write the words “Hello World” to the screen, but, seeing that I could make a computer do that, I knew I could make a computer do other things. That was one of the most significant moments of my life. From that point, I wanted to be a developer.

Software development is one of the most fascinating activities I’ve found. When working on a hobby project, hours can slip away as I add features and track down bugs. The same is true for a lot of programmers I know. Programming is full of interesting puzzles and challenges. It’s something that I often do for fun.

Given this is an activity that some people will do for free, being paid to be a developer ought to be a fantastic deal. Professional programmers should be some of the happiest people in the world. But this is not always the case.

Obviously, developers’ enjoyment of their jobs must be balanced with many other things. But, at the same time, I know of companies that have thoughtlessly hindered their developers from doing good work.

How to get started with Developer Experience

The main thing about Developer Experience is removing irritations from developer’s days, big or small. Some of these are common complaints and can become accepted as simply being the way things are. It’s easy to accept things that we should be challenging, known as ‘learned helplessness. Remember how quickly all those roadblocks to remote working disappeared when the pandemic lockdowns started? Ask yourself: are things done in a particular way because they need to be or because they were always done that way?

One suggestion for getting started with Developer Experience is getting people to keep friction journals. Does something annoy you? Note it down. Then gather the list of issues and fix them.

Admittedly, these things tend to be raised in sprint retrospectives but ask yourself how many things you don’t raise because they are ongoing issues. Teams often feel little agency about fixing these things and need active support from management. A friction journal can provide a useful starting point for discussion.

Some of the common things to look at are:

Latest tools

Do developers have the latest tools to work with? Do they have access to powerful computers that can run the code and tests quickly?
.

Office environment

If you have an office environment, is it conducive to work? Research shows that developers function best in a quiet office with few interruptions.

A good book on this is Peopleware: Productive Projects and Teams, written in 1987, has been ignored by most people ever since. However, the research is clear — noisy, open-plan offices are not good coding environments.
.

Appropriate issue tracking

Do your issue tracking tools support the developers or management? Most projects don’t need heavyweight project tools and can run perfectly with simple tools such as those supplied by GitHub.

Yes, I know Atlassian tools are used everywhere. But unfortunately, too often, projects are organised for the benefit of management reporting rather than to efficiently produce new work.
.

Meetings

Meetings should be respectful of the developer’s time. Developers often complain about too many meetings, yet few companies do anything about this. Paul Graham’s essay Maker’s Schedule, Manager’s Schedule explores this topic. Teams should also ask how valuable their agile ceremonies are. If it makes sense to move these into tools like slack, then do so!
.

‘Yak shaving.’

Ever heard the phrase ‘yak shaving’? It’s from an old cartoon called Ren and Stimpy and refers to how a simple task can involve a host of other tasks, and before you know it, you’re shaving a yak to get its hair. Internal processes can easily lead to bureaucratic hassles like this. But, fixing it can be an easy win. Important work should be easy to do.
.

Safeguards

It’s important to balance simple development processes with safeguards to prevent errors. But it’s also easy to add new checks and signoffs whenever something goes wrong. Before you know it, the software development process becomes slow and unwieldy. This has been referred to as ‘management debt’. Therefore, processes need to be reviewed regularly to ensure they are efficient.
.

Deployments

Are continuous integration and deployment pipelines fast and reliable? Are deployments to production easy and safe? Does the company culture acknowledge the inherent risks of releasing software and have processes to prevent major issues (efficient backups, simple rollbacks etc.)? Are developers supported rather than blamed when errors happen? Is the responsibility for changes shared among a team?
.

Documentation

Is there enough documentation to support developers in tasks, and is it kept up to date? Is changing the documentation an easy, quick process?
.

Opportunities to learn new things

Are developers given opportunities to learn new things? Is your company able to introduce new technologies and frameworks rather than being caught in the ‘crunch’ of terrible old technology?
.

Onboarding

One practical test of a company’s Developer Experience is through onboarding. How quickly can a new developer get working and producing good code? A company that supports newcomers will also help existing team members. Ultimately, we all function like newcomers when we look at a new area or something we’ve not done for a while.
.

Flow

Underlying most aspects of Developer Experience is the concept of flow, outlined and popularised by the psychologist Mihály Csíkszentmihály. He was researching what made people feel happiest. The finding was that when they entered ‘flow states’, where they felt energised concentration and complete absorption in what they were doing.

Psychologists have explored this further and found there are four main things that we need to induce flow:

1. Clear goals and ways to track progress
2. Clear and immediate feedback on the task
3. Enough of a challenge to push someone’s skills
4. A lack of interruptions

Developer Experience can be approached by looking at things which erode flow. For example, long build cycles slow feedback cycles and allow the mind to wander while waiting

Meetings interrupt people’s concentration, dragging them away from tasks. People in open-plan offices can also be interrupted by passers-by. It’s all very well having a fancy office with table football and free beer. The most important question is, are you providing an environment that supports and encourages flow?

The most subtle component of flow is the need for clear goals. It’s important to know when a goal will be completed and what our progress is.

Conclusion

One last thing needed for an excellent Developer Experience is a sense of narrative and purpose. We need our work to be meaningful.

As crucial as salaries are, it’s probably more important to be spending our time on work that feels significant. Can developers see that their work is part of a larger mission? Does that work positively impact colleagues, customers and the world? Life is short, and it’s important to know we’re using it well. So, developers and their employers must ensure that work is as meaningful as possible.

Further reading

• The classic book on human aspects of programming is Peopleware by Tom DeMarco and Tim Lister. While the book was first published in 1987, it’s still a valuable read.
• Remote working offers particular challenges, and many companies have yet to face up to these. Everyone involved in remote or hybrid companies should read James Stanier’s 2022 book Effective Remote Working.
• What Google Learned from Its Quest to Create the Perfect Team – a good discussion of what goes into making a good team.
• Anthropologist David Graeber’s book Bullshit Jobs is a provocative discussion about the opposite of meaningful work.
• The series of books by Basecamp/37 signals are brief guides to strategies for improving work environments.
• Paul Graham’s essay, Maker’s Schedule, Manager’s Schedule, is a good discussion of meetings and distractions.
• The Joel Test was a 2000 essay on 12 simple points to identify good software companies. Much of it is – thankfully – out of date (source control and testing are now almost universal), but some topics are still sadly relevant. For example, how does your company measure up to the development standards 20 years ago?