Meanwhile, it looks like I’ll be doing a couple of Geek Etiquette related sessions at some upcoming conferences.

• First up, I’ve been asked to help moderate a panel on Troll Whispering at Web2Open here in SF on April 23rd. I’ll be teaming up with Teresa Nielsen-Hayden of Making Light and Boing Boing, Amy Muller of Get Satisfaction, and Christy Canida of Instructables.
• And then in July at OSCON I’ll be joining long-time partner in crime Schwern and a bunch of others to present a panel-style tutorial on People for Geeks, a look at the various ways geeks interact and fail to interact as human beings.

I’ll definitely be blogging about these as they occur. And if you think you’ll be at either of these sessions, please let me know and hopefully we can meet up!

Your space. Especially for us big guys, flights can be tough because of how little space is provided for our enormous frames. For shoulder space, favor the side that has no one on it. Don’t lean the seat back if the person next to you has if you can help it. As for legs? Avoid spreading them like you got some big business down there. Cross your legs below the knee. You’ll be surprised.

Not a particularly geeky topic, but hey, NATHAN FILLION. Nuff said.

Edit: he’s also got a good article on contacting celebrities online:

Autograph requests: You kidding me? After all we’ve been through, you’re going to cheapen it with “Sign this”? Sheesh. And if you really are getting it for a really good friend who really deserves something really special, then why don’t YOU do something thoughtful and special? Cuz, guess what? You don’t care about that person. You feel guilty because they do so much for you and you do diddly squat for them. Case in point: Your big thoughtful special idea is to put three lines in an email and you can’t be bothered to send a self-addressed stamped envelope (customary for autographed photo requests, some folks include the photo as well). So, you won’t spend $2.50 and a walk to the post office for this friend. How does it then become MY job? I’m an actor.

Your nerd might come off as not liking people. Small talk. Those first awkward five minutes when two people are forced to interact. Small talk is the bane of the nerd’s existence because small talk is a combination of aspects of the world that your nerd hates. When your nerd is staring at a stranger, all he’s thinking is, “I have no system for understanding this messy person in front of me”. This is where the shy comes from. This is why nerds hate presenting to crowds.

The skills to interact with other people are there. They just lack a well-defined system.

Go read it and let me know what you think. Agree? Disagree? Insightful, or insulting?

As I mentioned before, I’m travelling at the moment to Vanuatu, a developing nation in the South Pacific. The technical community here is small and under-resourced; there’s only a little Internet access, and few computers. However, there are people working very hard to set up community computer centres and to train local people in computer and Internet use.

One thing they don’t have is technical books. I’m trying to put together a technical library from geeks’ cast-offs. I know you’ve got some technical books you don’t use any more, or never used, or received as prizes or review copies. Take a look at this post on my personal blog, Technical Books for Vanuatu, and see if you can help out at all.

(In more topical news, there’s nothing like visiting a totally different culture to make you self-conscious about your etiquette. Here, I’m always finding that I talk too loud; I feel like a loud American tourist even though I’m not American! Anyone else here got stories of etiquette blunders while travelling?)

My point is that posting here may be even patchier than usual for the next while, so please accept my apologies in advance. However, if you do have any questions of Geek Etiquette, post them in comments here or email me, and I’ll try to blog them pretty promptly; such posts are easy to do even while I’m on the road.

If you want to follow my travels, you can do so at my personal blog.

When someone with a feminine username joins your community, and you say “OMG a woman on the Internet,” or “jokingly” ask for naked pics, you are being an asshole. You are not being ironic. You are not cracking everyone up. You are the number one reason women are so rare on the Internet.

Check it out.

Here are three I’ve come up with:

Too much information. Geeks tend to over-share about the topics of their own obsessions.

The best is enemy of the good. Geeks often seek perfection, where non-geeks are more prepared to accept “good enough”. Lots of arguments occur around this.

Relevance mismatch. Geeks think some things (eg. how someone dresses) should be irrelevant, and largely disregard them. Non-geeks tend to place greater emphasis on personal grooming and dress codes. Conversely, non-geeks might think that something like desktop operating system is irrelevant, when it’s highly important to geeks. Either group will disregard what they consider “irrelevant”, not realising it’s relevant to the other party.

What other anti-patterns happen when geeks and non-geeks interact?

Firstly, Tim O’Reilly takes on social networking invitation etiquette. As a well known figure in the tech world, he gets more invitations than he knows what to do with. Which ones make it through his barriers and actually get his attention? The ones that take the time to introduce themselves properly and provide a bit of context.

Next, Nat Torkington talks about mailing list failure modes. At O’Reilly, mailing lists grow until they are no longer useful, and then a new one starts. Is this common everywhere? Nat links to this post on hottubbing, a technique for killing an overgrown list and letting a new one rise, phoenix-like, from its ashes.

And finally, Tim writes about the upcoming EFF Web 2.0 Compliance Bootcamp, a day of classes for people working on the coal front of Web 2.0 and trying to deal with the legal and customer service issues that arise when your business model is all about people. It’ll cover topics like harrassment, fair use, porn, and anonymity. I’m assuming that it’s an attempt to head off problems like those recently experienced on LiveJournal, where communications about account suspensions were handled poorly. Good to see that the EFF is helping these companies address such a tricky subject.

Why do software projects fail? It’s an interesting question because fail they do, and with disturbing frequency. Over the years I have seen projects fail for lack of hardware, because the technology just wasn’t ready, or because a supplier didn’t deliver. But the single most common thing that all of the software disasters that I have been involved in (other than me I suppose) was a failure of communication. Fred just couldn’t get his objections to this or that design across to Sally, who when ahead with it anyway. Sally couldn’t manage to convince George that the installation was just not going to work. And nobody thought that that bug was their problem.

As techies we tend to think that communication is someone else’s problem—just tell me what to code and get out of the way. Maybe in some world that will work out, but in this one the best way to ensure that your hard work will turn into a large black smoking hole in the ground is to think of communications as the manager’s problem. Part of your responsibility when you are
a member of a software project is to help with the driving and the only way you can do that is to get your ideas and opinions across to others along with really listening to them. If you ignore that responsibility then you shouldn’t be surprised if your project ends up wrapped around a tree.

With that happy picture firmly in mind, let me suggest five ways that you might ease the journey of your brilliant thoughts out to the rest of your team—and perhaps insure that other people’s ideas occasionally find their way to you.

5) Optimize

I am often called upon to speed up code. Over the years I have revved up printer drivers, database software and, most recently, web services. And I have learned that everyone loves a good optimization project. Get involved in one and you will be the most popular guy (or gal) on the hallway. I’ve had people stop me in on my way to lunch to explain how I can save TWELVE, many even THIRTEEN bytes by completely rewriting the caching system. Or make the code run 0.000353 milliseconds faster by going around the OS. Lately they want me to write my own (presumably faster) web services stack.

So why is it that we are so enthusiastic about writing efficient code and so lazy about writing efficient English? Why do we have specifications that could be written up in 20 pages struggling to escape from 200 page tomes? Why do we use big words:

"Fred, could you memorialize the stakeholders' inputs?"

When little ones ones will do:

"Fred, could you write down the customer requirements?"

Part of it is that nobody wants to look dumb or lazy and memorializing something in a 200 page document just seems to be harder and more intellectually demanding than simply jotting it down in an email.

Well here is some good news: if you consistently use small, simple words for the concepts that fit well into small, simple words, you will rapidly gain a reputation as an articulate person. And if you manage to boil that 200 page document down to an email you will be beloved by the people who hate reading 200 page documents. Which is everyone.

4) Email is only good for the things that email is good for

Another way that we sometimes communicate badly is by overusing email. Email has a subtle attraction for the mostly introverted folks that make up software projects. With email, I can send this message out and I don’t have to actually interact the other person. I send an email to Fred and with luck he won’t even see it before I’ve gone home for the day. That way I don’t really have to deal with old Fred, who makes me nervous anyway.

The trouble with email is that it is a very narrow communications pipe. Think about it: an email is a static bit of text that you write and send out. The text is all that goes out. Left behind is your facial expression – the big smile that telegraphs that this is a JOKE – and your body language – the tapping foot that says NOW – as well the crack in your voice that says HELP ME! Email also disconnects you from your correspondent in time: you send the message and your recipient will read it some time, perhaps much, later.

Instant messaging is much better for getting across a subtle, confusing or sensitive point. You still can’t see the person at the other end but at least you can interact with him or her in real time. Next in line of immediacy is the phone—I still can’t see you but not only can we interact but I can hear your voice, know if you are laughing or crying, angry or bored. And then there is the oldest person to person technology of all — commonly referred to as ‘talking’ —it involves getting up off your butt and going to
see Fred.

So, if you need to say that you will attend the regularly scheduled meeting, send an email. Got a 200 page spec? Email it. And if you need to leave a paper (or rather electron) trail, then nothing beats email. But if you have something delicate to say, if you need to ask a question that will require a subtle answer, if you need to negotiate anything, then email should be your last choice. Like most things in life, the choice of mediums for your message is a trade-off. You can choose the disconnected but narrow pipe of email. Or you can go for the high bandwidth of an in-person chat at the cost of breaking up your afternoon.
Think about that the next time your fire up Outlook.

3) Don’t clog the channel

One of my current coworkers is a car enthusiast. Whenever the conversation turns to the subject of automobiles you can see him just struggling to hold back a tidal wave of facts and opinions and advice. Sometimes he even manages to keep his enthusiasm in check for up to a full minute before it all comes bursting out. We geeks have a reputation for being shy and reserved, but for most of us our introverted shell can barely contain a roiling, bubbling enthusiasm for AJAX or web services or micro formats whatever the technology or technique of the day is. Anyone who manages to pierce that outer shell had better be wearing eye protection because all of that enthusiasm is liable to come gushing out, broken water main style.

Now don’t get me wrong, I love this kind of enthusiasm. In fact I think that that it is responsible for much of the progress of human civilization. The problem with all of this bubbling enthusiasm is that it tends to have a denial of service kind of effect on other conversations. If you have a tendency towards this kind of verbal explosion, do try to keep yourself in check. At least make sure other people and other subjects can get a word in edgewise. Now speaking of that telescope that I’m building…

2) Make sure you know what you agree on

Henry Kissinger, former US Secretary of State and erstwhile college professor once said that academic disputes were so vicious ”… because the stakes are so small.” I’m not sure if the same is true of software projects, but having some severe nastiness break out on a development project is not really all that unusual.

One of the best ways to prevent a difference of opinion from melting down into a team shattering nuclear accident is to step back and note the things that everyone agrees on. If the argument is over how exactly to optimize that pesky algorithm, see if you can’t get all sides to realize that everyone does really want it to run faster or smaller. If it is one of those “who will do what” kind of disputes, try to get everyone to agree on exactly what needs to be done.

The idea is not to paper over differences but rather to focus all of the attention on the actual difference. When a disagreement does breaks out, people, software folks included, tend to stop listening, to fortify their positions and proceed on the basis that the opposing folks are morons. Since it turns out that morons are actually less common than you might think, it helps to probe around and see where the boundaries of the disagreement are. More times than not you will discover that the argument is over less than you thought. But no matter if your disagreement is over the big picture or the pixels, it is your job to make sure that the argument is as productive as possible. And that means not wasting time yelling about things that no one disputes.

1) Remember that everyone is different

The civilians lump us all together: to the outside would we are all geeks. The thing that the non-geek world misses is is how many different kind of geeks there are. Yes we all share a love of technology, of making things work, of just plain wanting to find out. But there are almost as many ways of being a geek as there are geeks. I’m as much a geek as anyone who ever owned a slide rule but I am the kind of geek that tends to read a technical book from the middle out towards either end. I am a big picture, let me get the outline before you bore me with the details kind of guy.

By contrast, I have a coworker, a certifiable geek who walks around with more technology on his belt than most people will own in a lifetime, who I am sure reads books by starting with the copyright statement and finishing with the price in Canadian dollars on the back cover. We are both geeks, both software engineers, but we have two entirely different operating systems running between our ears.

I have learned that I cannot explain things to my friend the way I need them explained to me. He needs things put to him in enormous and exacting detail, right from the start. Conversely, when he tries to explain things to me I have to keep reminding
him that he needs to give me a feeling for the big picture before diving into the details of subsection 1.1.1.A.i.a.

The point is not that I am some kind of brilliant holistic thinker (though I’m willing to entertain the idea) nor is it that my friend is detail obsessed (though he is, God bless him). The point is that you need to go about explaining things differently to me than to my buddy. When you are talking to him you need to do it in a way that works for him. And whatever that is, it probably won’t work me me.

So there you have it, five ways you can make your project run a little smoother by taking advantage of all of the brainpower. Cause that is what communication is all about.

Russ Olsen is a software architect and writer whose work has been featured on JavaLobby, O’Reilly’s On Java, and the Java Developer Journal website. He writes the Technology As If People Matter blog and is the author of Design Patterns in Ruby which will be published by Addison-Wesley in December, 2007.

My lateral question, should anyone have spare time, is which interface jobs exist between geekdom and the rest of the world? (Or more specifically computer geekdom, as a concentrated nexus of paying geekdom). Which ones are open to people with no programming training?

My first two thoughts are QA and tech writing. Both of these are jobs that are best done by people who can swing both ways. There are also lots of domain-specific roles if you have an interest in one particular area; for instance, if you happened to have a qualification as a librarian, you could look for work around the edges of library IT, or with a company that’s doing something library-like (eg. LibraryThing), where the technical team might need to have someone around who knows the non-tech stuff and can explain it the right way.

But I’d like to open this up to everyone else and see what else might be suggested. Readers, over to you!