The central theme centered around developer experience or DX.
What is DX and why is it important?
DX is UX for developers. It covers the entire spectrum of how a developer interacts with your platform or tool and could range from API design and documentation all the way through to user interface. In short, DX revolves around enabling developers to be successful with a developer product.
For instance, hackability is key for developers; this means that having an API for your product is a no-brainer. API’s should be discoverable –– meaning that you can explore and test an API in an easy way and expand your understanding of it. The gold standard for API documentation is still Stripe.
Another great example of good DX is Heroku’s CLI and how it implements sensible defaults. For example when you first start a project and you’re unsure what to call it, the Heroku CLI will just generate a name for you. The consequent (Samurai inspired) naming convention is now famous and integral to Heroku.
My favorite talks
In my opinion Christine Yen from Honeycomb gave one of the best talks at DevGuild on baking developer experience into your company culture, the different phases your company can go through and how you can implement and support DX throughout the lifecycle of a developer product company.
Christine gave the following tips on how to grow out of being a passion product to something other people use for their use-cases:
Early on in the company’s lifecycle you primarily want to integrate dogfooding across all your business processes in order to be familiar with all the pain points and the problems you’re trying to solve as a company.
As the number of users of your product grows you want to emphasize support in order to complement dogfooding and keep everybody on the frontline. The interaction that your team has via support can be fed back into documentation and keep the feedback loop short. At Christine’s previous company, Parse, they had a company-wide support day every few weeks that made sure every member of the team interacted with users and the problems they encountered.
A great quote from her around developer evangelists and advocates was that they are ‘jetpacks’ not 'crutches’, i.e., everybody within the company should have a chance to talk to users, get some face time and support them.
In case you were wondering, at Wercker we use Wercker to build and deploy Wercker (and all the microservices it consists of). Our CTO Andy Smith gave a small performance presentation on building Wercker with Wercker at our Amsterdam office.
He also made some great points about how a CLI is one of the first touch points for a developer and how it allows your product to become part of their critical path. A successful CLI is not only part of the everyday developer workflow — it also needs to build trust. This can be achieved through versioning, backwards compatibility and an easy upgrade path (+ documentation!) to name a few. The importance of sensible defaults with CLI’s did not go unmentioned either.
Finally, consider the user of your API. Naturally when talking about CLI’s we default to people using them on their laptops. But CLI’s can also be invoked by machines in order to automate some processes. For people command line flags are a great way to specify a condition or option. However, for machines they are less than ideal — this is where environment variables come in, depending on the variable (for instance development versus production) a CLI might be executed in a different way.
Here’s the official Heavybit recap of this awesome event: Heavybit Blog
How wercker thinks about DX
At Wercker we believe that developer tools need to get out of the way. For this reason we created and open-sourced the Wercker Command Line Interface (CLI), that enables developers to execute Wercker pipeline on their laptops. The Wercker CLI is the exact same application that we run on the Wercker platform to run your builds and deploys. Not only does this provide dev-prod parity, it also rapidly increases the dev-build-test feedback cycle.
Another good example of how we think about DX at Wercker is our frontend and design aesthetic. It is an area where we continue to innovate in, in order to increase developer productivity for our users and create the best automation platform possible.
We’re totally aware of the fact that this recap is a bit late, but hey, we’ve been busy perfecting an awesome tool. Hope you enjoyed it.
We’re hiring! Check out the careers page for open positions in Amsterdam and San Francisco.
As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using Wercker, be sure to tweet out your #greenbuilds, and we’ll send you some swag!