Delete Your Development Environment

Posted on by Christopher Davis

Delete Your Development Environment

Eventually more than one person works on a piece of software. When new folks start contributing to a library or application what is that experience like? Is it easy to clone the repo and get started?

Project leads and senior developers have a responsibility to ensure that the developer experience (DX) for a new team member or contributor is, hopefully, pleasant.

Deleting your development environment is one of the cheapest ways to see what getting started is really like.

I don’t mean just rm -rf your_local_repo. Do that, yes, but also drop databases and stop all backing services. Stop short of removing whatever compiler or programming language the project uses, remove or reset everything. Get rid of all those little tiny things that were changed and tweaked to make the project run just right. Start from scratch.

Then re-clone your project and try to get started again. Do all those database migrations run from the initial migration to the more current? Is there scripting to start backing services? What do those readme instructions leave out?

At PMG, we have a few DX-related standards. One is that every project should have a ./bin/dev/up and ./bin/dev/down script. This up script does everything in one go:

  1. Starts all backing services via docker-compose
  2. Installs or updates dependencies (via npm or composer or glide)
  3. Runs any database migrations to bring the local database(s) up to date
  4. Installs the default .dist configuration files required for development if necessary1

This is great for new contributors. What they need installed is minimal and one script later they are ready to contribute.

It’s also great for folks who work on the project day-to-day. New changes from other contributors? Run ./bin/dev/up and the project is ready again.

Delete your development environment. Find out how difficult it is to get started with the project from scratch. Make it better.

—

1. These .dist files include whatever configuration is not sensitive and have placeholders for sensitive stuff (along with instructions on where to find the real credentials).