blarg?

May 5, 2020

The Shape Of The Machine

Filed under: digital,documentation,doom,interfaces,vendetta — mhoye @ 11:18 am

P4030207

The AMP people are rebranding their “AMP Stories” as “web stories“, raising that bland flag to the strained smiles of their publisher client-states, so it’s about time for me to click “post” on this. I was ranting about AMP a few weeks ago, partly because it’s a minor fraud being carried out at the expense of open standards and the common good, but mostly because of what an incredible social engineering exercise it’s been inside the big G.

The most remarkable thing about this machine – specifically, this corner of the massive Google monitor-and-monetize engine – how well they’ve broken up every part of the process internally at Google. The team working on AMP is making web pages lighter-weight and faster to load, and that sure seems like a net good in the world. Elsewhere, the search team has built out a preference for surfacing faster-loading and lighter-weight web pages to mobile users, which I’m sure was a decision with some sort of empirical basis and on its face seems like a good idea too. That a site would show up better in search results because it’s snappier or more responsive seems reasonable. And finally Google sells ads and shares ad revenue and that keeps a lot of sites alive these days, and I guess that’s good as well.

But when you put all the parts of that machine together under one P&L-statement roof suddenly you’re looking at a thinly veiled extortion scheme; as a publisher you either use AMP or your ad revenue goes away. Google could have approached the “be better on mobile” problem, search optimization and revenue sharing any number of ways, obviously, but the one they’ve chosen and built out is the one that guarantees that either you let them middleman all of your traffic or they cut off your oxygen.

That’s a real nice revenue stream you’ve got there; it’d be a shame if anything happened to it.

It’s got a certain sinister elegance to it, that mercenary Vintage Microsoft flavor, but Vintage Microsoft never pretended they were anything other than mercenary and this is all about the pretending. It’s not on the same level as Facebook, obviously, where they’ve managed to compartment their org structure so carefully that complicity in war crimes and other atrocities leaves facebookers feeling like they’re the ones being portrayed unfairly, but it’s still an accomplishment. That’s the most fascinating part of this exercise, to my mind: that Google has managed to structure this surveillance-and-value-extraction machine entirely out of people who are convinced that they, personally, are doing good for the world. The stuff they’re working on isn’t that bad – we’ve got such beautiful intentions! – and it’s interesting work and the perks here are really good… You can kind of watch their eyes de-focus for a second when you bring it up; it takes them a minute to remember who pays for their laundry and snacks.

April 27, 2020

Side Scroller

Filed under: arcade,documentation,interfaces,linux,toys — mhoye @ 8:35 am

I’ve never met Ian Albert, but years ago he painstakingly scraped and pasted together a set of maps and backgrounds from a various oldschool games, an effort that’s helped me in a bunch of odd little ways over the years and for which I’m grateful. Of particular interest today are the original Super Mario Brothers maps; for the sake of this exercise, let’s start with world 1, level 1.

ImageMagick and FFMpeg are a pair of “classically-Linux” command-line tools, in terms of how insanely complex and opaque they appear until you’ve worked with them for a bit and can sort of see the logic of their approaches. Even then the documentation takes some getting used to – the man page should just say “don’t bother, go to the website” – and even then you’ve gotta kind of fumble your way towards competence if you want to use them day to day.

Well, maybe you don’t, but I sure do. In any case once you know they exist you muddle your way to doing a lot with them. In particular, “convert” from the ImageMagick tool suite lets you upscale some of those Mario-level gifs to PNGs, like so:

$> convert mario-1-1.gif -scale 300% mario-1-1.png

We’re doing this conversion because FFMpeg (apparently?) doesn’t like to pan over gifs as an input stream but is happy to do that with PNGs, and scaling it up gets you an image size better suited for modern screens. We’re admittedly scaling up and then compressing something that eventually gets upscaled again, which looks like it should bea waste of effort. I’ve tested it, though, and on this machine at least it looks like movie upscaling comes out a lot mushier than static image upscaling and this approach is quite a bit crisper.

In any case, then you run “file” on that resulting image to see how big it is:

$> file ./mario-1-1.png
./mario-1-1.png: PNG image data, 10152 x 672, 4-bit colormap, non-interlaced

Do a bit of loose math to figure out your frame width and subtract 16/9 * 672 – that is, the aspect ration of your monitor times the height of the image – from the length – to get the number you need to work with next – in my case rounding to 1200, it’s 8952.

That’s the number of frames you’re going to tell FFMpeg to pan across, like so:

$> ffmpeg -loop 1 -framerate 5 -i mario-1-1.png -vf crop=1200:672:n:0 -frames:v 8952 -pix_fmt yuv420p mario-1-1.mp4

Now, order of operations and operation context both matters in FFMpeg usage, which adds a degree of complexity to figuring out wtf you’re doing with it, but walking through that command:

the “-loop” option is specific to the image processing part of ffpmeg, and in turn specific to some image-processing formats, so “loop 1” might or might not error out saying “unrecognized option”, depending on where you put it in the command line and which image types you’re choosing to process, which is not super helpful. In this case, it works for .png input files, and it means “go through this set of input images once”. We’ll get back to “-framerate” in a moment.

“-i” is input the png of the mario level we made earlier. The rest of this command is where the proverbial action is.

“-vf” means “create a filtergraph”, which is FFMpeg-ese for “transform the set of input images you’ve decoded in the following way”. “The following” can get pretty crazy, as you might imagine, but fortunately for us this will be reasonably simple in intent, despite the somewhat daunting syntax.

In this case, it means “crop out a sub-image from the given input image, of with 1200 and height 672, starting at horizontal offset “n” and vertical offset 0. “n” in this case is implicitly provided by the “frames” part, as we iterate over the frames from zero to the value of “-frames:v”

The “-pix_fmt yuv420p” part – “pixel format”, is what that means – I don’t really understand, beyond the fact that FFMpeg can encode videos in way more formats than browsers can easily decode, and its’ default idea of “best” doesn’t work everywhere. This incantation seems to fix that, which isn’t particularly satisfying but is definitely part of the whole fumbling-towards-competence part I mentioned.

In any case, the “-framerate 5” part is the interesting bit. That’s there because about nine thousand frames – 8952 specifically – divided by the number of seconds in a 30 minute meeting is very close to five. Five frames per second is really slow, so the resulting output video is, as predicted by our basic arithmetic, a lazy 29 minutes and 50 seconds long:

… and that’s the story of how you make a videoconference background that scrolls slowly through a Mario level over the course of half an hour.

A few notes:

  • If you leave out the framerate option and just want to see it scroll by at a default 25 frames per second, the movie is five minutes and change, which is amusingly a few seconds longer than the best speedruns of the entire game.
  • That crop=1200:672:n:0 option elides a lot of possible complexity; there’s an entire mathematical-expression interpreter under the hood of of crop and all the other FFMPeg filters, so if you want a 1080p movie panning diagonally across some of the many classic and modern works of art that are available now from any number of places, you can roll your own with relative ease.
  • The temptation to edit these to say something like “Thank you, Mario! But Peach went to another meeting.” is strong; if I get around to that, the fonts are here or maybe here.
  • I really need to get out of the house more. I guess we all do?

Update: A friend points me at FFMprovisr:

“FFmpeg is a powerful tool for manipulating audiovisual files. Unfortunately, it also has a steep learning curve, especially for users unfamiliar with a command line interface. This app helps users through the command generation process so that more people can reap the benefits of FFmpeg.”

Thank you, Sumana!

March 18, 2020

Notice

Filed under: analog,documentation,interfaces,life,mozilla,work — mhoye @ 9:56 pm

Untitled

As far as I can tell, 100% of the google results for “burnout” or “recognizing burnout” boil down to victim-blaming; they’re all about you, and your symptoms, and how to recognize when you’re burning out. Are you frustrated, overwhelmed, irritable, tired? Don’t ask for help, here’s how to self-diagnose! And then presumably do something.

What follows is always the most uselessly vague advice, like “listen to yourself” or “build resiliency” or whatever, which all sounds great and reinforces that the burden of recovery is entirely on the person burning out. And if you ask about the empirical evidence supporting it, this advice is mostly on par with leaving your healing crystals in the sun, getting your chakras greased or having your horoscope fixed by changing your birthday.

Resiliency and self-awareness definitely sound nice enough, and if your crystals are getting enough sun good for them, but just about all of this avoiding-burnout advice amounts to lighting scented candles downwind of a tire fire. If this was advice about a broken leg or anaphylaxis we’d see it for the trash it is, but because it’s about mental health somehow we don’t call it out. Is that a shattered femur? Start by believing in yourself, and believing that change is possible. Bee stings are just part of life; maybe you should take the time to rethink your breathing strategy. This might be a sign that breathing just isn’t right for you.

Even setting that aside: if we could all reliably self-assess and act on the objective facts we discerned thereby, burnout (and any number of other personal miseries) wouldn’t exist. But somehow here we are in not-that-world-at all. And as far as I can tell approximately none percent of these articles are ever about, say, “how to foster an company culture that doesn’t burn people out”, or “managing people so they don’t burn out”, or “recognizing impending burnout in others, so you can intervene.”

I’ll leave why that might be as an exercise for the reader.

Fortunately, as in so many cases like this, evidence comes to the rescue; you just need to find it. And the best of the few evidence-based burnout-prevention guidelines I can find come from the field of medicine where there’s a very straight, very measurable line between physician burnout and patient care outcomes. Nothing there will surprise you, I suspect; “EHR stress” (Electronic Health Records) has a parallel in our lives with tooling support, and the rest of it – sane scheduling, wellness surveys, agency over meaningful work-life balance and so on – seems universal. And it’s very clear from the research that recognizing the problem in yourself and in your colleagues is only one, late step. Getting support to make changes to the culture and systems in which you find yourself embedded is, for the individual, the next part of the process.

The American Medical Association has a “Five steps to creating a wellness culture” document, likewise rooted in gathered evidence, and it’s worth noting that the key takeaways are that burnout is a structural problem and mitigating it requires structural solutions. “Assess and intervene” is the last part of the process, not the first. “Self-assess and then do whatever” is not on the list at all, because that advice is terrible and the default setting of people burning out is self-isolation and never, ever asking people for the help they need.

We get a lot of things right where I work, and we’re better at taking care of people now than just about any other org I’ve ever heard of, but we still need to foster an “if you see something, say something” approach to each others’ well being. I bet wherever you are, you do too. Particularly now that the whole world has hard-cutover to remote-only and we’re only seeing each other through screens.

Yesterday, I told some colleagues that “if you think somebody we work with is obviously failing at self-care, talk to them”, and I should have been a lot more specific. This isn’t a perfect list by any means, but if you ask someone how they’re doing and they can’t so much as look you in the eye when they answer, see that. If you’re talking about work and they start thumbing their palms or rubbing their wrists or some other reflexive self-soothing twitch, notice. If you ask them about what they’re working on and they take a long breath and longer choosing their words, pay attention. If somebody who isn’t normally irritable or prone to cynical or sardonic humor starts trending that way, if they’re hunched over in meetings looking bedraggled when they normally take care of posture and basic grooming, notice that and say so.

If “mental health” is just “health” – and I guarantee it is – then burnout is an avoidable workplace injury, and I don’t believe in unavoidable mental-health injuries any more than I believe in unavoidable forklift accidents. Keep an eye out for your colleagues. If you think somebody you work with is failing at self-care, talk to them. Maybe talk to a friend, maybe talk to their manager or yours.

But say something. Don’t let it slide.

March 6, 2020

Brace For Impact

I don’t spend a lot of time in here patting myself on the back, but today you can indulge me.

In the last few weeks it was a ghost town, and that felt like a victory. From a few days after we’d switched it on to Monday, I could count the number of human users on any of our major channels on one hand. By the end, apart from one last hurrah the hour before shutdown, there was nobody there but bots talking to other bots. Everyone – the company, the community, everyone – had already voted with their feet.

About three weeks ago, after spending most of a month shaking out some bugs and getting comfortable in our new space we turned on federation, connecting Mozilla to the rest of the Matrix ecosystem. Last Monday we decommissioned IRC.Mozilla.org for good, closing the book on a 22-year-long chapter of Mozilla’s history as we started a new one in our new home on Matrix.

I was given this job early last year but the post that earned it, I’m guessing, was from late 2018:

I’ve mentioned before that I think it’s a mistake to think of federation as a feature of distributed systems, rather than as consequence of computational scarcity. But more importantly, I believe that federated infrastructure – that is, a focus on distributed and resilient services – is a poor substitute for an accountable infrastructure that prioritizes a distributed and healthy community. […] That’s the other part of federated systems we don’t talk about much – how much the burden of safety shifts to the individual.

Some inside baseball here, but if you’re wondering: that’s why I pushed back on the idea of federation from the beginning, for all invective that earned me. That’s why I refused to include it as a requirement and held the line on that for the entire process. The fact that on classically-federated systems distributed access and non-accountable administration means that the burden of personal safety falls entirely on the individual. That’s not a unique artifact of federated systems, of course – Slack doesn’t think you should be permitted to protect yourself either, and they’re happy to wave vaguely in the direction of some hypothetical HR department and pretend that keeps their hands clean, as just one example of many – but it’s structurally true of old-school federated systems of all stripes. And bluntly, I refuse to let us end up in a place where asking somebody to participate in the Mozilla project is no different from asking them to walk home at night alone.

And yet here we are, opting into the Fediverse. It’s not because I’ve changed my mind.

One of the strongest selling points of Matrix is the combination of powerful moderation and safety tooling that hosting organizations can operate with robust tools for personal self-defense available in parallel. Critically, these aren’t half-assed tools that have been grafted on as an afterthought; they’re first-class features, robust enough that we can not only deploy them with confidence, but can reasonably be held accountable by our colleagues and community for their use. In short, we can now have safe, accountable infrastructure that complements, rather than comes at the cost, of individual user agency.

That’s not the best thing, though, and I’m here to tell you about my favorite Matrix feature that nobody knows about: Federated auto-updating blocklist sharing.

If you decide you trust somebody else’s decisions, at some other organization – their judgment calls about who is and is not welcome there – those decisions can be immediately and automatically reflected in your own. When a site you trust drops the hammer on some bad actor that ban can be adopted almost immediately by your site and your community as well. You don’t have to have ever seen that person or have whatever got them banned hit you in the eyes. You don’t even need to know they exist. All you need to do is decide you trust that other site judgment and magically someone persona non grata on their site is precisely that grata on yours.

Another way to say that is: among people or communities who trust each other in these decisions, an act of self-defense becomes, seamlessly and invisibly, an act of collective defense. No more everyone needing to fight their own fights alone forever, no more getting isolated and picked off one at a time, weakest first; shields-up means shields-up for everyone. Effective, practical defensive solidarity; it’s the most important new idea I’ve seen in social software in years. Every federated system out should build out their own version, and it’s very clear to me, at least, that is going to be the table stakes of a federated future very soon.

So I feel pretty good about where we’ve ended up, and where we’re going.

In the long term, I see that as the future of Mozilla’s responsibility to the Web; not here merely to protect the Web, not merely to defend your freedom to participate in the Web, but to mount a positive defense of people’s opportunities to participate. And on the other side of that coin, to build accountable tools, systems and communities that promise not only freedom from arbitrary harassment, but even freedom from the possibility of that harassment.

I’ve got a graph here that’s pointing up and to the right, and it’s got nothing to do with scraping fractions of pennies out of rageclicks and misery; just people making a choice to go somewhere better, safer and happier. Maybe, just maybe, we can salvage this whole internet thing. Maybe all is not yet lost, and the future is not yet written.

February 18, 2020

Dexterity In Depth

Filed under: a/b,academic,documentation,interfaces,mozilla,science,vendetta,work — mhoye @ 10:50 am

Untitled

I’m exactly one microphone and one ridiculous haircut away from turning into Management Shingy when I get rolling on stuff like this, because it’s just so clear to me how much this stuff matters and how little sense I might be making at the same time. Is your issue tracker automatically flagging your structural blind spots? Do your QA and UX team run your next reorg? Why not?

This all started life as a rant on Mastodon, so bear with me here. There are two empirically-established facts that organizations making software need to internalize.

The first is that by wide margin the most significant predictive indicator that there will be a future bug in a piece of software is the relative orgchart distance of the people working on it. People who are working on a shared codebase in the same room but report to different VPs are wildly more likely to introduce errors into a codebase than two people who are on opposite sides of the planet and speak different first languages but report to the same manager.

The second is that the number one predictor that a bug will be resolved is if it is triaged correctly – filed in the right issue tracker, against the right component, assigned to the right people – on the first try.

It’s fascinating that neither of the strongest predictive indicators of the most important parts of a bug’s lifecycle – birth and death – actually take place on the developers’ desk, but it’s true. In terms of predictive power, nothing else in the software lifecycle comes close.

Taken together, these facts give you a tools to roughly predict the effectiveness of collaborating teams, and by analyzing trends among bugs that are frequently re-assigned or re-triaged, can give you a lot of foresight into how, where and why a company need to retrain or reorganize those teams. You might have read Agile As Trauma recently, in which Dorian Taylor describes agile development as an allergic reaction to previously bad management:

The Agile Manifesto is an immune response on the part of programmers to bad management. The document is an expression of trauma, and its intellectual descendants continue to carry this baggage. While the Agile era has brought about remarkable advancements in project management techniques and development tools, it remains a tactical, technical, and ultimately reactionary movement.

This description is strikingly similar to – and in obvious tension with – Clay Shirky’s description of bureaucracy as the extractive mechanism of complexity and an allergic reaction to previous institutional screwups.

Bureaucracies temporarily suspend the Second Law of Thermodynamics. In a bureaucracy, it’s easier to make a process more complex than to make it simpler, and easier to create a new burden than kill an old one.

… which sounds an awful lot like the orgchart version of “It’s harder to read code than to write it”, doesn’t it?

I believe both positions are correct. But that tension scribes the way forward, I think, for an institutional philosophy that is responsive, flexible and empirically grounded, in which being deliberate about the scale, time, and importance of different feedback cycles gives an organization the freedom to treat scaling like a tool, that the signals of different contexts can inform change as a continuum between the macro and micro levels of organizational structure and practice. Wow, that’s a lot of words in a strange order, but hear me out.

It’s not about agile, or even agility. Agility is just the innermost loops, the smallest manifestation of a wide possible set of tightly-coupled feedback mechanisms. And outside the agile team, adjacent to the team, those feedback loops may or may not exist however much they need to, up and down the orgchart (though there’s not often much “down” left in the orgchart, I’ve noticed, where most agile teams live…) but more importantly with the adjacent and complementary functions that agile teams rely on.

It is self-evident that how teams are managed profoundly affects how they deliver software. But agile development (and every other modern developer-cult I’m aware of) doesn’t close that loop, and in failing to do so agile teams are reduced to justifying their continued existence through work output rather than informing positive institutional change. And I don’t use “cult” lightly, there; the current state of empirical evaluation of agile as a practice amounts to “We agiled and it felt good and seemed to work!” And feeling good and kinda working is not nothing! But it’s a long way from being anything more than that.

If organizations make software, then starting from a holistic view of what “development” and “agility” means and could be, looking carefully at where feedback loops in an organization exist, where they don’t and what information they circulate, all that suggests that there are reliable set of empirical, analytic tools for looking at not just developer practice, but the organizational processes around them. And assessing, in some measurable, empirical way, the real and sustainable value of different software development schools and methodologies.

But honestly, if your UX and QA teams aren’t informing your next reorg, why not?

February 5, 2020

Misdirection

Filed under: arcade,documentation,interfaces,life,microfiction,toys,weird — mhoye @ 11:17 am

Karl Germain once said that “Magic is the only honest profession. A magician promises to deceive you and he does.”

This is sort of a review of a game, I guess. It’s called Superliminal.

“Every magic trick consists of three parts, or acts. The first part is called the pledge. The magician shows you something ordinary: a deck of cards, a bird, or a man. He shows you this object, and pledges to you its utter normality. Perhaps he asks you to inspect it to see that it is indeed real, unaltered, normal. But, of course, it probably isn’t. The second act is called the turn. The magician takes the ordinary something and makes it do something extraordinary. Now you’re looking for the secret. But you won’t find it, because of course you’re not really looking. You don’t really want to know. You want to be fooled. But you wouldn’t clap yet. Because making something disappear isn’t enough. You have to bring it back. That’s why every magic trick has a third act. The hardest part. The part we call the Prestige.”

— Cutter (Michael Caine), “The Prestige

You’ve probably heard David Foster Wallace’s speech to the graduates of Kenyon College in 2005, the “This Is Water” speech.

It is about the real value of a real education, which has almost nothing to do with knowledge, and everything to do with simple awareness; awareness of what is so real and essential, so hidden in plain sight all around us, all the time, that we have to keep reminding ourselves over and over: “This is water, this is water.”

It’s possibly the greatest College Graduation Speech of all time, both in its mastery of the form and the surgical precision of its own self-serving subversion of that same form. “This is a standard requirement of US commencement speeches, the deployment of didactic little parable-ish stories”, right after the parable-ish story. “I am not the wise old fish”, followed by an explanation of the whole point of the fish story. Over and over again, throughout, we’re shown the same sleight of hand:.

Tell your audiences that they’re too smart to want a certain thing and give it to them anyway. Remind everyone that they’re too hip for corny dad sermonizing and then double down on the corny dad sermonizing. This is a great way to write a commencement speech—not by avoiding platitudes, but by drawing an enchanted circle around yourself where the things we thought were platitudes can be revealed as dazzling truths. Where all of us can be consoled, if only for an instant, by the notion that the insight we lack has been here all along! Just hiding inside of our clichés.

I don’t think Harnette’s cynicism in that LitHub article, pointed at the pernicious consequences of Wallace’s “cult of sincerity” is the whole story. She’s not wrong, but there’s more: if you’ve got the right eyes to see it the outline of the Prestige is there, the empty space where the third act didn’t happen. The part where this long, drawn out paean, begging for sincerity and authenticity and “simple awareness” reveals itself for what it is, a cry for help from somebody whose inner monologue does not shut up or take its foot off the gas so much as a millimeter for anyone or any reason ever. A plea for a simplicity from somebody whose mind simply won’t, that nobody saw.

Because of course you’re not really looking. You don’t really want to know; you want to be fooled. I know that this stuff probably doesn’t sound fun and breezy or grandly inspirational the way a video game review is supposed to sound. But it’s just about capital-T Time to stop using this gag.


[ https://www.youtube.com/embed/30iHXafyXlw – Superliminal teaser trailer ]

I’ve played through Superliminal twice now, and I spent a lot of that time thinking about Wallace’s call for simple awareness as the game hammers on its tagline that perception is reality. I’ve got mixed feelings about it.

Superliminal opens in an obvious homage to both Portal and The Stanley Parable, guns on the mantle that never go off; in some ways it feels like the first Assassin’s Creed, an excellent tech demo that paved the way for the great AC2. It’s brilliant and frustrating, playing with the nature of constructed realities in ways that are sometimes trite, sometimes – the knife, the parking lot – unsettling and sometimes genuinely distressing. Like Portal it’s only a few hours long but they aren’t wasted hours, novel conceits and engaging mechanics flourishing through the iteration and conceptual degradation of the dreamscapes you traverse.

But I can’t shake the feeling like some part of the game is missing, that there’s a third act we haven’t been allowed to see.

As with Wallace’s Kenyon speech it’s the final conceit – in Superliminal, the psychologists’ summary – that ties the game together in a way that feels thematically complete, grandly inspirational and woefully unearned; where all of us can be empowered, if only for an instant, by the notion that the insight we lack has been here all along, if – perception being reality – we could only see it. And just like the Kenyon graduation speech, I can’t shake the sense that the same sleight-of-hand has happened: that what we’re not seeing, what we’re choosing not to see, is that this sincere inspirational anecdote isn’t really something meant to inspire us but something the author desperately wishes they could believe themselves, a rousing sermon from a preacher desperate to escape their own apostasy.

And how hard could that be, really? All you’ve got to do, after all, is wake up.

It’s a pretty good game. You should play it. I hope whoever made it gets the help they need.

December 26, 2019

Intrasective Subversions

I often wonder where we’d be if Google had spent their don’t-be-evil honeymoon actually interviewing people for some sort moral or ethical framework instead of teaching a generation of new hires that the important questions are all about how many piano tuners play ping pong on the moon.

You might have seen the NYTimes article on hypertargeted product placement, one of those new magical ideas that look totally reasonable in an industry where CPU cycles are cheap and principles are expensive.

I just wanted to make sure we all understood that one extremely intentional byproduct of that will breathe new life into the old documnent-canary trick of tailoring sensitive text with unique punctuation or phrasing in particularly quotable passages to identify leakers, and has been purpose-built as a way to precision-target torrent seeders or anyone else who shares media. “We only showed this combination of in-product signal to this specific person, therefore they’re the guilty party” is where this is going, and that’s not an accident.

The remedy, of course, is going to be cooperation. Robust visual diffs, scene hashes and smart muting (be sure to refer to They Live for placeholder inspiration) will be more than enough to fuzz out discoverability for even a moderately-sized community. As it frequently is, the secret ingredient is smart people working together.

In any case, I’m sure that all right thinking people can agree that ads are the right place to put graffiti. So I’m looking forward to all the shows that are turned into hijacked art-project torrents the moment they’re released, and seeing

THEY LIVE
THEY LAUGH
THEY LOVE

in the background of the pirated romcoms of 2021.

December 19, 2019

Over The Line

IMG_1500044662340

[ This first appeared over on the Mozilla community discourse forums. ]

You can scroll down to the punchline if you like, but I want to start by thanking the Mozilla community, contributors, industry partners and colleagues alike, for the work everyone has put into this. Hundreds of invested people have weighed in on our hard requirements, nice-to-haves and long term goals, and tested our candidates with an eye not just to our immediate technical and community needs but to Mozilla’s mission, our tools as an expression of our values and a vision of a better future. Having so many people show up and give a damn has a rewarding, inspiring experience, and I’m grateful for the trust and patience everyone involved has shown us in helping us get this over the line.

We knew from the beginning that this was going to be a hard process; that it had to be not just transparent but open, not just legitimate but seen to be legitimate, that we had to meet our hard operational requirements while staying true to our values in the process. Today, after almost a year of research, consulting, gathering requirements, testing candidate stacks and distilling everything we’ve learned in the process down to the essentials, I think we’ve accomplished that.

I am delighted and honored to say that we have one candidate that unambiguously meets our institutional and operational needs: we have decided to replace IRC with Riot/Matrix, hosted by Modular.IM.

While all of the candidates proved to be excellent team collaboration and communication tools, Riot/Matrix has distinguished itself as an excellent open community collaboration tool, with robust support for accessibility and community safety that offers more agency and autonomy to the participants, teams and communities that make up Mozilla.

That Matrix gives individual community members effective tools for both reporting violations of Mozilla’s Community Participation Guidelines (“CPG”) and securing their own safety weighed heavily in our decision-making. While all of the candidates offered robust, mature APIs that would meet the needs of our developer, infrastructure and developer productivity teams, Riot/Matrix was the only candidate that included CPG reporting and enforcement tooling as a standard part of their offering, offering individual users the opportunity to raise their own shields on their own terms as well as supporting the general health and safety of the community.

Riot/Matrix was also the preferred choice of our accessibility team. Mozilla is committed to building a company, a community and a web without second class citizens, and from the beginning the accessibility team’s endorsement was a hard requirement for this process.

Speaking personally, it is an enormous relief that we weren’t forced to make “pick-two” sort of choice between community safety, developer support and accessibility, and it is a testament to the hard work the Matrix team has done that we can have all three.

Now that we’ve made our decision and formalized our relationship with the Modular.IM team, we’ll be standing up the new service in January. Soon after that we’ll start migrating tooling and forums over to the new system, and as previously mentioned no later than March of next year, we’ll shut down IRC.mozilla.org.

Thank you all for your help getting us here; I’m looking forward to seeing you on the new system.

– mhoye

December 17, 2019

Poor Craft

Filed under: future,interfaces,linux,microfiction,toys,want,weird,work — mhoye @ 1:53 pm

Ghosting

“It’s a poor craftsman that blames his tools” is an old line, and it took me a long time to understand it.

[ https://www.youtube.com/embed/ShEez0JkOF ]

A friend of mine sent me this talk. And while I want to like it a lot, it reminded me uncomfortably of Dabblers and Blowhards, the canon rebuttal to “Hackers And Painters”, an early entry in Paul Graham’s long-running oeuvre elaborating how special and magical it is to be just like Paul Graham.

It’s surprisingly hard to pin Paul Graham down on the nature of the special bond he thinks hobbyist programmers and painters share. In his essays he tends to flit from metaphor to metaphor like a butterfly, never pausing long enough to for a suspicious reader to catch up with his chloroform jar. […] You can safely replace “painters” in this response with “poets”, “composers”, “pastry chefs” or “auto mechanics” with no loss of meaning or insight. There’s nothing whatsoever distinctive about the analogy to painters, except that Paul Graham likes to paint, and would like to feel that his programming allows him a similar level of self-expression.

There’s an old story about Soundcloud (possibly Spotify? DDG tends to the literal these days and Google is just all chaff) that’s possibly apocryphal but too good not to turn into a metaphor, about how for a long time their offices were pindrop-quiet. About how during that rapid-growth phase they hired people in part for their love of and passion for music, and how that looked absolutely reasonable until they realized their people didn’t love music: they loved their music. Your music, obviously, sucks. So everyone there wears fantastic headphones, nobody actually talks to each other, and all you can hear is in their office is keyboard noise and the HVAC.

I frequently wonder if the people who love Lisp or Smalltalk fall into that same broad category: that they don’t “love Lisp” so much as they love their Lisp, the Howl’s Moving Memory Palaces they’ve built for themselves, tailored to the precise cut of their own idiosyncracies. That if you really dig in and ask them you’ll find that other people’s Lisp, obviously, sucks.

It seems like an easy trap to fall in to, but I suspect it means we collectively spend a lot of time genuflecting this magical yesteryear and its imagined perfect crystal tools when the fact of it is that we spend almost all of our time in other people’s code, not our own.

I feel similarly about Joel Spolsky’s notion of “leaky abstractions”; maybe those abstractions aren’t “leaking” or “failing”. Instead it’s that you’ve found the point where your goals, priorities or assumptions have diverged from those of the abstraction’s author, and that’s ultimately not a problem with the abstraction.

The more time I spend in front of a keyboard, the more I think my core skills here aren’t any more complicated than humility, empathy and patience; that if you understand its authors the code will reveal itself. I’ve mentioned before that programming is, a lot more than most people realize, inherently political. You’re making decisions about how to allocate scarce resources in ways that affect other people; there’s no other word for it. So when you’re building on other people’s code, you’re inevitably building on their assumptions and values as well, and if that’s true – that you spend most of your time as a programmer trying to work with other people’s values and decisions – then it’s guaranteed that it’s a lot more important to think about how to best spend that time, or optimize those tools and interactions, rather than championing tools that amount to applied reminiscence, a nostalgia with a grammar. In any other context we’d have a term for that, we’d recognize it for what it is, and it’s unflattering.

What does a programming language optimized for ease-of-collaboration or even ease-of-empathy look like, I wonder? What does that development environment do, and how many of our assumptions about best collaborative practices are just accidental emergent properties of the shortcomings of our tools? Maybe compiler pragmas up front as expressions of preferred optimizations, and therefore priorities? Culture-of-origin tags, demarking the shared assumptions of developers? “Reds and yellows are celebratory colors here, recompile with western sensibilities to swap your alert and default palettes with muted blues/greens.” Read, Eval, Print looping feels for all its usefulness like a huge missed opportunity, an evolutionary dead end that was just the best model we could come up with forty years ago, and maybe we’ve accidentally spent a lot of time looking backwards without realizing it.

Long Term Support

Filed under: a/b,digital,future,interfaces,linux,toys,want,work — mhoye @ 11:34 am

I bought a cordless drill from DeWalt a few years before they standardized on their current 20 volt form factor. Today the drill part of the drill is still in good shape, but its batteries won’t hold a charge – don’t store your batteries in the shed over the winter, folks, that’s rookie mistake – and I can’t replace them; they just don’t make them anymore. Nobody does.

I was thoroughly prepared to be annoyed about this, but it turns out DeWalt makes an adapter that slots right into my old drill and lets me use their new standard batteries. I’ll likely get another decade out of it as a result, and if the drill gives up the ghost in the meantime I’ll be able to use those batteries in its replacement.

Does any computer manufacturer out there anywhere care about longevity like that, today? The Cadillac answer to that used to be “Thinkpad”, but those days are long gone and as far as I can tell there’s nothing else in this space. I don’t care about thin or light at all. I’m happy to carry a few extra pounds; these are my tools, and if that’s the price of durable, maintainable and resilient tools means a bit of extra weight in the bag I’ll pay it and smile. I just want to be able to fix it; I want something I can strip all the way down to standard parts with a standard screwdriver and replace piecemeal when it needs piecemeal replacing. Does anyone make anything like this anymore, a tradesman’s machine? The MNTRE people are giving it a shot. Is anyone else, anywhere?

Older Posts »

Powered by WordPress