Do you aim to get users working quickest or do you aim to teach?

[Mr Mike]

What do you think is the best way to help users? In a recent thread I helped a user with a basic data transport / manipulation problem. My reaction to her problem was to show her how to solve the problem with a better way to program so that her application would be faster and more flexible in the future. I didn't rearchitect anything, just made a suggestion for a small change.

Then rolfk came along and described a much simpler way to fix her problem. He acknowledged there were some potential problems in the design, but solved it quickly (i.e. with a simple cast)

How do you try to help users? What would you have done in this case? Where do you draw the line between these two ways of helping?

[ShaunR]

Users posting on a forum tend to have been trying for a while to get round a specific problem or lack of understanding. Muddying the waters with architecture (when not asked for) tends to just confuse and frustrate. I'm reminded of what a teacher once said to me for exam technique. Answer the the question, not what you think they are asking.

I tend to solve the immediate problem (usually with an example) then suggest improvements. However. Rolf has a huge amount of experience in umpteen programming languages as well as solving comms problems on a day-to-day basis so his one-liner is second nature.

It helps when they post an example as then you can tell their level of expertise. If they have roughly hacked an example shipped with LabVIEW and it "sort of works". They may have spent all day trying to get the last bit sorted. This generally means that they if you start spouting about OOP and Actor frameworks, then they will probably just give up as "LabVIEW is too hard to do simple things".

[hooovahh]

What do you think is the best way to help users? In a recent thread I helped a user with a basic data transport / manipulation problem. My reaction to her problem was to show her how to solve the problem with a better way to program so that her application would be faster and more flexible in the future. I didn't rearchitect anything, just made a suggestion for a small change.

Then rolfk came along and described a much simpler way to fix her problem. He acknowledged there were some potential problems in the design, but solved it quickly (i.e. with a simple cast) of helping?

To be fair I'm guessing rolfk was just suggesting another path. If you would have opened with the simple solution he may have replied with the "better way to program" answer.

You see this alot on the forums (and I do it myself). Someone will ask a question and an answer will have already been posted, but there are usually multiple ways to do the same thing, so I will post another possible answer (if I know of one). This gives the user more than one option, and they can choose what works best for them.

[jzoller]

Because it's fun and related, here's Alex P's related "Pounding a Nail: Old Shoe or Glass Bottle?" post... http://weblogs.asp.n.../25/408925.aspx

Does the user know enough to understand a sophisticated explanation? Are they interested in learning, or do they just care about their deadline in two hours? How much time do I have to explain? Is it the type of solution that I can explain without digressing into compiler/parser/memory structure/boring stuff/things I'm marginal on? Has the user actually thought about the problem yet?

Answering either short or long form is fine, but it just depends.

Personally, I often find that problems I have time to solve are too trivial to be interesting, and problems that are interesting I don't have the time to really dig in to solve them.

Joe Z.

[Darin]

Analogy: Let's say a friend of yours has called you up asking for directions because he/she is lost in the wrong part of town (probably she since directions are being requested ) . The route seemed like a good idea because it was the shortest on the map. Would you:

a) Say the problem is that you should not have taken that route in the first place, tell them to back up and start over.

b) Say that you need to make the next left, drive a short distance and you are there. In the event you need to go there again, perhaps take a different route.

a) is probably a good answer if you are tired of being asked for directions. I think b) is what most posters are looking for, instant gratification. An effective answer (ie. good learning experience) is to recognize the specific problem the OP has and work to correct it as quickly as possible. Do not question the motives or reasoning (at this point). "You want to use a local and sequence structure to do this, here is how you would use a local and a sequence structure". After solving the immediate problem, the OP now has a working version of the code. This can be invaluable, since the OP presumably knows the logic behind it, they can understand how it works. This makes a good crutch for debugging the future version (now comes the better architecture). Plus if you are inclined to make statements about flaws in the implementation you have not only gotten on their good side, but you can let them prove it to themselves because they have working code to experiment with.

Bottom line: it is a team effort, some like to hone in on immediate problems, some think big picture. There should be less tension between the two IMO, and sometimes the responders act like they are suggesting THE way to do it instead of A way to do it.

There is also a trap, and I fall into it on some slow days, and that is the question we think or wish was asked is much more interesting than the actual question. In this case a simple you wired this to the wrong terminal answer gets lost in the debate over the relative importance of LVOOP and sliced bread.

[Daklu]

The poll is fundamentally a question between how and why. Do you prefer to show someone how to fix their current problem or illustrate why that problem exists in the first place. I lean heavily towards answering the (often unasked) question of why and cast my vote accordingly, but both types of responses are valid and necessary. Often my response does depend on the specific question and who is doing the asking. If someone describes their overall system before explaining the specific problem they've encountered, I interpret that as an invitation to comment on it. When a persons asks for the "best" way to solve a problem, often it requires discovering and analyzing system architecture, non-functional requirements, and stuff like that, which of course also invites comments on it. Conversely, Dec/Jan is when FIRST is building their robots and we usually get a few questions from them. Given their time constraints and lack of experience, it's probably not a good idea to steer them toward the AF.

One thing I worry about with respect to answering the how question without addressing the why question is the impression it will leave with readers other than the original poster. Failing to highlight why implicitly validates poor (or at the very least, ignorant) decisions. Many times the problem only exists because the architectural situation is untenable. Doctors are taught how to treat a patient with a severed arm, but they don't ignore it when someone is sticking their arm in a combine simply because they know how to deal with the results. In the same way I prefer to try and show people how to avoid losing an arm rather than emphasizing how to apply a bandaid to the bloody stump.

Once somebody understands the "ideal" way to implement something--and more importantly why it is "ideal"--then they are in a better position to make decisions on when it is okay to use less-than-ideal implementations. But to get to that level of understanding requires somebody pointing out the flaws and consequences of the implementation they're using. IMO why is the most important question humanity has ever asked.

All that being said, I firmly believe a big part of what makes LAVA so valuable is the variety of user backgrounds and opinions expressed here. When I first came to LAVA I was a corporate drone working in an internal test tools group. Now I'm an independent contractor with my own business. Different positions have entirely different sets of environmental non-functional requirements underlying every design decision, and it's all too easy to unintentionally project my own environment requirements onto the user's question rather than getting clarification on their environmental requirements.

How much time do I have to explain?

This is very often the limiting factor for me. I'm already a really slow writer so I tend to have to pick and choose those threads I participate in. Too bad nobody wants to pay me to write posts for LAVA. (Although that's probably good news for the rest of you. )

[ShaunR]

Once somebody understands the "ideal" way to implement something--and more importantly why it is "ideal"--then they are in a better position to make decisions on when it is okay to use less-than-ideal implementations. But to get to that level of understanding requires somebody pointing out the flaws and consequences of the implementation they're using. IMO why is the most important question humanity has ever asked.

That's what training courses and seminars are for. Forums (to me) are for the "I've got this problem with this code,, anyone know how to fix it?" questions and general, unstructured "discussions". Therefore I don't see them as an ideal or even particularly good platform for "training". Most people IMHO post and want/need an answer in a day or so. Understanding architectures takes longer than that and doesn't solve their immediate problem.

So using your analogy. They already have the bloody stump. I usually give them a band-aid and tell them how not to lose the other one

[todd]

I worked with a smart guy who, when asked a question, would immediately give the answer. It motivated some people to work a lot more before asking him a question. "It was so easy for him! Maybe I can figure it out, this time." The people who came back to him with more questions tended to be either technicians or soon-to-switch-to-management-or-marketing types. (Hey, some of my best friends are managers and marketers.)

I worked with another smart guy who, when asked a question, would answer the question that should have been asked - but without telling the asker the difference. It motivated some people to never ask him a question again. Those who came back to him with more questions tended to be curious perfectionists - always searching for practical knowledge.

Forums have all types, so I vote with all those above who said, "give them both answers".

[crelf]

I'm reminded of what a teacher once said to me for exam technique. Answer the the question, not what you think they are asking.

That's fine, as long as the OP really asks what they want to ask, which isn't always the case.

I worked with a smart guy who, when asked a question, would immediately give the answer. It motivated some people to work a lot more before asking him a question. "It was so easy for him! Maybe I can figure it out, this time." The people who came back to him with more questions tended to be either technicians or soon-to-switch-to-management-or-marketing types. (Hey, some of my best friends are managers and marketers.)

I worked with another smart guy who, when asked a question, would answer the question that should have been asked - but without telling the asker the difference. It motivated some people to never ask him a question again. Those who came back to him with more questions tended to be curious perfectionists - always searching for practical knowledge.

Sounds like what you want is someone who is a blend of the two.

[Daklu]

That's what training courses and seminars are for.

Yes, that is what they're for. However,

1. They are expensive and time consuming, and not everyone is able to attend them.

2. The information in training classes and seminars tends to be outdated, especially with the way LV development has shifted the last 4 years.

3. Out of necessity training classes and seminars use contrived examples. Learning is far more effective when discussing code the user has written themself.

Therefore I don't see [forums] as an ideal or even particularly good platform for "training".

I don't view it as "training," I view it as "teaching." You "train" a dog to fetch a ball. You "teach" a programmer to understand a complex situation and make appropriate decisions.

You are correct forums are not an ideal platform for teaching. Ideally, a new programmer would work side-by-side with an experienced developer for years asking questions and understanding why things are done a certain way. Very few people have that luxury. Forums, while not ideal, are the best option many of us have.

Most people IMHO post and want/need an answer in a day or so. Understanding architectures takes longer than that and doesn't solve their immediate problem.

You are correct, and I don't mean to claim that it does. Lots of people here know more about specific functions, features, and tricks than I do. I leave it to them to provide those kinds of answers. But at the same time, if we don't point out why the problem occurred and how a different design could have avoided the problem, then they won't know there are better ways to structure their system. They will continue writing legacy code.

It motivated some people to never ask him a question again.

I can certainly understand why people wouldn't return to ask him questions, but at the same time I have to admit it's a clever way to filter out interruptions from people who aren't willing to invest the time in understanding what they're doing.

I do it all the time with my daughters. My younger daughter will often ask me a math question to verify something she's tried to figure out in her head, like "what's 17*9?" I could simply give her the answer and be done with it. Instead I guide her through the process:

Me - "Well, what's 17*10?"

Her - "170"

"How many 17's do you have to subtract to get your answer?"

"One."

"What's 170 - 17?"

"153."

Yeah, it drives them nuts and sometimes they get mad at me. I do it anyway.

Forums have all types, so I vote with all those above who said, "give them both answers".

I call foul. I think we all agree they should be given both answers. The question is what do *you* do, not what we as a group *should* do.