Developer Experience - 5 Core Principles

2 min read
Outline

Quality is an accumulation of subsequent right decisions.

thumbnail

Principles

  • Local development must be super easy to do.
  • Linting must be a standard.
  • Testing must be very easy to do and run.
  • The CI must run on any push.
  • Deployment to staging must be cheap.

Local development must be super easy to do

I have seen local developer setups that were so complicated, that it took days to get set up.

Especially when other services are involved, things can get messy. And then you need to run dev environment, but also the tests.

Also important: Have a comprehensive README.

What helps us: docker compose is great. And then having a good readme to walk through the steps.

This post helped a lot: https://stackoverflow.com/questions/71395156/how-to-separate-environments-of-a-project-in-docker-and-docker-compose

Linting must be a standard

We just follow the “Standard” gem for ruby. Many other programming languages have linting.

Bonus of using Python: the syntax is very straightforward.

Problem with something like Ruby or PHP: It can have many styles.

We use rubocop and erblint to make sure the code always looks the same.

Testing must be very easy to do and run

Local testing is super important, because then developers can apply TDD.

Also: simplecov - it makes is mandatory that there is enough test coverage.

pipelines example

The CI must run before a code review

Usually CIs run on every push to a branch / PR / MR. That’s a good way to go.

A company I worked for even had a kubernetes setup that created playgrounds for every feature branch. That’s too much for a small company, and has different drawbacks.

Best way is to create previews of the software (usually staging / preview env) on demand. Then a version can be tested before it is released to production.

Deployment to staging must be easy

In order to test a version, we need to test it on a preview/staging environment.

These things have helped us a lot:

  • Versioning in the footer, and a “Deployed 10 minutes ago” information
  • The same code as runs on production, so the same things can get tested
  • Deployment from a “preview” branch. Devs can use it anytime

Production is then deployed from the main branch with a version tag.


Till Carlos

I'm Till, a senior developer who started a software company. I explain software concepts for people in leading roles.