Want to get the developer experience right? Focus on the basics

“Developer experience” is a term that gets thrown around a lot these days. It’s come to encompass a lot including ping pong tables and work-from-home policies. However, an often overlooked and incredibly important piece of the developer experience revolves around something very basic: how a developer contributes code.

There is no better canary in the coal mine of developer experience and productivity than asking yourself this question:

How fast can a developer who just started working at your company contribute code?

Many companies don’t allow developers to contribute for quite some time. I’ve read stories from developers lamenting endless days of conference calls going over every line of code before being allowed to touch anything. As a result, it takes much longer to become productive than it needs to and leaves developers feeling anxious and frustrated.

Next question:

SEE ALSO: Developer first – a new Leadership Mindset

If developers do successfully contribute code, are they able to bring a whole production database down?

Here’s an extreme, but real, example: Imagine that it’s your first day on the job as a new developer. You receive instructions on how to set up your local environment and get to work. Then, you find out that you accidentally destroyed a production database and are fired immediately. You can read the full story on Reddit here.

If a new employee on their first day has the ability to wreak such havoc on the company’s database — it’s not their fault. It’s yours. More accurately, it’s a fundamental failure of your developer workflow process.

While we don’t know which organization this poor developer was unceremoniously dismissed from, we do know that such mishaps are not limited to nameless companies. Similar database issues have occurred at Amazon S3, Salesforce, and GitLab. (Of course, GitLab has a far better culture regarding learning from mistakes, unlike the Reddit user’s former employer.)

It’s fundamentally important that you nail the developer workflow experience. It could cost you an incredible amount of money in both the long- and the short-term.

Today, there are tools available to get developers who are new to your team to start contributing immediately and without risk, using realistic data. Also, just because you are using old technologies or old databases doesn’t mean you can’t update your internal workflow or use new development tools. Here are the basic ingredients:

Source code repository (e.g., Git)

It’s vital to allow multiple developers to work on the same codebase so that they can commit and merge code without conflicts and make edits to shared code, without unknowingly overwriting each other’s work.

Orchestration tool (e.g., Jenkins)

Orchestration tools are designed to streamline and optimize frequent, repeatable processes to ensure fast and accurate deployment of software.

A container (e.g., Docker)

Containers allow developers to create predictable environments that are isolated from other applications. They may also include software dependencies needed by the application, such as specific versions of programming language runtimes and other software libraries.

Data management/sharing tool (e.g., Titan)

These tools enable developers to clone, commit, checkout, push, and pull data just like code, making it easy to roll back to a previous state, build a test data library, or share a structured dataset with collaborators. Essentially, data tools that allow developers to manage their data like code.

SEE ALSO: Security engineering: Glide path for software products

Database schema migration tool (e.g., Liquibase)

Many developers struggle with database migrations. Tools can help teams track, version, and deploy database schema and logic changes and can integrate them into the CI/CD process for faster releases.

Your company most likely already uses many of these tools. Ensure that there’s a workflow in place that allows developers to feel comfortable (“I won’t bring down a production database if I mess up”), confident (“I can positively contribute to this team immediately”), and productive (“I can get my job done quickly”).

By nailing the developer workflow experience, you’ll have more productive developers, they’ll be happier, and they’ll stick with your company longer.

The post Want to get the developer experience right? Focus on the basics appeared first on JAXenter.