Benefits of a Developer Experience (DevEx) team
Tags: devops, tooling, productivity, devex
Published: 2023-02-23 13:41:26

Developer Experience (DevEx) is a concept similar to User Experience (UX). It focuses on the developer's perspective of how easy, efficient, and enjoyable it's to work with your product.

DevEx can be external or internal:

- External DevEx focuses on a developer who uses your product as a consumer, by, for example, integrating with your API. 
- Internal DevEx, which this blog post focuses on, strives to create the smoothest possible experience for the engineers who develop your product. 

Internal developer experience impacts the productivity of the Engineering team and how satisfied and engaged developers feel at work. It can encompass various elements, from the more technical, like clean code, good documentation, and efficient internal tooling, to more intangible things, like your engineering culture and the level of psychological safety in your team. 

# How investing in DevEx has helped us at Supermetrics
At Supermetrics, our DevEx team focuses on the technical side of things — it develops and maintains tooling and processes that make our developers' work easier and increase their productivity. 

Here are some of our DevEx team’s recently closed cases to give you an idea of how they improve our tooling and processes:

- Upgraded dependencies in shared repositories.
- Researched and compared code quality tools to be used across teams.
- Upgraded Docker container images.
- Improved error handling in `smtool`.
- Improved the performance of our package managers.
- Drove the PHP version upgrade.
- Added checks for required software’s versions and warned teams if it wasn’t up to date.
- Shared settings for PhpStorm (configured debugger and other external tools).
- Automated database migrations.

When the DevEx team owns our shared tools and scripts, developers can focus on their projects without worrying about who'll implement new features and whom to report new requests and bugs. A tight feedback loop between the DevEx team and developers allows the team to react to problems, needs, and improvement ideas quickly.

## Onboarding

A good developer experience starts with a positive first impression, which is why onboarding is a key focus area for our DevEx team. Comprehensive documentation on how to set up your development environment is essential for a new hire to get up to speed quickly. 

We've taken this one step further with our `install_dev.sh` script. It installs all the required software at the correct version and helps a new developer set up their local Docker environment, Git integration, common repositories, and even IDE configuration. 

Talk about getting a running start! Before, it could take 1–2 days to set everything up. With the script, you'll be done in 2–3 hours at most, with little chance of human error. Considering how frequently we've welcomed new developers to our team lately, we appreciate the time saved.

## Developer environment

Another time saver is when you can easily replicate whatever you do in a production environment in any other environment, including local. It means using a similar setup, the same software version (HTTP server, PHP, database), and the same version of packages. The DevEx team helps ensure that the local environment mirrors the production one, resulting in fewer discrepancies between the two and fewer bugs.

The DevEx team has built a handy tool that our developers use daily to manage their development environment — the `smtool`. It works for both macOS and Linux, automates the running and updating of Docker containers, and keeps repositories and IDE up to date. It started as a collection of Bash scripts, but we're now migrating them to Go. 

My personal favorite is the `smtool check` command. It checks if the required software is up to date and all required shared repositories and local configuration are in place. It's the first command I use to look for the cause of issues with the local developer environment. Most common issues are handled automatically. Whether that's outdated software, lack of configuration or credentials, `smtool` will offer to solve it right away. 

### 3rd party software and packages

Our [Core Engineering Group](https://dev.to/supermetrics/meet-our-core-engineering-group-1il1) tends to be the source of most packages that are used in most projects. By using [Private Packagist](https://packagist.com) and [Dependabot](https://docs.github.com/en/code-security/dependabot/working-with-dependabot) we can handle them easily and ensure up to date versions are used. 

New vulnerabilities are discovered every week, and new versions of popular packages are released. Keeping them all up to date is tedious work that takes time. With some automation, it's only a matter of a manual review and approval before changes are made. That's because Dependabot is a software that automatically looks for possible updates and prepares a PR with an update to the latest available version.

## Error handling and documentation

Meaningful error messages in internal tooling are one way of making developers’ lives easier. Whenever `smtool` fails to do something, it tries to come up with a helpful error message. It links to a troubleshooting guide, prints a help page, or asks for credentials to set up missing configuration. This way, you don't have to type in or copy-paste long and complex commands. 

If all else fails, we aim for logs to be useful enough to identify bugs quickly.

It's a crucial thing to have documentation for common issues. We tend to test our internal software and document any potential issues we find that can’t be automatically solved. That way our developers get a troubleshooting guide that’s helpful when we’re doing a backward incompatible change (like new PHP or database version).

Documentation is also a place where we keep good practices documented and a common coding style we’d like to follow.

# Investing in DevEx is paying off for us

The desired outcome of devoting time and resources to improving Developer Experience is an engineering organization that works comfortably with the local environment and handles tasks efficiently. If working with the code or the environment causes frustration, confusion, or fatigue, it might be a sign of a bad Developer Experience.

We're only at the beginning of our DevEx journey, but the benefits to our developers' happiness and productivity have been encouraging. We're in it for the long run and excited to see where further emphasis on a good Developer Experience will take us! 


If you’re interested in diving deeper into DevEx, here are our favorite resources on the topic

- https://microsoft.github.io/code-with-engineering-playbook/developer-experience/
- https://www.redhat.com/architect/developer-experience
- https://developerexperience.io/articles/good-developer-experience

---

Learn more about Supermetrics as a workplace at [supermetrics.com/careers/engineering](https://supermetrics.com/careers/engineering).