How to ship products faster, attract the best software engineers and keep them.

Lewis Barclay

Published in

HackerNoon.com

8 min readApr 24, 2019

Meaningful work versus waste

“This sucks.”

A common phrase muttered by software developers.

Spending time working around problems, when there is pressure to complete features, sucks for a developer. It’s worse when the problems are caused by substandard tools, restricted access or a lack of documentation. Software developer environments often suck because of these problems, and what happens next? Productivity slows down, product delivery deadlines slip and management tears out its collective hair. What’s worse, is that progress and motivation drops.

“ The motivational power of progress, (is) well known in just about every field that focuses on mastery … think of progress as a motivation mechanism and you will create a completely different atmosphere.”
Energised workers, The Lean Mindset, by Tom Poppendieck; Mary Poppendieck

A majority of developers want to see progress by completing meaningful work and meaningful work rarely equates to “working around problems introduced by prescribed tooling, technology or languages”. The acceptance of working around development environment problems is, in reality, a total waste. This waste is often masked by increased developer effort or worse, hidden from view completely.

If developers can’t make progress, by completing meaningful work, they look for other places to work. In the Stack Overflow Developer survey 2018, the second most important criteria for assessing potential developer jobs was the choice of languages, frameworks and tech they’d be working with, and only just second after renumeration.

A bad developer experience can lead to organisations fighting a war of attrition, a constant churn of staff.

https://insights.stackoverflow.com/survey/2018

What is developer experience?

Like User Experience considers the experience of the end user, Developer Experience, considers the more nuanced experience of a developer.

At React Amsterdam 2019, Peggy Rayzis discusses her work at Apollo, as an engineering manager, in a developer experience team.

I’m an engineering manager at Apollo, and I lead a team of engineers who focus on Developer Experience. Developer Experience equals a productivity boost for developers. Developer Experience is important because it helps ship products faster. It helps us attract the best engineers and it helps keep them.

Preparing for her talk, Peggy asked the development community a question, on Twitter:

What does a great developer experience look like to you?

Developers responded:

A good developer experience happens when doing the right thing is natural and messing up is hard.
Great developer experience is when you can pour your brain straight into the code. Without your development environment getting in the way!
Great developer experience is one that you never have to think about. It gets out of the way and lets you focus on building your product.
A great developer experience abstracts a correct amount of complexity away and is still transparent. When customising it, the process is additive rather than subtractive.
Great developer experience is one where you can focus on business logic and customer value.
A great developer experience can’t get in the way of what I’m trying to do, and it needs to fit the workflow.
Great developer experience is when it’s so easy that your abilities start to regress.
The best DX makes the right thing the easy thing. Built-in, default, decisions are great ones, with easy paths to customise as needed.
Great developer experience is getting out of the way of the developer and letting them Get Sh*t Done
Great developer experience is adoption that doesn’t involve hours troubleshooting undocumented errors. Usage doesn’t entail having to refer to documentation over and over again.

Articles online mostly talk about DX from the perspective of producing software and software services.

In “The Best Practices for a Great Developer Experience”, Sam Jarman has some great points about open source software, clarity and documentation, when producing software.

Justin Baker says “Devs are people too” and that we should consider: Function, stability, ease of use and clarity when creating developer tools.

DX doesn’t have to start or end with the software a company produces or apply only to organisations selling software that developers use. For any company, employing developers, it is an important consideration when creating productive developer environments.

The benefits should be clear. Improving developer experience will increase your return on investment if your company is creating software, adding efficiencies through automation, driving innovation with software, and more.

So, how can senior stakeholders, execs and managers apply DX thinking to improve productivity and increase the flow of meaningful work?

Know your audience

Research. Consider keeping experience diaries, and complete a readiness assessment.

Getting to know the developers in the organisation is a significant first step. Misunderstanding developers’ needs and making assumptions of what those needs are, is a killer of good developer experience. Especially if the people making the assumptions are not actively developing software! Not all development teams are the same. Not all developers in development teams are the same.

Productivity and business value should be the focus of initial research. Identify what productivity and business value output mean for the business and associated development teams. Then find a way to measure it and ask what needs to be added, removed or improved.

Watch out for a reduction of a developer’s productivity, from any of the following common issues;

The prevention of utilising learned muscle memory
An unnecessary increase in cognitive load
The introduction of learning new tools
Forcing developers to accept sub-optimal tooling
Removing access to valuable resources.

Asking developers to keep an “experience diary” is a low cost way to observe the experience a developer might have. A diary can be as simple as keeping a list of hours spent fixing issues that don’t directly relate to delivering business value, but can often form more than that by utilising tools and practices that are already common in Agile workflows.

Next, conduct a readiness assessment. This should identify potential impedements to any changes that need to be made in order to help resolve the challenges that were identified in research. The outcome of the readiness assement is a report. The intent for the DX readiness report is to aid dicussions that will drive changes within an organisation, with the prime objective of increasing return on development staff through increased retention, productivity and happiness!

Align Developer Experience with other objectives

Introduce “good DX” and align it with other team or organisation objectives. Find representatives or form a team to champion good Developer Experience

Once a readiness report has been completed, it is time to understand the issues the research raised and begin seeing what you can “go after”. This is no small task. You are likely to run in to some long standing decisions involving; environments, procurement, support, software, hardware and security, amongst other things. The readiness assesment will likely have highlighted areas of contention or “imovable objects” that stand in the way of an organisation reaping the rewards of adopting Developer Experience thinking.

Now is the time to encourage business stakeholders to answer the question: ‘how often do the decisions to introduce process, rules and regulations consider developer experience while calculating a net benefit or loss?’

As we saw in the responses to Peggy Rayzis’ tweet, good DX “gets out of the way and lets developers deliver business value.”

Getting out of the way doesn’t happen by accident. So, the introduction of ‘good DX’ as a goal, will help reduce inefficiencies in developer productivity. Having representatives evangalise Developer Experience thinking alongside other goals, will raise awareness and increase the voice of development staff in conversations that affect them, where they didn’t exist previously. With representation in the right places, discussions need to take place to identify a sensible approach to change adoption. Forming a change plan to improve developer experience at a company or in a team, you should be good to go!

Introduce positive DX change

Formalise a developer experience change schedule

With DX now a considered goal, some representation at the right levels, a list of issues and some considered resolutions, a team is ready to start addressing the issues that were highlighted by the research previously undertaken.

A change schedule doesn’t have to be as grand as it sounds! It could be as simple as a top ten list of prioritised improvements to introduce and the outline for introducing them.

Then it’s time to make the changes!

Empirical evidence of any changes and associated effect should form part of a valuable change feedback loop. Use the feedback loop to build, measure and learn, iteratively.

A team might be tempted to introduce a low risk research phase in a contrived situation to test changes before rolling them out to a team or organisation. It’s important to test changes in realistic environments that offer real feedback. Genuine feedback is vital to understanding the impact of a change. Rather than running Research and Development phases, keep changes small, easy to put in place and easy to rollback.

Measure improvement

Install DX analytics. Define business value and then identify metrics that can correlate to changes

Empirical evidence of improvement, through the introduction of good DX, is a “golden egg” when implementing change. Defining what improvement means and finding metrics a team can be confident in, is like using web analytics to measure changes in customer or user experience. “When we introduce this change, this happened. What should we do now?”. It forms the core practice of any good feedback loop.

Look for quantitative data first to measure change. For example, the definition of improvement might map to delivery of features. Then, collect qualitative data, for the same changes. Request developer feedback. For example:

Question: ‘Following our changes, how easy was it to implement the new features? Answers: 1. Easier, 2. The same 3. More difficult.

The path to more meaningful work

There is nothing wrong with working around problems, if that’s a core business of your organisation but continuously working around problems to try and get to meaningful work is a DX smell. Being “busy” is the antithesis of good developer experience. High value output driven by low effort is the golden ratio to strive for when it comes to solving developer experience issues!

If success is understood and well defined, developers are trusted, sensible automation is introduced and good choices are made to abstract away complexity, then impediments to a good developer experience will disappear and the flow of meaningful work will improve. Products will be shipped faster, developers will be happier and the return for the business employing the developers will increase.

Try it out. Let me know how you get on.

I’m interested to hear from anyone about their experiences with good and bad DX.

Tweet me @barclaytweets or @supasympa

—