Think, for Perl's sake


I'm no longer surprised when I read about verbal abuse of other humans in my community. It makes me sad, both for the person who would say that to someone else, and for the person who gets the abuse. Worse, it makes me sad that the abusers don't care about the effects on their fellow human beings, or on the projects that they are representing.

Using technology in a community like ours is far more than just a choice of which code does more. Choosing to use a technology on a project is an investment. When you invest in a project, whether it's a language like Perl, or a module like DBIx::Class, you're not just investing in code. You're investing in the community that comes with it. There are at least two major Perl projects I will not invest any time in because of the communities that surround them. I'm not alone in my convictions and actions.

The other day I ran across an acronym, THINK, that gives questions to ask about what you're about to communicate, before you actually say it.

Is what I'm about to say:


Geeks in technical discussions are really good at the Intelligent, and usually Thoughtful. The Honest is just a given.

It's with Necessary and, especially, Kind where some fail, with damaging results.

I'd like to urge all of us to keep THINK in mind in all our interactions, whether in IRC, mailing lists or in person at user group meetings and conferences.

As an aside, I've always moderated Perlbuzz comments, and will continue to do so. THINK crystallizes my criteria perfectly.


I like that mnemonic.

I don't know anything about the incident in question, but it's important that people remember that THINK is just as important when asking questions as when answering them.

With respect to IRC, particularly, "Getting Help on IRC" is worth reading.

And more generally, esr's "How to Ask Questions The Smart Way" is a classic and speaks pretty directly to the rudeness issues that come up time and again and how to cope with them or avoid them in the first place.

David, I agree that people seeking advice should ask questions well. The thing is that they don't, but that doesn't excuse verbal abuse. I know that you're not trying to excuse it, but many others have in the past, trying to say "Well, they deserved it, because they didn't ask the questions right."

Go back and read the original article that I link to. There's a great quote in there.

[E]very time an "Enterprise" guy is looking in a Perl mailing list, all they see are bunch of petty "you do not follow rule 23 of how I want the world to act".

Now go back and read esr's instructions, and it's a perfect example of exactly that syndrome. He even refers to telling someone to RTFM as "an ancient and hallowed tradition."

That's the worst kind of thinking there is.

Andy, I'm not suggesting esr is right, I'm suggesting his article as a way people unfamiliar with that culture can better prepare for it. (The article is typical of the culture, naturally.)

In the ideal world, communities would be more civil. In the real world, if I go to a group for help, I can't change them, but I can change my approach to asking to try to get a better outcome.

David, I know you're not suggesting he's right, and I said that above.

My concern is that when we tell people "This is the best document there is to learn to talk to those who might otherwise be abusive and cruel to you," we do ourselves a disservice. We're saying "If you want to play in open source, dealing with anti-social people who consider it a gift to be cruel to you is just part of it all."

Why would anyone want to stay around?

It also influences others who read it. They see that esr condones anti-social behavior, so hey, might as well join in and do it as well.

esr's document has become a disservice to open source. It needs to be replaced in the public mindset by one that does not condone cruelty to others. I'd love for others to help me write it and start letting the world know.

I'd love to help rewrite it. That document conflates two objectives: (1) educate people about useful ways of thinking and expressing yourself as a developer; (2) foster elitism and protect the egos of fragile geeks who need to feel superior.

I think we can produce something that eliminates the second part, and preserve the first part there or somewhere else. It's time to learn how to play well with others.

Either the newcomers must change, or the group must change. After 25+ years of online discussions, I've seen no evidence that the newcomers are going to change.

Leave a comment

Job hunting for programmers

Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.