Developer success is about paying the rent

I look at developer experience as a nested set of microeconomic problems. A well-optimized DX makes the most of the individual and team labor needed to:

• Learn developer tools, from APIs to design patterns to integration strategies
• Apply these tools to the developer’s specific domain and goals
• Debug outcomes to arrive at a reasonably robust, predictable, correct implementation
• Successfully ship artifacts on whatever terms the developer cares about (creative, commercial, collaborative)
• Iterate on these artifacts to refine their effectiveness and power
• Collaborate across all these facets, either as a distinct team, or with fellow developers on the internet working on distinct projects

In short, DX is about creating the conditions for developers to be successful.

There are many ways, meanwhile, to define developer success. But for the specific context of a developer tools business, I would argue the definition is simple: developer success is a rent check that clears.

While times are turbulent in the technology industry, the fact remains that software skills are a high-leverage form of labor. When you create software, you’re creating impact that can scale at near-zero marginal cost, serving dozens of customers up to billions. This has power and the need for it exists across every industry sector.

Every business needs software, and most businesses will use it in some form to deliver value to their customers. To accomplish this, they hire the best developers their labor budgets, networks and cultures can attract.

Thus, if you’re making devtools for money, you have to understand how your tools are competing against alternatives that make developers more effective at creating results that pay their rent and advance their careers.

Onboarding is an essential lever in this equation. If the activation energy needed to become productive in your tool is too great, it’s going to lose against alternatives that provide more immediate results. You want the time between a developer reading your marketing page, and that same developer making their first API call, successful build, or other hello-world-like activity, to be as short as possible.

A few minutes is ideal.

A few seconds is even better.

But even if you optimize your basic mechanics to make that moment of traction easier, there’s more to do. Your project needs to demonstrate its design patterns in a way that lets developers import the mental model of your expectations for a successful integration.

Mere docs of the existing functionality are not enough. Tutorials are better. But best is a collection of reference implementations—Glitch.com calls these “starters”—that let developers begin tinkering with a system that’s already complete and working, even if its scope is limited or simplistic.

Tinkering your way into a proof-of-concept is fairly cheap from there, and when the artifacts are good, pretty fun as well. This is how you can convince a developer that your solution has the tangible qualities they need to invest the considerable labor of learning and integrating your stuff into both their project and their longer term professional destiny.

Remember, too, that your competition isn’t just other developer tools. It’s developers avoiding your tool by solving the problem the hard way, because short-term, at least they are feeling traction on their progress.

So as we build developer tools, we have to think about:

• Who will be made more successful when this ships?
• How will we make the case to them they’ll win with us?
• How will we demonstrate the superiority of our approach?
• How can we limit the costs of initial exploration and proof of concept?
• How can we maximize the impact of the investments developers make to integrate us into their workflows, products and future outcomes?

Hey, I never promised it would be easy. But it is worth it. There’s nothing more powerful than a legion of grateful developers whose rent checks clear because once upon a time, you made them successful.