dxday: A Report

Introduction

On the 14th of March we were at DxDay, the first conference organised by GrUSP dedicated to the Developer Experience.

It was very cool to see so many different focuses on the same topic, showing how delicate and articulated the DevEx concept is.\
GrUSP will upload the videos of the speeches in the next few months, but if you are already feeling the fear of missing out, we will try to give you the essence of the speeches in this article to give you a taste of what the conference was like.

What is DevEx?

Developer Experience is the study of how people, processes, culture and tools affect the ability of developers to work efficiently. This is a definition provided by Github in one of their blog posts.
As mentioned before, developer experience is a complex and holistic concept, and we need to understand that none of these aspects can overcome the lack of another area, if you want to improve it, you need to work on each topic: technologies, tools, processes, culture and people.

This means that building a good DevEx requires a lot of effort!

It's also a dynamic, evolving concept, and improving it is a continuous process, not a static goal.
But even small steps can contribute, so you should manage the improvement gradually and develop a DevEx improvement process rather than a single big action, dividing the effort required into subtasks.

Why working to improve DevEx

Pleasure in work brings perfection to work.
(Aristotele)

The main reason to improve DevEx is to increase productivity and quality in its broadest sense.

It's not only about increasing revenue, but could potentially lead to it. The goal is to remove most of the friction, reduce cognitive load, automate repetitive tasks, improve communication and processes, create a positive mindset, flesh out the company's vision and mission, and unleash the full potential of human capital.

Striving for quality, creating a trusting environment and being transparent about areas that need improvement could create engagement and a proactive tendency where employees feel they can contribute to improving the overall structures and start to do so.
However, the main output metric of DevEx should be increased developer motivation and perceived satisfaction.

Talks

Ok, with that concept disambiguation out of the way, let's talk about the conference.
First of all, 4 of the 7 talks focused on tools for developers and the other 3 on process management and culture fostering.
The speakers come from very different backgrounds, which might justify the different focuses of their talks

Tools focused talks

Let's start with the tools, Maxim Salnikov, Developer Productivity Lead @ Microsoft showed us the power of GitHub Copilot and its ability to understand the context of your project, a tool that claims to allow developers to request all the boring tasks that keep them in the zone, making it easier to experiment the world famous Mihály Csíkszentmihályi flow state. Such a very ambitious claim and also a very ambitious goal: to offer a pair programming experience without the need for a senior engineer and increase productivity.
If you live in the desert or come from another planet and have never heard of Copilot, take a look at this "magical" looking tool.

Talita Gregory Nunes Freire Engineer @ Spotify and Vincenzo Scamporlino Senior Engineer @ Spotify have demoed Spotify Backstage, a tool that allows you to easily build a developer portal, an interface that could aggregate all your utilities for your microservices, allowing you to have a schematic view of your microservices' dependencies for example, but also much more!

They claim to address issues such as discoverability, system ownership, fragmentation, duplication and context switching. The focus is on reducing cognitive load, improving collaboration and transforming complex software into manageable units. We also use Backstage for some projects at SparkFabrik and its adoption is growing every day, confirming it as the de facto standard tool for complex cloud project management. Oh yeah, I forgot, this tool is completely open source, great!

Lou Bichard, Product Manager @ Gitpod, talked about his groundbreaking and, in such cases, futuristic Gitpod, a cloud development tool that removes the pain of onboarding and transforms your projects into code-ready, globally maintained development environments, removing the abstraction of infrastructure in your environment, what Lou called outer loop removal, a production-like environment. It looks like VSCode but in your browser, a future where you can upgrade hardware resources without changing your PC.

And it's not just Gitpod's product manager who is betting on cloud environments, but also Francesco Corti, Principal Product Manager @ Docker, with his talk on the future of growing DevEx tools, highlighting how companies are increasingly interested in this type of solution. He also tried to foresee the future of AI tools, predicting a future where we will move to a whole team of specialised AI assistants that will help you not only to automate boring tasks, but also to create documentation, debug, deploy, make data entries, get feedback on requirements, respect and test your software, an environment where developers don't usually code, but ask AI to do it for them.

If you have never heard of any of these technologies, look for demos, tutorials and so on, because it takes too much effort to explain all their functionalities in this blog post, the good news is that there are tons of resources about them.

Processes and culture-focused conversations

As I said, it's not just about tools, history has taught us that: the aeolipile was the first steam engine, but it didn't lead to a revolution, probably because the Greek culture didn't need to replace servant work. For DevEx, it is also easier to demonstrate because we work in teams: communities made up of people with social dynamics that affect our ability to perform.

Abiodun Olowode, Senior Engineering Manager @ Factorial, introduced us to Documentation Driven Development, which focuses on process optimisation, and how this could shine a light on team collaboration and knowledge sharing, potentially reducing code churn and introducing a faster feedback loop that could accelerate development.
One thing we've too often forgotten is that developers want to know why something works the way it does, why one implementation was chosen over another, we can understand code but we can't always deduce the reasons behind it and it's not always possible to ask someone for an explanation, we need a more robust and shared tool like documentation.
And also this kind of development could lead to less intolerance about writing docs, because it became part of development, you don't have to pass back your whole implementation process to describe it, the task becomes progressive and manageable. However, it was cool that maintaining and developing a tool together could improve DevEx.

Thomas Khalil, DevEx Head of Platform & Site Reliability Engineering @ Trivago, with his beautiful allegory of the Wizard of Oz, described some of the behavioural patterns that people in the organisation tend to adopt in order to challenge the psychologically complex situations that our jobs require today, and how empathy and awareness could lead people to unleash their true potential.
For Kahil, DevEx is about deeply understanding people's needs, motivations and aspirations, building trust, finding answers behind their defensive behaviours without needing a guru, keeping processes adaptable and choosing metrics wisely, keeping in mind that they are and should be holistic metrics. Even though it wasn't the focus of his talk, I'd like to focus on Kahil's use of surveys to identify areas for improvement and employee perceptions.

Suffering comes from trying to control what is uncontrollable, or from neglecting what is in our power
(Epictetus)

This quote used by Kahil highlights the main problem of the archetypes he describes and reminds us to try to improve what is in our power and to take care of it.

Dulcis in fundo our Paolo Pustorino, Head of HR @ SparkFabrik with his talk focused on the influence of culture on DevEx, alignment of values, sense of community, engagement, commitment, caring, transparency and the importance of psychological safety as a driving engine of developer experience satisfaction. He gave a lot of information about the processes of recruitment, onboarding and also career paths within Sparkfabrik and how the company tries to support you along the way, asking you for feedback on relationships, core values, training needs and perspectives. He gave an insight into the company's goals, such as the pursuit of quality in a broad sense (not only technical quality, but also relationship quality, communication quality, which revolves around the value of transparency, etc.) and the decision to make cultural fit and team fitness the key guiding values required during recruitment in order to preserve the culture and DevEx quality within the company.

"The chef is not the best cook in the kitchen, but he helps everyone to succeed" is probably the most emblematic phrase describing the previous assumptions. He also talked about the so-called Expert's Deception, the bias that innovation is a process driven by exports when their main quality is to offer experience, assumptions based on the past rather than challenging the status quo, and the desire to avoid the Peter Principle with career progression.
He gave us an introduction to the Cynefin framework, which could help you to support line managers in their work, remembering that you need to avoid instilling fear to get people to perform at their best.

I hope that you now have a broader perspective on DevEx and that you understand that a good company culture usually coincides with optimising tool adoption, but no tool adoption can improve your company culture.

Metrics

We didn't talk so much about metrics to measure it, only Kahil did a little bit. We need to specify that we need to separate developer productivity or job performance metrics from DevEx metrics or job satisfaction.
Even if your ultimate goal is to improve productivity, make sure you have improved DevEx first. DevEx metrics could give you insight to better understand productivity metrics and could encourage hidden latent innovation processes.

One of the most popular tools in this area is the SPACE framework, which uses some performance metrics to gain insight into DevEx. It's an acronym that stands for the following concepts:

• Satisfaction and Well-being: it measures how healthy and happy developers are, with a focus on psychological safety and satisfaction, worrying about workload and detecting and acting on possible toxic practices such as Compulsory Citizenship Behaviour (CCB) or lack of boundaries with personal life such as calls outside working hours. It also consists of assessments of personal goals and aspirations such as tool adoption and so on.

• Performance: difficult to measure because the business outcome doesn't imply a quality outcome. To balance better quality and quantity outcomes, you will better separate the metrics for the two areas, allowing you to understand if you are sacrificing code quality to deliver fast, undermining developer satisfaction and increasing code churn with its associated costs.

• Activity: Many activities such as brainstorming, meetings, or supporting a teammate are not usually evaluated by these metrics. Choosing the right metrics in this area could give you insights into quality, such as spending enough time on design decisions, code review, refactoring and identifying bottlenecks.

• Communication and Collaboration: focus on information discoverability and dissemination, network metrics, role clarity, awareness, transparency and team member contribution to team fitness. These metrics could influence all other areas of the SPACE framework.

• Efficiency and flow: the ability to complete work with minimal interruption or delay, measured by what is known as focus time. For efficiency, we could suggest the famous DORA (DevOps Research and Assessment) metrics: deployment frequency, change lead time, change failure rate and mean time to recovery (MTTR).

All these aspects could be measured individually or for teams, and we also have to mention that maximising one factor could have a negative impact on another, like for example reducing interruptions to improve flow could damage the collaboration of the team, it's not a law but consider that this could happen, so you will better have a holistic approach and also always consider that metrics by themselves are not reliable and could reflect other things, the choice of these metrics itself reflects company or team opinions and is influenced by irrationality processes.

Try to extract insights from metrics rather than using them as a driving force.

Conclusions

Unhappy the land that is in need of heroes.
(Bertolt Brecht)

DevEx focuses on improving the development environment with tools, but also in terms of a social environment that allows people to express their full potential.
A corporate culture less focused on workaholism and control and more on empowerment and trust contribute to DevEx, and in this sense could help the adoption of a transformational leadership style or Hansei framework, or encourage community participation and avoid silo mentality that could lead to a positive sense of identity with the larger organization and its members and could unleash Organizational Citizenship Behaviors (OCB) that consists in spontaneous mentoring, support, conscientiousness and sportsmanship that create virtuous cycles that put people in conditions to express their potential.

I don't know if future tools will move from promoting staying in the zone and achieving flow experiences to leading to Maslow's peak experiences, at least for those working from the Greek concept of Meraki, but as focused on Kahil's talk, the right tool at the wrong time might not be able to improve DevEx, and certainly gurus are not the answer, as Paolo also noted, we need to foster and nurture a psychologically safe environment with transparency, trust, communication, empathy, room for mistakes to avoid spreading fear because innovations arise from failure, so never lose the spark!

Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.
(Samuel Beckett)