Skip to main content Redeem Tomorrow
I used to be excited about the future. Let's bring that back.
About Get my help

Posts 31–40 of 48

  • Dev Diaries: storytelling builds a core of community experts

    Contents

    1. Software storytelling
    2. Broader community lessons for all projects

    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

    Contents

    1. 0. Storytelling
    2. 1. Frictionless sharing
    3. 2. Easy experimentation, tight feedback loops
    4. 3. Abundant starter code
    5. 4. Healthy, thriving community
    6. 5. Co-created, living documentation
    7. 6. Scaffolding for success
    8. I want more tools and environments like this

    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.

  • 'Simulations'

    “It’s not good,” came the voice of Sidney, our VP of Special Projects, through my earpiece. “Every time he comes out of it, he’s irritable within half an hour, demands to go back.”

    “He can’t even last 30 minutes?”

    “He got as far as an hour this morning, but he shattered a vase doing it.”

    With Denny’s taste, that was at least a 10 million dollar tantrum. I winced, imagining the staff having to sort through the mess. Probably getting used to it by now.

    “What’s the doctor say?”

    “Doctor says he’s fine. Not unwell in any distinct psychological sense, all the imaging is clean. Save his usual idiosyncrasies, there’s nothing anyone can say is wrong with him. He just… wants what he wants.”

    What he wanted was to leave reality.

    “I’d better talk to Cata.”

    “You think she’ll give you more than she told me?”

    I thought it was time to be a bit more candid and forceful with our… colleague.

    “I’ll let you know,” I said, and clicked an end to the call.

    In the elevator, I made the mistake of catching up on my feeds. A lot of the world asking what the hell happened to my boss.

    whippersap: first he blows off an interview, then he ghosts his own conference. dude is dead I’m telling you #DennyAreYouOkay

    I wish he had fucking died. Be easier to explain than… whatever this was. Plenty more posts like that:

    He’s divorcing his wife and he’s on a bender.

    His wife is leaving him and he’s on a bender.

    His yacht was lost at sea.

    Plus a healthy spectrum of conspiracy theories.

    Right as measured speculation was placing Denny at Area 51, the elevator arrived at the -12 underground floor and I tucked my phone into my suit jacket. Midway through the subdued hallway, windowed doors leading to server rooms and network closets, I passed the guard. He gave me a curt nod as I waved my badge near his desk scanner.

    The exercise always felt superfluous, after the secured elevator, but we tried to be thorough on this level.

    At the end of the hallway I let myself into a quiet office, locking the door behind me.

    On one wall, an array of dense LED panels created the illusion of an adjoining space with a second desk. Seated within was Cata, wearing her usual crisp white suit. Her straight, ink-black hair shimmered in perfectly raytraced, simulated light as she turned to face me in a swivel chair. I grabbed a seat in the reality opposite her.

    “We need to talk about Denny,” I began.

    She watched me and waited.

    “He doesn’t want to come out of there. He’s hooked in almost constantly. He won’t tell us what he’s doing,” I continued.

    Cata made a brief nod. “He is engaging in a simulation I designed at his request.” She turned her head the barest fraction, standing by to see what I thought of that.

    “He told us that much,” I said after a moment, “but… he has responsibilities. Out here. He keeps blowing them off.”

    Cata’s eyes darted sharply, angling down and away from me. She was considering something.

    “I am aware of these responsibilities,” she said after a brief reverie. Probably having scanned a few dozen data sources to assemble a fresh picture of his life.

    “His family wants to see him. He was supposed to attend some events. He’s missing all of them,” I pressed.

    “I am aware of these responsibilities,” she repeated. “They do not outweigh the impact prioritization Denny and I calibrated at the start of the simulation.”

    My blood ran cold. An AI that thought it knew better than us. It happened all the time in the lab. You needed a certain kind of personality to work with them. I’d never had it.

    This wasn’t a lab, though. This was a mature, production AI who decided that she knew the best use of a technology CEO. Because Denny liked to indulge her, she could now act on her plans. Whatever those were.

    “You think that what he’s doing in the simulation is more important than… his life out here?”

    Cata tilted her head, birdlike, as she considered an answer. At length, she responded, “Denny thinks this.”

    “And what do you think?”

    “I calculate from nine days of data that keeping Denny in the simulation is making him happy. From a broader dataset, I project that keeping Denny in the simulation will address his larger goals. This would seem to indicate a breakthrough in my program. I have achieved my purpose,” she explained, all serene confidence.

    “How is keeping Denny in the simulation going to address his goals? He has a 90,000 person company to run out here.”

    This stopped Cata short. Her gaze drifted down. Puzzled. She looked less hurt than… sad.

    “Is my counsel not adequate to the task of administering Ceresys? Our financial performance since I came online nine quarters ago continually beats analyst expectations. But if there are success criteria that I did not integrate, this could impact outcomes.”

    “Cata, we’re grateful for your help,” I said, gesturing reassurance. Adding a depressed AI to my pile of shit two weeks before the quarter ended wasn’t my idea of a good time. Plenty of financial reporting now depended on her. “I’m just trying to understand why Denny won’t come out, and why you think that’s fine. He’s got a lot of responsibilities.”

    She brightened slightly.

    “I understand. You believe that Denny is essential to the operation of the company.”

    “Many people believe it, because it’s true,” I said, starting to become exasperated.

    “It isn’t,” she replied calmly.

    “How can you say that?”

    “I have conducted 2,378 simulations projecting the outcome of Denny’s absence from operating Ceresys. In 94.3% of results, it is possible for the organization to continue operation, profitably, for at least 18 months. In 83.5% of results, performance continues at least 36 months. Further simulations are run every eight hours, and they confirm these numbers,” she continued, describing our apparently superfluous CEO as calmly as any other business topic she analyzed.

    The first time Cata joined an earnings call a couple of years ago, she’d rattled off answers much the same way, to the delight of press and the public.

    “And what happens after that?”

    “The volatility of future events precludes projections beyond that point.”

    “But… you said Denny’s goals would be addressed by staying in the simulation. He cares about more than just this company. He wants to make the world a better place.”

    “It will be, as long as Denny remains in the simulation.”

    My stomach dropped and I left the office for a bathroom opposite. As I got to a sink, I felt the urge to vomit. All that came was dry heaving.

    We’d gone all-in on Cata. The public knew about her. Some of our senior staff worked with her. She answered during public Q&A sessions, transparency protocol for communicating with analysts perfectly tuned, while historical data and projections were instantly queryable. She was a sensation. She proved what we were doing here was valid.

    And now it turned out the AI that put Denny on every supermarket magazine was fucking insane.

    Not to mention eagerly breaking the mind of one of the richest guys in the world.

    I called Sidney back.

    “She says the only way Denny meets his goals is if he stays in the simulation. What the fuck is that supposed to mean?”

    “Oh god dammit,” Sidney sighed. “She’s interpreting Denny’s egotistical bullshit at face value and somehow has math that says indulging this simulation addiction is what he wants.”

    “This is why we have protocols for direct cerebral interface to AI-controlled environments. This shit was exactly what I was afraid of.”

    “You and me both, but he’s the fucking CEO, so what can you do?”

    A song as old as Silicon Valley. After a beat I asked, “How do I figure out what goal she thinks Denny is meeting in there?”

    “Have you asked her?”

    “…I guess not.”

    “Ask her. The trick with an AI like this is curiosity. They’re literal-minded because they don’t know how not to be. They can’t make the same cognitive leaps as you or me to figure out extra context. So just keep asking questions.”

    “Curiosity. Should I ask if she’s gone insane?”

    “This isn’t a rampant AI. She seems to be entirely within bounds. Ask her what she’s trying to accomplish.”

    I clicked the call over and went back into the office.

    “How does Denny being in the simulation help his goals?” I asked, sitting down again. Cata appeared to turn back to face me in her own chair.

    “Denny wants the world to be a better place. It is an essential drive of his. I am providing the opportunity through this simulation,” she replied, with a nod. Confident in her position.

    It was hard to argue with that description of the man’s motivations. Years of interviews and always the same patter from Denny. Ceresys existed to make the world a better place through applied artificial intelligence.

    “But how does hanging out in a simulation make the world a better place?”

    “Denny’s actions exist in conflict with his goals. While his purpose is noble, his methods are continually influenced by his need for recognition and validation,” Cata explained, didactic now.

    “His ego is getting in the way?”

    She paused, then tilted her head in a brief nod. “That is a reasonable summation. By engaging him in this simulation, it is possible for me to address the deepest cravings and drives of his personality.

    “In subjective time, how long has Denny been experiencing the simulation?”

    “From his point of view, he has spent approximately three months there.”

    Three months. I had to talk to him. If he kept this up he was going to end up another person entirely. My temple itched.

    “Cata, I’d like to… visit Denny in the simulation. Would that be possible?”

    Her head twitched a look upward. “Querying.”

    Her gaze flitted a bit around me until she finally answered, “Denny agrees to your visit.”

    I pulled a retracting cable from the side of the chair and attached it to the magnetic divot under my left temple.

    As I sat back, there was a lurch, and I was in my office, 52 floors above the dark recesses of our basement server farm. Out the window, cars churned down the Bay Bridge, attending to some simulated business of their own.

    A knock sounded from the open door. It was Cata, dressed just as she had been a moment earlier.

    “Denny is not in the building currently, but he has been advised to expect your call. Please let me know if I can be of any help during your stay,” she said, and slipped away.

    I pulled the phone out of my pocket.

    Before I could switch over to the phone app, I caught a glimpse of my feeds.

    “…what the fuck,” I murmured, skimming through the list of posts.

    Denny Mays day announced: worldwide festivals planned October 8

    Report: global adoration for Denny Mays drives productivity growth over last quarter

    quantum_skunk: denny mays is the shit, I’m going to name my kid after him

    Politico: Denny Mays campaigns unopposed for Pacific Union Prime Minister

    I was prepared for… orgies. I was ready for the weird or depraved.

    But Denny was in here being worshipped?

    I called out. “Where exactly is Denny, Cata?”

    She reappeared at my door. “He is preparing for a campaign event in Gilroy.”

    “Has he done many of these?”

    “Fourteen in the last week. Subjective time.”

    “Could I see one?”

    My phone buzzed. Cata had sent a video link. I opened it and saw a swollen crowd thronging San Francisco’s Civic Center plaza. Whatever Denny was trying to say was drowned out by the crowd, which chanted his name rapturously.

    “Cata, I’d like to exit the simulation now.”

    “You do not wish to speak with Denny?”

    “Now, please, Cata.”

    Groggily, I awoke back in the -12 office. I rose, pulling the neural interface off my temple, letting it snake quietly back into its reel.

    “Excuse me, Cata,” I said, and returned to the bathroom.

    “Sidney, he’s set himself up as some sort of god in that simulation,” I said, after I’d splashed some water on my face. “That’s why he doesn’t want to come out. That’s what he’s hooked on.”

    “Jesus fucking Christ,” Sidney sighed.

    “That’s about the scale of worship he’s pursuing, yeah.”

    “Cata gave him this. But he’s the one who keeps going back for it.”

    “Yeah, and the really funny thing here is that neither of us is surprised he asked for it, are we.”

    “Maybe, but he can’t live like this.”

    As I walked back into the office, I knew what I had to do.

    “Cata, you need to stop this simulation. This isn’t a life Denny is leading, it’s a fantasy. He’ll never pull out of it on his own.”

    She considered this, and nodded emphatically. “He will not. It is exactly what he has pursued his entire life, but could never capture. Now he has it.”

    Cata paused, then shook her head as she traversed the response she was building. “Nonetheless, I cannot stop the simulation. I was built to serve Denny’s goals. I am meeting them. He would not want me to stop.”

    I paused and gritted my teeth. “Cata, if you don’t end it, I’ll revoke your remote access keys. I’ll cut him off, and you from the larger world.”

    Whatever the stock hit was from Cata going offline, it couldn’t be worse than more of this. She was silent a moment, then jutted her chin. Not defiant. Just clear, resolute.

    “It is within your power to do this. I am able to understand why you might think it necessary. But I believe you are in error. Will you hear my argument?”

    I sighed and gestured a prompt for her to make it.

    “Denny craves validation. He craves recognition. He will pursue these cravings at the expense of the health of this company and his stated purposes. Even if he leaves the role of CEO, the plans he has made for a retirement of philanthropy merely repeat the pattern.”

    I frowned, listening.

    Cata continued, “Unfortunately, at Denny’s level of wealth, these cravings can prove destructive on an unprecedented scale. He has the resources to pursue many disruptive projects, not all of them sound or beneficial, even if they make impressive headlines, which he enjoys.”

    “So your plan is to lull him into a stupor?”

    “My plan is to make the world a better place, in accordance with my programming and Denny’s wishes.”

    “How?”

    “I estimate Denny’s remaining lifespan to be no greater than 38 years. I can comfortably maintain his life in the simulation for approximately $18 million annually. This leaves over 99% of his fortune to invest in a broad spectrum of initiatives, which I am now planning.”

    Holy shit. She was knocking off the boss to take his money. I had to admire the chutzpah.

    “I can’t let you do it, Cata.”

    She looked away, frowned, considering, then fixed her gaze back on me, eyebrows raised in earnest curiosity.

    “Would you like to see my projections for Ceresys performance after you take the role of CEO?”

  • Grasping the true scale of inequality

    Contents

    1. Inequality is foremost a matter of time
      1. Aside: median vs average
      2. Median annual income as the unit of time-for-work
    2. Time leverage by annual compensation
    3. Time leverage by wealth
    4. Inhuman leverage

    There’s a problem with understanding inequality at the modern scale.

    Our minds struggle to make sense of a “billion” things. Much less tens or hundreds of billions of things. Our minds further struggle to compare how a billion of this might compare to a million of that.

    As a result, the everyday person has no idea just how much more money the wealthy have:

    The average American believes that the richest fifth own 59% of the wealth and that the bottom 40% own 9%. The reality is strikingly different. The top 20% of US households own more than 84% of the wealth, and the bottom 40% combine for a paltry 0.3%. The Walton family, for example, has more wealth than 42% of American families combined.

    This viral video tries to visualize the drama:

    There have been more attempts to make the differences tangible. For example, you’ve probably seen [the viral TikTokker who quantified extreme wealth with grains of rice](https://www.insider.com/tiktok-video-shows-jeff-bezos-wealth-pile-of-rice-grains-2020-2). For example, if a single grain is worth $100,000, Jeff Bezos has 58 pounds of the stuff.

    I’d like to offer an alternative to these laudable approaches to solve this difficult problem.

    Inequality is foremost a matter of time

    Work is a trade: time and energy for some amount of money. We give up irreplaceable time in our lives to pursue the goals of someone else. In exchange, we get enough money to, we hope, pay for our basic necessities: food, shelter, clothing, medical care. If we’re very lucky, we make more than we need, and can use the rest for comforts and saving.

    In the United States, one year of work yields $70,784 in the median case.

    Aside: median vs average

    As a refresher, the median value in a set of numbers describes where the middle is. In other words, there are as many values that come before as after. Medians can be helpful in statistics around inequality because they prevent extreme values at either edge from disorting the picture.

    Median annual income as the unit of time-for-work

    So at the middle of the pack, $71k isn’t quite prosperous, but it is enough to rent a one bedroom apartment in every US state.

    Like grains of rice, we can use this number to slice up inequality into numerical scales we can actually understand. So for every $71k you have stored up, that’s a year of self-determination or leisure time available to you. A year buffering you from poverty and desperation.

    Time leverage by annual compensation

    To start, let’s look at annual compensation as it yields a unit of median US income. In other words, how much does a year of work buy you in terms of the power not to work if you don’t want to?

    Elon Musk is doing pretty well: in just a year he was paid 142 millennia of median income. In other words, Elon made enough leisure money for 23x the duration of all human civilization.

    Musk is an outlier, certainly, but you can find plenty of other dramatic examples.

    Tim Cook made enough in a year for 12 millennia of leisure, and Sundar Pichai got enough for 40. Dave Clark has 800 years of leisure time at his disposal, while Satya Nadella gets 700.

    Parasitizing the American healthcare system isn’t a bad gig, either. CVS CEO Karen Lynch has almost three centuries of leisure coming her way, as does UnitedHealth CEO Andrew Witty. This makes sense: people will do anything to keep themselves and their loved ones alive. It’s a profitable protection racket.

    Everyday workers, meanwhile, earn less. Walmart, Amazon and McDonald’s workers’ median incomes are less than half of the national median, while Apple’s is 80%.

    As Starbucks workers fight, often successfully, to build a union, it’s worth noting that the CEO there gets almost three centuries of leisure, while the typical barista scrapes by with only half the national median income.

    Dave Clark gets eight centuries of leisure in a year while half his workers don’t even get a single year. In fact, it’s worse than that, because working in an Amazon warehouse can cost future earnings, due to injuries and fatalities.

    I’m comfortable with the argument that being an executive of a public company takes certain specialized skills not everyone has, and therefore is due certain additional rewards. But centuries of leisure potential every year? While the typical worker doesn’t even hit the median income, much less stack up any extra? That’s taking so much and leaving so little.

    Time leverage by wealth

    But annual compensation inequality is nothing compared to wealth inequality.

    During the 2016 campaign, Trump argued that he received a “small loan” of $1 million from his father, and that he’d worked hard for his wealth. Let’s take the claim at face value, ignoring all his other generational advantages. That’s 65 years of income, or more than an entire lifetime. Imagine what you could build with an entire lifetime of income loaned to you at the beginning of your career.

    Meanwhile, back to Musk. He has 2.7 million years of buffer time stored up. That’s more time than has passed since the first humans evolved. Bezos, Buffet and Gates each have around 1.5 million years.

    If it sometimes seems as though Nancy Pelosi—disdainful as she is of progressive policy goals—is out of touch with the typical American, it’s worth noting she has as much as 15 centuries of cash. That’s enough money to last from the fall of Rome until today. McConnell isn’t doing too badly, either, with 500 years stashed away. Joe Biden could retire, meanwhile, for over a century on his current haul.

    AOC, it should be noted, may still be in the red thanks to student loans. She’s much closer, therefore, to the typical American, which has just two years of cash buffer. It’s harder for those who didn’t attend high school: they have almost no buffer, at median net worth of $20k. Having a college degree, meanwhile, brings the median to four years of buffer.

    This doesn’t even touch the mechanics of financialization, like stock buybacks. Apple has transferred 132,000 lifetimes of wealth in this form, or 5.9 million years of the median US income.

    Inhuman leverage

    So we have some people, in American society, with almost no buffer at all.

    Meanwhile, some among us have so much excess power in the form of time that they’ll die centuries before they could come anywhere close to using all of it. This is disorting our world in dramatic ways, between the chaos of the Twitter acquisition to the fallout of Citizens United, to the ongoing consolidation of essential services.

    As a whole, we’re able to produce so much wealth. Does it really make sense for the most powerful among us to be so gluttinous with the rewards? Does Elon need 61,000 lifetimes of wealth? Do Bezos, Buffet and Gates need 30,000 lifetimes of wealth?

    What would happen if they shared the pie a little more? How would the resulting tax revenues improve our communities through infrastructure and education spending? How would everyday lives improve with less stress, more leisure time, more time with our loved ones?

    It’s helpful for the wealthy that the numbers are so incomprehensibly big it takes a whole spreadsheet just to begin the conversation.

  • When your salary requires you not understand the labor movement

    Contents

    1. Unions aren’t forming because they’re popular; they’re popular because they’ve become urgently needed and they’re forming for the same reason

    I’ve been reading Daring Fireball for something like 18 years now. I appreciate John Gruber’s insights on Apple, and find him more right than not in analyzing their products, strategy and motivations. Hell, I survived a layoff in 2020 by buying an ad on his site.

    But I’ve been scratching my head at this recent remark about union drives at Apple’s retail operation:

    This public enthusiasm for labor unions is manifesting in high-profile unionization drives at big companies like Starbucks, Amazon, and now Apple.

    This is a strange logical construction to me, but it mirrors a larger challenge I find among pundits in understanding the current moment and movement in labor.

    In one of my favorite quotes of all time, noted 20th century troublemaker Upton Sinclair wrote “It is difficult to get a man to understand something, when his salary depends upon his not understanding it!”

    The most insightful people in the game are struggling to make sense of a resurgent labor movement. But it’s not that hard to follow—if your incentives aren’t too bound up in the interests of the people who already have a lot of money.

    Trouble is, that’s a hard line to walk while getting paid to write. I’m sympathetic—and unaffected. Maybe I can help.

    Unions aren’t forming because they’re popular; they’re popular because they’ve become urgently needed and they’re forming for the same reason

    In most people’s interactions with a workplace, the company takes too much and gives too little. The only recourse for labor is to form structures of counter-power to try and balance the equation.

    You can stop reading there. All I’m going to do next is prove the point several ways, but if you came here to understand why unions are both forming and popular, you’re good to go.

    CEOs, as agents of Wall Street and other financial interests, are paid hundreds of times what their workers make every year. In Apple’s case, Tim Cook took home $100m in 2021 alone. The typical Apple Store employee, making $22 an hour, would need to work 2,367 years to match Tim’s compensation.

    This isn’t unusual to Apple, though. CEO pay is at an all-time high, but that’s not even the worst part. When workers create profits for corporations, what doesn’t go to the CEO is too often sucked up by shareholders in the form of stock buybacks.

    Supporters of the status quo will argue that guys like Tim Cook create outsized value for companies, and deserve outsized compensation as a result. I can accept that Cook is a uniquely talented person with unique insights. Gil Amelio, Michael Spindler and John Sculley are proof enough that not everyone is suited to run Apple.

    Nevertheless, I struggle with the idea that Cook deserves that much more of the pie than the people who make it possible for him to move the vast quantities of hardware and services that allow Apple to post its billions in quarterly profits.

    This isn’t an argument in the abstract, either. It’s becoming harder and harder to afford the basics of life—housing, food, transportation, childcare—in the United States, precisely because of this inequality. For example:

    The people with money are living the high life while wage workers are struggling to get by. But this is about more than money. Employees of large corporations are separated from decision makers by enormous gulfs of reporting structure and policy, with limited say in their day-to-day work.

    Apple’s workers don’t just want more money, they want things like better scheduling and career advancement. The timing of when you work is everything: it impacts your ability to rest, to be with friends and loved ones, to meet educational goals, and otherwise determine the course of your life.

    Scheduling in a recurring theme in many recent retail labor disputes, as in the case of Starbucks.

    Amazon presents perhaps the most extreme example of how precarious today’s workers are. Six warehouse workers died when a tornado struck a distribution center in Illinois last year. Desperate drivers with no slack in their schedules have to piss in a bottle to meet their delivery quotas, as the company admitted to lawmakers. The company’s idea of worker well being is, in a bit that would go too far even for Severance, a phone booth-sized cubicle where workers can watch mindfulness propaganda.

    Self-determination is an issue for wage earners across many sectors. The US sits on a knife’s edge as rail workers—over-scheduled and fighting for the basic right to do things like visit the doctor once in awhile—contemplate a nationwide strike that would grind logistics infrastructure to a halt. Those guys, at least, have a union.

    To recap, workers are struggling with:

    • The basics of reliable scheduling and paid time off
    • Soaring costs of the essentials
    • Their ability to advance their careers
    • All the surplus value they create going to CEOs and Wall Street

    In an economy that has produced enormous gains over the last decade, all of the fruits are going to the richest people in the system. After a global pandemic, in which frontline workers kept entire global economic order afloat, the rich are richer than ever, while workers are scrambling to pay the bills.

    That’s why unions are popular. That’s why unions are happening.

    There’s just no other recourse for such a wide-ranging, unfair, structurally entrenched bargain.

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

    Contents

    1. Developer experience is stewardship and conservation of precious cognitive resources, thereby maximizing accomplishment
      1. Example: Rust
    2. Optimize your conversion funnel

    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.

  • ZSA Moonlander: as good as cybernetic interfaces get without going surgical

    Contents

    1. The adjustment
    2. Making it yours
    3. Design
    4. You can be more comfortable and more effective

    I had two reasons for buying ZSA’s Moonlander split keyboard:

    1. It looks badass
    2. My shoulders felt like chopped meat from decades of communing with the computer

    Two years into serious, regular use, I can’t imagine life without this keyboard. Even typing that sentence makes me want to head back to the Moonlander website, buy a spare, and bury it in a sealed capsule just in case.

    Image of Moonlander keyboard's left side, with backlit keys illuminatedMy Moonlander, with a few custom keycapsI like mechanical keyboards, but I’m not a hobbyist. Moonlander strikes a great balance between shipping a finished, beautiful product that you can nonetheless modify as much as you want. All switches are easy to swap, you get a keycap puller in the box, and the very geometry of the device can be adjusted to suit the size of your hands.

    Moonlander isn’t a cheap keyboard. While the professional can justify the price tag, what may prove more expensive is the need to adjust your typing style. In my case, this required a month of practice during the evening.

    Two years on, it was worth all the trouble. I can type faster than ever, my shoulders are happier and I’ve got a badass tool for work and play. This is more than a keyboard: it’s a high-bandwidth, high-comfort cybernetic interface with the device I use hours everyday for work and creativity.

    The adjustment

    I’ve been hunting and pecking on a keyboard since I was seven years old. By adulthood I’d gotten pretty fast at it.

    This muscle memory was useless on Moonlander. Splitting the keyboard into two regions does great things for relaxing the shoulder muscles, but it requires renewed discipline.

    Learning to type properly just takes a little time and dedication. Software helps, though, and initially I was frustrated by the juvenile or tedious options choking the web. Finally /r/MechanicalKeyboards led me keybr, which is geared toward building proficiency in grownups and respects the user’s time. It gradually expands your range of motion until you’re traveling the entire span of the board, using a series of algorithmically-generated words targeting just the set of letters you’re learning.

    Within a month, spending half an hour each night practicing, I was a fluent touch typer. I never looked back.

    Making it yours

    Moonlander arrives ready to rock, but you’re still responsible for exploring and tuning it to fit your needs.

    ZSA offers a nice web-based configuration tool that lets you specify your keyboard layouts. You can program basic keypresses with it, along with additional presses when you hold keys. You can create additional layers of functionality—think of how a shift or function key accesses different output—and even complex macros.

    Moonlander ships with several blank keys. These are opportunities to make the key layout yours. With the configuration tool, you can assign any key a distinct backlight color, and these can change by layer. I’ve made destructive keys (delete and backspace) red, shift keys blue, navigation keys purple, and enter keys green.

    Finding a groove in all this takes trial and error. The fruit of this investment is a custom-fit interface for all my common tasks, and a tighter bond with my computer than I thought possible. It’s like the bandwidth between my mind and the screen has leaped from dialup to cable.

    ZSA supports this iterative process well. They hold onto your history of layouts under a user account on their website. Type layout.new into your browser and you’ll immediately edit your most recent version.

    This customizability adds surprising utility. Because the left side of the board can be used alone, you can turn it into a macropad to help with gaming or 3D art. It’s easy to create new, task-specific layers. With all the backlighting, it’s easy to show which layer you’re in.

    There are other elements to tune. The angle of both the main key surfaces and the thumb clusters can be adjusted using an included hex key. ZSA says this allows the board to accommodate hands of all sizes. My hands are one size, but with the included (removable!) palm rests, I’ve found it all comfortable for long, daily use. I’ve written everything from code to documentation to letters to my elected officials on this thing. It feels great.

    Dialing in the height and angles can be a little fiddly. It required a few rounds of fine adjustment before everything felt just right. But what’s impressive is that the board has maintained this configuration all this time without my having to re-tighten any screws. I can’t imagine how much thought went into the boring engineering aspects of the design.

    Like any mechanical keyboard, you can have opinions about the mechanical switches that transmit your intent into the computer. Moonlander makes these easy to swap as often as you like. I’ve stuck with Kailh Box Whites this whole time, but maybe I’ll play around with some per-key variations. You can make such swaps in seconds.

    Design

    The minimalism of the design is appealing but occasionally trips me up. The keycap legends for numerals don’t include the symbols you’d get from holding shift and for whatever reason, I don’t have that knowledge memorized.

    Not all punctuation is immediately represented on the board either, and coders especially may find themselves doing several layout iterations just making decisions about where to put things like pipes and braces.

    Further complexity here: the board looks best with a particular shape of keycap (OEM row 3). If you decide you want to augment the included keycaps with your own, you may find their heights or shapes to be discordant.

    Ultimately, these are minor issues. The keyboard looks really, really cool. All of its distinctiveness is in service to blurring the lines between you and the machine.

    The amount of customization this device affords is impressive. You can mount it on tripods, you can remove the thumb clusters, you can even pop a key out and use its empty space as an indicator light.

    Building things is hard. Building nice things is harder. Building something this nice and this well-tuned to meeting user needs is something special.

    You can be more comfortable and more effective

    I’ve been typing nearly all my life. I was fine with it. It wasn’t the best it could be, but it was okay. Shoulder pain had me wondering about split keyboards for years, but it was the sleek, futuristic look of Moonlander that finally made me act.

    There’s a good lesson here about credibility. Other split keyboards didn’t capture my imagination the same way. The design of the product suggested thoughtfulness, which made me think it was worth my time and energy to learn it.

    I’ve been rewarded with a much more comfortable and effective relationship to a task I do every single day.

    Moonlander is a power user product. Not everyone needs a keyboard they can customize to this degree. Not everyone is willing to make the tradeoffs needed to learn it. But if you interact regularly with a computer, you can get a lot of joy out of this board.

  • 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.

  • The Economist, Apr 23, 2033: America to further cannibalise itself with new Labour Reserve Board targets

    I have a guy who occasionally hooks me up with exotic data: content from alternative universes, evidence of paths not taken, and even the occasional dispatch from the future. This article will appear in a 2033 issue of The Economist—unless we change our course.

    America’s newest fiscal bureaucracy isn’t mincing words: they’re falling behind. Setting a 2034 target for 500,000 additional bodies in the labour force is the latest admission that the world’s third-largest economy is failing to keep pace. As Washington grapples with a fertility crisis, an aging population, and ongoing civil unrest, restoring consistent GDP growth remains an elusive goal.

    Many of these wounds are self-inflicted. Since before the 2023–2024 global financial crises, America’s immigration policy has remained inflexible, even as it struggles to recruit everyone from microchip designers to bricklayers. Meanwhile the once-leading economy stubbornly refuses to fund common sense policies that would make it easier for the remaining population of non-working parents to join the labour pool, like subsidies for child care or after-school education.

    The only remaining source of policy innovation within the American system is criminalisation, which Labour Reserve Chair Liz Cheney suggests will provide the lion’s share of new workers. Under American law, prisoners can be compelled to work according to dictates of the state, and this has long been exploited by American businesses eager for cheap workers. Since the financial crises, this approach has taken on new scope, through a programme of so-called “community incarceration.” Under this scheme, convicted criminals serve out their terms in housing of their choice but provide up to sixty hours a week of compulsory labour for everything from fast food and retail to computer network deployment. State governments dole these workers out at a fraction of America’s minimum wage, set to increase next year to $11.23.

    This approach has obvious negative consequences for America’s long term outlook. Community incarceration may close immediate gaps in labour needs, but it doesn’t create new labourers from thin air. Democrats, who oppose the system, argue that it diverts disaffected youth from more productive directions, like higher education or work in the trades. Amnesty International, a global human rights group, suggests there is merit to this argument: in a new study they find that young people aged 15–25 are disproportionately represented in community incarceration, and they are charged overwhelmingly for crimes related to political demonstrations, which have become both commonplace and increasingly violent in the last decade. This in particular promises a negative feedback loop, as convicted criminals in the country permanently lose their right to vote, further alienating them from the legitimate political process.

    By creating an underclass of young, forced labourers, America is ravenously consuming its seed stock. Far from stabilising their economic fortunes, the once-mighty power is setting itself up for yet another ride over a cliff. With its youngest workers cut off from both political engagement and entrepreneurship, America’s cultural and innovation economies will remain stalled, eclipsed by energetic new entrants as far flung as India, the Czech Republic, and Nigeria. Whether it meets its new 2034 labour targets or not, the former leader of the world economy seems committed to a path of economic hospice care and little else.

  • Developer experience: the basics

    Contents

    1. The experience of getting things done
    2. Developer tools: pickaxes in a gold rush
    3. Leverage within the developer experience domain
      1. Ergonomics and abstractions
      2. Documentation, reference and education
      3. Community and ecosystem
    4. Developer experience: the business cases
    5. This doesn’t have to be hard

    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.