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

Geek tip: g_object_new and constructors

tl;dr Don’t put any code in your foo_label_new() function other than g_object_new(), and watch out with Vala.

From this GJS bug report I realized there’s a trap that GObject library writers can fall into,

Avoid code at your construction site.

Avoid code at your construction site.

that I don’t think is documented anywhere. So I’m writing a blog post about it. I hope readers from Planet GNOME can help figure out where it needs to be documented.

For an object (let’s call it FooLabel) that’s part of the public API of a library (let’s call it libfoo), creating the object via its foo_label_new() constructor function should be equivalent to creating it via g_object_new().

If foo_label_new() takes no arguments then it should literally be only this:

FooLabel *
foo_label_new(void)
{
    return g_object_new(FOO_TYPE_LABEL, NULL);
}

If it does take arguments, then they should correspond to construct properties, and they should get set in the g_object_new() call. (It’s customary to at least put all construct-only properties as arguments to the constructor function.) For example:

FooLabel *
foo_label_new(const char *text)
{
    return g_object_new(FOO_TYPE_LABEL,
        "text", text,
        NULL);
}

Do not put any other code in foo_label_new(). That is, don’t do this:

FooLabel *
foo_label_new(void)
{
    FooLabel *retval = g_object_new(FOO_TYPE_LABEL, NULL);
    retval->priv->some_variable = 5;  /* Don't do this! */
    return retval;
}

The reason for that is because callers of your library will expect to be able to create FooLabels using g_object_new() in many situations. This is done when creating a FooLabel in JS and Python, but also when creating one from a Glade file, and also in plain old C when you need to set construct properties. In all those situations, the private field some_variable will not get initialized to 5!

Instead, put the code in foo_label_init(). That way, it will be executed regardless of how the object is constructed. And if you need to write code in the constructor that depends on construct properties that have been set, use the constructed virtual function. There’s a code example here.

If you want more details about what function is called when, Allison Lortie has a really useful blog post.

This trap can be easy to fall into in Vala. Using a construct block is the right way to do it:

namespace Foo {
public class Label : GLib.Object {
    private int some_variable;

    construct {
        some_variable = 5;
    }
}
}

This is the wrong way to do it:

namespace Foo {
public class Label : GLib.Object {
    private int some_variable;

    public Label() {
        some_variable = 5;  // Don't do this!
    }
}
}

This is tricky because the wrong way seems like the most obvious way to me!

This has been a public service announcement for the GNOME community, but here’s where you come in! Please help figure out where this should be documented, and whether it’s possible to enforce it through automated tools.

For example, the Writing Bindable APIs page seems like a good place to warn about it, and I’ve already added it there. But this should probably go into Vala documentation in the appropriate place. I have no idea if this is a problem with Rust’s gobject_gen! macro, but if it is then it should be documented as well.

Documented pitfalls are better than undocumented pitfalls, but removing the pitfall altogether is better. Is there a way we can check this automatically?

Wave at the camera

You have probably seen the fake advertisement for Wave, the new way of charging your iOS 8 phone in any standard household microwave. (Although I would venture that some of the responses with fried microwaves and phones are hoaxes as well.)

I admit I did giggle when I first read it — some chump microwaved their expensive phone and blew it up, funny, right? Only I realized that it’s not funny at all.

Why shouldn’t people believe that a new technology would allow them to charge their phone by microwaving it? It’s no more or less magical than any other new technology being invented every day. It just happens not to have been invented yet.

Yes, people need to think critically, check sources, use common sense, and become less science-illiterate. Is microwaving your phone a smart thing to do? No. Could the average person probably have known better? Yes. But if you are lucky enough to be in the minority for whom this is obvious, you don’t have any right to laugh at those for whom it is not.

Nature, why?!

Scientific journals charge subscription fees in order to access their content. If you’re an employed scientist, the university or company where you work usually buys an institution-wide subscription to a journal. In that case you don’t have to log in to the journal website because it recognizes your IP address as belonging to a subscribing institution. In fact, you don’t even get an account on the journal website, because it’s impractical to issue an account to every single user at a university, for example.

So what do you do when you have to look up something when you’re away from your office? You use SSH with port forwarding to connect to work, then visit the website using a proxy server on that port. Since you are now browsing through a work computer, you can read the journal. There’s nothing wrong with this, because your employer has already paid for your access that content, but the barrier was simply the impracticality of issuing you an individual account.

So it’s really strange that Nature Publishing Group, which publishes the overrated Nature family of journals, seems to want to discourage this practice. If you visit the site of a Nature journal from a non-subscriber IP address, they set a cookie in your browser that says you are not a subscriber. So even when you turn on your proxy server and revisit the site, it still tells you you’re not a subscriber and can’t access the journal article. Luckily, it is easily remedied by erasing your browser’s cookies. (Easily done, that is, but not easily thought of. Hope this helps someone.)

Why, Nature, why? Why would you do this? Do you have scientists’ best interests at heart and you want to prevent them from working at home? Or do you hope that people are gullible enough to pay twice for the same content?

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

Illegal Were Folon’s!

The American elections are coming up tomorrow, which for me means completing an absentee ballot. I actually like this, since I can sit down and Google all the candidates at my leisure before voting, to make sure they’re not KKK members. One resource that I often use is vote411.org, which is sponsored by the League of Women Voters, a nonpartisan organization.

They send out questionnaires to every candidate for every elected office on every ballot, interviewing them on the relevant issues, which they then reprint on their website; you can even compare two candidates’ answers side by side. This is an amazing (and free) service. I rely on it to help me form an opinion about Maryland politics, since I’m registered to vote there.

There were four candidates for the US Senate on the ballot: a Democrat, a Republican, a Green candidate, and one from the Constitution Party. I would have thought that the Constitution Party was a recent consequence of the Tea Party, since every third word out of a Tea Partier’s mouth is “constitution”, but apparently it’s been around for ten years. Anyway, this Constitution candidate, Richard Shawver, answered the interview questions so incompetently that I truly don’t understand how he was able to string enough coherent sentences together to get on the ballot. For your reading pleasure, I reproduce the interview in full below [the links to the sections of the US Constitution are mine]:

QUALIFICATIONS: What are your qualifications for this office?

Richard Shawver: Article 1 Section 3 I believe in the constitution, want to keep this country a repubic.

BUDGET: What methods would you support to address the federal budget deficit?

Richard Shawver: Article 1 Section 8 Congress must obey thier oath.

FOSSIL FUELS: What should be done at the federal level to reduce our use of and dependence on fossil fuels?

Richard Shawver: Hydroelectric plants, clean burning coal plants.

IMMIGRATION: What changes, if any, do you support in regard to immigration policy?

Richard Shawver: Article 1 Section 8 Illegal were folon’s, could not become citizens.

CORPORATIONS/ELECTIONS: What do you think is the proper role of corporations in elections?

Richard Shawver: There no proper role.

EDUCATION: What role should the federal government play in public education?

Richard Shawver: None, its the states role.

SECURITY: What are the most important steps towards assuring the short- and long-term security of our country?

Richard Shawver: Article 1 Section 8

First of all, it’s obvious that writing coherent English must be an elitist policy designed by the Obama administration to give furriners an unfair edge over red-blooded Americans — wait, what? I don’t like to nitpick, but there is at least one spelling, grammar, or factual error in every answer, except the last one which isn’t even trying to be a sentence!

For example, I just love his stance on immigration. “ILLEGAL WERE FOLON’S!” is such a pithy slogan, it should be the new battle cry of Blondie and the Freedom Party as they lead the Netherlands back into the Dark Ages, cheered on by the neo-nazi English Defence League. They could print it on their flags. What are folon’s? That’s the beauty of it, nobody knows. My best guess is “felons”.

My favorite part, though, is that he wants to keep the country a “repubic”. I think it’s only fitting that if America is in the throes of repuberty, then who else but hormone-fueled brats should lead her.

Now my only worry is whether to be relieved that these people can’t possibly be taken seriously, or scared that they’re taken seriously enough to get this far. This is why I implore you, if you are one of those inhabitants of this world with the right to vote in the United States on Tuesday, to do at least a minimum amount of research. Watching smear ads on TV doesn’t count.

Fox News don’t know Jack Bleep

This travesty was brought to my attention: Freaky Physics Proves Parallel Universes Exist, a worse-than-amateurish piece of what I hesitate to call scientific journalism by Fox News. I won’t waste space on why I consider the article so terrible, since someone else has already heaped scorn upon it better than I could: The Worst Physics Article Ever. Besides, it’s Fox News, and by now it shouldn’t be a surprise that they just write down whatever the hell they feel like.

I want to draw your attention to something mentioned in the article that I find much more worrying and insidious: the name Fred Alan Wolf. Wolf is a former physicist, turned crackpot, and anytime you hear his name mentioned in connection with legitimate science, alarms should start going off inside your head.

I recognized him as one of the “experts” featured in What The Bleep Do We Know, a piece of pseudoscientific rubbish that basically asserts that quantum mechanics allows us to control our destiny by wishful thinking. Just to give you some background, it’s a propaganda film made and paid for by students of Ramtha’s School of Enlightenment. This hotbed of charlatans is led by one J. Z. Knight, a cigar-voiced medium from Washington who claims to channel a 35000-year-old warrior named Ramtha from the lost continent of Lemuria.

To be fair, not everyone interviewed in the movie is a fraud. For example, there’s Professor David Albert, who, according to this Salon.com article, spent hours on camera explaining why the film’s physics was utter nonsense, only to see his contribution spliced and edited so as to imply the exact opposite.

Fred Alan Wolf, on the other hand, was not misrepresented in the least. Wolf, whose stage name is Dr. Quantum, has been on the lecture circuit since the 1980’s promoting quantum wishful thinking, according to an interview on the What The Bleep website. This claptrap has been popularized more recently by Rhonda Byrne and cronies in the bestseller The Secret, and what do you know, Wolf also appeared in the film version of that.

As far as I’m concerned, Dr. Quantum has about as much to do with real, falsifiable science as the iPad has to do with blue cheese. One might ask why I care so much. Let me put it this way: if Fox News not giving a crap about proper science reporting is a slap in the face of my profession, then the thought of Fred Alan Wolf being any journalist’s go-to guy for quantum physics is a kick in the nads.

PS. If you’re interested in what was actually achieved in the experiment, hysterical claims of time travel aside, here is the original press release from UCSB. Or see Nature 464, pp. 697–703 (2010).

Given two or more ways…

Most people know Murphy’s Law as the cynical maxim “Anything that can go wrong, will go wrong.” A more engineering-oriented form, which some claim to be closer to Murphy’s original cry of exasperation, goes like this: “Given two or more ways of hooking something up, if one of them will result in disaster, then someone will do it that way.”

For example, the Jargon File says this about it:

…you don’t make a two-pin plug symmetrical and then label it “THIS WAY UP”; if it matters which way it is plugged in, then you make the design asymmetrical.

I bring this up because I solved an experimental problem on Friday that has been torturing me for months. I was using an aspheric lens to focus a laser beam. For people who don’t know what that is, it’s a small piece of glass with a flat side and a curved side, and it matters which way round you put it in. Take a look at the lens and the tube mount that came along with it. There is external thread on the lens holder, and internal thread on the tube mount:

Picture of the lens and its tube

How would YOU put it together?

“Now that’s an example of good design,” I thought to myself on what must have been October 26, 2009 according to my lab journal, when I first started using the lens. “There’s only one way of screwing it into the tube, so it’s impossible to get backwards!” And I thought no more of it.

And so, between that time and now, I tried all sorts of tricks to correct the strange deviations I saw in my experiment. But for some reason, this lens occupied a mental blind spot, until last Friday, when I was talking to one of my advisors about the experiment.

He asked if I’d put the asphere in backwards, and I said, “No, that couldn’t be it — it only fits into the tube mount one way, and if I was supposed to use the tube the other way around, then the focus would be inside the tube.” But I checked anyway, and, well, what do you know.

It turns out that the correct way to mount the lens in the tube is to drop it into the unthreaded end, and then use a special tool to tighten it.

The special tool

The special tool

This has to be some of the dumbest engineering I’ve ever seen on the part of Thorlabs, the manufacturer. Not only are there two ways of hooking something up here, but the only obvious way is the wrong way. And the right way is not only not obvious, but even requires a special tool which is guaranteed to get borrowed and never returned or misplaced in some toolbox somewhere. And worst of all, the whole issue could easily have been avoided by putting the threads on the other end of the lens holder.

At least I got the satisfaction of solving all my problems at once by flipping over a centimeter-sized piece of glass. Shame on you, Thorlabs.