Whose Developer Experience is it anyway?
Part 1
After a long pause from The Platform Space, this week I am back with a topic that is very close to my heart and has also been at the core of my career in the last few years. Developer Experience.
I wanted to write this for such a long time but never truly did it because I felt in the last year or so we have been inundated by all sorts of reports, articles, platforms, and experts, everyone selling the dream of offering the ultimate Developer Experience. Therefore, I decided to focus more on the product side and not trying to define something so complex and I’d argue, also contextual.
The inspiration for this content piece came from two very random events: one, watching the Ruby-on-Rails documentary by Honeypot, and two, a LinkedIn post I saw recently that said something along the lines of “why are we talking so much about Developer Experience as it’s a thing? Developers want what everyone else wants, a good product to use”. I am paraphrasing a bit, but that was at the core of the post.
Returning to my initial source of inspiration, the Ruby-on-Rails documentary, I could not help but not be in awe of what DHH achieved through the Rails movement and getting a bunch of developers to contribute to the same code base, pre-GitHub days. Now I do not want to focus here on the programming language itself as I am conscious people love it and hate it, but I want to focus on the idea of building something that it is easy to use, exciting to contribute too, and even more compelling to form a community around it. In my opinion, this is not as easy to achieve these days.
Sure, there are many platforms that use all the right words and focus on what execs want to hear, but the reality is that there is no silver bullet for building a great Developer Experience if you lack the fundamentals: an easy-to-use product that solves their problems, a way to get feedback and action it, and a pretty great culture that people want to be part of.
I titled this Whose Developer Experience is it anyway because I see this divided into two parts: one focusing on the definitions and the factors that impact it, and the second focusing on how to start thinking about these initiatives and how to (successfully) roll them out, irrespective of any platform.
Let’s start from the basics. What is the Developer Experience?
Out in the wild, Developer Experience is a term used to describe the overall experience of a developer when using a particular set of tools, frameworks, or platforms to develop software. It usually includes all aspects of the developer's interaction with the tools, including ease of use, documentation, community support, satisfaction with the product development process, and the internal software development lifecycle.
I trolled the Internet for some definitions, and I have included the ones I personally think are the most useful ones here:
Source: Author’s input on definitions
In comparing these definitions we can identify different areas of focus.
Focus on Tools and Processes: Microsoft Open Source and GitHub both highlight the importance of tools, processes, and the broader ecosystem in facilitating or hindering developers' work. GitHub, however, extends this to include culture as a key component.
Emphasis on Psychological and Emotional Aspects: GetDX and "Developer Experience: Concept and Definition" both stress the significance of developers' feelings, thoughts, and values regarding their work. They suggest that these psychological and emotional factors are crucial in enhancing developers' performance and the outcomes of software development projects.
Broad Ecosystem vs. Individual Experience: GitHub's definition is the most comprehensive, considering the entire ecosystem affecting developers, including technology, systems, process, and culture. In contrast, GetDX and "Developer Experience: Concept and Definition" focus more on the individual developer's experience, including their emotional and psychological well-being.
This comparison hopefully show you, the reader, that while there is a common understanding of Developer Experience involving the ease of performing development tasks and the tools used, there is also a significant emphasis on the psychological and emotional aspects of Developers' Experiences. You can’t have one without the other.
Why does Developer Experience matter?
Research has showed us that a positive Developer Experience can lead to increased productivity, better quality software, and higher job satisfaction for developers. This is why many companies and open-source projects are increasingly investing in improving the Developer Experience of their tools and platforms.
Let’s look at a different data set to really understand this.
In their paper titled "Developer Experience: Concept and Definition" , Fagerholm, F., & Münch, J. (2012, June 2) discuss the concept of Developer Experience in software development, focusing on understanding developers' feelings, motivations, and identification with their tasks.
It draws parallels with User Experience (UX) and emphasises the importance of human factors in software project success, especially in global software development.
Figure 1 below shows there core areas of perception for developers: infrastructure, their work (what problem are they solving) and how they see their contribution.
Source: Fagerholm, F., & Münch, J. (2012, June 2)
Combining the definitions above, the data from the paper and some of what I experienced makes a good Developer Experience, I came up with the following key components:
The rating is totally hypothetical and biased but this can be established based on each company’s context and goals. Think about why you started caring about Developer Experience in the first place and what matters for your developers the most.
A final thought I have is that no platform can offer you the secret to a good (or even great) Developer Experience. You have to approach that in the same way you approach building the products you sell - by solving a real problem. This time for your developers.
Platforms should help you gather qualitative and quantitative data to make decisions and understand where the problems are, but they won’t fundamentally solve the problem for you.
See ya next Friday with Part 2.
A closing note: If you are new to Platform Space, welcome. I’m Alex, a Senior Product Manager working on Developer Products and I write about Product Management and Behavioral Economics. I am also a PhD student in the field of Behavioral Science and as both my job and my research have taken over my time, I have been writing more sporadically, but I hope to change that. Thank you for subscribing! Your support means the world.