Random

Customers judge the quality of customer service based on their expectations. So, in order to offer poor customer service, fail to meet to your customer's expectations.

Let me share with you the worst customer experince I have had recently:

I purchased something with a credit card Wednesday morning. What I purchased is irrelevant. I've purchased the same product before with that card.

This time around, something about this transaction was flagged by the credit card company. I came home to a message from their fraud prevention service asking for me to return the call as soon as possible. It was an automated message, complete with taped voice and a low quality speech synthesizer mixed in where the information differed between calls. Given the nature of the call, this didn't surprise me.

So I call the number that was left on the answering machine. I navigate through a bunch of options to verify the card in question. Then I am given information about the charge and asked to push a button on the keypad to indicate whether or not the transaction was authorized. Since it was, I pressed the appropriate button and the process ended after another canned speech.

The entire process took a couple minutes and was entirely between me and this computer on the other end.

There was nothing horrible about the steps in the process. If anything, the process was too streamlined. "Press one if this is the phone number on the information for the credit card." "Press one if you are the cardholder." "Press two if this is an authorized transaction."

What bothered me most about the process was that it was completely automated. At no point did I interact with a person. During the process, I expected to interact with a real person. Every other call I have made to a credit card company has featured a real person at some point. (The only exception has been when I called to my balance which I haven't done for at least seven years.) I expected to need to say "Yea, verily, this was an authorized transaction" while talking to an operator and being recorded. If nothing else, this would cover the credit card company in case of legal issues. Instead, I got the computer.

My expectation was that I would deal with a real person at some point. At some point in the process, my identity would have been challenged and I would have needed to present a recorded statement. What I received failed to meet these expectations. As a result, I feel that the customer service experience was poor. Further, because the perceived quality of service was so poor, I am inclined to regard the company poorly. Since my identity was never challenged, what's to stop my roommate from "borrowing" that card, purchasing things, and then dealing with the fraud prevention hotline himself before I even find out about it? I come away from the experience feeling that the fraud prevention hotline is just a fake system they have set up to make their customers feel good.

If I had dealt with a real person at some point, my expectations would have been met. Even if it were a mediocre experience with that person, I would still have had my expectations met and I would have come away regarding it as sufficient customer service. However, with no interaction at all, they failed to meet my expectations and I regard the customer service as being poor.

(In defense of the credit card company's system, if this had been about an actual fraudulent transaction, I'm sure I'd feel differently because my set of expectations would have been different.)

I have been rereading Thomas Limoncelli's Time Management for System Administrators. One of the points Limoncelli makes is: "[P]sychologists tell us that it takes 21 days of doing a new behavior to develop it into a habit." Give or take a few days, of course.

Test-driven development (TDD) is something I keep revisiting. I have Kent Beck's book on the subject and have read it at least twice. I have tried doing TDD on at least four separate occasions but I seem to stop usually a few hours or a day into the process.

Mark Mzyk wrote of having similar issues with TDD. I disagree with his statement that the issue with TDD is a lack of experience. Instead, I think it has to do with a lack of practice. If you don't do it consistently for any length of time, say three weeks, you're not going to adhere to it. If you follow it, even if not deliberately, you eventually find yourself, as Peter Harkins put it, "drifting into test-driven development."

I think it's kind of like learning to touch-type properly. It's painful and difficult and slow now because I lack experience. As I said before, I spend time actively thinking about which finger should be used to press which key. However, even just a few days into it, I find I spend less time thinking about it.

"How can I practice TDD?" I ask myself. Well, my big thing recently has been problems from Project Euler. I can use it there!

Most of the problems from Project Euler provide a sample test case. For example, problem 1 states:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.

Find the sum of all the multiples of 3 or 5 below 1000.

From this, I know that we are solving for the sum of all multiples of 3 or 5 below 1000. We also know that the sum of all such multiples below 10 is 23. This means that I can set up a test script:

Running it complains that it can't find a file for euler1. After touching euler1.rb, it complains that there is no method euler1. And after each new error, more changes are made until, eventually, euler1.rb looks like:

and the test passes. This obviously won't answer the question correctly but doing this proves that the unit testing framework works. It also proves that it considers 23 to be equal to 23 which indicates that there are no silly math errors in the language interpreter, at least at this point. From here, I know I can implement an algorithm and as long as it meets the given criteria, the test should pass. If I'm uncertain about this, I can find other points to test as well. The values for any given n up to 58 are listed in sequence A126592 at The On-Line Encyclopedia of Integer Sequences.

Since this process appears to work for one problem, it should work for all of them. I'll try it and see how it goes.

My dirty secret (well, not secret much longer) is that I don't touch-type in a traditional sense. I do type reasonably fast and I do type with more than two fingers but it's not touch-typing. I don't follow the standard home row method that is taught in typing classes everywhere.

I've had plenty of chances to learn how to touch type and, to be honest, I squandered them. I'm certain that some of my teachers throughout middle and high school would love to hear that, fifteen to twenty years too late.

The issues I have with my typing, compared with normal touch-typing, is that I have a comparatively lower (but not significantly so) accuracy rate and sometimes I find myself looking at the keyboard.

Jeff Atwood states "We are typists first, programmers second." This is true for system administrators as well, although perhaps less so for those who work solely in a Windows environment.

I used to say "Well, I type well enough, right?" However, Steve Yegge says "If you have two hands, then 70 wpm, error-free, is easily within your reach." And while I might have 70+ wpm, I'm certainly not error-free.

What most people don't realize is that typing errors cost. As if to underline my point, I made an error when typing that sentence. I originally typed "that typiung er" and then I noticed, backspaced back, fixed it to say "that typing" and went on with the rest of the sentence. Fixing errors breaks flow and costs keystrokes. It cost six keystrokes to backspace and remove the error and then five keystrokes to retype what I had erased. (I could have kept the cost to eight keystrokes if I'd been paying attention: Left arrow 6, delete 1, end 1.) Eleven keystrokes is more than a word and possibly might be counted as two by most wpm counters.

If I can improve, it behooves me to do so.

Since I was waiting for something to finish running in the background, I decided to practice for a bit. I loaded the TI-99/4A emulator and started the Touch Typing Tutor cartridge. Touch-typing has not changed significantly over the past thirty years so I figured this should work as well as anything else.

What surprised me most going through even the basic exercises is that I had to think about which key to press. Being asked to type 's' made me have to remember which finger was over the 's' key. As it went on, I was hard-pressed to keep myself from reverting back to my existing habits just so I could finish it. By the end of the second sublesson, my hands hurt although that could have been a posture issue.

Tonight, I'll do the same thing again. Until I'm no longer thinking about which finger to use, I'll keep doing it these sublessons. Then I'll do the next one. And maybe, in the end, I'll have this figured out.

Books are probably my preferred medium of learning. I prefer books to the degree that I chose to look into Ruby last year rather than concentrate on Python because of the availability of good quality Ruby books and a dearth of good Python books.

I know that I prefer books partially because of personal, fluff reasons. I know books. Books have a physical presence. Books are old-fashioned, just like me sometimes.

Books are "offline" resources. If I read something in a book and need to go back to it, I can pick up that book, page to where it was, and reread it. As long as I have physical access to a book, I can find that information at any time, no matter where I am. Computer resources instead rely on the presence of a computer. I tend to forget to bring my aging laptop with me so I can't rely on that. Internet resources rely on being connected to the internet, which is not likely in some circumstances, such as on a train.

Books are "permanent" resources. Barring physical destruction, a book is going to last a reasonably long time. Texts dating back at least a millenium are known to still be usable and readable (assuming you understand the language). Internet resources are, by comparison, "transient." A web page that you look at today may not be available tomorrow. The site maintainer could take the site offline. The author could delete the page. The page could be moved as part of a site reorganization and the maintainer could fail to put redirects in place to send visitors to the new location.

Books are more useful to me than web browsers for accessing many things at once. However, this is likely because I only have a single screen for development. If I had multiple monitors (two, or even Jeff Atwood's three), this may not be as much of an issue.

Books have their drawbacks too. They're heavy so they're not really portable. I think two decent-sized books (thinking the hardback first edition of W. Richard Stevens' Advanced Programming in the UNIX(R) Environment and Martin Fowler's Refactoring: Improving the Design of Existing Code) are heavier than all but the largest laptops. Computers clearly win for information density. (The PDF for the second edition of the Pickaxe book (or, if you prefer, Programming Ruby) is not quite 6 MB. Since you can get light, less-than-a-pound flash drives that hold 8 GB, you could carry over one thousand books on a key chain.)

The search function of books sucks. Unless you know about where the content you want to find is, you have to consult the index and then use that to try to find it. There's no ready indicator of fluff versus desired content. And, in the end, you are at the mercy of whoever created the index. If they did a poor job of making the index, you will encounter difficulties finding what you're looking for. The internet clearly wins here. Google can search a vast repository of human knowledge which easily contains more information than some libraries.

There are some compromises. Several publishers offer their books in eBook or PDF format. This increases portability and, in some cases, search as well. I imagine you could possibly write a local search engine to search PDFs if you can access their content. O'Reilly and Pearson Technology Group created Safari Books Online, a service by which you pay money every month (or year) to get internet access to a large number of books. $42.99/month gets you unlimited access and there are cheaper although limited options. I personally find this service invaluable for what I do but your mileage may vary.

I personally believe that books and computers (including the internet) will eventually balance themselves out and complement each other. In addition to services like Safari Books Online, I expect most of the short-term information, e.g. what goes into books like Python Cookbook, will eventually end up online. A wiki equivalent of O'Reillys Cookbook or Hacks series is where I see that going. The longer-term information, more "language agnostic" topics, e.g. Refactoring or the Gang of Four's Design Patterns will continue to be seen in book format. Books will never completely vanish, not even from the developer culture.

I discovered Project Euler yesterday via a post on the Ruby-Talk mailing list. If you're the sort of person who enjoys puzzles and doesn't mind math, I suggest that you try out the problems for yourself.

I've been working through the problems slowly and in numerical order. While most of my solutions have been "brute force," it has given me an opportunity to learn how to do things in Ruby.

Why slowly? Because I haven't had a lot of time.

Why in numerical order? Later problems build on earlier ones. As I reach a problem that requires a given function or routine, I can go "Hey, I just did that in problem #x" and reuse it.

Why Ruby? Ruby was my "language to learn" last year but I neglected it so I'm hoping I can get more done before I work on this year's language (which will probably be Erlang or Scheme).

A lot of what I've learned to do is quick one-liners with arrays, much like what Drew Olson posted almost two years ago. (I love reinventing the wheel, don't you?) And then there have been neat numerical tricks.

For example, to find out if a number is prime with a somewhat naive algorithm:

Monkeypatching this into Fixnum is probably not the greatest idea to some people but it allows use of syntax like 31.prime? (useful for testing) and ( n + 1 ).prime?, which is theoretically useful. For example, to find if the Mersenne number for a given power of two is prime, you could write: ( 2 ** n - 1 ).prime?

And, most importantly, I find n.prime? to read better than prime?( n ). Readability always trumps cleverness. Luckily, here, it's both readable and clever.

If you want to learn how to use a language better, I suggest you use it for the Project Euler problems. After a while, you'll find ways to do things you've probably not thought of before (or, possibly, ever needed to do before). And for Ruby fans, you can find a use for Array#each_cons.