You Can't Win an Argument

I hate arguing.  Actually, I feel that if a discussion gets to the point of becoming an argument, I've already lost.  Or, more accurately, both sides have already lost.

I could never quite articulate why I felt that way, but now I think I can.  And I have Dale Carnegie to thank for that:

Nine times out of ten, an argument ends with each of the contestants more firmly convinced than ever that he is absolutely right.  

You can't win an argument.  You can't because if you lose it, you lose it; and if you win it, you lose it.  Why?  Well, supposed you triumph over the other man and shoot his argument full of holes... Then what?  You will feel fine.  But what about him?  You have made him feel inferior.  You have hurt his pride.  He will resent your triumph.  And- 

A man convinced against his will 

Is of the same opinion still.

Ben Franklin illustrates it with this trade-off:

If you argue and rankle and contradict, you may achieve a victory sometimes; but it will be an empty victory because you will never get your opponent's good will.

So figure it out for yourself.  Which would you rather have: an academic, theatrical victory or a person's good will?  You can seldom have both.

Lincoln chimes in with what to do instead of arguing:

No man who is resolved to make the most of himself can spare time for personal contention, still less can he afford to take the consequences, including the vitiation of his temper and the loss of self control.  Yield to larger things to which you show no more than equal rights, and yield to lesser ones though clearly your own.  Better give your path to a dog, than be bitten by him in contesting for the right.  Not even killing the dog will cure the bite.

As Dale says, will proving someone wrong make him want to agree with you?  Of course not!  You just made him hurt and angry.  In other words, you've evoked emotions.  Negative ones.  And once those are in play, all the reason and logic in the world won't do any good.

Don't Roll Your Eyes

"[John] Gottman has proven something remarkable.  If he analyzes an hour of a husband and wife talking, he can predict with 95 percent accuracy whether that couple will still be married fifteen years later."  - Malcom Gladwell, Blink.

How does he do it?  By looking at the microexpressions on their faces while they have meaningful communication.  Each expression conveys an emotion or attitude.  The "Four Horsemen" of negative emotion are: defensiveness, stonewalling, criticism, and contempt.  But within those four, the king is contempt.  Contempt is the single strongest indication that a marriage is in trouble.

A disagreement, even criticism, can be discussed rationally and worked through.  But contempt is putting the other person on a lower plane than you.  It is immediately discounting what they are saying for no other reason than because you feel superior to them.  That is detrimental.

So what is the facial expression that indicates contempt?  You guessed it: eye-rolling.





  

How to Ask for Feedback... or Any Favor

I don't remember much about 7th grade. But I do remember one time when I asked some of my classmates to help me fold sheets of paper to be passed to the rest of the class. I offered [what I considered] a tip as to how to do it more efficiently.  But the response I got was, "When you ask someone do to you a favor, don't then ask them to do it faster."

Now, when we ask someone to give us feedback, we're really asking them to do us a favor. We want to improve whatever it is we're asking for feedback on and thus by providing it, they are helping us. So if they are already going to this effort to help us, we really shouldn't ask more from them than necessary. In fact, we should make it as easy as possible for them to help us.

Probably the most common mechanism for providing feedback today is the survey. Someone buys a product, uses a service, attends a class, etc and then fills out a feedback survey about it.

We can see the same thing with software and websites. There is often a form or something that vendors use to gauge the user experience of their digital product. I posit that such a mechanism tries the patience and goodwill of users. It makes them have to go out of their way - do extra work - to do a favor for the vendor. So some vendors offer small rewards for filling out these surveys, in recognition of this fact.

But I think we can do better. Consider this juvenile, but brilliant, example:

Why do I say this is brilliant? It takes something the user has to do anyway, and turns it into a feedback mechanism. The user doesn't have to do any extra work or go out of his way at all. He just does his normal business (heh) and has no choice but to provide feedback in the process. 

I just checked and apparently it's no longer there, but Skype used to be a good example of this. You would make a call (over the internet) and when the call was over, you would have to close the 'call' window. But the only way to close it was to click a button that gave feedback on the quality of the call. Now, you have to close that window anyway. So it's no extra work for me to provide feedback while I do it. It's not intrusive. It's convenient.

This is the kind of mechanism we should be using more with software. Users are using it anyway, why not build in ways to gather feedback that don't disrupt their workflow?

I, personally, am more than happy to provide feedback to software companies if that process doesn't get in my way. For example, I always check the 'send anonymous usage statistics to the vendor' box when I install a program. I'm happy to help in making the software better, as long as it doesn't inconvenience me.

Granted, we may not be able to do this for every kind of feedback. But I feel there is a huge amount of data that we are missing out on because we just make it too hard for people to give it to us. We could be making our products and services a whole lot better... we just have to be a little creative in how we ask for feedback.

Goals Are for Losers

Scott Adams, creator of Dilbert, discusses why systems are better than goals.

Hint: it's because systems allow for - and in fact, are improved by - failure.

http://online.wsj.com/news/articles/SB10001424052702304626104579121813075903866

I Love Limitations in Programming Languages

I'm not being sarcastic! I really do love them. Here's the thing:

Writing code is a very free-form exercise. Each developer has their own style, there are usually many ways of accomplishing the same task, and everyone has their own idea of what 'pretty' or 'clean' code looks like. The computer, of course, doesn't care. It just cares that, basically, there is some code. It finds this 'some code' and it happily compiles or interprets it.

Humans, however, care about more than that. At the most fundamental level, humans care about understanding what the code is doing. (At least, they should!) Now, what is easier to understand: one thing or 100 things? I hope you said one thing.

And this is exactly my point: If the language only provides one way of doing something, it makes it easier for every other developer to understand what the code is doing. If the language provides 100 ways of doing the same thing, well, then every developer has to know all 100 ways.

So some might look at that language that only provides one way as very limiting. "There's only one way! Psshaww!" But I look at that language and say "That's so easy to understand!" I love those kinds of limitations because they make things easier. And I love easy.

Now, if the designers of the language were clever, they will make it such that the one way happens to be the best way. In other words, they build the best practice into the language and don't allow you to (or at least, make it difficult for you to) deviate from it. In this case, I really love the limitations! Because when you learn the language, you're also learning the best practice by default! And it becomes very hard to do it the wrong way.

Let's pause for a quick example. I really enjoy the C# programming language for this reason.  C#, like C++, is object-oriented. But unlike C++, everything in C# is an object. Is that a limitation? Yes: everything has to be an object. Does it help? Yes: you only need to know one way to treat everything (like an object).

Critics of C# would say that this business of everything being an object makes the code more verbose. And I agree. But you know what? I like verbosity too!

Recently, there has been a push for more concise programming languages. Quite frankly, I think this is misguided. Remember, a human's foremost concern should be understanding the code. Code will be read (and hopefully, understood) many more times than it will be written. So emphasis should be placed on ease of understanding, not ease of writing.

Another example. C# has a method called "ToString". Ruby has a method called "to_s". If you have never programmed in C# or Ruby before, which of those two method names do you think would be clearer?

"But," some may say, "if you are calling the method many times, those extra characters add up to a lot of extra development time!" This is wrong for several reasons.

The first reason is Intellisense or other code-completion tools. Rarely do you have to type every character in a language like C#. The IDE makes intelligent guesses as to what you are about to type and gives very accurate completion options.

The second reason is that the actual typing of your code should probably be a small portion of your development activity. Hopefully, you spend more time thinking and designing than you do typing.

The third reason is that, as mentioned above, code will be read more often than it is written. So speeding up the reading [ie. understanding] of code should take precedence. Granted, anyone experienced in the language will understand the built-in abbreviated method names. But those shortcuts create a sort of 'culture of obfuscation.' Developers will follow that same standard in code they write and then the whole code base becomes difficult to understand. True, a language like C# has a 'culture of long method names,' which may look silly. But silly or not, I don't have to guess at what they do. And that is what matters to me.

To sum it up, limitations make it hard[er] to write bad code. And limitations + verbosity makes your code easier to understand - both by yourself and others. So why the push for more free-form, concise languages? I really don't know. I will say that if a language can be more concise, without sacrificing understandability, that's great! But I do know that I'd rather read Java over Perl any day of the week.