A long way to heaven

If you are asking for something unusual and specific like an unusually low ring then maybe a good idea to write it down and give a note with the clarinet just so they don't foget.

However! Are you saying a person purposely didn't agree to do this?! Instead only willing to set the ring to what they thought was correct!? And... are you saying that after 90 mintues drive to get to the repairer, and for whatever reason they didn't do part of the repair you asked, they said they don't have the time to lower a ring (or several rings) for you?! This is absurd... With almost any customer, it's rare that I don't chat longer than it would take to lower a ring. I can't blame you for not wanting to go back to someone so unreasonable.
 
MartinMods said:
You forget that a printer is a computer with an operating system, various languages, various memory configurations, a horde of real world sensor interfaces, various user interfaces, networking interfaces, communication protocols, all of which must integrate with that incredibly complex computer world that you describe. In that, printer problem solving is even more of an art. LOL.
Click to expand...
No. No, I'm not. Yes, it has a computer, but it's standarized for that model, especially if we're talking old HPs. Yes, it has various languages, but those are either in the hardware or through a driver: and the driver's on the computer. Sensor interfaces? Again, standardized hardware for that model, as are user interfaces. Networking interfaces? You just have to remember that the JetDirect is for THIS model, not THAT model (and it's a component part that you remove when troubleshooting; I can successfully argue that it's not necessary for the function of the printerer and that it's its own mini computer interface, especially as one JD can be used for multiple models of printerer). Network protocols? Again, more a function of the NIC and the computer you're connecting the printerer to.

However, it's not that I'm saying that a printerer isn't difficult to fix: if you're stripping it to bare metal, which I've done once (I never have found it necessary to strip a machine to the bare metal except for this one instance, but I wasn't trying to restore the unit, either), you know you need to find the broken part(s) replace it OR that if the printerer does X, there's a flowchart in the HP repair manual on what to do/replace and if you replace the right thing, the printerer works. Connecting it to a computer and havening the printerer successfully communicate with it and vice-versa is the trick ...

... which leads us back to the strained example I was attempting to make: there is a certain set of instrument problems that can be easily fixed by saying, "If there's a problem with X, always do Y." However, I think there are some things in an overhaul where Y is not well defined and needs tweaking, such as, "Player has had his pinky broken two times and can't press down the G# if the spring is too tight. We need to remember to loosen that spring and/or install a modification to make that key easier to use -- and make sure he tests it before we say that all is good."

A flowchart is like a recipe: just follow the steps. However, if you encounter a problem at one of the steps, that's going to separate "good tech" from "robot following instructions".

Here's a however, based a bit on what SOTDO mentions: if a user tells me, "Computer broke. Please fix." That means that I can do ANYTHING I think is necessary. If a user gives me a time limit, I'll honestly tell the person what I can do to fix his problem in the time indicated and determine if that's all good before doing anything. If a user tells me just to fix one problem, I'm not going to be fixing a different problem, unless the different problem is affecting (or caused by) the original problem OR if the repair will be done during his own time and everything else is done (I charge hourly rates, after all) OR if I've contacted the user and he says it's OK.

I've had more than one person tell me, at work, "I have X broken. Please fix, but you can't reimage (remove and reinstall everything) it." I do my best to comply and if I get to a point (or initially determine) that I can't comply with the user's wishes, I'll tell him.

Just remember that your definition of fixed, the dictionary definition and MY definition might be three different things. Going back to the world of printerers, if you repair an 8150 and it prints great after the restore, but it's noisy, is it "fixed"? Hey, if the noise levels are within HP's specs and the user complains, is it "fixed"?

(I tend to have a point, but it takes me a while to get there :))
 
You just modify your flow chart for the situation, either by changing the area of focus - saxophone mechanics, acoustics, materials, user requirements, etc, and/or changing the degree of resolution. Your flow charts are constantly developing. A pesky problem just means your flow chart is incomplete.
 
I think you're missing the point, MM. I may not be doing a very good job of explaining.

Let's make up a flowchart: make a PB&J sandwich:

1. Go to cabinet and get PB.
2. Go to fridge and get jelly.
3. Go to breadbox to get bread.

Ooops. No bread. If this was a flowchart, you'd probably stop here. But, hey, what about that tortilla that's in the fridge? You're making a leap of logic. Yes, you could put in a logic chart that says, "If no bread is available, search house for bread-like substance." You could branch it even further and say, "If no bread-like substance is available, put everything away and go down to Subway ("Mr. Sub" for the Canadians in the audience)." There just comes a point when there are too many branches in the logic tree and you say, "Mmmm. Can't write out all the possibilities." This is the reason why Artificial Intelligence is a big deal: try to get a computer to make the leap from flowchart to a different logic step to solve a problem ("I'm hungry and it's time for lunch").

As another example, I have techs under me. I can give them good flowcharts on how to do a particular thing, but if something untoward happens, they call me. And something untoward will happen: hey, the computer's locked. The user doesn't have the right software. The user didn't have the right permissions. And on and on.

Anyhow, that's my point.
 
I'm beginning to wonder if Heaven is actually closer than the end of this thread. :)


John
 
pete said:
As another example, I have techs under me. I can give them good flowcharts on how to do a particular thing, but if something untoward happens, they call me. And something untoward will happen: hey, the computer's locked. The user doesn't have the right software. The user didn't have the right permissions. And on and on.

Anyhow, that's my point.
Click to expand...

Pete,

I think we are saying the same thing. The higher you are on the learning curve, the more comprehensive your flow charts are and the more adept you are at juggling them around into new combinations. Your assistant does not have the personal flow chart access that you have. The spontaneous connection of two unrelated flow charts which solves a problem is considered divine intervention or creative artistic genius one day, and routine the next.
 
jbtsax said:
I'm beginning to wonder if Heaven is actually closer than the end of this thread. :)
Click to expand...
We're knockin' on heaven's door.

I suppose my other point is that the heuristics have to be defined by someone and, while experience can substitute for skill and/or genius, I'd prefer to have the skilled person that made the flowcharts than someone that's just following them work on my horn.
 
I think that computer repair is a much more straightforward matter, being objective, comparing to that of an instrumental repair.

Being in IT, I pretty much construct build my own desktop computer and troubleshoot any issue that I run into, whether it'd be the incompatibility of device or even the rare reflow by baking a video card. The end results and the process to troubleshoot just seem to be so objective and definitive.

One can pinpoint very clearly in the case of IT as to what am I dealing with component wise. For example, base on the serial number of a CPU, I can realistically get to the week that this unit was manufactured if need be... and asking for a specific replacement is actually possible, with plenty of resources available to tap into component source wise.

Perhaps the best part about diagnosis of computer issue to me comes with that people post symptoms online and as such, I have some leads to start on in order to eliminate the possibilities. One example lies with a gaming laptop crashing after 10 minutes when a demanding video game gets loaded on it, which is enough to go on to make a search query and immediately lead myself to the direction of hardware force shutdown to prevent overheating...

That and the fact that all computing device follow the set Von Neumann architecture means that we can separate all hardware issue by the category of components being in each part of this architecture. One example: no display on startup. One will identify the components involved in display being: video graphic output or display monitor, and the cabling running from the display output to the monitor. This example may be trivial, but no display can mean anything from having a cat chewed up the video cable to a video card dead from overheating... whatever it is, getting a display back is pretty much the objective with no ambiguity whatsoever.


(to be honest, the case of "no reimage allowed" actually makes me happy as I can take a testbench drive and load up a vanilla OS on it to determine hardware faults)


With the case of instrumental repair, the right answer depends much on the uncertainty with the end user...
 
The main reason I disagree is because there really isn't ambiguity. The desired end result is exactly the same: you want a working thing and it doesn't matter if that "thing" is an instrument, computer, car, or (being generic) a widget. There's also the "I want it to work the way I want it to" formula included. Hey, you can't do your job because the desktop's the wrong color? We can fix that. Your altissimo keys are too awkwardly placed? We can fix that.

Extending your example, we've got "monitor not working". You have to ask
What's the monitor doing? Is it buzzing, bursting into flames, opening a portal to R'yleh? That tells you what your next step is. It's a hierarchical chart you're following, but you have to get an accurate problem description and then you can come up with an adequate way of resolving the problem. You also have to have some creativity. Here's a simple (and true) example that happened to a fellow tech a few years back.

Problem: Can't connect to the network.
-> Is the network cable plugged in? Yes.
-> Blinky, blinky lights on the network card where the cable's plugged in? No.
-> Anyone else havening the same problem? Only person in the office.
-> When did this problem start happening? Yesterday.
-> Did you recently install any hardware or software? No.
-> Where are you? New Jersey office.
-> Weren't they evacuated because of the hurricane? Yes, but I stayed behind.
-> Are the overhead lights on? No, power was shut down.
* Conclusion: you don't have network connection because the building doesn't have power. User's a moron. Replace user.

However, you could have a hierarchical chart that says, "No power = no network connection," but how big of a chart do you want? You could make the argument that any problem can be solved with the proper hierarchical chart, but the question is how do you create that chart to begin with? Are you following steps just because or do you know AND understand the rationale behind them?

(The "Von Neumann architecture" is more regarding how programs work. Arguably, you could extend that to how hardware works with a computer, but that's probably pushing it a bit.)
 
Which reminds me of this famous old help desk story (not sure if this is urban legend). Names have been changed to protect the guilty.

This is (supposedly) a true story from the Wxxx Pxxxxxx Helpline which was
transcribed from a recording monitoring the customer care department.
Needless to say the HelpDesk employee was fired; however, he/she is
currently suing the Wxxx Pxxxxxx organization for "Termination without
Cause." Actual dialogue of a former Customer Support employee
"Rxxxx Hxxx computer assistance; may I help you?"

"Yes, well, I'm having trouble with Wxxx Pxxxxxx."

"What sort of trouble?"

"Well, I was just typing along, and all of a sudden the words went away."

"Went away?"

"They disappeared."

"Hmm. So what does your screen look like now?"

"Nothing."

"Nothing?"

"It's blank; it won't accept anything when I type."

"Are you still in Wxxx Pxxxxxx, or did you get out?"

"How do I tell?"

"Can you see the C: prompt on the screen?"

"What's a sea-prompt?"

"Never mind, can you move your cursor around the screen?"

"There isn't any cursor: I told you, it won't accept anything I type."

"Does your monitor have a power indicator?"

"What's a monitor?

"It's the thing with the screen on it that looks like a TV. Does it have a
little light that tells you when it's on?"

"I don't know."

"Well, then look on the back of the monitor and find where the power cord
goes into it. Can you see that?"

"Yes, I think so."

"Great. Follow the cord to the plug, and tell me if it's plugged into the
wall."

"Yes, it is."

"When you were behind the monitor, did you notice that there were two cables
plugged into the back of it, not just one?"

"No."

"Well, there are. I need you to look back there again and find the other
cable."

"Okay, here it is."

Follow it for me, and tell me if it's plugged securely into the back of
your computer."

"I can't reach."

"Uh huh. Well, can you see if it is?"

"No."

"Even if you maybe put your knee on something and lean way over?"

"Oh, it's not because I don't have the right angle - it's because it's
dark."

"Dark?"

Yes -the office light is off, and the only light I have is coming in from
the window."

"Well, turn on the office light then."

"I can't."

"No? Why not?"

"Because there's a power failure."

"A power... A power failure? Aha, Okay, we've got it licked now.

Do you still have the boxes and manuals and packing stuff your computer came
in?"

"Well, yes, I keep them in the closet."

"Good. Go get them, and unplug your system and pack it up just like it was
when you got it. Then take it back to the store you bought it from."

"Really? Is it that bad?"

"Yes, I'm afraid it is."

"Well, all right then, I suppose. What do I tell them?"

"Tell them you're too xxxxing stupid to own a computer.
 
Yah. I knew the punchline to that after the first sentence.

There is a recording, somewhere out on the Intertubes, of me talking with a user who's really flipping out. I even remember where it was recorded.

BTW, the "urban legend" about the cupholder is true. I had that call a couple times. No, the users weren't kidding. If anyone out there has ever worked for a call center of any kind, they know that people can be that stupid.

Anyhow, my story about the power outage is true. I also remember that week: no calls because of the hurricane. Fun playing with HTML! I'm glad I got promoted out of there.
 
'n other one (dunno if urban legend or not):

Customer calls because of a hardware malfunction.
Tech asks customer for the serial number of computer because of warranty etc.
C: "Where would I find this serial number?"
T: "It's on a white label with a bar code, at the back of the unit"
C: <rummaging> "Okay, got it"
T: "Can you read it for me?"
C: "Thin line, thick line, thick line, thin line, thick line, ..."

I don't mean to ridicule users. But I found that one...cute.
 
tictactux said:
Actually, that bloody mutt is just as annoying.
Click to expand...
Easier to turn off, tho.

Gently picking at Gandalfe, what about (Microsoft) Bob?

:D

Clippy was really, really easy to make fun of. According to this, Microsoft, itself, made fun of Clippy.
 
"Dave, would you like to compose a letter?"

Allegedly, the guy that did HAL's voice is pretty much a recluse because he's way too well known for his voice. I think he'd make a lot of $ doing voices for GPS thingies. "Dave, you're going in the wrong direction. Why don't you take a sleep pill and we'll talk about it in the morning?"
 
You must log in or register to reply here.
Back
Top Bottom