Comments on: Debugging https://blog.learnlets.com/2009/04/debugging/ Clark Quinn's learnings about learning Wed, 12 Aug 2009 16:31:20 +0000 hourly 1 By: Clark https://blog.learnlets.com/2009/04/debugging/#comment-74336 Mon, 20 Apr 2009 16:09:39 +0000 http://blog.learnlets.com/?p=945#comment-74336 Lori, LOL.

Sreya and Rob, interesting alternatives. Yes, Rob, I’ve had the same experience (and I won’t buy HP either, they fixed one problem on a new Compaq (they’d just bought them) and introduced another. Maybe the fact that if you’re calling about a router, a more technical piece of equipment, rather than a computer, they have a more educated tech support.

I, too, hate the folks that have been hired not because of their knowledge but their ability to speak English and follow a decision tree. And any reasonably astute person’s game is ‘get them to escalate to 2nd level support as quickly as possible’. And they need the first level for all the unreasonably unastute people out there!

I do find that when they say “I have to ask you to do this”, I’ve generally been able to say “I did that and this was the result”, and get them to skip to the next stage of the script.

But I have seen it degenerate to the level you’re talking about, Rob, and I’ve seen it improving more of late. Yes, you have to negotiate auto-phone trees, but I don’t mind that if it gets me to the right person faster and it’s reasonably good (I’ll shout out United as being good about that, at least for a relatively frequent flyer). I think Netgear did a good job. ATT was *pretty* good. At least they seemed relatively knoweledgeable. Maybe the whole ‘customer experience’ thing is finally holding sway as a differentiator for the clued-in, and HP’s not there yet ;). Here’s hoping. (And venting’s ok, I reckon, as long as you also tout the wins. ;)

]]>
By: Rob Moser https://blog.learnlets.com/2009/04/debugging/#comment-74332 Mon, 20 Apr 2009 08:24:09 +0000 http://blog.learnlets.com/?p=945#comment-74332 ve learned to be very clear about the steps I’ve already taken, and that helps to short-circuit what can often be very basic stuff</i> I've had nearly the opposite experience. I still debug code for a living on a regular basis, and whats more I spent quite a few years working in a 2nd level system support group, so I got used to helping other people debug their problems, both hard and soft. As a consequence, I used to try all of the obvious systematic tests, read all the FAQs, etc., and basically diagnose my problem before ever contacting anyone in support. What I found is that they are almost invariably (though most of my examples in recent years are with HP, so maybe they're just especially bad) highly trained at following the procedure in the flowchart, and nothing short of global thermonuclear assault by three-headed aliens is going to shift them from it. After a couple of calls where I tell them that the monitor is faulty and they insist on walking me through the procedure to prove that its the monitor first anyways, I started just saying "Yes, I'm trying the incredibly complicated half-hour procedure now" *5-second pause* "No, that didn't work. Because its the monitor that's dead." Eventually though, through the heavy use of excruciating feedback, they trained me to not investigate the problem at all before calling, since I knew they'd only drag me through the testing again anyways. I found this kind of sad. Short of venting, I'm not really sure where I'm going with this. But in a vague attempt to tie it back to the learning focus of your blog Clark, I'll say this; they have a system which is _not_ designed to train me to do something, yet it _has_ trained me to do something, and the thing it has trained me to do is - presumably - costly and detrimental to the company. (Ok, so the minimal cost of a few hundred extra operators in Bangladesh is probably mostly offset by the expense saved not having to fix the problems of the people who give up in disgust. But as its definitely one of the reasons that I will never buy another computer from HP for as long as I live, it can't be good for the business in the long run...) Whats sort of interesting about the whole process is that I'm not entirely sure how you would go about fixing it. From my own experience in support I know that for every person who has already correctly diagnosed their own problem there are 99 guys swearing that the server is "down" because they've kicked the power cable on their desktop out for the third time this month. Unless the people answering the phone have a deep model of how the system works, they haven't got any idea if the steps you're claiming to have taken are sufficient to properly diagnose the problem... and if they somehow acquire that deep model, then you have to promote them away from the phones before they leave for a better-paying job with someone else.]]> I’ve learned to be very clear about the steps I’ve already taken, and that helps to short-circuit what can often be very basic stuff

I’ve had nearly the opposite experience. I still debug code for a living on a regular basis, and whats more I spent quite a few years working in a 2nd level system support group, so I got used to helping other people debug their problems, both hard and soft. As a consequence, I used to try all of the obvious systematic tests, read all the FAQs, etc., and basically diagnose my problem before ever contacting anyone in support. What I found is that they are almost invariably (though most of my examples in recent years are with HP, so maybe they’re just especially bad) highly trained at following the procedure in the flowchart, and nothing short of global thermonuclear assault by three-headed aliens is going to shift them from it. After a couple of calls where I tell them that the monitor is faulty and they insist on walking me through the procedure to prove that its the monitor first anyways, I started just saying “Yes, I’m trying the incredibly complicated half-hour procedure now” *5-second pause* “No, that didn’t work. Because its the monitor that’s dead.” Eventually though, through the heavy use of excruciating feedback, they trained me to not investigate the problem at all before calling, since I knew they’d only drag me through the testing again anyways. I found this kind of sad.

Short of venting, I’m not really sure where I’m going with this. But in a vague attempt to tie it back to the learning focus of your blog Clark, I’ll say this; they have a system which is _not_ designed to train me to do something, yet it _has_ trained me to do something, and the thing it has trained me to do is – presumably – costly and detrimental to the company. (Ok, so the minimal cost of a few hundred extra operators in Bangladesh is probably mostly offset by the expense saved not having to fix the problems of the people who give up in disgust. But as its definitely one of the reasons that I will never buy another computer from HP for as long as I live, it can’t be good for the business in the long run…) Whats sort of interesting about the whole process is that I’m not entirely sure how you would go about fixing it. From my own experience in support I know that for every person who has already correctly diagnosed their own problem there are 99 guys swearing that the server is “down” because they’ve kicked the power cable on their desktop out for the third time this month. Unless the people answering the phone have a deep model of how the system works, they haven’t got any idea if the steps you’re claiming to have taken are sufficient to properly diagnose the problem… and if they somehow acquire that deep model, then you have to promote them away from the phones before they leave for a better-paying job with someone else.

]]>
By: Sreya Dutta https://blog.learnlets.com/2009/04/debugging/#comment-74329 Mon, 20 Apr 2009 04:47:16 +0000 http://blog.learnlets.com/?p=945#comment-74329 Hi Clark,

I think this is valid. We should be able to apply or learn the skills required to debug any problem rather than just call for help. It is pertinent to identify the steps and be systematic in implementing them. I was recently planning to buy a wifi router and this would be a good review for me to know one of the situations that could come up.

Thanks for sharing it and nicely highlighting the learning aspect related to the activity of debugging.

Sreya

]]>
By: Lori TZ https://blog.learnlets.com/2009/04/debugging/#comment-74328 Mon, 20 Apr 2009 04:01:09 +0000 http://blog.learnlets.com/?p=945#comment-74328 I hope you have a solid fix too, time will tell. And bonus, you won’t have to think about your options to switch providers, at least for a year…

]]>