Michael,

Condescending and belittling treatment of others in this list is not the norm. 
Your personal attacks are unwarranted and unhelpful.


Since you reached out and asked for help in relating to others I will share 
with you this piece from Dr. Phil Agre which helped me immensely when I was 
learning the ropes at the helpdesk and I still refer to it regularly to help 
keep me on track:


"How to help someone use a computer.


Computer people are generally fine human beings, but nonetheless they do a lot 
of inadvertent harm in the ways they "help" other people with their computer 
problems. Now that we're trying to get everyone on the net, I thought it might 
be helpful to write down everything I've been taught about helping people use 
computers.

First you have to tell yourself some things:

  1.  Nobody is born knowing this stuff.
  2.  You've forgotten what it's like to be a 
beginner.<https://www.edu-cyberpg.com/Read_This_First.html>
  3.  If it's not obvious to them, it's not obvious.
  4.  A computer is a means to an end. The person you're helping probably cares 
mostly about the end. This is reasonable.

Their knowledge of the computer is grounded in what they can do and see -- 
"when I do this, it does that". They need to develop a deeper understanding, of 
course, but this can only happen slowly, and not through abstract theory but 
through the real, concrete situations they encounter in their work.

By the time they ask you for help, they've probably tried several different 
things. As a result, their computer might be in a strange state. This is 
natural.

The best way to learn is through apprenticeship -- that is, by doing some real 
task together with someone who has skills that you don't have.

Your primary goal is not to solve their problem. Your primary goal is to help 
them become one notch more capable of solving their problem on their own. So 
it's okay if they take notes.

Most user interfaces are terrible. When people make mistakes it's usually the 
fault of the interface. You've forgotten how many ways you've learned to adapt 
to bad interfaces. You've forgotten how many things you once assumed that the 
interface would be able to do for you.

Knowledge lives in communities, not individuals. A computer user who's not part 
of a community of computer users is going to have a harder time of it than one 
who is.

Having convinced yourself of these things, you are more likely to follow some 
important rules:

  *   Don't take the keyboard. Let them do all the typing, even if it's slower 
that way, and even if you have to point them to each and every key they need to 
type. That's the only way they're going to learn from the interaction.
  *   Find out what they're really trying to do. Is there another way to go 
about it?
  *   Attend to the symbolism of the interaction. Try to squat down so your 
eyes are just below the level of theirs. When they're looking at the computer, 
look at the computer. When they're looking at you, look back at them.
  *   Explain your thinking. Don't make it mysterious. If something is true, 
show them how they can see it's true. When you don't know, say "I don't know".  
When you're guessing, say "let's try ... because ...". Resist the temptation to 
appear all-knowing. Help them learn to think like you.
  *   Be aware of how abstract your language is. For example, "Get into the 
editor" is abstract and "press this key" is concrete. Don't say anything unless 
you intend for them to understand it. Keep adjusting your language downward 
towards concrete units until they start to get it, then slowly adjust back up 
towards greater abstraction so long as they're following you. When formulating 
a take-home lesson ("when it does this and that, you should check 
such-and-such"), check once again that you're using language of the right 
degree of abstraction for this user right now.
  *   Whenever they start to blame themselves, blame the computer, no matter 
how many times it takes, in a calm, authoritative tone of voice. If you need to 
show off, show off your ability to criticize the bad interface. When they get 
nailed by a false assumption about the computer's behavior, tell them their 
assumption was reasonable. Tell *yourself* that it was reasonable.
  *   Formulate a take-home lesson.
  *   Take a long-term view. Who do users in this community get help from? If 
you focus on building that person's skills, the skills will diffuse outward to 
everyone else.
  *   Never do something for someone that they are capable of doing for 
themselves.

* Don't say "it's in the manual". (You probably knew that.)"


Source: http://polaris.gseis.ucla.edu/pagre/how-to-help.html

This is just a basic framework to keep in mind when helping others learn 
something that you already know. Adapt it as necessary to fit the situation.

I hope this helps.

Sincerely,
Mike


________________________________
From: Michael Stowe <michael.st...@member.mensa.org>
Sent: Sunday, September 16, 2018 11:39:51 AM
To: General list for user discussion, questions and support
Cc: G.W. Haywood
Subject: Re: [BackupPC-users] BackupPC 4.2.1 apparently in an infinite loop.

On 2018-09-16 05:27, G.W. Haywood via BackupPC-users wrote:

> Once again, thank you for your input.  Do consider some restraint.

That's fair.  Consider the context:  you've already admitted to breaking
BackupPC after an upgrade and instead of methodically going through the
steps of getting it working again, you upgrade to a completely new
version, misunderstand how it works, and start mucking about with
internal tools from the command line, while demonstrating that you don't
know the side effects.

Is there a quick fix for this?  Not if you're trying to solve one
problem with a completely unrelated tool:  if you want to solve taking
too much space, there are better ways to do it.  If you want to solve
rsync problems, there are better ways to do it.

You do have my apologies for any confusion I have caused -- so yes,
BackupPC_backupDelete is capable of removing directories from a share
that were backed up.  Will this solve your problem, or is it a good
idea?  No.  Are you interpreting what it's doing and its side effects
properly?  No.  Did you get the syntax right?  Hard to say, as you've
edited the command line and its responses -- and as I've already pointed
out, most people wouldn't run it from the command line, so if there are
quirks in how it handles directory input, a test case would be
warranted.

In many years of helping users who have wide variety in degrees of
expertise, I do struggle with people who demonstrate an incomplete
understanding of the tool they're trying to use, while insisting on
doing things that are, at best, orthogonal to their problem.  It is
usually coupled with a healthy dose of failing to follow reasonable
steps up until that point, and unwinding that is difficult, if not
impossible.  It is often unclear whether it is a problem of attention to
detail, ability to comprehend, missing fundamentals, poor
troubleshooting techniques, or an outsized ego.

Tech Support: "Okay, let's see what's in the directory.  Type 'ls -l' "
Customer: [typing sounds continue for several minutes]
Tech Support: "Uh.  Do you have a directory listing yet?"
Customer: "I read that hard drives need fsck'ing every now and then"
Tech Support: "It would help to know what's in that directory"
Customer: "It's rebooting now"

I'm open to suggestions as to how to be helpful in such situations.  If
obliquely pointing toward the documentation doesn't work, would it be
better to be more direct?  Would you prefer no response?  What is the
best way to gently suggest that leaping to a solution before
understanding the problem is unlikely to yield satisfying results?

Thanks


_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Reply via email to