Archive for the ‘Communication’ Category

“Fifteen minutes longer and a thought process and probably you wouldn’t have done that”

December 27, 2013

In last month’s Esquire, there’s an interview with George Clooney where he briefly discusses Twitter:

“So one drunken night, you come home and you’ve had two too many drinks and you’re watching TV and somebody pisses you off, and you go ‘Ehhhhh’ and fight back. And you go to sleep, and you wake up in the morning and your career is over. Or you’re an asshole. Or all the things you might think in the quiet of your drunken evening are suddenly blasted around the entire world before you wake up. I mean, when you see, like, Ashton Kutcher coming out going, you know, ‘Everybody leave Joe Paterno alone,’ or whatever he said, you just go, ‘Fifteen minutes longer and a thought process and probably you wouldn’t have done that.’ ”

Granted, most of us don’t live in a world where everything we say can and will be used against us in the court of television infotainment, but it still applies. I’m sure we’ve all said something publicly on the net that we wish we hadn’t.

I think it’s especially true for those of us who live in the little echo chamber of the world of open source. Maybe it’s a snarky comment in a Perlmonks thread, or a flippant remark at a conference, or something rude in a bug report. These things get remembered and hurt us.

“I have often regretted my speech, but never my silence” — Publilius Syrus, 1st century BC, well before Twitter.

Advertisements

Open source is improv, so say “Yes and”

January 23, 2012

In her fantastic book Bossypants, Tina Fey has a sidebar about how improvisational comedy has changed her life, and given her a new worldview. We in open source would do well to adapt these ideas to how we conduct our projects as well.

Improv and open source share many characteristics. A group of people come together to create something without a plan, and the result is greater than any one person could have created on his own. Everyone has a wellspring of ideas, and adds to the work created by others. In improv, the people make a scene or a sketch. In open source, they make software, or a body of knowledge, or a community, or a gathering.

From her book:

The first rule of improvisation is AGREE. Always agree and SAY YES. When you’re improvising, this means you are required to agree with whatever your partner has created. So if we’re improvising and I say, “Freeze, I have a gun,” and you say, “That’s not a gun. It’s your finger. You’re pointing your finger at me,” our improvised scene has ground to a halt. But if I say, “Freeze, I have a gun!” and you say, “The gun I gave you for Christmas! You bastard!” then we have started a scene because we have AGREED that my finger is in fact a Christmas gun.

Now, obviously in real life you’re not always going to agree with everything everyone says. But the Rule of Agreement reminds you to “respect what your partner has created” and to at least start from an open-minded place. Start with a YES and see where that takes you.

As an improviser, I always find it jarring when I meet someone in real life whose first answer is no. “No, we can’t do that.” “No, that’s not in the budget.” “No, I will not hold your hand for a dollar.” What kind of way is that to live?

The second rule of improvisation is not only to say yes, but YES, AND. You are supposed to agree and then add something of your own. If I start a scene with “I can’t believe it’s so hot in here,” and you just say, “Yeah…” we’re kind of at a standstill. But if I say, “I can’t believe it’s so hot in here,” and you say, “What did you expect? We’re in hell.” Or if I say, “I can’t believe it’s so hot in here,” and you say, “Yes, this can’t be good for the wax figures.” Or if I say, “I can’t believe it’s so hot in here,” and you say, “I told you we shouldn’t have crawled into this dog’s mouth,” now we’re getting somewhere.

To me YES, AND means don’t be afraid to contribute. It’s your responsibility to contribute. Always make sure you’re adding something to the discussion. Your initiations are worthwhile.

Too often in open source, we do the opposite. We quickly say no, without regard to its effects. In improv, “no” kills a scene. In open source, it can drive away a contributor or kill an improvement to a project. It doesn’t need to be the word “no”, but any negativity towards a fresh idea.

Consider this exchange, all too common in mailing lists and IRC channels right now.

Al: “I’m thinking about writing a tool to do X in language Y.”

Bob: “Language Y is a pain in the ass.”

In one quick bit of snark, Bob has taken a giant crap on Al’s idea, even though his only disagreement was in the implementation. Chances are Al will lose enthusiasm for the probject. In many cases, Al’s reaction might just be “Screw it, I don’t need this.”

Consider this alternative response from Bob:

Al: “I’m thinking about writing a tool to do X in language Y.”

Bob: “That sounds like a cool idea. I bet a lot of people could use X. I have some concerns about writing it in Y if you’re interested in hearing them.”

This is not “sugar coating the truth” or “being politically correct.” It’s being polite. It’s being a human who understands that other people have feelings, and that those feelings drive behavior.

I’m certain that some reading this will say “If Al gives up based on that, Al needs to toughen up. If someone doesn’t like something I’m doing, I’ll still do it anyway.” That’s great for you, Mr. Self-Esteem. Not everyone is as highly advanced as you are.

The “suck it up and take rude criticism” attitude might make sense if your project can be picky enough to only take contributions from those with your level of self-esteem. No project that I’m on is so overflowing with contributors and code that it makes sense to drive away those who want to help. It’s my job in my communities to help bring in more contributions, and I suggest it’s yours, too.

Open source is not standup comedy. It’s never one star on stage, doing it all himself. It’s a worldwide improv ensemble. Try saying “YES, AND” and see what can come out of it.

Video: How to give a conference presentation, by Mark Jason Dominus

December 8, 2011

Mark Jason Dominus is one of my inspirations for giving talks at technical conferences. I saw him give this presentation at YAPC 2002 in St. Louis and was inspired to try it myself. The video below is from OSCON a month later.

The video is horrible by today’s standards, but it’s the audio that matters. You can follow along with his slides since they don’t always show up in the video.

Thanks to MJD for his kind permission in letting me post it to YouTube.

Mark Jason Dominus on the importance of giving fish

November 2, 2011

By Mark Jason Dominus, from a talk in 2003, reprinted here with permission. Sadly, it’s still relevant today.

The #perl IRC channel has a big problem. People come in asking questions, say, “How do I remove the first character from a string?” And the answer they get from the regulars on the channel is something like “perldoc perlre“.

This isn’t particularly helpful, since perlre is a very large reference manual, and even I have trouble reading it. It’s sort of like telling someone to read the Camel book when what they want to know is how to get the integer part of a number. Sure, the answer is in there somewhere, but it might take you a year to find it.

The channel regulars have this idiotic saying about how if you give a man a fish he can eat for one day, but if you teach him to fish, he can eat for his whole life. Apparently “perldoc perlre” is what passes for “teaching a man to fish” in this channel.

I’m more likely to just answer the question (you use $string =~ s/.//s) and someone once asked me why. I had to think about that a while. Two easy reasons are that it’s helpful and kind, and if you’re not in the channel to be helpful and kind, then what’s the point of answering questions at all? It’s also easy to give the answer, so why not? I’ve seen people write long treatises on why the querent should be looking in the manual instead of asking on-channel, which it would have been a lot shorter to just answer the question. That’s a puzzle all right.

The channel regulars say that answering people’s questions will make them dependent on you for assistance, which I think is bullshit. Apparently they’re worried that the same people will come back and ask more and more and more questions. They seem to have forgotten that if that did happen (and I don’t think it does) they could stop answering; problem solved.

The channel regulars also have this fantasy that saying perldoc perlre is somehow more helpful than simply answering the question, which I also think is bullshit. Something they apparently haven’t figured out is that if you really want someone to look in the manual, saying perldoc perlre is not the way to do it. A much more effective way to get them to look in the manual is to answer the question first, and then, after they thank you, say “You could have found the answer to that in the such-and-so section of the manual.” People are a lot more willing to take your advice once you have established that you are a helpful person. Saying perldoc perlre seems to me to be most effective as a way to get people to decide that Perl programmers are assholes and to quit Perl for some other language.

After I wrote the slides for this talk I found an old Usenet discussion in which I expressed many of the same views. One of the Usenet regulars went so far as to say that he didn’t answer people’s questions because he didn’t want to insult their intelligence by suggesting that they would be unable to look in the documentation, and that if he came into a newsgroup with a question and received a straightforward answer to it, he would be offended. I told him that I thought if he really believed that he needed a vacation, because it was totally warped.

Mark Jason Dominus has been doing Perl forever. He is the author of Higher Order Perl which belongs on the shelf of every Perl programmer. Follow him on Twitter at @mjdominus.

Andy’s jobs/work news roundup for 2011-02-21

February 21, 2011

These links are collected from my Twitter feed. If you have suggestions for news bits, please mail me at
andy@petdance.com.

  • Job boards no more “help” you find a job than a billboard “helps” you find a new pair of shoes. (codeanthem.com)
  • A few things every job-seeking programmer should know about project manager (stellman-greene.com)
  • What job qualifications can trump work experience? (askamanager.org)
  • Ten tips for submitting your resume (money.usnews.com)
  • Don’t call to schedule an interview (askamanager.org)
  • This is how salary negotiation should work (askamanager.org)
  • RT @mjdominus A recruiter asked me to rate my programming 1–10. I said 10, since nobody who asks that is qualified to dispute my answer.
  • From the daily @tom_peters email: If your failure rate is one in a million, what do you tell that one customer?
  • RT @AskAManager Be Cautious When Referring a Friend for a Job (bit.ly)
  • What to do when you think you might lose your job (thecynicalgirl.com)
  • Should you work for free? Probably not. This fine chart lays it out. (jhische.com)
  • The importance of being able to say “I don’t know” (chadfowler.com)
  • How to tailor a resume for an employer (bit.ly)
  • 57% of the Inc. 500 use social media to recruit (talentline411.com)
  • Quit whining and send a thank you note after an interview (xrl.us)
  • How to be a better coworker (mashable.com)
  • Ditch Starbucks and work at the library. (52tiger.net)
  • 8 things you should know about job references (from @AskAManager) (xrl.us)
  • Smokers need not apply (bnet.com)
  • Six reasons you shouldn’t quit without notice (bnet.com)

What you say vs. what others hear

July 29, 2008

As you work through life, and especially the job hunt, never forget that what you say may not be what others hear. Your message often has unintended side messages.

This article from the Wall Street Journal discusses how job candidates trash their chances of landing jobs by using overly informal communications.

After interviewing a college student in June, Tory Johnson thought she had found the qualified and enthusiastic intern she craved for her small recruiting firm. Then she received the candidate’s thank-you note, laced with words like “hiya” and “thanx,” along with three exclamation points and a smiley-face emoticon…. Workers in their 20s and younger are accustomed to online and cellphone messaging, and the abbreviated lingua franca that makes for quick exchanges, [David Holtzman] says. “It’s just natural for them. They don’t realize that it’s perceived to be disrespectful.”

Sometimes it’s not even the medium or the message, but when you send the message.

Executive recruiter Hal Reiter recently received … a thank you from a chief financial officer candidate sent by BlackBerry just minutes after the interview. “You don’t even have time to digest the meeting and you’re getting a thank-you note,” says Mr. Reiter, chairman and chief executive of Herbert Mines Associates, a New York-based search firm.

In this case, the very method of sending the communication told the recipient that it wasn’t worth much of the candidate’s time. The candidate was on his way somewhere else and dashed off a reply, as if he was getting an odious task off his checklist, rather than giving a respectful letter that matched the gravity of the communication.

It’s all about respect, and the ways that we can easily show our lack of respect or interest in others. Unintentional messages are messages none the less.