Once upon a time, UX become a big buzzword in software.

Reasonable enough: UX ensured the person who landed on your digital product could happily navigate the critical path that ended with your making money. It was discovered that frustrated or confused customers abandoned shopping carts. Good money was being spent on everything from ads to headcount to server infrastructure, all with the hope that customers would engage in a transaction. But pesky things like subjective human experience were getting in the way.

Bad user experience increased customer acquisition costs, because some percentage of customers would bounce off of your product even if it absolutely could solve their problem, simply because they couldn’t be bothered to finish the transaction.

Investments in UX sealed gaps in the funnel, but successful UX had more holistic consequences. My first paid development gig was running mobile for Hipmunk, a travel search startup that differentiated on user experience. Hipmunk’s investment in UX translated into powerful word of mouth marketing. Users gushed to friends about our Gantt chart UI and a helpful sorting algorithm that penalized high “agony” flights.

Hipmunk was the best way to find a flight. It was fast and easy to pick something that would work great for your budget, comfort and plans. Skimming the Gantt chart made it much clearer how long any given trip was, and what kinds of layover penalties you endured in exchange for a cheaper ticket. It was easy to be confident because the best flights popped out of the results like beacons.

Sadly, the margins on selling plane tickets were shit and Hipmunk took an exit. But the lessons here are germane to developer experience as well.

Developer experience practice perceives a funnel, smooths its rough edges, and closes its gaps

A developer tools business has a funnel like anyone else. At the top of the funnel are people with problems. At the bottom of the funnel are people who depend on your tool to solve those problems, thanks to a successful integration.

There’s some Pareto stuff going on here: a smaller chunk of these developers will actually make you money. But with luck, the pleasure of using your tool will make most of this population happy to recommend you, regardless of individual spend. We’ll get back to this.

First, let’s talk about the funnel.

An abstract developer tools funnel

In a developer product, your job is to shepherd developers through these steps:

1. Awareness: “I understand how this tool can help me”
2. Experimentation: “I am playing around with the tool to evaluate its power”
3. Success: “The tool has helped me reach a goal”

The more people who reach the end state of that funnel, the broader the network of people willing to recommend your product and help each other use it.

So the first question becomes: How do we optimize that funnel?

”DevEx: What Actually Drives Productivity” argues that developer experience depends on flow state, feedback loops and managing cognitive load. Their perspective is much more about corporate productivity than is relevant for our purposes here, but those levers are absolutely the correct ones.

Cognitive load is a primary concern: if it seems painful or complex to a solve a problem with your developer product, plenty will bounce off right at the top.

We manage cognitive load a number of ways, for example:

• Abstractions around complex tools with affordances that make it clear how to access their power (think: pre-built containers with a terminal interface, or a GUI for a debugger)
• Docs that sequence learning to provide just enough context to make exciting progress, without overwhelming in the details
• Example projects demonstrating a working implementation of your tools in a context that’s analogous to a developer’s end goal
• Organized code snippets that demonstrate viable approaches to common tasks

Every time you see a project on GitHub with a snippet of “setup” or “basic usage” code near the top of the readme, you see the management of cognitive load.

By making cognitive load more manageable by more developers, you unlock the next phase of your funnel: a developer engaging in feedback loops with your product.

Feedback is essential: it tells developers if their efforts are working. Modern UI development integrates this power deeply, as everything from web frameworks to native development for mobile now offers hot reloading and live previews.

Feedback also shows up in the form of compiler warnings and errors, and this is central to modern workflows with typed languages. As you code, your editor can give you immediate feedback about the correctness of your implementation, warning you about a mismatch between what one function returns and what another accepts as input. This feedback is powerful, as it prevents entire categories of error that, in previous eras, would become crashes at runtime.

Error logging is yet more feedback, and the more detailed it is, the more developers can get help from an even more powerful source: other human beings. A developer community is an essential source of feedback, as not everything can be handled by automation. A strong developer community acts as an exception handler for issues that fall through the existing documentation and feature set. More than that, a strong community can help developers become better at their work, by providing suggestions and perspective.

Successfully facilitated, agreeable cognitive load and consistent feedback lead to flow state, which is the ultimate goal of your funnel. When developers are capable and confident enough to maintain consistent flow toward their goals, you’re almost guaranteed to arrive at a successful integration.

But this is more than just a business outcome. This is a personal accomplishment on the part of the developer your tools have been enabling. The results of this can range from short term satisfaction all the way to career advancement and even wealth.

As a field, computing has a lot of power, and having power shared with you can be an emotional experience.

‘Developer tools’ is culture, and culture breeds fandoms

All of these represent culture:

• A dog-eared script for King Lear
• East Coast vs. West Coast rap beef
• A Star Trek convention
• Building Iron Man armor with a 3D printer
• Your favorite programming language

Fans are people who strongly identify with an element of culture, willing to invest time in the replication of that culture within the larger story of humanity. Fans make costumes, props, creative homages, and outright remixes of their favorite culture.

To be a fan is to become part of something greater, because you think it’s worthy.

So, of course, developer tools have fandoms. Make someone a success and you’ve probably earned a fan. This is a relationship that transcends mere business transactions. This is certainly belief in your mission: conviction that you’re creating something special. But it goes deeper, into the primordial relationship of trust and gratitude we feel toward the tools that help us grasp beyond our reach.

A fan can become someone who will work actively themselves to improve the total of your developer experience. They might create tutorials, supplemental tools or code, even give their time to help other people become more fluent in your product. Fans will generate pull requests on your projects, and open issues that help you improve.

En masse, fans can even re-shape larger technology culture to better adopt your stuff. This is the goal of the vaunted “bottom-up” or “developer-led” growth strategy: developer consensus that yours is the best way to solve some category of problem.

It’s also why we can have such emotional responses to acquisitions of software products and firms. The guiding ethos that shapes a technology subculture can be vetoed by the new owner, changing basic assumptions that have guided our investments—that is, our hopes for the future.

Having a fandom is a serious responsibility because it means managing the vibes and health of a community.

A better world is possible

Fandoms aren’t set-it-and-forget-it. They require stewardship. So let me tell you about one of the healthiest fandoms in speculative fiction.

It’s The Expanse.

Here’s how we know this:

Some years back, actor Cas Anvar (Alex Kamal) was accused by multiple members of SFF fandom of abusive behavior. An investigation ensued and Anvar was written out of the show.

On /r/TheExpanse, mods organized immediately to set norms to respond to this crisis. Comments on the controversy were actively cordoned to specified threads. Participation in these threads was governed by a set of agreements, including compulsory reading of specific accounts from the accusers. As a whole, the subreddit maintained order. In the higher-stakes discussions, clear terms of engagement allowed moderators to shape productive conversation, dismiss bad actors, and prevent toxic flame wars.

It didn’t devolve into the kinds of vitriolic misogyny that is too common in these situations. Meanwhile, the community was able to reach consensus by talking through the substance of actually happened, instead of fracturing along chaotic lines of misunderstanding.

Enabling this was culture established from the very top. The Expanse was written in a way that always respected its women characters. The creatives made deliberate decisions to eschew gratuitous sexual violence as a storytelling mechanism, by contrast to projects like Game of Thrones. And, when trouble emerged within their own ranks, the show’s leadership took it seriously, communicated the investigation to the larger fandom, and took decisive action.

Fandoms can be scary stuff, but consistent leadership opens the door to norm-setting, orderly discussion of high-energy topics, and a place where people don’t feel excluded or pushed out because of their identities.

And so, the theory:

1. You can make more people more likely to be successful with your developer tools
2. People who you’ve made successful will want to share that success, encouraging others join the party you started
3. This creates a positive feedback loop that encourages fandom to form
4. Productive fans energize your ecosystem and enroll yet more developers if you remain aligned with their success, and maintain community health

It’s obviously much messier than that. Especially the bit where you need to come up with something that genuinely moves the needle on someone’s individual sense of power.

But in the game of software automation, power is all around us. We’re saturated by unprecedented opportunity to create impact and leverage, with a ceiling in the billions of customers. It’s never been more possible to package up power and wisdom and share with those who are eager to apply it through code.

Do with this knowledge what you will.