The experience of working in Developer Experience
How it is to belong to a DevEx team?
Well, first, what is DevEx? It’s likely that you have never heard about it, as it’s a relatively recent concept. The main idea behind it would be an analogy of what a UX (User Experience) is for users. DX (or Dev Ex) would be a similar concept, but in this case the users would be other fellow developers.
DevEx stands for “Developer Experience” so the main goal for a DevEx engineer is to make your life as a developer a bit, hopefully a lot, better. The idea isn’t totally new, as for instance, “Tool teams” focused in developing custom software to support development tasks have been there for quite a while now.
The innovative idea behind the DevEx concept is that in this case the focus is not only development tools, but also development processes. This means that yes, creating tools and scripts that simplify usual and repetitive tasks will be part of your daily life inside a DevEx team, but also things like identifying bottlenecks in CI processes that are making your pipelines slower or looking for inefficiencies in compilations or in build scripts.
Reducing waiting times and cognitive load is essential in order to let developers focus on what is important and avoid switching from task to task, losing the focus on what they are doing.
The Human factor
So it looks like, to improve a developer working experience, we should improve the technology, and that’s true, but that is only one side of the task, as there are also inefficient human processes that should be tackled.
This means that a DevEx engineer should have a good amount of technical skills but also strong social skills, like empathy, as they will need to identify potential pains, get in other developer’s shoes and understand ways of working that could lead eventually to burnout if not taken care of appropriately.
We all have this handful of annoying tasks that we do on a regular basis. We didn’t like them at all when they started, but after a while they don’t seem that bad, right? Why? They keep being annoying, but we just got used to them, so now they are part of our own mindset.
Part of the work of a DevEx engineer implies understanding the reasons of the very existence of those tasks, understand why they keep being done by the team and make proposals to remove them, automate them or at least avoid them affecting the daily life of the developers.
Our own experience
In ClarityAI we created a new DevEx team in June 2021. After almost one year of existence, we think it’s a good time to share our experience and some valuable lessons learned.
- We had a Positive impact: We can affirm that the team has improved some crucial processes like the code release or the waiting times for CI pipelines. It’s not an impression, we have the numbers :)
- We received Positive feedback: Other teams appreciate to have a team focused on those things that they would like to improve but that would require time and probably all focus. Those two things are usually hard to find when you need to keep releasing new functionalities and need to prioritize putting things in production.
- Observability first: You need to identify bottlenecks. Sometimes they could seem obvious, but we found that many times our intuition was pointing us in the wrong direction. We introduced Honeycomb events in our CI pipelines to check the time for each step, and we were surprised by the results. This helped us discard some improvements that seemed obvious at first glance but that were actually not providing as much benefit as we thought initially.
- Focus on your customers’ needs: And who are your customers? Well, in your case, other developers like you. A good idea would be only good if it’s really accepted and adopted by the other teams. This means that it’s possible that you find initial resistance to some of your proposals. Thus, you could need to prove its usefulness first. Do a PoC (Proof of Concept), show some numbers and it will be easier to convince anyone (including yourself).
- It’s all about empathy: You’d need to put yourself into your colleagues’ place and understand their pains first hand. It would be very useful to do shadowing sessions with some of the members of the other team, install their local environment, reproduce their daily processes, and in general, try to become one of them during the time you collaborate with that team.
- Baby Steps: Don’t try to come up with the ultimate solution at once. It will be easier to make sure that you are in the right direction if you validate little improvements with the users as soon as you have them. Release the improvements as soon as they start adding value and take advantage of the feedback you receive once the developers start testing them so you know if it’s worth going that way.
- Collaboration & communication: You can not work isolated from your users, on the contrary, you need to be in constant contact with them and listen to what they have to say, at the same time you are proposing solutions. It’s important to discuss those solutions together between the DevEx team and the users team, and to do so at an early stage in the development process, so you can validate that the changes are actually solving the issues that are causing the most important pains.
- Clear Ownership: The ownership of the tools and procedures should stay inside the development teams that are using them. The DevEx team is a support team and are there to help, giving a boost to make those tools great again, but cannot be responsible for all software and processes across the company.
- Platform as a Product: We consider that our developer’s platform is a product, as important as any of the other products inside the company and thus it deserves the same level of attention. It just happens that our “clients” in this case are our own colleagues inside the Tech Team.
My own experience
I was excited with the creation of the team. I had the idea that I was going to learn a lot about many technologies that I knew very little about, improve my infrastructure skills, my automation skills and probably make useful tools that will help other developers be more productive.
And yes, it fulfilled all of that, but I found out that actually the most valuable learning for me was not that much about technologies but about methodologies. I learnt how to develop in a more sustainable way, following good practices and opening my mind to a new way of crafting software.
As an example, here you can find some of the techniques and practices that are references for our DevEx team:
Conclusions
After less than one year of existence we’ve already decided that the team needs to grow. We’re happy with the results so far and we think that the team is having a very positive impact on our Tech team.
If you not only want to improve the software you make but also how you make the software, consider a DevEx team as a potential catalyst for that change.
Some things may seem impossible to change (or at least to improve), but usually is just a matter of assigning the proper resources and prioritization.
Make an estimation of how much developer’s time you’re wasting by not solving those issues that are slowing down your teams and there you will find a possible budget (in developer time or its corresponding value in money) for your DevEx team.
It’s always good to remember that Developer time is probably the most expensive resource.
After reading all of that, what do you think? Do you have your own experience building developer experience? Please feel free to share your thoughts and drop your comments on this same article.
