Airs – Ian Lance Taylor

Public Development

Although it hasn’t been my habit to track other blogs closely, Ben Collins-Sussman wrote an interesting post about Programmer Insecurity. The gist of the post is that programmers need to share code early in the development process. They should not develop code in their own cave, and then unleash it on an unsuspecting world.

This is particularly an issue for the case of modifications to an existing free software project. And it’s particularly true for design rather than code. It’s most important to do your design in the open, and let other developers comment on it. Unfortunately, there can be a catch-22 here: a design without code can be vaporware, so people won’t necessarily pay attention to it. But a poor design supported by good code will also not receive a good reception.

The flip side to public development is that free software programmers can be quite harsh. This is magnified by the nature of the medium used to communicate, e-mail, and it is magnified by the fact that people from different cultures have different expectations. It’s very easy for people to send an e-mail message which is intended to be friendly criticism but which is received as an attack. I’m sure that many free software projects have permanently alienated new developers through this sort of mistake.

So my advice for new contributors is to design in the open and to learn how to read e-mail to extract the useful information while ignoring the attacks. These are two separate skills which need to be developed by aspiring free software programmers.

And my advice for people who want to become maintainers is to develop the skill of making helpful comments which are not disparaging. This requires the use of euphemisms and careful attention to language, which are not characteristics of all good programmers.

I’m not a particularly nice guy on the inside, but I’ve learned to play one by applying a set of transformation to my thoughts. A few examples:

  • You’re wrong => That turns out not to be the case.
  • This is stupid => I think you need some more thought here.
  • Learn to use the indent program => You should add spaces there, there, and there.
  • We already know this is a terrible idea => You may want to review this e-mail thread.
  • Have you heard the word “portability”? => You need to consider other types of processors.
  • What idiot told you to do it this way? => Here are some good examples that you may want to follow.

You get the idea. The point is two-fold: developers should try to extract facts from e-mail while ignoring the language, and developers should try to use friendly language to put across their points.

Posted

in

by

Ian Lance Taylor

Tags:

Comments

5 responses to “Public Development”

  1. Pádraig Brady Avatar
    Pádraig Brady

    You make good points. There was a related thread on the linux kernel mailing list….
    http://lkml.org/lkml/2008/5/21/66

    It’s obvious why better programmers tend towards open source, as
    it’s a better model to get stuff done, as long as you’re not conscious of your code.
    Average/Most programmers are unfortunately.

    It’s worrying that the vocal few arrogant assholes can scare away potentially
    good programmers just starting out.

  2. graydon Avatar
    graydon

    I’m one of the odd men out here, I suppose, because I really disagree with this.

    There are strong, clinically-established psychological reasons why you might wish to work in isolation for a time. First impressions stick harder than subsequent impressions, for example. Criticism is easier than leadership. Negative feedback affects mood and therefore motivation. Anonymous criticism from abusive internet people, doubly so. Perhaps most of all: other people can be distracting! There is a cognitive cost to being interrupted with a diversionary design issue, just as there’s a cognitive cost to a constant stream of interrupting phone calls and emails (not to mention spam). This is why we give people their own offices with doors they can close. They think better when their brains are given time to spin-up and focus.

    Getting feedback is valuable. Being able to control what you get feedback on, and when you are soliciting it, is also valuable. I think Ben is simply wrong here. One of the great virtues of the internet is that there are always more private spaces. It is true that this carries risks of splintering, and impedence-mismatch when you try to integrate two previously-private spaces. But the private spaces can be very valuable.

  3. Ian Lance Taylor Avatar
    Ian Lance Taylor

    Pádraig: Thanks for the link, that is an interesting thread.

    graydon: thanks for the thoughtful comments. Clearly there is an appropriate balance to be struck between going public too soon and too late. I think it’s worth asking: which mistake to people, especially people new to free software, tend to make? What advice should we give?

  4. graydon Avatar
    graydon

    Advice? Oh, naturally, to be as public as you feel comfortable being, given the obvious value to be had from feedback and the increase in such value the earlier you get it. Just not to forcefully over-do it, any more than we force all conversations to be recorded for posterity and broadcast to everyone we know. Privacy serves a psychological role, even if one with costs.

    (For reference sake: I tend to follow a 3-stage process in publishing work, rather than 2. I work on my own for a bit, then I do controlled review with a group of my own choosing, and *then* I do public releases. I see many people working this way, and think it is more fitting with our psychological groupings: self, small-familiar-tribe, whole-universe. I think this is actually common, and what Ben describes as “code bombs” are more often releases from the 2nd to 3rd level: a company throwing code they’ve only reviewed internally out to the whole net. Not an *individual* throwing code they alone have developed out to the net.)

    I’m surprised to see Ben chastising git for its support of such features. Rebasing — writing a fresher and tidier version of a content subgraph, adjusting a branch-head pointer to point to the edited version and GC’ing the messy one you disconnected from your content graph — is one of the single strongest positive UI differentiators git has over its competition. Positive in the sense that *real humans want it*. Perhaps it comes as a surprise, but people will prefer to use the tool that does things they want easily. Arguing them out of this desire is like trying to convince people to desire a word processor without a delete key.

  5. Ian Lance Taylor Avatar
    Ian Lance Taylor

    graydon: I certainly agree that what type of source code control you use is irrelevant to Ben’s point.

Leave a Reply