This website uses cookies to ensure you get the best possible experience. See our Cookies Policy.

PMG Digital Made for Humans

Three Ways to Improve Internal Developer Experience (DX)

4 MINUTE READ | July 20, 2017

Three Ways to Improve Internal Developer Experience (DX)

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.

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.

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.

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.

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.

.travis.yml

script:  - 'if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then ./bin/dev/fixcs; fi'

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.

Insights meet inbox

Sign up for weekly articles & resources.

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.


Posted by Christopher Davis

Related Content

thumbnail image

Get Informed

PMG Innovation Challenge Inspires New Alli Technology Solutions

4 MINUTES READ | November 2, 2021

Get Informed

Applying Function Options to Domain Entities in Go

11 MINUTES READ | October 21, 2019

thumbnail image

Get Informed

My Experience Teaching Through Jupyter Notebooks

4 MINUTES READ | September 21, 2019

Get Informed

Trading Symfony’s Form Component for Data Transfer Objects

8 MINUTES READ | September 3, 2019

Get Inspired

Working with an Automation Mindset

5 MINUTES READ | August 22, 2019

Get Informed

Parsing Redshift Logs to Understand Data Usage

7 MINUTES READ | May 6, 2019

Get Inspired

3 Tips for Showing Value in the Tech You Build

5 MINUTES READ | April 24, 2019

thumbnail image

Get Informed

Testing React

13 MINUTES READ | March 12, 2019

Get Inspired

Tips for Designing & Testing Software Without a UX Specialist

4 MINUTES READ | March 6, 2019

Get Informed

A Beginner’s Experience with Terraform

4 MINUTES READ | December 20, 2018

ALL POSTS