(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Tuesday, November 06, 2007
  Off topic: Advice

Most of you can shrug your shoulders at the following piece of advice. If, for some reason, it strikes you as novel, please pay close attention. And after thinking things through, if it doesn’t seem to be a nearly infallible rule, a dictum to follow 99% of the time, please, please, please talk to your closest friends and family, people who care about your well-being, before you deliberately go against what I’m about to say:

Do not publish the content of private—as in one-on-one—conversations, meetings, IMs, or emails—without consent in advance from the other party involved. It will mark you forever as someone who cannot be trusted.

You may think “Oh I don’t care if I make that person angry, I don’t like them.” However, you are not just burning your bridge with that person, you are wearing a sign around your neck warning everyone else who meets you that they run the serious risk of having their laundry—dirty or clean—aired out in your memoirs, at your local pub, or worst of all on your blog.

Do not publish the content of private conversations, meetings, IMs, or emails without consent in advance from the other party involved. It will mark you forever as someone who cannot be trusted.

I saw a variation of this malfeasance recently. Giles Bowkett wrote something that—for some reason—inflamed and outraged people. I will say immediately that although I didn’t agree with the literal premise of his post, I found it interesting, and hardly on the scale of an insult against my family. I did not rush to my keyboard to accuse him of heresies and poll my readership for the most appropriate wood to use for his immolation.

However, some people jumped into the flame storm with both feet. Fine. One such person had worked at the same company as Giles for some period of time, and saw fit to air his opinion of Giles’ talents on a public site, describing workplace incidents in the process. Were I the critic’s employer, I would ask that person to step into the conference room, bearing with them their employment contract and a match. They simply cannot be trusted.

People discuss their work. They criticize their colleagues. But the rule is that you do not “name names” from the office. At least, you do not name names until your career is at an end and you are dictating your tell-all memoirs to a ghost-writer. Should you choose to name names before then, do not be surprised if you find yourself prematurely retired. Even if everybody at the company shared your opinion, they will now worry that theirs will be the next name plastered over the Internet.

Notice that this is very different from writing a comment or blog post saying, “raganwald is an idiot, here is why.” Fire away, especially if you are criticizing publicly available information: So-and-so wrote this blog post, such-and-such a company released this terrible product.

But when you criticize colleagues—current or former—you run the risk of disclosing confidential information about your employer, about other colleagues, about clients… It is very difficult to discuss the workplace in a public forum without betraying a confidence of some sort.

I am not preaching from a pristine pulpit. I have, in my life, broken trusts. I regret these expressions of weak character to this day. And I don’t mean the mealy-mouth regretting the consequences, I mean I regret my own weaknesses deeply and with a pain that time does not lessen.

Consider this questionable choice on my part: The Interviewee’s Perspective. Now I did not name names. But all the same, if you were considering working with me or interviewing me, would you hesitate for a fraction of a second after reading this? Even if you sympathize with my plight as an interviewee, would you worry that somehow what transpires between us will end up on my weblog?

I was going to remove The Interviewee’s Perspective, however I am leaving it up as a warning to myself and as an example of what not to do.

Do not make this kind of mistake in your own life. No matter what your walk of life, rich, poor, popular, unpopular, smart, so-so: being trustworthy is a quality of character that everyone can and should cultivate. Do not discuss private conversations. Do not air workplace laundry.

Do not squander the trust of others.

Comments on “Off topic: Advice:
you should not remove this post
Great Post . i have been both guilty & Target of same in past . i can understand your point . but i guess its human to break down in Heat .
I will follow your advice :)
Thanks for the great piece of advice, I committed this mistake less than a week ago, now I'll try to make ammends by spreading your post to as many people I can, keep the great posts coming...
Actually it was two people. One identified himself and the other didn't. From the "workplace incident" I think I can tell who it is, and I think they came from the same company, but I'm not sure, so now I'm kind of leery about everyone who might have been there, which is really a terrible thing. When you're naming names, you have to name your own name.

But I actually disagree on some points. Firstly because exposing hypocrisy involves naming names, and there are sometimes very good reasons to highlight a contrast between what somebody says in public and does in private. (or vice versa.) Secondly because the criticisms didn't sting. I post code for all the world to see all the time. I get dissed by these guys, but I also get credit from very credible people from time to time. I'm constantly amazed at conferences when I find out who reads my blog. I'm not going to drag anybody into this, but you get respect from heavyweights and you get dissed by some guy who used to be your roommate for about three months, the heavyweight's opinion carries more weight, by definition. It really just makes you question the other guy's ability to recognize good code.

I think you're right. Those kind of aggressive comments definitely burn bridges. I systematically blocked the guy who identified himself from communicating with me ever again in any form. But I think taking it too seriously is a mistake too.

If anything, it's a powerful reason to blog and release code. Otherwise, you risk having your reputation ruined because you stole somebody's cheese from the fridge one too many times.
Could you tell us what company it was, so we can avoid applying there? But seriously, interviewers seem to forget sometimes that both parties are under scrutiny. You didn't name names, though. Maybe if you had just written up the experience more abstractly as 'how not to conduct an interview' the trust issue wouldn't exist.
Secondly because the criticisms didn't sting.

I'm glad to hear it. But ah, that wasn't my point. My point is that if I ever meet the person who talked about you in the workplace, I would be leery of working with them myself.

I would constantly be wondering, "is what I'm writing in this email going to end up on a programming forum?"

There's a certain expectation of confidentiality in the workplace. Breaking it in a way that names names weakens the whole thing, even if the "victim" is too much of a man to be bothered.
I've made this mistake re: an evening out with the guys one night, then blogging about it the next day.

In retrospect it was totally stupid of me.

I see articles about companies and future employers digging through potential hire's archives on blogs, social networking sites, etc. to find any dirt on them.

To live one's whole life in fear of this far-flung threat, just smacks of quiet desperation to me. But I know not everyone feels that way.

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /