A few minutes ago, I announced to the ISO C++ committee that all our meetings originally planned for 2020 have been postponed. We had already postponed the Varna meeting originally planned for June 1-6, and earlier today INCITS (the U.S. national body) announced that it was banning all face-to-face standards meetings for the rest of the year, so we are also postponing the New York meeting previously planned for November 9-14. We deeply appreciate all the work the Varna and New York hosts have put into planning to have us in town, and we still look forward to meeting there as soon as it is safe to do so.

The meeting after that is currently still planned in Kona for February 22-27, but that too is now under review as we monitor developments including any possible further ISO or INCITS meeting ban extensions. We will not meet unless we are permitted to do so and can be confident we can meet safely.

It still feels surreal that in just one week from now we would all have been traveling to Bulgaria for the first meeting of C++23. But that was in a different world, and reality and facts matter. In the meantime, the ISO C++ committee and the C++ community have been moving online, with more ISO subgroup meetings already working on C++23 features and more C++ community events taking place in wonderful locations called “Zoom” and “YouTube Live,” instead of in Varna and New York, at least for now. Thank you again to everyone who is organizing those meetings and events for us, including the recent Pure Virtual C++ online event and the upcoming C++ Europe and C++ Russia and C++ on Sea online conferences, and still more to come!

Stay safe, everyone. We hope that you and your loved ones are holding up well and that we’ll be able to see each other again soon.

I try hard to always ask for feedback on drafts of my talks and articles, and I always learn important things from the responses, including especially things I omitted but should include so as to pre-answer audience questions. Just like the best support call is the one the customer doesn’t have to make because they didn’t have a problem, the best post-talk question is the one the audience doesn’t have to ask because the answer was clear in the talk.

Here’s a very small example from the talk I gave last week… just a “little thing,” but like many little things one that could derail people’s minds and be a distraction from the talk’s intended message.

When we did the tech check a few days before the talk, I displayed my opening slide, which was…

When it came up on the stream, I heard the techs say “great, we can see it fine, Bridge to Newt… Hinge… Ya…” and they stumbled over the last word. Only then did I realize that the cute name I was using that was so clear to me (and kind of central to the talk’s message) was not clear at all — in fact, instead of setting the stage for the message, it created a “what does that mean?” question that distracted from the message.

(Aside: I think it’s pretty funny that the bug appeared to be a version of the “max munch” rule, but with the English language — it seems that their eyes scanned the word and found that the first four letters matched an English word, “newt,” and then they took that and scanned onward for the next part but their mental tokenizer was already derailed.)

So I updated the slide to try to preempt the problem, by capitalizing one letter to provide a visual cue about the intended word end (and doing some minor visual rebalancing so it fit):

I also tried variations like “NewThing-ia” but the extra punctuation seemed unnecessary and felt a bit stilted. It felt like just capitalizing the T was enough… and as far as I know this eliminated the problem, though admittedly I didn’t re-test the update on a new person before the talk. :)

It was just a little thing, but it’s an example of how little things can be important. I suppose it’s also an example of “naming is hard” and of “names matter.”

I appreciated the techs’ implicit feedback that helped me debug my title and pre-eliminate a “what does this mean” question.

Next week, I’m honored to be part of DevAroundTheSun, a live 24-hour global event for COVID-19 relief that starts on May 12 at 12:00 UTC. It’s like LiveAid or Lady Gaga’s recent One World: #TogetherAtHome, but for developers. You can watch on Twitch and YouTube, and all the talks are relatively short at 25 minutes… think TED talk style and length, and hopefully similar quality in content even though the production is a little different since we have to present our talks from home. Some of the speakers may be familiar to you, such as Bjarne Stroustrup giving an updated version of his actual TED talk, and Kevlin Henney who is always entertaining and enlightening. Other speakers may be new to you and me, but are all excellent presenters with interesting topics.

The event starts at 12:00 UTC May 12, and I’m scheduled to be on in the second hour (13:20 UTC), which will be right around dawn for me here in Seattle. I’ll be giving a new talk with all-new material about how to get from OldThing to your shiny NewThing… and in this case “all-new material” means I have to finish writing it this weekend. Here’s the title slide and abstract:

Great new ideas are common, and their developers and users want them to succeed. So why do the large majority fail to ever achieve wide adoption? For example, thousands of genuinely interesting programming languages have been invented, but few ever achieved widespread or long-lasting use. This talk considers examples, and identifies some basic (but frequently-violated and hard-to-make-retroactive) strategic success predictors, that you can use to evaluate someone else’s new idea and to “design for success” in your own new project or language.

I hope you enjoy all parts of the event you’re able to watch, and I’ll post a link to the video recording when it’s available.