Developer Experience or DX is a relatively new idea. It doesn’t even have a Wikipedia page yet (that I could find in July 2017). This is a fairly nice overview of the DX idea related to APIs and Heroku has a page dedicated to it. Symfony, an open source PHP framework we use quite a bit, has a whole dashboard of DX initiatives.
Open source projects have DX initiatives. So do platforms as a service and tooling. But what doesn’t get talked about much is developer experience inside a company — how pleasant is it to build things at your workplace? PMG’s development team has doubled in size in the last year (we’re still growing if you’d like to join us) and that growth has me thinking about DX.
Here are a few things I think play a huge role in your internal DX.
1. Consistency is Key
How many internal applications or microservices are running at your company? Is the process to get started with the same for each one? Or is it different? How does one run a local copy of the app?
These are important questions. If the process is different or some apps require certain versions of backing services or languages, that’s a huge missed DX opportunity.
It should be a single script or command to spin up a development environment and backing services, and that command should be in the same place in every application or service.
At PMG, we only assume folks have docker, docker compose and the programming language(s) of the app installed on their local machine. Nearly all of our applications launch all the required backing services (Postgres, Redis, MongoDB, etc.) by running ./bin/dev/up from the root of the project repo. This script is safe to run multiple times and also does things like run database migrations and ensure application dependencies are up to date, e.g., in npm install or composer install). This means the workflow is the same for every single application:
git checkout -b feature_branch origin/master ./bin/dev/up # make sure we're up to date! # work work work
At PMG, we only assume folks have docker, docker compose and the programming language(s) of the app installed on their local machine.
Use tools like docker or vagrant to provide development environments to make the experience of starting to work on anything painless.
2. Script Everything
Especially script things that are more than one command. Even single commands deserve a script that’s well named for the context of the application.
This can be done with shell scripts or something like a makefile. Should you chose to go the script route use bash or sh to make it easy to run for any developer. PMG has gone down the route of having scripts rather than makefiles because they’re a bit easier to deal with.
The process to deploy the application? Script it. Something simple like clearing a cache directory? Script it. Script literally anything and everything you can.
The key here is that the processes in your application are given descriptive names. This serves a few purposes:
- Living documentation as code. No one needs to ask how to do something because it’s already there — they can dig into how things really work by reading the code.
- Anyone can do anything on the application, no matter what skill level.
Script literally anything and everything you can.
3. Automate Coding Style Checks
No one should have to check coding style (CS) in a pull request. That’s a waste of everyone’s time. Instead, use automated tools to fix files or show warnings or suggestions.
PMG uses PHP CS Fixer and ESLint regularly.
Those fixer invocations? They should be scripted (see #2 above): ./bin/dev/fixcs.
How to Automated CS Fixers on Travis CI
PMG runs our CS fixers (which exit with a non-zero code if something needs fixing) on Travis CI only for pull requests. This keeps normal test runs fairly fast, but fails any PRs that come through with coding style errors.
This can be done by checking the TRAVIS_PULL_REQUEST environment variable.
This Sounds Like a Lot of Work
It is! Specifically, it’s a lot of work for the more experienced folks on your team(s). They are the ones that have to setup a lot of this stuff and distil their tribal knowledge into named scripts and processes.
This work by the experienced devs empowers the less experienced to get more things done and feel like a badass. That’s worth the investment.