Nathan Fillion, aka Captain Mal “Tightpants” Reynolds of the Joss Whedon TV show Firefly, has posted in his blog about airplane etiquette:

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.

The ever-entertaining Rands has just posted his Nerd Handbook.

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?

Not quite on the etiquette subject, but I was hoping some of you lovely people could help out with another project of mine.

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?)

I’m going off on international travels with potentially patchy net access for the next two months. No, seriously. I’ll be spending some time in a developing country, and some time in a yacht at sea, and, OK, some time in San Francisco where I presume the net access will be better, but that’s only for a few days.

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.

Web comic xkcd takes on sexist morons in the geek community:

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.

So, I’d like to open up a bit of discussion here. What are some of the anti-patterns that are commonly seen when geeks and non-geeks interact?

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?

I’m a few days behind in my RSS feeds, but today while reading O’Reilly Radar it seemed like there was a run of articles of relevance to the subject of Geek Etiquette.

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.

This is a guest post from Russ Olsen, who blogs at Technology as if People Matter. I must admit that I’ve forgotten how I first came across his blog, but when I did, I pretty quickly emailed him and asked if he’d be interested in writing for Geek Etiquette. Now I’m happy to present Russ’s take on how communication skills can make your software projects more effective.

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.

Tiffany asked the following question in the comments to my earlier post about Michael Schwern’s Geek2Geek Communications talk:

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!

I’m at BarCampBlock so there’s going to be a bit of a change in format here while I liveblog Michael Schwern’s talk, “Geek to Geek: how we fail, how to fix it.”

What’s this talk about?

• We’re good at computer science and bad at people
• We have certain patterns of failure and certain ways to fix those
• Schwern is especially looking at mailing lists and bug reports
  • Mailing lists are where we mostly talk to each other
  • Bug reports are where we ask each other to do things, and where we start to interact with “real” users
• There’s no existing clearinghouse for this information
• Schwern completely missed GeekEtiquette! So what other resources are out there? The conversation is open.

Going round the circle, people introduced themselves and talked about why they’re interested in g2g communications.

• geek communities like IRC, how to avoid toxicity
• internal technical documentation (person who raised this works at Google)
• interfacing with business/sales people
• QA and bug reports and how to smooth the process

Literalist fuckheads

So, let’s look at what geeks are like. In general, we’re:

• analytical
• literal
• very direct
• truthful - academic purity
• aggressive

Schwern gives a quick anecdote about what he calls “Literalist fuckhead mode”. When he arrived at BarCamp, he ran into someone and said, “Excuse me”. The other geek said “No.” “Huh?” said Schwern. “Oh, i just like to screw around with the social conventions,” said the geek.

That’s a geek fallacy right there — the idea that the social niceties must be questioned. Words aren’t necessarily meant to be taken completely literally, they’re communicating something else: respect, etc. (We come back to this later when talking about Tact Filters.)

So, on the subject of literalism, Pete K raises the sort of communications you see with literalist/geek kids:

Parent: “Could you get the stuff from the car?”
Kid: “Yes.” (You didn’t ask me to actually do it, just whether I could.)

Parent: “Why didn’t you get the stuff out of the car?” (Rhetorical question, intended as a prompt/reminder.)
Kid: “Because… blah blah blah.” (Responds to literal question.)

Sometimes when kids do this it’s just because they simply parse things literally and honestly don’t realise the social conventions. In other cases (one participant pointed out) it’s because they’re being annoying on purpose. The “excuse me” literalist was probably in the second category.

Is it time to get past our Aspergers’ issues?

All this — the list of geek attributes — is low-level aspergers stuff. That puts a label on it but doesn’t actually help us communicate and get stuff done.

There are a lot of people here — in the session and in the wider geek community — who have a feeling that “something is wrong”.

At OSCON they had a “people” track and Schwern wasn’t the only one talking about this. Lots of people are realising there’s a communication problem but don’t know how to deal with it.

Well, says Schwern, we’re smart and analytical. If we can find out what the problem is, we can try and figure out what it is and how to fix it. So for now, let’s try and identify the anti-patterns in geek communication.

The problems of textual communications

One common problem with g2g communications: text. I can’t even demonstrate schwern’s “fuck you” act here because it had lots of non-verbal components. ASCII has no context. ASCII has no empathy.

We have emoticons and actually they sort of help. But aren’t emoticons a band-aid for unclear conversation? People who write professionally feel that emoticons are a sellout, because you should’ve expressed yourself more clearly in the text itself. Geeks sometimes like emoticons because they achieve the same effect as a paragraph of words in 2-3 ASCII characters.

Besides, we don’t write like pro writers, crafting our words to perfectly express our meaning; instead we transcribe what we’d say out loud, and we type fast and don’t stop to think.

In email, some of us suffer from “Me too” damage after years on Usenet. We don’t like to reply unless we’ve got something substantial to say. But this can lead to Warnock’s Dilemma:

The problem with no response is that there are five possible interpretations:

1. The post is correct, well-written information that needs no follow-up commentary. There’s nothing more to say except “Yeah, what he said.”
2. The post is complete and utter nonsense, and no one wants to waste the energy or bandwidth to even point this out.
3. No one read the post, for whatever reason.
4. No one understood the post, but won’t ask for clarification, for whatever reason.
5. No one cares about the post, for whatever reason.

The Apache project gets round this using a +1 / 0 / -1 voting mechanism; a quick response saying “+1″ means “I read this and agree,” -1 means “I read this and disagree”, and 0 means “I read this but don’t have any particular opinion.” This works well if everyone understands, but if you start doing it at random on a new mailing list it might cause some confusion.

Instant messaging

Sometimes IM is a better communication method than email. Even though it’s text, it provides some non-verbal cues. For instance, interjections, time delays, and notifications that the other party is typing can all provide additional context.

“I’m better in text because I can backspace, delete, etc.”

“Backspace only works until you hit return.”

One common IM/IRC problem is people who ask you if they can ask a question. Ask-to-ask is a mainstream cultural behaviour that appears polite in most circles, but geeks find it inefficient. On #perl on IRC there used to be a bot that would reply to anyone who asked to ask. Ask-to-ask is an outbound tact filter.

Tact filters

Most non-geeks have outbound tact filters: they filter what they want to say and add polite noise as it passes through. Geeks have inbound tact filters: they take bare communication with no politeness and just wrap it in assumed politeness as they interpret it.

When non-geeks talk, geeks think the polite sounds they make are redundant.

When geeks talk, non-geeks just think they’re being incredibly rude.

Pete’s son at age 6 went through a period of hating tact words (please, thank you, etc) and wouldn’t say them and got upset when people said them.

Tact filters in email

Schwern and I both recently started using email salutations/endings as outbound tact filters. Typical geek email doesn’t have saltuations/closings, but now we’re saying “Hi, Stan,” and “All the best” and the like.

I got this stuff from Send: The Essential Guide to Email Etiquette which I described as “the geek’s guide to email camoflage”. Mostly it’s aimed at business people and doesn’t fit geek communication styles, but it does help you get a feeling for what non-geeks are expecting.

Many people talked about “mirroring” with email and outbound tact filters in general: observe what the other party says, and say the same thing back: if they say “Hi, Bob” then you reply with “Hi, Alan.” If you are initiating the conversation, though, you can’t mirror. So you need to have a mental profile of the type of person you’re talking to, and think about what they’d be expecting.

Isn’t that kinda phony?

Is camoflaging or using outbound tact filters being “phony” or somehow untruthful? Typically, if geeks don’t mean something then they don’t want to say it. But building rapport doesn’t actually change who I am. In fact, literalist fuckhead mode can be a form of lying, by blatantly ignoring the non-verbal signals.

Let’s get back to g2g

Schwern tries to get the conversation back onto the subject of g2g communications rather than g2other… with only limited success.

Ken says: what we really ought to be talking about is Aspergers Syndrome. A type of high-functioning autism, aka Geek Syndrome (c.f. Wired).

But is Asperger’s really a disorder? Is treating it that way just “pathologising the other”? US culture seems to love medicalising this stuff and medicating it. (NB: that comment was from me, speaking from an Australian perspective.)

Other people had discomfort with geek/non-geek duality: we live on a continuum depending on what we’re doing at any given time. Some people have geekish tendencies not related to code: music geeks, theatre geeks, etc.

“I like urban planning a *lot*.”

“I think we’ve forgotten it comes from the whole biting-the-head-off-chickens thing.”

“Are we still allowed to look down on those people?”

Other frameworks

One attendee suggests other frameworks to look at: dating advice, relationship books, books about interpersonal communications. All these might provide perspectives outside of the autism-spectrum discussion.

Geek girlfriends vs non-geek girlfriends. Who here primarily dates geeks? About half. Various personal opinions on how they find it easier to communicate with geek girlfriends/boyfriends.

On empathy

Two components to empathy: wanting to communicate with other people and wanting to talk and listen; and understanding that not everyone is the same, and need to be profiled individually rather than as a member of a set.

“Was there a point where you realised that not everyone else was an idiot, they just didn’t know the things you knew?”

“What? They’re not idiots?”

The thing is they just have a different set of domain specific knowledge. We privilege our own knowledge set. But presumably business and marketing people have their own DSK too. When you get geeks and business people together they don’t understand and don’t care about each other’s DSK. Then each party tries to show off how smart they are by showing off their own DSK and they completely miss each other.

The wrap-up

Schwern’s set up a mailing list to discuss this: g2g@schwerniverse.com

“It’s a mailman list and I’ll just assume you guys know how to deal with that.”

Finis.

Up or down?

Logic dictates that you leave it the way you like it. If everyone did that, then the toilet seat would be in each user’s preferred position in proportion to their frequency of use.

As usual, logic and etiquette only have the faintest connection. There are any number of arguments I could give for why you should leave the seat down — from midnight surprises to the visibility of splashbacks — but in fact, the only real reason is convention. If you leave the seat up, in any toilet facility that a woman may use, then you’ll be considered uncivilised… even if it’s illogical.

Merlin Mann of geek productivity fame asks, What’s your best “best practice” for email?

The Dress Code Guide answers all your questions about dress codes from White Tie to Casual… as long as you’re in North America or the British Commonwealth.

Lifehack talks about How to exit a conversation.

Web Worker Daily teaches us How to network like a human, not a computer.

And these three on a related theme:

• CNN: Where are your high tech manners?
• CNN: Hey you, with the iPod! Keep it down!
• New York Observer: The Laptop who came to dinner
  

Just wanted to mention that I’m travelling at the moment, which is why the posting schedule here is a bit patchy. I’m in San Francisco, playing tourist and geeking out a lot. Are there any GE regulars in town? Drop me a line if you’d like to meet up. Meanwhile, I’m blogging my travels over at my personal blog, if you’d care to follow along.

I was thinking the other day about coding standards, and what’s considered good coding practice. Let’s consider a handful of examples:

• neatly laid-out code (indentation, line length, etc)
• informative variable names
• inline documentation/comments

When we work in coding teams we tend to hammer this into people. Most software projects have a “house style” of some sort, to which all contributors are expected to adhere. Newcomers sometimes take some convincing, but most get there in the end.

We usually say that we have coding standards and style guides because it improves code quality, or makes the software easier to maintain. That’s certainly true. But it occurred to me a while ago that coding standards are also a matter of etiquette.

By conforming to a coding standard, we smooth our interactions with the rest of the team.

That one guy who always uses tab characters, or names his variables LikeThis instead of like_this, isn’t just making the code worse; he’s driving everyone else nuts with his rudeness.

Years ago — it must have been the late 90s or thereabouts — I thought I heard something about RMS getting kicked off a plane for refusing to turn off his mobile phone. Unfortunately Google isn’t giving me much love on the subject, so perhaps I just hallucinated it. Maybe it was some other free software/open source big-name. Whatever the case, it’s easy to imagine: a logical, scientifically-minded geek who’s convinced that cellphones don’t affect aircraft systems and is determined to prove the flight staff misguided and incorrect.

There are plenty of insane, illogical things that happen when you travel by air, and every single one of them makes you (well me, anyway) want to set people straight, possibly with the help of a blunt object. Of course, pointing out to a security guard that you could kill someone much more easily by breaking your bottle of duty-free liquor and slitting their throat with the broken glass than by using a set of nail clippers is… well, not too clever, unless you really like spending time in a cell.

Air security is an extreme case, but there are plenty of situations where people or organisations are excrutiatingly stupid and telling them so is a bad idea. What I want to know is, how the hell do you resist it? How do you find a more productive channel for your SMRTness? If I knew the answers to these questions I’m sure I’d be a much nicer person, but in truth I find it very very hard.

Meanwhile, to get you nice and riled up, here’s a link to Bruce Schneier’s blog.

I’m off to the USA soon: land of compulsory tipping. Every time I go to a country that tips, I’m reminded of the interminable arguments I used to see on Usenet on the subject. You see, tipping is an artifact of a culture which does not pay waitstaff a living wage, and by tipping you’re propping up a broken system, and if everyone just stopped tipping then employers would be forced to pay, blah blah blah.

Here’s the etiquette of tipping: If you’re visiting a culture that tips, tip the recommended amount. (If you actually live in a culture that tips, you can move on to advanced topics like tipping above or below the recommended amount based on service.)

Tipping might be illogical, but the time to debate or protest against it is not when you’re settling up your bill at a restaurant. Save that for Usenet. Or, to be more 21st century about it, your blog. Arguing over tipping in an attempt to avoid paying a tip just makes you look like an asshole. And here at GeekEtiquette, one of our mottos is “It’s better to be POLITE than RIGHT.” OK, I only just made that up, but it’s one of our mottoes now.

Not sure of tipping etiquette in other countries? I usually find that the Lonely Planet series of guidebooks (my personal favourite; I’m not paid by them in any way) give fairly straightforward tipping advice. Or, of course, there are approximately a squillion websites dealing with the subject.

Rude Geek writes:

I recently upset a cafe owner, in retrospect with good reason, for plugging in my laptop without asking.

What is the currently (evolving) etiquette for using someone’s electricity and bandwidth? If I take out my mobile telephone and use someone’s open Wi-Fi network should I ask?

Etiquette would generally suggest that you should never use someone’s stuff without gaining permission. Never ever.

Generally you’ll be looking for explicit permission either in the form of a “Wifi Available” sign or by asking the staff. However — and here’s where I probably part ways with Miss Manners — there’s also implicit permission.

Implicit permission to use power or network connections include:

• Lots of other people around you doing so without getting in any apparent trouble
• Being in a hotel, convention centre, or similar venue
• Being in an airport or other major transport hub

Those are the only implicitly safe places I can think of to plug in a phone charger or use any open wifi you might find. Can anyone think of others?

Other than that, if you don’t have implicit or explicit permission, you should ask first.

We’ve talked about how to quit before, but let’s look a bit closer at reasons for quitting, and what to say about them.

Presumably if you’ve handed in your notice, you’ve got a reason for it. Sometimes your reason is innocuous and inoffensive:

• Got offered something much higher paying.
• Relocating for personal reasons.
• Pursuing further studies.

And sometimes your reason is… less innocuous:

• Co-workers are assholes and/or morons.
• Management are assholes and/or morons.
• The job just sucks.

If you’ve got a Type A reason on your hands, your life is easy. If you’ve got a Type B, however, you’ve got some tricky moves ahead of you. The vital point is: Try not to burn too many bridges. Or, ideally, don’t burn any.

The asshole you’re escaping today might be the hiring manager at a later job. Or might just be playing golf with the hiring manager at a later job. Or you might need a reference from him. Or — more likely — any negative feelings will just suffuse randomly through the web of faint connections that is the tech industry, and people will have a vaguely bad feeling about you without knowing why.

So, you don’t want to leave on a sour note. If possible, you want everything to be amicable, and for your ex-boss to provide you with a positive — if not positively glowing — reference. But how do you do that if you hate your job, or the people you work with are assholes/morons? Here’s my advice: Treat it like a relationship break-up.

Key phrase: “It’s not about you, it’s about me.”

Don’t say: All the other programmers are assholes.
Try this instead: I don’t think this team culture is right for me.

Don’t say: You’re making us work on laughably obsolete technology.
Try this instead: I’m looking for opportunities to increase my skills.

Don’t say: Working with this legacy code is like kicking dead whales down a beach.
Try this instead: I don’t feel like I’m achieving much here.

Of course, you need to balance your “I feel…” talk with your own personal comfort levels. I’m not saying to lie about your reasons for leaving. I’m just saying, if you can’t resist saying something, try not to be too confrontational about it.

Plenty of people will tell you never to say anything about your reasons for leaving, especially not in your resignation letter or an exit interview. The theory is that nothing good can ever come of it. Companies routinely ignore criticisms expressed by staff who’ve quit, and let’s face it, if they didn’t listen to you before you left, why would they listen now?

Me, I prefer to face up to reality. You can’t see out your 2-4 weeks’ notice in complete silence. Chances are you’ve got some friends at the office, or even get along quite well with your boss, and your urge is to want to communicate with them. So I say, go for it. Just tone down any negatives as much as you can, pad them amply with positives, and don’t put anything nasty in writing.