• About Us
  • Work
  • Capabilities
  • Careers
  • Technology
  • Blog
  • Contact Us
  • About Us
  • Work
  • Capabilities
  • Careers
  • Technology
  • Blog
  • Contact Us
July 20, 2017

Three Ways to Improve Internal Developer Experience (DX)

Posted by Christopher Davis

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.

codingdeveloper experienceDX
Previous
Next

Latest White Papers

  • Why Voice Matters: Identifying the Latest Opportunities in Voice Search
  • eSports Advertising and How Brands Can Get in the Game
  • Navigating the Amazon Ecosystem
  • See all White Papers

Featured Posts

  • How An Unusual YouTube Partnership is Disrupting an Entire Industry
  • PMG Among Best Employers for Parents
  • Why You Should Take Your Vacation: My Experience Going Off the Grid
  • Working with an Automation Mindset
  • Why B2B Brands Should Use Video

Categories

  • Content
  • Creative Design
  • Data Analytics
  • Development
  • Display
  • E-Commerce
  • Industry News
  • Local
  • Mobile
  • Paid Search
  • PMG Culture
  • SEO
  • Social Media
  • Structured Data
  • Video
Fort Worth

2845 West 7th Street
Fort Worth, TX 76107

Dallas

3102 Oak Lawn Avenue
Suite 650
Dallas, TX 75219

Austin

823 Congress Avenue
Suite 800
Austin, TX 78701

London

33 Broadwick Street
London
W1F 0DQ

New York

120 East 23rd Street
New York, NY 10010

Get in touch

(817) 420 9970
info@pmg.com

Subscribe to the PMG Newsletter
© 2019 PMG Worldwide LLC. All Rights Reserved.
  • Contact
  • Privacy Policy
We and our partners use cookies to personalize content, analyze traffic, and deliver ads. By using our website, you agree to the use of cookies as described in our Cookie Policy.