What is Developer Experience and Why it Matters
date
Mar 2, 2022
slug
developer-experience
status
Published
tags
Developer Experience
summary
Some said that developer experience (DX) is basically a UX for developers. Get to know more about DX and why it matters in this article.
type
Post
The world of software engineering is changing everyday, and we can all agree that the most parts of it are changing for the better.
It all began when I started to put my attentions on the ‘big personalities’ of the software development industry. As a CS student with big aspirations to be able do something big and meaningful in this industry, I felt the need to look for a role-models that I could look up to.
So, I started following the likes of Dan Abramov, Sarah Drasner, Cassidy Williams, Shawn Wang, Telmo Goncalves, and many others—mostly on Github, Twitter, and their Blog. Hoping that I could at least get some insights on how does it like to be a software developer.
Upon following them, it came to my knowledge that the world of software developer that we’re living in today, is not just about coding and finishing projects after projects. Because, indeed, being a software developer should be based upon the principle of making everyone’s life easier, including the process itself.
It was then exposed to me terms that contains the word ‘develop’, but it somehow felt that it doesn’t directly connected with the ‘coding process’, such as Developer Experience, Developer Relations, Developer Advocates, etc.
Even further prove the previously stated points about how the software development world is changing towards better everyday, and making ‘coding’ aren’t all there is to it. In this article, I’m going to talk about Developer Experience, what about it and why everyone should put more attention into it.
What is Developer Experience (DX)?
The Developer Experience (DX) describes the experience developers have while using or working on your product.
— Good Developer Experiences by Simek et al. on developerexperience.io
I think the definition above already summarizes the big idea of DX. But then, being a general definition as it is, we then might wonder on what are and are not considered as DX, and what are the criterion of a DX to be regarded as Good DX.
According to Simek et al., there are four factors on how Good DX can be defined, which are Fitting Architecture, Great Tools, Processes to back that all up, and Nontoxic team culture. Well, that should be easy to tell which are DX and which are not.
After knowing the metrics when a DX is a Good DX, there are many ways on how one could achieve a Good DX. In which you could read further in the article below:
In the upcoming section, I’m going to explain further about the four defining factors of DX by relating it to my experiences. But for next, let’s dive deep on why we should put DX as an important variable upon developing a projects, and not just cost and performance.
Why DX Matters?
Before starting on why DX matters, we might want to look at the background of why even the term DX existed.
Bad DX is like a 007 without Q
— Why should we care about Developer Experience (DX) by Marek Gajda on The Software House
According to Gajda, there are three most common problems with developers:
- Spaghetti code that drains the soul
- Working with technology that’s near retirement
- Software made of hieroglyphs
As one could probably tell, the issues mostly revolve around problematic legacy code and wrongful choice of technology. Hence, it is beyond question that the conditions above will bring a lot of discomfort to the developers. This is where DX’s point of Great Tools come to play.
Other than draining and discomfort to the developers, the said problems would certainly impact the efficiency of the development. Therefore, time and money would be in danger of being jeopardized.
Above is a very good illustration by Prokop Simek et al. on how often Emotional Cost is taken lightly in most projects. Cases such as giving developers task based on a problematic legacy code, weighing them with abundant of tasks and justify the wrongful of it by branding it as ‘being agile’, etc.
The accumulation of these kinds of mishaps would surely bring a lot of loss to the project and the company per se. Be it a toxic and non-functioning team environment, tons of wasted time from doing tasks in an ineffective and repetitive manner, bad-quality code & technical debts, and so on.
Having a great DX helps you having this emotional cost under control. Keep the emotional cost low to make your developers happy.
— Good Developer Experiences by Simek et al. on developerexperience.io
My Experiences on DX as a Student Developer so far
As a 3rd year CS student, I have been blessed with some opportunities of being in a real-world software projects. At the time of this writing, my PPL (CSCM603228 Software Projects) team is currently working on an information system on grant management for the Faculty’s board & research management team.
At the beginning of the course, we were introduced to many tools and best practices on developing a software. Therefore, I’m going to share my experience on developing the said system, in the format of the four defining factors of Good DX:
A. Fitting Architecture
In pre-production stage (development and staging), we were given a liberty to choose any architecture, in any form whatsoever, regarding how our implementation would be. Thus, our team—in this context, led by our DevOps Adil and Gita—decided to use Heroku for backend, and Netlify for frontend as a staging and temporary production deploy environment.
The DX perspective of this is that the CI/CD integration between Heroku/Netlify to the Gitlab repository is so seamless, in compared to having to manually deploy on the server everytime changes is being introduced into the staging or main branch. The setup is also quite simple as well.
B. Great Tools
Amongst the examples of Good DX is a good documentation. In our backend project, we are using
drf-yasg which allows the system to automatically generate API documentations w/ OpenAPI 3.0 format, with the built in ReDoc and or Swagger interface out of the written code.
The DX perspective is this is that having your system generating API docs as you go, really saving us a lot of time from manually creating the docs ourselves. Imagine having to go to Google Docs or Notion everytime you created a new API or when you’d like to consume the API.
Other tools that we also use, to maintain the quality and the well-being of both our team and the code we’re writing is to have great code quality assurance tools. Aside from the tools that is common (e.g. ESLint for JS/TS, flake8 for Python projects, etc.), we are given a free access to Faculty’s SonarQube.
It is an awesome code quality inspector that would surely help maintaining the quality of our project’s code. Thus keeping the developers happy 🥳
C. Processes to back that all up
As mentioned before, having a good CI/CD integration with a deployment services is a blessing. It’s like having someone to do your very mundane development tasks, such as qode quality checking, running the tests, and deploy to the respective environment.
Thanks to the very talented DevOps of our team, بإذن الله, we are able to have these processes well instrumented. Hence saves us from the previously said mundanities.
D. Nontoxic team culture
Lastly, this point perhaps is more related to a team-culture and a team-dynamic sector. The Good DX elements of our team relating to this point is how we could know what everyone is doing, so that we could collaborate better. There are two things that we are doing in order to achieve that.
First, since we’re doing our developments in Scrum manner, we are obliged to follow one of its events or ceremonies, which is Daily Scrum. But since we’re students that also have other classes beside this course, we’re only obligated to do our Daily Scrum twice a week.
So far the meetings went well, everyone is stating what they have done, the problems they encounter, and what are they planning to do for the upcoming days. This helps keeping every one of our team members informed on what each of us are doing, and also serves as a medium should one of us is having a problem on our tasks.
Second, we also have a rather magical Gitlab-Discord integration. With the same purpose as the Daily Scrum explained before, this also helps keeping our team informed on everyone’s progress. But in a cooler manner, you know, with it being integrated with Discord and all 😎
Afterwords
Long story short, development experiences can be a lot of aspects of our development, and investing our time and resources on trying to have or keep it in a good condition should always be a consideration.