Topic 4 Posts

Developer Experience

Dev Diaries: storytelling builds a core of community experts

Stellaris is a strategy game where players can build the stellar empire of their dreams. By navigating a series of interlocking economic, scientific and political systems, players create a unique storyline of exploration and contact with dozens of species.

On a spectrum of simplicity versus complexity, this is at the far opposite end from checkers. Still, once you learn the basics of managing your empire, Stellaris can be a blast.

The business model for Stellaris is echoed in many strategy titles. The 1.0 version of the game forms a foundation upon which years of new functionality and paid DLC can be designed and shipped. In the case of Stellaris, 20 expansions are available, ranging in price from $8 to $20, with the game itself retailing for $40. These expansions add everything from new species to entirely new storylines, political systems, and technologies. In Overlord, you can create new stellar megastructures and better specialize vassal states, while Synthetic Dawn introduces AI civilizations and hive minds.

This strategy makes the lifetime value of a committed Stellaris fan as high as $280 over the course of six years of releases, and there are further expansions on the way.

The approach of adding both new content and new game systems keeps things fresh, engaging both experienced players and newbies alike. It allows amortization of initial development expenses over a longer period, while maintaining the viability of the base game’s price.

Of particular note is that every major DLC release coincides with an update to the game that every customer gets even if they don’t pay for any expansions. The DLC model makes it economically viable to continue maintaining the intricate systems that drive the game, fixing bugs and eliminating tedium.

Stellaris is a better game today than it was six years ago.

How do I know all this? It’s easy.

Occasionally, I read the developer diaries.

Software storytelling

Software is itself a strategy game. We are constantly pivoting between the scope of our ambitions, the time cost of building systems, the complexity cost of systems already in motion, and the coordination and labor costs of the humans driving all of it. None of this is easy, and much of it is hidden well beneath the surface, out of view of most software consumers.

Indeed, it is a frequent gripe of game developers in particular that players rarely understand just how expensive it is to build a game to any high standard.

In the case of Stellaris, the business model requires at least a handful of engaged players to grasp these tradeoffs, and the game’s underlying systems, well enough to have a conversation about making changes and fixes.

Only by having informed dialogue with the community could Paradox Development Studio hope to learn what they need to make the game have lasting business value six years running. A game that no one wants to play isn't a viable commercial enterprise.

Their solution? Like many indie games, Stellaris publishes developer diaries. These represent an exhaustive body of regular dispatches from the code mines where the game is constantly reborn, revealing everything from the high level goals of a new release to the underlying minutiae of the development process. As of this week, Stellaris devs have written 279 dispatches, posted to their forum, where fans of the game can respond.

Dev diaries provide a tantalizing preview of upcoming adjustments to the game, which builds interest and even stimulates participation in betas and previews, when necessary. The diaries describe changes, fixes and replacements to game mechanics, show off new UI elements, and explain the rationale for changes and investments.

While only a small proportion of the game’s player base reads and engages with the diaries, the ones who do understand both the developers themselves, and their output, on a level that’s rarely seen in the software business.

This opens the possibility for communication and feedback with much deeper shared context between the most invested community members and the development team. As changes are in-flight, discussion in response to dev diaries allows the team to gauge sentiment and interest, while players can ask questions and learn more about goals and hiccups.

The result is a fruitful venue for dialogue and a community that can be as informed as it wants to be. This matters in a multiplayer strategy game. You need people eager and willing to participate, or there will be no one for new customers to play with.

Broader community lessons for all projects

“Community” is a frustrating, poorly understood concept in technology spaces. It’s not stickers or t-shirt guns. It’s not a thing you bolt onto a conference. It’s not a thing you can buy.

Community is the sum total of people who are invested in the success and fruitful application of a project, as well as their bonds with one another. Community emerges around a project when that project’s values and ambitions are shared by a larger group than just its developers. Community could be measured in the volume of people who would have a genuinely shitty afternoon if they learned your project was dead, as well as the resulting acts of commiseration between them.

In the 60’s, when it seemed Star Trek might die, letter writing campaigns to NBC bought the show extra life. After the show’s cancelation, the community of people served by Star Trek’s vision of the future lived on, organizing spontaneous conferences to discuss the show, and eventually, to meet its stars and creators.

Not everyone is making Star Trek or Stellaris. But if you want your project to punch above its weight, you need to build the ranks of people willing to work for its success.

Developer diaries are a powerful lever on this point. They create a regular cadence for project storytelling, they provide context around your decisions, they invite people to engage you with ideas and feedback—some of which will be grounded in the exact constraints your diaries have explained!

This creates a basis for relationships. Not just between you and the people who you hope will care about your project, but between those people as well. It’s an opportunity to create a lingua franca of the project, creating bonds between those who are similarly excited by its progress and intricacies.

Without concerted storytelling effort, the work of building software is invisible, even in the most open source of contexts. Your commits and files can only tell part of the story. Sometimes the most interesting code is the stuff you chose not to write. Developer diaries are an opportunity to reveal those decisions.

If you want a base of truly invested community members, literate in the larger philosophical and strategic underpinnings of your work, it’s worth exploring how a developer diary practice could serve your project.

I owe my career to Second Life's developer experience

I’ve told this story a million times:

I have the career I do because eighteen years ago, by accident, I learned to code in Second Life.

What began for me as a series of experiments with scripted 3D assets evolved into my first business and my first software products. I made enough money selling content in Second Life to pay my real life rent, for months. With this experience in hand, I was prepared for the iPhone’s App Store indie developer revolution, which rocketed me to a career in Silicon Valley startups.

There’s immense gratitude I feel for this experience. I’m a first-generation knowledge worker. The leverage of a technology career isn’t something I grew up anticipating. I didn’t even think writing code was for “someone like me.” What a joy, to surprise oneself this way.

I also feel a duty. The power of microprocessor automation and global computer networking is unprecedented in human history. You can reach audiences on a scale that was once simply impossible, and later merely the exclusive domain of a half dozen corporations. Now, through the internet, you can share ideas, build relationships, shape culture itself.

A single individual, wielding these tools, can have an accordingly unprecedented effect. Teams can go further still. I want others to have access to this, to find their own path to prosperity, to make their own mark on the future.

So I want to talk about the broad lessons of Second Life, as a developer experience. I want to talk about how it’s possible to create an environment that is so creatively fertile, someone could stumble backwards into learning code, changing their first life forever.

0. Storytelling

The journey always starts with a story.

Different tools have different stories for different audiences. In the case of Second Life, the story was larger than life. Build anything. Be anyone. Fly.

No, really, you could fly in Second Life. Why not?

While this story was dramatic and over-the-top, the product could back it up. When you arrived in Second Life, you really could build anything and be anyone.

Tools existed to compose primitive geometric shapes into larger orders of complexity, enabling everything from jewelry to robots to airplanes to skyscrapers. There were limits, but the expressiveness was deep.

You could also look like anyone you wanted. Every parameter of your avatar’s physical expression was editable. Advanced users could even upload custom UV mapped textures to apply as a custom skin.

The story promised a lot, and the platform delivered.

1. Frictionless sharing

When we create something we are proud of, we want to share it.

In the case of Second Life, everything you built was instantly visible, in realtime, to anyone nearby. You could attach creations to your avatar, parading them around everywhere you went in-world. With a click and a drag, any object could be transferred from your inventory into the shared environment around you.

For those who had access to Second Life’s land, sharing took on permanence. You could leave creations in place for others to discover and enjoy.

2. Easy experimentation, tight feedback loops

Any object could be scripted, using the C-like Linden Scripting Language (LSL). Select an object you owned and within a couple of clicks an editor would appear where you could begin writing code. Another click to check your script and then it would run immediately, affecting the object that contained the script.

The time to “hello, world!” was instantaneous.

As a consequence, the cycle between experimentation and result was tight. And again, it happened within a frictionless sharing context. You could quickly show off your scripted work to friends, or even get help from a more experienced coder. More on this in a moment.

Because of these attributes, I spent more time rewarded by experiments than I did setting them up. This built confidence and made it easy to develop a mental model of how the tools and language actually worked.

3. Abundant starter code

Glitch demonstrates the value of working implementations as a jumping-off point for both new and experienced developers. But more than a decade earlier, Second Life was bursting with working code you could drop into anything.

Want an elevator? There was a script for that you could modify and drop into your custom-designed elevator geometry. Between Linden Lab, Second Life’s developer, and a thriving community of tinkerers, scripts were everywhere, for every kind of purpose. Whether you wanted to build a car or learn more about the Second Life particle engine, it was easy in roaming around the environment itself to discover leads you could use to get moving.

4. Healthy, thriving community

In its heyday, Second Life was packed with the most generous, creative community. Animated by the principles of open source, “stores” popped up giving away free content newbies could use as a foundation for building their own experiences. This included everything from low-priced, pre-fab furniture to open source scripts.

Linden Lab did their part to foster this, and it was work. They enforced a terms of service, but also established and maintained community norms through their presence in-world. The investment yielded a community that was welcoming and multiplied the power of the platform. More and more people could be successful in whatever ways their imagination called them to be.

The resulting culture was transformational to me. People willingly spent their time teaching me everything from how to coax interesting shapes out of the building tools, to the vagaries of debugging a script. And once you were in, as a creator, with the crowd of creators? The heavens opened up. I was gifted the most interesting skins, offered pre-release products, even handed complex automatic update code from a more established creator. (Thanks, Francis.)

I’ve never known anything quite like it since.

5. Co-created, living documentation

The Linden Scripting Language wiki was my first piece of developer documentation. It was an exhaustive listing of the APIs that existed for interacting with Second Life as a platform, along with a primer on basic language features.

I got a complete crash course in programming—variables, logic, loops, types, functions, event handling, and more—thanks to the LSL wiki, which was a joint effort between Linden Lab itself and the community.

The wiki was packed with examples and notes. It was thorough and technical as it needed to be, while still being a friendly and accessible reference.

Being a successful developer is, more than anything else, learning how to learn. I couldn’t have asked for a better onramp than this living, hypermedia tome.

6. Scaffolding for success

Second Life’s ambition went further than all this.

Linden Lab wanted an economy to animate the incentives needed for all the content creation Second Life’s user-generated model demanded.

Anything you built, you could sell, paid in the platform’s virtual currency. It was this component that fueled me to go beyond tinkering to actually building full products, with marketing and advertising, documentation, even custom packaging.

Thanks to this economy, I was an engineering manager before I was a confident developer. At 20 years old, I was running my first software project, contracting with a friend I’d made who was good at scripting. Gathering requirements, checking on status, feedback, iteration, QA—I learned it all thanks to the promise of loot.

I built robot avatars people could wear, with little touches of personalization. The first one, largely cosmetic, netted me a few dollars. The second one, more elaborate, with goofy missiles you could take to Second Life’s various live-fire environments, did a little better.

By my third robot, I had enough contract code written that I could make sense of how the scripting language mapped to the various domains I needed to interact with. Everything from particles to user interaction handling to manipulating the physics engine—now I knew the foundations of how to do it all, and could expand and iterate even further.

Writing everything from the color customization scripts to the HUD UI, I was in the driver’s seat, and I could go as deep as I wanted. Months of late-night coding sessions, the joy of creation, the agony of bugs… the thrill of release.

The result made me thousands of dollars.

Through the internet.

What a revelation this was, discovering firsthand that you could make money through the internet. My working class roots had nothing even remotely analogous.

I still remember the night my third robot launched. The money kept pouring in. Every few minutes, another notification would slide down, another jingling coins sound effect. While it was great to clear a month of rent in a weekend, what was even more exciting was more than 18 months of passive income. The robot sold steadily, until everyone who wanted a science fiction robot appearance had found and paid for it and the cash petered out.

Forever after, I would see the world differently.

I want more tools and environments like this

I want a world where imagination, expression and technical implementation have the flimsy, porous boundaries that made Second Life so special.

I want more tools that are easy to dive into, easy make your own, and fast to share with the world. Environments that reward your investment by connecting your work to people who will enjoy it.

I want tools that bake in a sense of both community and camaraderie, lifting up newbs and accelerating them into a space of accomplishment.

I want tools that have serious power and impact, but still offer a friendly and accessible face, from the starter resources to the documentation.

Second Life was ambitious. It was a shared, persistent 3D environment that was completely dependent on user-generated content. Only through a potent developer experience could it find the success it needed. They had dire incentives to get this right.

But I think there’s a lot to learn there. As this technology cycle sputters to a close, a new one lurks around the next corner. I’ve always carried the hope that a new platform like Second Life could emerge.

Whether or not we find a worthy, broadly-adopted metaverse in our future, I think these lessons can help any developer tools project find some leverage for growth, positive impact, and creative power.

Meanwhile, I’ll always be grateful to the visionary team at Linden Lab. Their strange, powerful creation permanently altered the course of my life. When technology trends get me down, I can always look back and find inspiration in the place that got me started. Second Life, bandwidth and GPU-hungry, was far ahead of its time.

It was a singular achievement nonetheless.

Developer experience: the fine art of making tools and platforms suck less

Love it or not, developer experience is buzz that’s here to stay. As the next generation of technology firms is born, while the last generation struggles to stay relevant, one of the best ways to grasp and hold a growth trajectory is simple: become a technological dependency of other firms.

To do this you have to make the case for integration.

This is harder than it sounds. Many technological abilities have become commodified. Developer experience is a differentiation play.

A successful developer experience strategy emphasizes tactics like:

  • Storytelling: Clear, ongoing narrative about the benefits of using a given technology so developers can understand where, why and how to apply it
  • Education: Approachable material—including documentation and sample code—for developing a mental model of how a technology works and how it integrates into developers’ systems and workflows
  • Onboarding: Low-friction, low-cost, high-speed onramps to test-drive a technology, allowing developers to get a feel for its abilities
  • Ergonomics: Optimization of workflows, tooling, standard libraries and API design to limit complexity, protect against error and quickly address the most common use cases

All of these areas can contribute to success, but none of them will matter without a strong commitment to a simple cause: providing accomplishment.

Developer experience is stewardship and conservation of precious cognitive resources, thereby maximizing accomplishment

You get success by creating success for other people. To do this, you have to maximize the yield of accomplishment for time, energy and attention invested in your technology.

Shitty technology that frustrates the developer is always at risk. The moment an alternative comes along that better respects their time and, especially, their sense of motivation, the incumbent technology has only inertia and lock-in to save it.

Example: Rust

Rust is a specialized language. It emphasizes performance, correctness and safety, so it can have a bit of a learning curve as a consequence of serving those goals.

But getting started with Rust is easy. A thoughtful system of trams exists to get you quickly to the foothills of its learning curve. Consider its get started page:

  • Automatic OS detection, providing a one-line terminal command to run an installation script
  • Quick briefings on the basic components of the Rust ecosystem, with links to editor-specific plugins so expert practitioners can easily use their existing tools
  • Introductions to common tasks, like creating new projects and adding dependencies
  • Sample code for a basic Hello, World! written in Rust

By covering all the necessary introductory topics, this intro to Rust:

  • Protects time and attention
  • Relieves new users of research burdens
  • Introduces tools and workflows
  • Creates a rough mental model of how to interact with the tooling
  • Generates a sense of accomplishment

It only takes a few minutes. Most of this time is the install script. By the end of a not-long page, you’ve gone from not having Rust at all to running your first program written with it.

Optimize your conversion funnel

At the top of the funnel are people who have problems and need to solve them.

At the bottom are people who have built solutions that depend on your technology.

Conversion funnels take effort, care and curiosity to optimize. You need to find the cheapest obstacle in the funnel that’s preventing your conversions, smooth it out, and repeat the process iteratively until your technology is easy—maybe even fun—to integrate.

A successful developer experience strategy is powerful because it creates irrefutable evidence of your technology’s value, in the form of people whose lives, projects and businesses are better.

For services and platforms whose billings scale with customer accomplishment, the math is obvious. Invest in your funnel, just like any other e-commerce business.

Developer experience: the basics

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.

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.