When talking about developer experience, there are a couple of other names thrown into the conversation that all kind-of mean the same, but IMHO have a slightly different touch / focus and can be perceived quite differently.
Some may call it developer productivity or developer effectiveness. I, however, prefer the term developer experience. And here is why:
While all those terms may have the same intention and are also highly correlated, there can be small differences in the perception. From my perspective, developer experience is focussing more on the humans and that they have a good time and just a stellar experience at work, regarding all aspects of software development.
Developer productivity or effectiveness on the other side focus more on the outcome in terms of speed, quality or other KPIs.
While experience would probably be measured by asking and listening to developers, productivity or effectiveness tend to be measure by hard KPIs. This can quickly become toxic as the organisation might lose focus on the humans and gets too attached to optimising metrics.
From a business perspective, it is pretty clear, that we want developers to be effective. Basically, it is interesting how the ratio between value generated by the development team and the number of team members (or the sum of their salaries) is. This might be a KPI that could be measured. But should we?
The answer is “No!” — Assuming, that motivated employees will do the best work possible, this KPI completely takes the human out of the equation and hides the real problem. If developers are not effective, there is a good reason for that, which often lies in an inferior experience. An inferior experience can have many and multiple root causes that need to be addressed instead of putting pressure through KPIs. Having those KPIs as a goal quickly kills employee motivation and if their experience is a cause for frustration too, this situation will quickly get worse.
Therefore, if you believe that your people want to do excellent work, you should as well assume, that superior developer productivity directly follows from an excellent developer experience.
In fact, recent studies have shown, that happy employees are around 12% more productive1 and there is no reason to believe that this is any different for developers.2
Furthermore, if people enjoy their work and feel that they are effective and spend their time meaningful, they are much more likely to stay with the company longer. Consequently, they would attain more profound understanding of the product, the system, and the organisation.
How does developer experience work differ from developer productivity work? — Interestingly, not really much.
Many tasks that a team would do to improve the experience would also be the tasks they would do to improve productivity and effectiveness. Examples are
- reducing build times,
- helping teams to shorten their feedback loops,
- enabling teams to understand the behaviour of their systems in production, or
- simplifying the local toolchain setup.
All those are examples for tasks such teams would focus on, no matter, how you call them. However, the difference lies more in how they seek feedback for their work and prioritise work. It is more about asking people and addressing their biggest pain points rather than optimising some KPI.
While terms like developer productivity, developer effectiveness and developer experience are about similar topics and long-term outcomes, I find developer experience to be the more human-centric term and therefore prefer it over the others.
Update December 2022: Nowadays I use the term developer productivity frequently when speaking with outside stakeholders. For managers, C-level or investors, it sounds sometimes strange to focus on the experience of a group of people. However, they are all-ears, when we talk about productivity instead.
- Does Employee Happiness have an Impact on Productivity?
- Of course, it is important to note, that many factors influence the experience of employees, outside the scope of a developer experience team.