Question about answering Questions

[Tommy]

:)
Just as a general rule of thumb, I was wondering about some things on answering questions that are posted here. I try to post something that solves the questioners problem, if they don't ask for more I normally will not offer "optimized" code. My reasoning is sometimes they are looking for pointers to a solution. Maybe they are an advanced user and looking for a clue/direction. :dunno Maybe they posted the re-simulated problem and what is actually going on isn't close, so optimized code would be harder to incorporate than the pointer. I also feel that optimized code is sometimes harder to maintain <getting ready to duck the flames :devil: >, meaning it sometimes can be cryptic.

[MWE]

:)
Just as a general rule of thumb, I was wondering about some things on answering questions that are posted here. I try to post something that solves the questioners problem, if they don't ask for more I normally will not offer "optimized" code. My reasoning is sometimes they are looking for pointers to a solution. Maybe they are an advanced user and looking for a clue/direction. :dunno Maybe they posted the re-simulated problem and what is actually going on isn't close, so optimized code would be harder to incorporate than the pointer. I also feel that optimized code is sometimes harder to maintain <getting ready to duck the flames :devil: >, meaning it sometimes can be cryptic.
I absolutely agree that "optimized" code can be difficult to understand and maintain (even by the original author). My answers tend to be "step by step" and (I hope) easy to understand. Brute force is another description of my code.

It is sometimes possible to figure out the skill level of the thread owner and adjust the response to that level. Unfortunately, language can get in the way and people with good VBA skills appear to be less skilled because their ability to express themselves in English is not the best. So generally, simplier is safest.

[Zack Barresse]

I agree but only to a point. Simpler may be safest, but who got very far in life by being safe? My point is this, I will generally tend to give a 'better code' answer to somebody asking a simple question.

Example. Somebody asks how to select an entire row. Well, that unto itself is very easy, and a short little one-liner. But, as we know, the majority of the time there is an underlying issue here that needs to be done. This is generally and ususally due to the users lack of experience or technical expertise in the field.

So should we just give them the 'simple' answer? I say no. I say we ask questions and give them a real answer that is going to suit their needs in an efficient and effective manner.

(Sorry if I missed the point here. :) )

[Tommy]

I always, whenever possible "Keep It Simple Stupid" <KISS theory>. Today I will have a good day and write some (for me) brilliant code. http://vbaexpress.com/forum/images/smilies/082.gif Tomorrow I will be hitting delete and the backspace key so much I wear em out LOL http://vbaexpress.com/forum/images/smilies/045.gif .

I guess what I am getting at is if I know how to reduce the amount of code some one posts by 50%, should I post that with the "solution"? or should I bring em up to that. Should I post the fix and suggest alternative methods if there?

I normally post what I think will fix the problem. Then wait to see if they want an explaination, or streamline (optimize) the code, or a better way, or tell me what the newest problem that's been created (time to look again and maybe take another route).http://vbaexpress.com/forum/images/smilies/102.gif

[MWE]

I agree but only to a point. Simpler may be safest, but who got very far in life by being safe? My point is this, I will generally tend to give a 'better code' answer to somebody asking a simple question.

...

So should we just give them the 'simple' answer? I say no. I say we ask questions and give them a real answer that is going to suit their needs in an efficient and effective manner.

(Sorry if I missed the point here. :) )
Not sure if you missed Tommy's point, but you did miss mine. I certainly try to understand what the real problem is and provide answers that demo how and explain what.

But, I still believe that most questions are from folks who want simple solutions that are easy to understand and maintain. Sometimes that is several lines of code vs one compact statement.

[shades]

From experience, sometimes we learn when we see alternatives. I remember when I first asked about faster replacements (on MrExcel). Seven pages in that thread! And about 7 different ways to approach the problem. I tried most of them - except the one (now in the KB) and one by XL-Dennis. I decided at the time to try a simpler one. That lasted about 6 months or maybe a year. In that time I learned enough to try the one in the KB. By then I could handle it, and better maintain and expand it. So part of it involves the requester knowing his/her limits.

[XL-Dennis]

I agree that thing should bee kept simple in a questionary public forum. Most users tend to overestimate their skillness & knowledge and by providing more complicated code then necessary the threads may turn out to be questions on the solutions instead, which may leave the OP behind.

Another aspect is that new members may, in order to "flash", both overwork their solutions and also ignore previously answers from others.

An additional aspect is that too many questions are very unclear per se and I quite often wonder what they are upto.

The older I get the more I like to keep things simple, no matter what issue being discussed :)

Kind regards,
Dennis

[Ken Puls]

I guess what I am getting at is if I know how to reduce the amount of code some one posts by 50%, should I post that with the "solution"? or should I bring em up to that. Should I post the fix and suggest alternative methods if there?

I normally post what I think will fix the problem. Then wait to see if they want an explaination, or streamline (optimize) the code, or a better way, or tell me what the newest problem that's been created (time to look again and maybe take another route).http://vbaexpress.com/forum/images/smilies/102.gif

I tend to post the code that fixes the issue. If it's an easy transition to more efficient code, I'll post it. If harder, I'll think about noting that. I went looking for php the other day, so I'm getting back in touch with being a newbie to code again, and I am all too aware how easy it is to get lost.

I always try to make sure the solution fits. If the code doesn't end up being the most efficient, it isn't necessarily the end of the world. If it works, the op is happy... and if they continue coding and learning, they will, as Shades points out, learn bigger and better ways.

All in all, you have to try and figure out how well you know the poster. Sometimes that is very hard to read on the net, but it's the most important piece of the solution. ;)

[TonyJollans]

Most people seem to be saying that it depends. I can agree with that.

Like Tommy I have good and bad coding days - and good and bad forum days :)

I know my own weaknesses (if that's the right word) - in particular in this context I don't like loose ends or incomplete solutions - but it simply isn't always possible (in fact isn't usually possible) to understand what a poster really wants to do. As a general rule I try to answer a question as posted but may well add a question about a poster's real intent, or perhaps a suggestion about an alternative method.

I think we should be trying to educate (ourselves as well as others) as well as inform - otherwise we (and many questioners) will get stuck in a rut.

Hope that all makes sense - if not it must be a bad forum day :)

[Bob Phillips]

I have learnt to my cost many times that trying to second-guess a poster's real requirements, underlying question, (often what the question means) leads to tears.

As such, I try to keep my replies short (curt some may say), answering the question, not 'improving' any 'rubbish' code (because I never write rubbish code myself http://vbaexpress.com/forum/images/smilies/cloud9.gif) except where I see obvious errors, or pet hates (Ramge("A65536).End(xlUp).Row for instance),

I work on the premise that the OP can always ask a follow-up, which is invariably more focussed than the original.

.

[geekgirlau]

Personally I like to see the 101 ways to skin a cat that are available in VBA. I know that I have also learned a lot from example presented where code has been "improved", and often seen methods that I may not have discovered myself if someone hadn't pointed them out to me. I see this forum as having a role in the education of coders (myself included) as well as just solving the immediate problem.

(Note: no cats were harmed in the posting of this message)