In today’s world of digital products, the developer is instrumental to business success. By not considering the experience of developers, in the same way we consider the experience of our end users, the whole process of bringing new digital products to market becomes lengthier, and ultimately delivers less value.
The Forgotten User
We are all familiar with the acronym “UX”. We care deeply about the user experience – when users engage with our digital products – and we spend a non-trivial amount of time and resources trying to figure out what that experience should ultimately look and feel like. Whole teams are assembled and leveraged in our businesses to try to predict what our users want out of our products. We have revered individuals in our organisations who think like a user and then help build our products according to those intuitions: the UI/UX Developer. We do all of these things because we know that users talk about the products that they interact with, a sort of social currency in today's digital age. Do your users talk well, or poorly, about your products?
Users are chatty, and “chatter” is more accessible than ever in the digital age. A chatty user can be a boon for your product or a curse, and that “dose” is determined solely by your team and how you’ve built your product; you get to pick your poison. With good UX, we hope to acquire the holy grail of any business: the loyal chatty user, the user that tells everyone about your product and how happy they are to be using it.
What if I told you that most organisations are ignoring, what I believe is, their most crucial user base? They are ignoring these users and yet, those users are sitting right under their noses. As a member of a digital product team, you probably speak to at least one of these forgotten users every day, and they undoubtedly have the most intimate knowledge of your product. In fact they probably are the most active users of your product. These users are the development team – a Software Engineer, DevOps Engineer, or Quality Assurance Engineer – and they also expect to enjoy interacting with your product. They expect a good Developer Experience; good DX.
What is DX?
Justin Baker says “When software is consumer facing, we see a sweeping trend of minimalist elegance aimed at cultivating an emotional connection with the user. But, when that target user is now a developer, design seems to take a back seat to functionality.”
What is DX? Fundamentally, it’s the same thing as user experience: users, in this case developers, should be able to intuitively interact and engage with your product. What does this mean in practice? Let’s try to summarise some key points that you’d usually see in the context of UX:
- Onboarding: developers should be able to be onboarded to your product seamlessly. (This isn’t just access to your organisation’s tools, like Jira, Wiki, Slack, team directory etc.; it includes setting up a local environment as well, ideally by running a single command or script *gasp*.)
- Separation of concerns: each part of your product should be clearly defined with a bounded context and do one thing, and one thing only, really well.
- Usability: it should be obvious what each part of your product does, and how it benefits the developer. (Follow common practices and avoid reinventing the wheel. A need to reinvent the wheel is often a smell of something gone awry with your DX.)
Notice each of these bullets makes sense in the context of a general user. Go ahead and try replacing instances of “developer” with “user” (in developer lingo, we call this doing a “grep and sed”). Developer Experience is User Experience.
Why is DX Important?
Believe it or not, developers are people too. We want to use products that are fun, easy, and engaging. And we talk about them too. Ask a non-developer about Netflix, and they will tell you how much they enjoy the Netflix platform. Ask a developer about Netflix and they will tell you the greatness of Netflix's technology that powers their platform; two sides of the same product.
“Happy developers are chatty developers, and when we talk to each other to recommend products, the ones with the best DX are at the top of the list.” – Sam Jarman
DX is a feedback loop, meaning DX fuels DX. If your product has good DX, your developers will not only enjoy working on your product, they will tell other developers how great your product is. Sound familiar? This is the loyal chatty developer. This means more developers will want to work on your product, more developers will stay to work on your product, and that means you can deliver more value to your users more quickly. Putting DX first means better, more robust tech, which attracts more talented developers, and the cycle feeds into itself. All business KPIs are downstream from Developer Experience.
Doing the DX
DX is for developers by developers. Developers are first class users of your product and first and foremost need to be encouraged and given the time, by leadership, to put these conventions and infrastructures in place.
Single step local environment setup
Automate this process, and have a single entry point for on-boarding new team members. Ideally this would be a script that can be run to spin up everything a developer needs to start contributing.
Single step startup
Similar to the ease of setting up a local environment, starting the app locally should just be just as easy. There should be a single entry point for starting your app locally, ideally `npm start`. If your app depends on other services, make those services mocked by default when running the app locally, or point to services in a stable shared environment, like a QA environment.
Developers should be encouraged to make changes and be confident that their changes won’t break other parts of the application. This information should be available to them in their local environments. This means thorough contract tests against real implementations and stubs of integrated systems, and also means each application should have a single bounded context. Tests should be easy to run, cheap to run, and reliable to run and they should be run any time new code is introduced. We use Husky to tie checks into our git lifecycle.
Shared code styles
Adopt a common set of rules on code style and then enforce them everywhere, as code. This is exactly what companies like AirBnB have done with their AirBnB style guide. StandardJS is also great and my style guide and linter of choice. Do not reinvent the wheel. Pick an existing standard and stick to it. This also applies to your version control commit styles, which leads to the next initiative.
Use a commit message linter
Lint your commit messages with a tool like commitlint, a spec like Conventional Commits, and tie it into your git lifecycle with a tool like Husky. This cleans up your version control, enforcing a readable standard on all commit messages. This initiative is often overlooked, but has a ton of benefits to DX.
Follow SemVer for versioning all of your codebases. Tools like Standard Version will inspect your commit messages and automatically tag and bump versions, according to SemVer, for you – AND it will automatically generate and maintain a committed changelog for you.
Maintain a changelog
Changelogs tell developers what has changed in a piece of code over time. You get this automatically by following the last two bullets (remember DX is a feedback loop?)...
Infrastructure as code
Poor CI can bring software delivery screeching to a halt. CI should be as close to the developers as possible through the use of infrastructure as code. Tools like Travis and CircleCI encourage this approach and empower developers to describe the continuous integration their projects need without compromising on security. These tools can be used to automate most of the DX initiatives previously mentioned.
Store documentation with code
Documentation separated from the code that it documents is more likely to become stale. Keep READMEs up to date. Use ESDoc or a type system like TypeScript to directly document code, as code (with Babel 7, you don’t even have to use the TypeScript compiler to get the advantage of TypeScript’s static type checking).
Keep dependencies up to date
One of the quickest ways a product starts being called a “legacy” system in your organisation is when its dependencies are not kept up to date. Use a tool like GreenKeeper to automate keeping dependencies up to date and encourage developers to update dependencies often. This will often make dependency updates a non-issue.
Unlock the value
Developers are the forgotten users of many digital products. By making DX a primary concern of your organisation, alongside UX, you will have an edge on the scalability, maintainability, and robustness of your digital products.
Encourage your development team to take that extra time to document a new feature, or to add some of the developer facing initiatives detailed above. Your users, the end users and developers, will be happy that you did.
Author: Tyler Hall