A Guide to Good DX: Introducing DXmas

December is often a time of slowdown. This can be for good reasons, e.g. payments companies instilling a code-freeze to ensure nothing breaks during their customers’ busiest time of the year. But, it can also be a time to speed up. To use the looming closing of the year, and the dawn of a new one, as an incentive to knock out a bunch of little things.

Those little things can add up. So, for December, we’re doubling down on developer experience (DX) with a team-wide commitment to what we’re calling DXmas. In the spirit of the festive season, we’re making a list, checking it twice, and putting it in Linear. We’ll also be sharing some thoughts here along the way.

Intro to Developer Experience (DX)

DX is the process of making software development easier, faster, and more enjoyable for developers. Developers want to spend their time writing code. Any time spent faffing around with clunky UIs, messy SDKs, or poorly thought-out APIs is wasted. If you hinder the builder, you’ll soon find yourself without customers. Industry-leading DX is more than an aspiration for us; it’s crucial for survival. Good DX is mission-critical for every business that developers interact with regularly.

When designing a new product, the product needs to be an order of magnitude better than its competition to succeed. That’s an incredibly hard bar for anyone to reach. However, that 10x goal is a vague one. And we believe that it is possible to meet it by providing an outstanding developer experience alone. Let’s start by considering the principles you should abide by to 10x your DX.

Principles of Developer Experience

1) Show, don't tell

It's essential to show developers working examples of your product in action. Seeing it in action proves to them that it works as expected and makes it far easier to imagine what they can build with it.

2) Gradually reveal complexity

Planning the learning curve for your product is a delicate balancing act: too steep, and you'll scare everyone away; too gentle, and you'll miss opportunities to create value for your customers. You must place yourself in the developer's mind as they first explore your product and carefully plan when you introduce new 'Aha'-inducing concepts to them.

3) Deliver on developers’ expectations

As a developer, there's nothing more frustrating than expecting that you'll be able to do something and realising that it either isn't supported or wasn't implemented in the way you expected. Developer tools should strive to work in the most obvious way; where that's not possible, they should clearly document their shortcomings.

Similarly, it's vital to ensure consistency across your product stack. For instance, if you offer SDKs to interact with your product, they must all be of the same standard. You'll quickly frustrate developers if they find that the SDK for their language doesn't contain features you support in your other SDKs.

4) Earn their trust

Developers will only use your product if they trust you. Trust is hard to win and easily lost. You must implement proper API versioning, so changes don't brick their workflows. Earning their trust means recognising that any regression is unacceptable; you must build proper test suites to prevent it. It means responding to support queries in minutes, not hours or days.

5) Don't hinder the builder

Your implementation needs to be fast; developers don't want to waste time writing boilerplate to get the simplest demo up and running. Design everything with speed in mind from the outset, and ensure that developers can run a proper local testing environment, so you never slow them down.

DX is in the details

“When art critics get together, they talk about Form and Structure and Meaning. When artists get together, they talk about where you can buy cheap turpentine.”

― Pablo Picasso

While this blog is a primer for DXmas, we generally subscribe to a Picassian theory of DX — focusing on the practical — expect a lot more turpentine over the next few weeks! For now, let’s consider a specific case study to see how developer experience has enabled the development of the internet itself.

A DX Case Study - Hosting

Early Internet:

Companies had to buy servers directly from companies such as Apple, Dell or HP to host their content on. These servers didn’t come cheap - the entry-level Apple Network Server 500/132 sold in the US for $11,000 each back in 1996. For that price, you got a blazing fast single-core 132 MHz PowerPC processor and 32 MB of RAM. (For comparison, the octa-core M2 chip inside new Macbooks has 250 times more RAM!)  Once they were done forking out for servers, early tech companies needed to hire developers to manage these servers. The servers needed to be loaded with the latest version of the Apache HTTP — or, God forbid, Microsoft IIS! — Server and PHP runtime. Back then, the application and the server were one construct — there were no VMs.

Once that was set up, there was the challenge of keeping it all up to date and ensuring that they had enough computing resources to manage any reasonable level of customer traffic. Companies had to pay thousands to ISPs for robust, high-bandwidth internet connections, and having a US and an EU region meant having physical operations in both continents. This wastage and forced overprovisioning was particularly challenging for early tech startups, who often spent large amounts of their funding on servers just in case they blew up on launch day.

This led to a lot of waste. Companies would frequently have to massively overprovision servers because any downtime was unacceptable.

Mid Internet:

Amazon popularised cloud computing with the launch of AWS in 2006. Amazon started AWS because they wanted to reduce the wastage of expensive servers on their site, which were needed at times of peak demand but usually went idle. AWS saved developers time by managing server purchasing and setup, software updates, internet connectivity, and a whole lot more.

However, it wasn’t perfect. While Amazon kept the machines up to date, developers had to spend time thinking about how the software would scale across multiple instances and at which traffic thresholds it would scale.

Now:

Enter modern hosting platforms like Vercel - a company renowned for its developer experience. Vercel connects directly to where you store your code and can instantly deploy it across the world whenever you push new code to your repository.  Developers don’t have to worry about scaling or updates, and cross-region can be turned on by adding a single line to a config file.

Some businesses grow by providing a better developer experience than their competitors. Vercel didn’t grow its customer base by allowing developers to do things they had never been able to do before; they grew it by making it trivial to do the things they had already been doing. At Evervault, we want to do the same for encryption: make it ubiquitous by making it trivial.

We’ll be sharing our DXmas updates here on the blog and on our Twitter over the next few weeks. See our DX in action in this video, or explore our DX for yourself by creating a free account.