Topic 6 Posts

Software Economics

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.

The invisible skill at the heart of every technologist

There’s a skill that’s core to success at all levels of software development, but it hides like dark matter: inferred, rather than observed, lurking beyond description and discussion. On a gut level, we know it’s necessary to the work, but we don’t often know how to teach it. You’ve either got it or you don’t in the perception of the average workplace.

Let’s call this skill investigative reasoning. Or, more simply: “working the problem,” as Apollo legend Gene Kranz might frame it.

(Let me know if MIT press has a $70 textbook explaining this, situating it in computing or engineering, and giving it a name.)

This pile of skills manifests as a reflex to make sense of an issue or failure, locate its causes, and design a fix. Without these abilities, you’ll be helpless in the stew of complex abstractions that define modern computing.

Consider a common software development workflow:

  • You write some code
  • It’s compiled, bundled, or otherwise transformed
  • The transformed code is transferred to a host device
  • The host runs the code

Failures can emerge at or after any of these steps. The code may have errors which prevent compilation. The code may have errors despite compiling fine, and they manifest only at runtime, during certain circumstances. There may be a failure in the systems that package and transfer the code, preventing it from running.

The experienced practitioner understands their job is to analyze the problem, develop a hypothesis for its source within the many layers of technology they’re using, and validate the hypothesis by checking logs, adding print statements, starting an interactive debugging session, or using other means of peering inside of the machine. Working the problem may require research: finding online discussions of similar issues, or consulting documentation.

But core to this activity for both the novice and the expert is a simple conviction: problems can be understood and investigation can yield solutions.

At any level, hobbyist to advanced professional, confidence in this premise is the indispensable requirement. Without the confidence to work a problem, it’s unlikely anyone can make progress in building and integrating technical systems.

Domain experience helps to work a problem. Every class of system, from microcontrollers to native applications to web apps, has its own set of quirks, its own unique abstractions and design decisions where trouble may sneak in. But working the problem is a skill that transcends domains. Fixing a broken software development toolchain can prepare you for troubleshooting the boiler in your basement.

The paranoia in hiring for software roles, I’m certain, is rooted in the fear that the organization will hire someone who is unable to work a problem, outsourcing their investigative reasoning tasks to others, depleting productivity per unit of headcount budget.

Working the problem is also a feature of seniority. Translating business requirements into software development tasks is an expression of this skill, as is understanding how technical tradeoffs (debt) in existing systems will impact the needs of new features. The more senior a practitioner is, the more likely they are to feel a sense of confidence working a problem no matter how many layers stack up—even when those layers are “non-technical,” derived from business or customer needs.

We laugh at the fixation on languages or frameworks in job postings, but even the most thoughtful organizations struggle to identify this set of activities as a job requirement, much less map their outcomes within the team’s problem space.

Not every person is the ideal practitioner to work a given problem. The startup costs in research, learning new tools, or picking up domain-specific expertise, may outstrip any return on investment. Still, I have to think that applying a more conscious growth mindset around this would give our industry better results in recruiting, professional development and retention than we have today.

How can we elevate our understanding of these skills? How can we instill the confidence needed to work a given problem? How can we better train people to be able investigators?

I think there’s a lot of missed opportunity here.

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.

Wordle: A factional skirmish for the soul of technology

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.

Wordle score panel: 207 5/6

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

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.