From Novice to Adept: On Answers to Smart Questions

| 1 Comment
Shlomi Fish made a good point in a comment on Embracing (Perl) Idioms. Sometimes a novice question can trigger a huge discussion of personal style among people ostensibly intending to answer the question.

I see this often on PerlMonks. I haven't see it as often on the Perl Beginners Mailing List. I think some community differences explain this behavior.

I don't intend to answer the question of why (though that could be amusing; I find bleak amusement in certain PerlMonks threads that descend into several respondents flailing about to offer suggestions which they have obviously not tried because Perl does not work that way). I prefer to give advice for novices who want to ask questions and get useful answers.

I could recommend How to Ask Questions the Smart Way and leave it at that. You should skim that document. I know most novices won't read it in part or in full, but they should. Even so, that document doesn't answer an important question: how can I tell if the advice I've received is useful or a meaningless debate over brace placement that isn't worth my time?

There's one general rule: if you've asked a good question (per the linked document) and you've received at least one meaningful response which seems to answer your question, you can safely ignore the contents of responses which don't answer your question directly.

In other words, if anyone on PerlMonks says "I don't know, but you should always use strict and warnings," you can ignore the rest of the post.

If someone gives you an answer that seems reasonable and, after you test it locally, seems to do what you need and then offers some style advice, consider it.

If someone tells you that your entire approach is wrong and gives you an alternative which seems credible, you should consider the alternative enough to get a sense of its benefits and drawbacks. If this means posting a followup, that's fine too.

If more than one response suggests that your code is too difficult to debug without changing your style, consider it.

If every response suggests that you're doing something wrong, take that advice.

That's all well and good, but how do you tell whether approaches are matters of style or the difference between correct and incorrect behavior or maintainable or unmaintainable problems? You cheat. Run your program through Perl::Critic and see which, if any, severity level discusses the style issue. If the default, least strict severity suggests you have a style problem, address it now. If the most strict severity level is silent about your style problem, you can ignore it for now.

If the style issue is over brace placement or indentation or something P::C doesn't care about, compare your code with Perl::Tidy's reformatting and see which you find easier to read. Then ignore style discussions.

As for the rest, take advice where you can get it. A lot of experienced developers have a lot of practical experiences using and maintaining Perl programs for many years. They have written and maintained programs that solve a lot of problems. They've seen community idioms and common solutions wax and wane as community members discovered problems and new solutions and better abstractions. Don't walk away from that wealth of knowledge and advice in favor of a short-term solution. Yet also don't get confused that people care about long-term sustainability of programs and programmers; the kind of people who care about answering novice questions -- the kind of people you want to answer novice questions -- have some interest in seeing you avoid the rough spots they had to encounter the hard way.

Safety and correctness are concerns -- but P::C goes a long way to identify the most important antipatterns there. Ultimately the question of whether one construct is more readable than another depends on your preferences, the coding standards of your organization, your problem domain, and your experience and familiarity with the language and its idioms. The best thing you can do is train yourself to consider short- and long-term ideas. That's not easy, but fortunately many people answering novice questions will do so. Learn from them.

1 Comment

Indeed, sometimes the difficulty of getting help comes from the responses of those who either don't care, don't know, or don't understand... but more often than not the problem is because the person seeking advice does not know how to phrase their questions. (Even worse are the people who demand help without even *caring* how they communicate, but I don't think they can be helped)

I really, really like for this sort of thing. The whole workflow of the site allows folks to give advice, clean up the original question, vote up-and-down responses (and questions) and really seems to work to bring the most thoughtful, helpful answers to the foreground, along with helping those asking to refine their questions.

I have a special place in my heart for so suggesting that they change anything almost feels ungrateful, but imagine if PM could re-design to implement something like SO? It could be the next "killer app" of the Perl community!

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide



About this Entry

This page contains a single entry by chromatic published on October 28, 2009 4:26 PM.

How not to Manage the Risk of Perl as a Shipped Dependency was the previous entry in this blog.

From Novice to Adept: The Act of Naming is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?