Developer experience: the basics

23 May 2022

Periodically, tech Twitter swells with a discourse I find to be weirdly unproductive: people arguing about developer experience. Does it even exist? Does it matter?

I’m not going to recap the various head-scratchers in detail. But I do want to talk about what developer experience is, why companies invest in it, and what we all get for their trouble.

Spoilers: it's a problem of labor and software economics. A positive developer experience amplifies the return of effort invested building new software products.

The experience of getting things done

Put simply, developer experience is the sum of events that exist between identifying a requirement for a piece of software, and delivering code that satisfies it. Broadly, these events may be practical, emotional or social in nature.

Examples:

Referencing documentation to plan an integration of a third party service
Trying to install tools or libraries necessary to develop against a particular software framework
Getting frustrated because of an unfamiliar or undocumented design pattern
Successfully receiving help in a support forum when you get stuck

The practice of developer experience, of being deliberate in its design, is to identify the places of greatest leverage for clearing paths and relieving burdens. The objective is to improve adoption of a technology by making it easier to accomplish personal and business goals with it.

Developer tools: pickaxes in a gold rush

Selling developer tools is a straightforward business strategy. Rather than the risky bet of serving a broad consumer or cultural need, you can build technology that helps anyone who is building software be more successful.

Instead of trying to sell to hundreds of millions of users, you sell to a comparatively smaller handful of companies, typically by hooking their individual developers. If one of these customers succeeds, you succeed along with them, scaling your billings according to the growth of their business.

It sounds great, but there’s always a catch. In this case, your customers become a handful of technologists with a broad spectrum of experience levels and highly specialized needs. Your business success then rests upon a premise that’s easy to explain but harder to execute: making people more prosperous and effective because of your tools.

Leverage within the developer experience domain

How can you make people more successful and effective in accomplishing their goals? If we think of developer experience as the sum of all events between defining requirements and delivering them, we can identify some broadly recurring points of leverage.

Ergonomics and abstractions

Where the fingertips meet the keys, how does it feel to work with your tools? Does integration require painful, recurring boilerplate code, or can developers easily drop in your tools to solve a problem and keep moving to their unique implementation?

Is it easy to debug and inspect the state of your tools at runtime? When errors are thrown by your tools, is log output clear and descriptive, allowing further investigation and social troubleshooting on forums or Stack Overflow?

What is the everyday texture of life with your tool?

Tools that feel good to use obviously earn more loyalty, enthusiasm and word of mouth than tools that grate and frustrate.

Documentation, reference and education

How do people learn to use your tool? Do you provide clear documentation? Recipes? Tutorials?

What references exist for troubleshooting, debugging and discovery of features within your tool?

Thorough reference material makes it easier for developers to get the most out of everything you’ve built.

Community and ecosystem

Is there an active community experimenting and sharing their experiences with your tool? Is there a reliable, active, healthy venue where someone who is running into trouble can get help?

Is an eager community filling in gaps with their own tutorials, plugins, libraries and ergonomic improvements?

It’s easier to roll the dice on a new tool when you know that, should you need help, you’ll find a community that has your back.

Developer experience: the business cases

From these levers, we can identify the business cases for developer experience. In the context of the adopters of developer tools—whether individuals or teams—the question is whether a tool enhances their ability to be successful.

Does it make iteration cycles faster and cheaper?
Can you do more—accept international payments, integrate with legacy telephone systems, write code more correctly—with a smaller team and less effort?
Does the tool limit everyday friction for accomplishing work, allowing more work to get done?

In a software production context, developer labor budget is among the costliest resources a business has to manage. Any tool that allows a business to get more for that budget is creating serious impact.

For purveyors of developer tools, the business case becomes clear as well. Success depends on adoption. You can improve adoption by addressing points of friction in existing developer workflows, and by making your tool’s experience more positive and productive than frustrating.

This doesn’t have to be hard

When we’re talking about developer experience, we’re talking about real things:

How people feel when using tools and making software
How effective they are in meeting their goals
How these factors converge into amplified productivity versus wasted effort
What leverage exists in your strategy to shift that balance more and more toward success for individual practitioners and businesses that might pay for your service

Developer experience is a process of shifting the economics of building software to be more favorable for every dollar or hour invested. There's a lot going on there, but conceptually, this doesn't have to be that hard.

Wordle: A factional skirmish for the soul of technology

12 Jan 2022

So check out today's Twitter beef.

You know all those emoji squares that have been popping up everywhere? That's Wordle. It's a bracingly earnest word puzzle web app deliberately built to a non-commercial ethos.

Wordle is a darling of the press because of its artisanal, small-batch sensibility. No compulsion loop—you get one puzzle per day. The score-sharing tweets are informational, instead of promotional. The tweet isn't about getting your friends into a conversion funnel.

It's about showing off your adventure and prowess.

Cue the stormclouds: a guy came in, saw the cultural fervor for this, and decided to build a paid, native application, using the same name and design. Taking people for $30 a year if they keep the subscription, this Pirate Wordle started printing money.

And its developer decided to tell Twitter about it, making him the day's Main Character:

Zack Shakked gushes about the game he cloned.

A schism in tech

The Wordle beef happens at a particular cultural fault line. Information technology has politics of all kinds, but one of the most strident is described on a spectrum:

Technology used for:

joy and wonder...sacks of money

Software automation is incredible. It offers leverage unlike anything we have ever seen. You can be worth billions of dollars because you build something that solves broad-scale problems for just $0.003 a user.

Sofware is all margin.

Which attracts the money fetishist.

Money fetishist?

Money's only something you need in case you don't die tomorrow.

Martin Sheen said this in Wallstreet, and it fucked me up for life. You can't unsee it.

This is absolutely an age where having money has become synonymous with safety and security. I can't fault anyone for trying to be okay, nor being strategic about it.

But some of us are building an entire identity around being the sort of person who has money, can get money, is the ultimate money chessmaster.

They'll go through any trial proudly for access to a capitalism lottery ticket.

So, for the money fetishist, software is an irresistable lure. Software is a lottery ticket dispenser. There are scratcher tickets, like building indie software. Those are occasionally gushers of a win.

But the scale goes all the way up to lottery tickets in the shape of a term sheet for massive investment to build a company. Assemble the right team, seize the right market, and you're a billionaire.

For this group, joy in computing is not always central to their goals. Mostly their participation in information technology is a cold calculation: "how many disposable robots can we build to seize a market?"

Computing's true believers

To the other end of the spectrum, this posture is off-putting, even revolting. For better or worse, the opposing faction truly believes in the power and wonder of computing, for its own sake. Money is a second order concern to pursuing the magic of making sand have dreams.

@computerfact: computers think using etchings in poisoned sand and measure time using vibrating crystals so if you were looking for magic you found it

It wasn't always obvious—either individually or societally—that the computer was a money printer. For some folks, the computer was simple fascination. An all new frontier, defined by different rules than our everyday existence.

Everything that makes computers good at money also makes them interesting.

For many, huge chunks of a lifetime have been dedicated to exploring the power of a digital realm. Building up skills, knowledge and imagination for a playing field that's not always intuitive, but so often rewarding as you develop mastery.

This is also a path to lottery tickets. Sometimes exploring the frontier leads you to a gold mine. But on this side of the spectrum, you've got people eager to explore computing as a creative endeavor first, grabbing what money they can in case they don't die tomorrow.

The beef

Wordle exists at the maximal edge of this non-commercial ethos. It's earnest in its humane approach. Instead of an engagement treadmill, Wordle is a limited, daily treat. Rather than promoting Wordle, the tweets for announcing a score simply describe the player's adventure for the day as a score with some emoji. No URL.

In the context of Wordle's cultural froth—all these articles, all these score tweets—developer Zach Shakked saw an opportunity. To take Wordle's name, concept, and design, then strap a yearly subscription price to do it. Where the original Wordle was written for the web, this clone was built as a native iOS app, the better to capitalize on Apple's built in payment system.

My bias here: I think that move is tacky as hell, and quite possibly legally actionable. You can draw your own conclusions.

Quite a few more took exception to this approach. Kottke sums up the prosecution's case succinctly:

This person stole Wordle (a game @powerlanguish invented), put it on the App Store, and is now crowing about how rich it's gonna make him. 🤬

What this beef can show us is a fault line in the culture of those who participate in technology. Some for fun, others for profit. This is a long-brewing conflict, and you can find the seeds of it going back generations.

This Wordle beef gives you a model for this conflict that's small and fast enough to dissect as it happens.

But it's not the only beef you'll find in Wordle town. Did you know what those scores are like for screen readers?

Epic's ambitious plan for Unreal Engine and content-as-a-service

♺ 11 Dec 2021

Fascinating twitter thread by game professional Mike Bithell about the strategy Unreal is telegraphing with their recent Matrix Awakens tech demo:

Epic is attempting to flip the economics of game production towards film production.

In games, we build everything, so (and this is over simplification) game assets are a fixed cost. If I need 100 things, I need to pay for the production of one thing a hundred times. Efficiencies come in, but we're still building stuff from scratch.

An open world game? Only possible if you're a mega AAA company, or you wanna stylize to the point of affordability. Movies don't build a city, they find one to shoot in. They buy props and costumes. They hire actors rather than making westoworld style puppets.

Asset stores brought some of this prop shop and central casting mentality to games, but the problem is aesthetic consistency. If you buy 10 characters off the unity store and throw em in a game together, unless you did so very tastefully, it's gonna look shit.

With Epic offering a fully coherent city backdrop, including efficient rendering technology and consistent design across characters and architectures, Mike argues, it becomes cheaper than ever for game devs to tell stories in realistic settings. This introduces new tradeoffs:

But it also increases the quality bar and expense of doing anything that's not on the shelf. Alien characters? Metahuman with some forehead bumps added... 6 limbs is expensive and out of scope. Guns? Take a prop gun and stick something on it. 90s film solutions.

I think it's interesting to see Epic touting this just a year after Cyberpunk 2077, an ambitious platform play that nearly tanked its developer, CDPR.

Sure, Cyberpunk is a game. It's also an elaborate canvas of characters, settings, and content that they can use to sell a series of stories. Night City is enormous and immersive, and the initial story they shipped barely scratched the surface of all they built there. I suspect we'll see plenty of paid DLC over the next few years leveraging that investment.

CDPR was hoisting an enormous open world, full of systems that could be reused. The complexity of pulling something like this off is formidable, and in Cyberpunk's case, led to a disappointing initial release full of technical issues, especially for players on older consoles.

Epic, decades deep into the game engine business, understands most teams don't have the capital or risk appetite to undertake that level of investment, but sees a similar opportunity to build that kind of canvas and rent it out.

As Bithell says:

Movies don't build a city, they find one to shoot in. They buy props and costumes. They hire actors rather than making westworld style puppets.

The software economics of games continue to evolve.

Software Economics