The following are my current opinions and thoughts on DevEx, this might change and I welcome any discussion or input.
What is DevEx Engineering?
DevEx or Developer Experience engineering is the practice of improving the tools and processes of Developers.
Much like DevOps (Developer Operations) focuses on tools and processes to improve the movement and automation of systems from Development into Operations DevEx attempts to use a similar approach to the tooling and development workflows of teams.
While it could be viewed that DevEx is just a subset of the DevOps process I think that it can have a wider impact in improving development speed as well as reducing a lot of the bottlenecks in modern software development.
Goals of DevEx
The primary goal of DevEx is to make things easier for developers. To automate tedious tasks and boilerplate code, and to provide tools and processes for standing up development environments that provide fast feedback.
We can accomplish these goals by looking at the following:
- How hard is it to onboard a new developer?
- How long does it take for a change to be submitted to feedback being provided?
- Is the development environment consistent across all developers in a team?
- How quickly can a new project go from an idea into the initial code?
Tools and Processes
Just as with DevOps, DevEx has not just about new fancy tools and systems. It is about working out what are the most useful tools along with improving development processes. There is no point rolling out a big automated deployment system full of bells and whistles if the development team is struggling with source control and how to best manage and track changes.
What is right for one team might not fit in with another, and the tools for one tech stack might not be suitable for a different tech stack.
While this might seem like a bit of a lazy answer, the key here is that development teams are as diverse as the engineers that make them up.
So where to from here?
The first step towards improving the Developer Experience is pretty easy, talk to your teams. Find out what their pain points are, the bottlenecks they face, and the improvements they would like to see. Once you know this then you can look at what tools and processes can be brought in to address the issues.
While throughout this post I have not specified any specific tools or processes I will be following up with more posts and talking about different options as well as building out demos to show different ways of doing things.
And as with anything in technology all of this is subject to change and update, tools/processes that might have been useful previously might turn out to have some drawbacks, or a new tool or process might come out to replace existing ones. I will be doing my best to talk about these things as they happen.
So I hope you will all join me on this journey to improving the Developer Experience and I hope that some of what I talk about on this blog will be useful and interesting.