The Cause and the Effect

This week Richard Stallman resigned as president of the Free Software Foundation. It is long overdue, and I am grateful to Selam G., the writer of the blog post that sparked it.

I was disappointed to read that Michael Meeks’ post Tuesday on Planet GNOME repeated the excuses I’ve seen on Twitter and Reddit about mob rule and mischaracterization. Michael is of course entitled to that opinion, and unlike most Twitter and Reddit threads I’ve seen, has expressed it thoughtfully (which is why I think I can actually achieve something by writing this in turn.) I personally believe that that opinion does not stand up under scrutiny, and I hope writing a counterpoint might give him or others in the GNOME community food for thought.

I believe that we — especially in the GNOME community where it’s a goal to hold ourselves to high standards of treating each other well — must not let ourselves fall into the trap of saying ‘Stallman was just defending a friend, out come the pitchforks, just for one email, who will they come for next’ and thereby fail to see the whole picture. If it was really just one email and not years of well-documented bad behaviour and refusal to change, we’d be having an entirely different conversation.

Many who are grateful that Stallman has finally left the FSF are nonetheless anxious or grieving in some way: for the ideal of someone who may have been a hero to us before we realized what he was like in person; for trepidation about the future of the free software movement; or even for having to watch Stallman bring himself down in an avoidable, decades-long slow-motion train wreck. This is all understandable, but we should not let grief channel itself into minimizing or excusing or working around bad behaviour, or rules-lawyering about the interpretation of Stallman’s words. These two lines from Leonard Cohen and Sharon Robinson, singing about a different kind of grief, seem oddly fitting here:

Do not choose a coward’s explanation
That hides behind the cause and the effect

I will also refer you to Thomas Bushnell’s reflections from which I’d like to emphasize this paragraph, which is a response (expressed better than I could myself) to anyone who thinks that this one event can be regarded in isolation:

RMS’s loss of MIT privileges and leadership of the FSF are the appropriate responses to a pattern of decades of poor behavior. It does not matter if they are appropriate responses to a single email thread, because they are the right thing in the total situation.

The words of Matt Blaze are also appropriate here:

We will, as always, be treated to much examination of the precise nature and mass of the last straw, with observations that it would not by itself be sufficient to cause spinal damage in camels, and is therefore utterly harmless.


This post is my personal opinion, and is not written on behalf of the GNOME Foundation, its board of directors, nor anyone else.

Why Don’t You Just

If there was one phrase I could snap my fingers to make unutterable forevermore, it would be “why don’t you just …?”1

Someone is talking about a problem, or an achievement, or an idea, and the inevitable dismissive smartass pipes up and asks “Why don’t you just (move to a different apartment / adopt / rewrite it in Rust / eat more vegetables / mount your FTP account locally with curlftpfs, and then use SVN on the mounted filesystem)?”

“Why don’t you just?” is so second nature in my old field, physics, that XKCD made a comic about it: “So why does your field need a whole journal, anyway?”

“Why don’t you just?” means “I’ve thought about what you said for five seconds and I’m so smart that I really believe what I came up with in those five seconds is more valuable than whatever YOU thought of.”

“Why don’t you just?” means “I don’t trust you to do your own thinking.”

Sometimes “Why don’t you just?” even means “let me show you how smart I am by asking you why you didn’t just do something that I know won’t even work, and make YOU explain it to test if you’re as smart as me.”

The only possible answer to “Why don’t you just?” should be “If I could just, then I would just.”

…most of the time.

The tricky part is that sometimes, “Why don’t you just?” is the right question to ask, with the wrong wording. When you’re guiding people who are inexperienced at something, sometimes they do miss the obvious, easy solution. Or even experienced people miss it sometimes.

In those cases, how do you help them out without insulting their intelligence? Because “Why don’t you just?” is all about “me smart, you dumb”. The key is to put aside your ego and accept that this time, you may not get a chance to show that you are smart. First of all, check whether it is really the right time and place to give criticism! It might not be. If it is, then it’s a great rule of thumb to assume that they already tried the obvious thing you are about to suggest. That way, if they didn’t think of it themselves, they feel flattered and can save face. And if they did think of it or try it already, then you allow them to shine by explaining their thought process. Try something like “The way that I might have solved that problem is X. Would that also work in your situation?” Or “Stop me if you tried this already, but the way I’d have tackled it would be X.”

So, why don’t you just stop saying “why don’t you just?”


[1] Well, actually, I’d probably pick well, actually

The Parable of the Code Review

Last week’s events, with Linus Torvalds pledging to stop behaving like an asshole, instituting a code of conduct in Linux kernel development, and all but running off to join a monastery, have made a lot of waves. The last bastion of meritocracy has fallen! Linus, the man with five middle fingers on each hand, was going to save free software from ruin by tellin’ it like it is to all those writers of bad patches. Now he has gone over to the Dark Side, etc., etc.

There is one thing that struck me when reading the arguments last week, that I never realized before (as I guess I tend to avoid reading this type of material): the folks who argue against, are convinced that the inevitable end result of respectful behaviour is a weakening of technical skill in free software. I’ve read from many sources last week the “meritocracy or bust” argument that meritocracy means three things: the acceptance of patches on no other grounds than technical excellence, the promotion of no other than technically excellent people to maintainer positions within projects, and finally the freedom to disrespect people who are not technically excellent. As I understand these people’s arguments, the meritocracy system works, so removing any of these three pillars is therefore bound to produce worse results than meritocracy. Some go so far as to say that treating people respectfully, would mean taking technically excellent maintainers and replacing them with less proficient people chosen for how nice1 they are.

I never considered the motivations that way; maybe I didn’t give much thought to why on earth someone would argue in favour of behaving like an asshole. But it reminded me of a culture shift that happened a number of years ago, and that’s what this post is about.

Back in the bad old days…

It used to be that we didn’t have any code review in the free software world.

Well, of course we have always had code review; you would post patches to something like Bugzilla or a mailing list and the maintainer would review them and commit them, ask for a revision, or reject them (or, if the maintainer was Linus Torvalds, reject them and tell you to kill yourself.)

But maintainers just wrote patches and committed them, and didn’t have to review them! They were maintainers because we trusted them absolutely to write bug-free code, right?2 Sure, it may be that maintainers committed patches with mistakes sometimes, but those could hardly have been avoided. If you made avoidable mistakes in your patches, you didn’t get to be a maintainer, or if you did somehow get to be a maintainer then you were a bad one and you would probably run your project into the ground.

Somewhere along the line we got this idea that every patch should be reviewed, even if it was written by a maintainer. The reason is not because we want to enable maintainers who make mistakes all the time! Rather, because we recognize that even the most excellent maintainers do make mistakes, it’s just part of being human. And even if your patch doesn’t have a mistake, another pair of eyes can sometimes help you take it to the next level of elegance.

Some people complained: it’s bureaucratic! it’s for Agile weenies! really excellent developers will not tolerate it and will leave! etc. Some even still believe this. But even our tools have evolved over time to expect code review — you could argue that the foundational premise of the GitHub UI is code review! — and the perspective has shifted in our community so that code review is now a best practice, and what do you know, our code has gotten better, not worse. Maintainers who can’t handle having their code reviewed by others are rare these days.

By the way, it may not seem like such a big deal now that it’s been around for a while, but code review can be really threatening if you aren’t used to it. It’s not easy to watch your work be critiqued, and it brings out a fight-or-flight response in the best of us, until it becomes part of our routine. Even Albert Einstein famously wrote scornfully to a journal editor after a reviewer had pointed out a mistake in his paper, that he had sent the manuscript for publication, not for review.

And now imagine a future where we could say…

It used to be that we treated each other like crap in the free software world.

Well, of course we didn’t always treat each other like crap; you would submit patches and sometimes they would be gratefully accepted, but other times Linus Torvalds would tell you to kill yourself.

But maintainers did it all in the name of technical excellence! They were maintainers because we trusted them absolutely to be objective, right? Sure, it may be that patches by people who didn’t fit the “programmer” stereotype were flamed more often, and it may be that people got sick of the disrespect and left free software entirely, but the maintainers were purely objectively looking at technical excellence. If you weren’t purely objective, you didn’t get to be a maintainer, or if you somehow did get to be a maintainer then you were a bad one and you would probably run your project into the ground.

Somewhere along the line we got this idea that contributors should be treated with respect and not driven away from projects, even if the maintainer didn’t agree with their patches. The reason is not because we want to force maintainers to be less objective about technical excellence! Rather, because we recognize that even the most objective maintainers do suffer from biases, it’s just part of being human. And even if someone’s patch is objectively bad, treating them nonetheless with respect can help ensure they will stick around, contribute their perspectives which may be different from yours, and rise to a maintainer’s level of competence in the future.

Some people complained: it’s dishonest! it’s for politically correct weenies! really excellent developers will not tolerate it and will leave! etc. Some even still believe this. But the perspective has shifted in our community so that respect is now a best practice, and what do you know, our code (and our communities) have gotten better, not worse. Maintainers who can’t handle treating people respectfully are rare these days.

By the way, it may not seem like such a big deal now that it’s been around for a while, but confronting and acknowledging your own biases can be really threatening if you aren’t used to it… I think by now you get the idea.

Conclusion, and a note for the choir

I generally try not to preach to the choir anymore, and leave that instead to others. So if you are in the choir, you are not the audience for this post. I’m hoping, possibly vainly, that this actually might convince someone to think differently about meritocracy, and consider this a bug report.

But here’s a small note for us in the choir: I believe we are not doing ourselves any favours by framing respectful behaviour as the opposite of meritocracy, and I think that’s part of why the pro-disrespect camp have such a strong reaction against it. I understand why the jargon developed that way: those driven away by the current, flawed, implementation of meritocracy are understandably sick of hearing about how meritocracy works so well, and the term itself has become a bit poisoned.

If anything, we are simply trying to fix a bug in meritocracy3, so that we get an environment where we really do get the code written by the most technically excellent people, including those who in the current system get driven away by abusive language and behaviour.


[1] To be clear, I strive to be both nice and technically excellent, and the number of times I’ve been forced to make a tradeoff between those two things is literally zero. But that’s really the whole point of this essay

[2] A remnant of these bad old days of absolute trust in maintainers, that still persists in GNOME to this day, is that committer privileges are for the whole GNOME project. I can literally commit anything I like, to any repository in gitlab.gnome.org/GNOME, even repositories that I have no idea what they do, or are written in a programming language that I don’t know!

[3] A point made eloquently by Matthew Garrett several years ago

Healthy Code

I work on a team of software developers that maintains several large codebases — too much code for any one person to easily know what’s going on in every part of it at any particular time. I found myself thinking a lot about how to keep the code healthy and a while ago I set my thoughts down as a list of good practices. Thanks to my coworkers at Endless for input, editing, and debate.

The good practices in this post differ slightly from the ones we adopted at work, which reflect the opinions of the whole team; these are worded to reflect my personal opinions.

Assumptions

I don’t like rules without a rationale. I believe these six assumptions underlie the rules that I set out below. That is, if you don’t agree with these assumptions then you probably won’t agree with the rules… ☺︎

  1. We can never know that our own code is correct.
  2. Left unchecked, we will believe our own code to be correct.
  3. Even small mistakes can lead to catastrophic data loss.
  4. Non-trivial programs have interconnections too complex to keep entirely in one person’s mind.
  5. Modifying non-trivial programs will break code unrelated to the modifications.
  6. The business value of maintainable code is only visible to developers.

Good practices for code health

Use your judgement

As always, rules apply only in the absence of any overriding reason to ignore them. Breaking them should be in mutual agreement between the writer of the code and the reviewer. (This system only works if everyone agrees about what the rules are in the first place, though.)

Example reason to break this rule: If no agreement can be reached, then the default is to follow the coding standards.

Review code

Code gets reviewed by a developer who didn’t write any part of it, because of assumptions #1, #2, and #3 — and to spread familiarity with different parts of the codebase throughout the team. Develop with ease of reading in mind, as if you are writing a letter to an unfamiliar code reviewer. Review code skeptically and with full attention, as if it came from a malicious agent out to erase your hard drive.

Example reason to break this rule: You are committing a trivial fix for a broken build and your continuous integration system acts as the code reviewer.

Observe the style

Code follows the coding style. Coding style is important because when code looks the same it’s quicker to read and errors jump out more easily. Apply automated tools when possible to save the code reviewer from becoming a parenthesis counter.

Example reason to break this rule: The code reviewer agrees with you that deviating from the style is more readable.

Test your code

Code needs automated tests. The rationale for this is assumptions #2 and #5, but could be the subject of an entire blog post itself. Lack of tests can be by itself a reason to fail code review, or at least start a dialogue between developer and reviewer about why tests are not necessary in this particular case.

Example reasons to break this rule: A one-off script. A component that proxies an external resource which can’t easily be mocked out.

Refactor on write

You will always have to deal with legacy code (code on which development has ceased but still must be maintained) and rushed code (code which you were forced by circumstances to check in that didn’t quite work well, works but is difficult to maintain, or is not tested.) By assumption #6, you will probably never set aside time to refactor code for its own sake. Therefore, refactor bit by bit to leave the code in a slightly better state each time it’s touched. In this way, code receives refactoring attention roughly proportional to the benefit you receive from refactoring it. If at all possible, add new code with a unit test even if the rest of the code is not written in a testable way.

Example reasons to break this rule: The code is already in good shape. The feature is critical and cannot be delayed. You are contributing your code to an open source project, in which case it is better to work with the upstream community to refactor.

Refactor only on write

Make your diffs per commit no larger than they have to be, in order to make code review easier. Since diffs go line-by-line, do not fix style errors in lines that that are not already being touched in the same commit. Use separate commits if there is an opportunity to make other style fixes.

Example reason to break this rule: If it makes more sense to fix lines other than the ones being edited in one shot (e.g. large sections with wrong indentation), do so throughout the whole file in a separate commit.

Pay down technical debt

Sometimes it’s not possible to build a feature without doing a large refactor first. Determine this as early as possible and include it in the time estimate for the feature. Do not shy away from paying down this debt; it will only compound if you borrow more on top of it. However, keep the changes incremental, and the functionality unimpeded while making these changes.

Example reason to break this rule: Extreme time constraints force you to take out a second mortgage on the code (even then, do this only with a healthy dose of disgust.)

Discretization is the better part of valorization

V is for Valorization. What’s that? A buzzword coined by the Dutch government that signifies how all scientific research should make money, and lots of it, sooner rather than later. It’s certainly not an English word, as evidenced by the quizzical looks on the faces of physicists who haven’t been working in the Netherlands lately, when some official government delegate gets to make a speech at a Dutch physics conference and says, beaming into the audience, “We are ferry heppy to see so much fellorizable research going on here!”

(UPDATE: Merlijn van Deen reports that valorisation is, in fact, a borrowing from French, where it is used in the same context of scientific research as in Dutch. In English, according to Wikipedia, it is used only as a translation of the German Verwertung, a technical term coined by Marx in Das Kapital meaning to add surplus value to capital by human action.)

I don’t fit the popular caricature of a scientist who thinks all research should be pure and untouched by worldly concerns. On the contrary, I have a Master’s degree in applied physics. One of my current projects is to build a new kind of wavefront sensor that works on a different principle than the commercially available ones. I’m firmly of the opinion that the original reason for this ‘valorization’ policy is quite sound: to get academia and industry interested enough in each other so that academia’s more marketable efforts get passed on to industry instead of dying the death of obscurity in a professor’s filing cabinet, and industry knocks on academia’s door when they have an interesting problem to solve with a longer time-to-market.

But it’s been blown all out of proportion now. The government has declared some research more valuable than other research: fields like high tech systems and energie (energy) are now designated topsectoren (top sectors,) research to which funds should be diverted at the expense of all other research. They are headed by topteams (top teams) each including a captain of science and captain of industry, which draw up innovatiecontracten (innovation contracts) that are required to hit each vertex of the gouden driehoek (golden triangle) of kennis, kunde, kassa (knowledge, expertise, and cash.) It will be successful in making the Netherlands #1 worldwide in the use of buzzwords, which I’ve italicized and translated (only where necessary, since half of them are in English anyway to make them sound more important.) If you read the actual documents, you get the feeling that the government is telling the big companies, “Hey! Want some cheap contract research? We’ve given those scientists free rein for too long and it’s time they worked for you to redeem themselves!”

The thing that spurred me out of lethargy was this, the Sell Your Science contest. You have to make a 90-second video about your research and the winner gets the title “Best Science Communicator of the Netherlands.” Sounds great. But it turns out that you literally have to sell your research: in the description, they treat ‘the audience’ and ‘investors’ as one and the same! I’m sorry, but science communication and sales pitches are two different things. Nothing wrong with a sales pitch contest, but at least call it by its rightful name!

Science crosses borders that politics doesn’t, so it may not have even occurred to their bureaucrat brains that they’re shutting out a large share of the scientists in the Netherlands, who are not Dutch and might not speak it well enough to read the rules of the contest which aren’t in English.

And this part really makes my blood boil (translation mine):

Nowadays, it’s not enough just to write scientific articles and to talk to people in your own field. A broader, open attitude towards society is expected, and valorization sections are required in NWO grant applications. The modern scientist will have to communicate differently and more widely in order to propagate their research.

I explain exactly why this makes my blood boil in the letter that I sent them on May 10. My own English translation is reproduced below. It’s been two weeks and I’ve received no reply. So I’m sharing it:

Dear Sir or Madam, (cc: editorial office of the Leiden University employee newsletter)

I read about the ‘Sell Your Science’ contest in Leiden University’s employee newsletter, and from there I clicked over to the website www.valorisatie.nu. My astonishment was boundless when I read there that this contest is failing to distinguish between the two entirely disparate concepts of ‘science communication’ and ‘science valorization.’ I would like to take a moment of your time to explain why I think this is wrong.

Science communication is, as you say, presenting research to a broad audience in a clear and understandable way. But is that the same as ‘valorization’? Only if one assumes that the broad audience is exclusively interested in marketable research. That is a dangerous fallacy.

The passion that drives a researcher to be good at science communication usually doesn’t spring from the commercialization of research. It’s likely that someone who’s motivated by commercialization won’t choose a career in research. These days, there are those who would rather deny that, but it’s a fact. The description of Sell Your Science, in which scientists are portrayed as hermits, only speaking to their fellow scientists and avoiding contact with society, and in which you say that the ‘modern’ scientist has to start doing things differently, feels like a slap in the face of my profession. There are countless scientists, both in the past and in modern times, who may not necessarily be oriented towards industry, but do stand 100% squarely in society. These people are marginalized by the tendentious introduction on the website. ‘Hermits’ may exist, it’s true, but they are a small minority.

Anyone that I’ve ever encountered who’s been good at communicating science, was able to captivate their audience using their dedication and passion, no matter what the economic value of the research was. Good science communication makes sure the audience has learned something by the time they leave. Good science communication fans the sparks of curiosity in the audience, so that someone, the day after or the day after that, might just hit upon the idea to ask “How does that work, anyway?” A scientist who can captivate an audience (apparently, a hostile one at that) with ‘unmarketable’ science and at the same time, manages to convey its importance despite its unmarketability, is a much better candidate for the title of “Best Science Communicator of the Netherlands” than someone who can sell ‘marketable’ science to investors. That’s the difference between ‘science communication’ and ‘science valorization.’

Sincerely,
Philip Chimento
PhD student, physics
Leiden University

Writing letters seems to have had an actual effect — read Part II.

Rain in the Desert, Part II

Recently I wrote about my experience with microblogging at a physics conference. I was gratified to find out that people actually read and enjoyed it, and it might even have had an effect on next year’s conference. Roy Meijer was kind enough to send me some tips on how to use social media at scientific conferences. I’ve said what I wanted to say about the experience, but I want to discuss my further thoughts about two inappropriately sexist messages that showed up on the big Twitter screens at the conference.

A conference-goer who made one of the sexist comments wrote a comment on this blog, anonymously, objecting to me calling him a socially retarded asshole in my essay. Let it be absolutely clear that I don’t take kindly to people who create an unwelcoming or unpleasant environment for women in physics. But it made me think anyway: he seemed genuinely convinced that women enjoy this kind of attention, and indeed, one shouldn’t ascribe others’ objectionable behavior to malice when it could be just cluelessness. So maybe I should just have said socially retarded.

But no matter whether it’s malice or cluelessness, I know that physicists can do better. Not just can, but have to. Sexist attitudes just don’t belong in the world today, and most other professions have gotten with the program. But physicists apparently still live in 1972. Here are some examples of what women in physics have to put up with:

  • A few years ago a professor at our Institute gave a really horrifying speech at the Christmas party, in which he thanked the secretaries for being our mothers who took care of us, and the technicians for being our fathers who brought us toys to play with. As if that piece of gender stereotyping weren’t enough of a train wreck by itself, he had actually started out his speech by telling an off-color story that involved mistresses, then said he’d heard that story from a Jewish colleague and that it was typical Jewish humor. (Although this post is about sexism, not racial stereotypes, and I can only be outraged about one thing at a time if I want to keep my message on track.)
  • Another professor at our Institute told grad students that to be a successful physicist, you have to have a supportive family, so his wife stayed home and took care of the children. Yes, there were female grad students in the audience. Perhaps there were gay grad students too.
  • At a conference I was at, a professor put a slide of a bikini model into his talk. He had photoshopped her head to be the professor organizing the conference (who is a woman).
  • If you go to the poster session at a physics conference, you’ll always see a crowd of nerds clustered around a few posters. At the center of each cluster is a female physicist presenting her poster. If I put myself in her place, I figure the attention to one’s research is gratifying — as a male physicist, I always have to work really hard to get anyone to even stop and take a look at my poster — but on the other hand, as a male physicist, I never have to worry about whether the attention comes from sincere interest in one’s research, or ulterior motives.

[Man writes incorrect equation on chalkboard] ONLOOKER: Wow, you suck at math. [Woman writes incorrect equation on chalkboard] ONLOOKER: Wow, girls suck at math.

Dear readers, I respect you, really I do. I know everybody on the whole internet links to this XKCD cartoon and you've seen it fifty thousand times already. But there's just no possible way to illustrate sexism in science more accurately and simply than Randall Munroe does.

So the question is what in particular is wrong with these comments I objected to. The Geek Feminism Wiki’s page on technical conferences has a list of problems with which women are often confronted. My experience is that FOM does a good job at making sure that most of these problems don’t occur at the Veldhoven conference. (Although my personal experience doesn’t really count, does it, since I’m lucky enough not to have to face these challenges.)

However, our conference-goer who made the inappropriate comment on the public screen, in my opinion, has made the mistake of falling into the “You should be flattered” trap: the misguided belief that since he was actually making a compliment, it should be OK. I quote (and slightly paraphrase) from that link on why this belief is wrong:

  • “It attempts to dictate women’s emotional responses to such comments, in particular perpetrating the idea that women are socially obliged to be pleasant and accommodating;
  • “It places the blame on women for responding negatively to attention which is wholly inappropriate in [a professional context];
  • “It reminds women that they are subject to men’s approval […];
  • “It reminds women who aren’t the object of the comment that they are also subject to men’s approval;
  • “It ignores the fact that many women have had negative experiences with sexual attention, such as immediate or eventual criticism or violence, and therefore do not view it with unmixed (or any) pleasure;
  • “It makes non-straight women feel particularly marginalised;
  • “Focusing on women’s appearance contributes to feelings of exceptionalism and conveys the judgment that a woman’s [physics] expertise is less valuable than her attractiveness.”

In my mind, there’s still an unsolved question. Does the conference organizer have a responsibility towards the conference-goers to prevent this stuff from happening or mitigate it when it does? On the one hand, you have to assume that people will comport themselves decently in public, and you can’t prevent every possible turd that people might drop in the punchbowl. On the other hand, allowing someone to create a poisonous environment for a minority lasts much longer than the conference does.

Addendum 1: I debated with myself whether to name-and-shame the professors in the examples above. They certainly deserve it, but I’m not sure it would serve any purpose other than spite. The time for denouncing the first and third incidents was right after they happened, and I will always regret that I said nothing in both cases. I wasn’t present at the second incident myself; I only heard about it from people who were there.

Addendum 2: Please realize that I’m not trying to flog a dead horse by chastising someone for an inappropriate comment at a conference that has been over for two months now. I am writing this because I think that the problem is an important one and I think that we have a responsibility to educate our colleagues so that physics can move out of the social Dark Ages, and women will actually feel welcome in our field, and nobody will argue about affirmative action policies, because we won’t need them.

Rain in the Desert

My employer, FOM, held their yearly national physics conference again in the town of Veldhoven. It’s always a good opportunity to catch up with people and learn about whatever’s been going on recently in Dutch physics research.

This year, the chairman of the executive board, Niek Lopes Cardozo, opened the conference with a short speech. To my astonishment, he concluded by urging the conference attendees to use Twitter during the conference! This was underscored by two giant projected video screens out in the main hall, scrolling messages from the #FOMveldhoven stream.

How does one set about the task of tweeting about a physics conference? I’m all for getting physicists, who are among the most conservative of scientists, to use exciting new technologies, but in this case I was skeptical. It sounded to me like the proverbial Underpants Gnomes’ half-baked business plan:

  1. Use Twitter.
  2. ???
  3. Profit!

…coming the way it did, with little more explanation than “Tweet for Science!” Possibly there was some metaphorical idolatry involved too, as if a consultant had advised FOM that they needed to “leverage the power of social media” and then leaned back in expectation of managers bowing down before him.

I have the unfortunate habit that when I see somebody’s golden calf, I have to poke at it until it falls over. So I decided to plunge wholeheartedly into it, skeptically but with an open mind.

This was new ground for me. I did already have a Twitter account, although I barely post more than once a month. I use it mostly to read other people’s messages. I thought this would be a nice experiment to try and see what ways I could come up with to put it to actual useful use at a conference.

Unfortunately, the results were underwhelming. It was a lot of inane chatter that in my opinion was a waste of time to read and participate in. Neither can I say that my own messages were very scientifically newsworthy — and it follows from symmetry that if I didn’t think other people’s tweets were interesting then they probably didn’t think mine were.

Here’s what kinds of things went on:

  • The usual let-off-steam tweets about trains being late.
  • Lots of chatter in Dutch from FOM. Of course people are free to tweet in whatever language they like, but projecting tweets on a big screen at an international conference in a language that less than half of the attendees speak is not going to make them disposed to participate.
  • Tweets about Twitter itself: can we get #FOMveldhoven to trend, who’ll be the most active Twitterer at the conference, etc. Meta-conversation is the refuge for people who really don’t have anything to say.
  • Tweets about lunch.
  • People exclaiming which talk they were going to, or at, or had just visited. This was the first reasonably useful Twitter phenomenon at the conference. There were not really any people advertising their own talks, but I found out why that was when I went to give my own talk: I was too busy setting up my laptop and concentrating to get out my phone and type a message, and it would have been disruptive to the person who went before me anyway.
  • Tweets about dinner.
  • People repeating the statistic of how many people there were at dinner including someone who didn’t get the chairman’s joke that it was a “world record in Veldhoven” (one-horse town where the conference is held) and tweeted that it was a real world record.
  • Tweets about how fascinating the after-dinner talk was. I thought the talk was fascinating too. So much so, that I paid attention to the speaker while he was speaking. When I got out my phone afterwards, I was half-amused and half-shocked to see how many people had publicly claimed they were listening raptly on a medium that made it impossible for that to be true. (You’d think this was the nadir, but it wasn’t. Read on.)
  • A snide political remark from me about the junior minister of Education which I later thought better of and deleted. Not my proudest moment.
  • Drunk tweets from people in the nerd disco.
  • The absolute nadir: “Rain in the desert! I saw a beautiful girl at #FOMveldhoven” (later deleted) and “Is this being moderated? Beer and boobs #FOMveldhoven” Congratulations assholes, you’ve just undone more progress for women in physics than any “20% female professors by 2020” policy can do. And seriously, only a physicist could be so socially retarded that, instead of telling a woman she’s beautiful, he manages to tell hundreds of others they’re ugly.

I’m convinced that the lack of useful content is because nobody really knew how to put Twitter to work at a physics conference. For example, it didn’t occur to me to post the slides from my talk online until the day after it was over — but I was surprised that I was the only one who posted any slides at all! Twitter is a powerful tool, but it won’t work for you if you don’t know how to use it, and I don’t know how to use it. Apparently hardly anyone else did at this conference either.

Accordingly, following along with the conference on Twitter would have been nice if it hadn’t been shoved into our faces quite so much. Exhorting the attendees in the opening speech and projecting the tweets on a big screen makes people feel expected to join in. Feeling expected to follow along with it makes it all the more annoying when it turns out to be a waste of time. It should have been optional.

I’d like to amend what I tweeted near the beginning of the conference. I said, “Twitter isn’t magical. Tweeting random crap from a conference doesn’t automatically make it nifty.” Twitter can actually make magical things happen, but like most magical things in this world, you can’t just wave a wad of cash around and say “I’ma get me some of that.”