Today we finally had a run of "real questions".
I don't know where the recent batch of "interview/homework questions" came from, but it was a relief to see some questions whose answers I actually cared about. Maybe ssandv is right and those tiresome questions really were interview questions asked either during a take home quiz or after the interview. Maybe they were part of a "are you a real programmer/how well do you know Perl" quiz that is making the rounds on a programming site or email circuit not generally frequented by the regulars here. Maybe some professor or team leader was handing out problem sets and told the students/team members to check out Perl Monks if they got stuck. Whatever the source, they all fell into the category of questions I call "stupid stumpers".
So what makes a "stupid stumper" different from a real question? For me, "real questions" are connected in some visible way to a person, their passion, their learning process or their work responsibilities. Or it has significance in the wider world, for example, a bug to report, or a chance to show the PM community at its best.
In a stupid stumper, there is nothing beyond the question and answer. The OP (original poster) hasn't bothered to tell you what they think the answer is or why they know it doesn't work. The sample data says nothing about the life outside of the question. The preamble doesn't tell you why the OP even cares about the answer. Even if it isn't a quiz question, it stands on its own like a page from a quiz book.
A good answer to a good question leaves one with an ego boost: "Hey! I know that!". But with a stupid stumper all I'm left with is a dull nagging feeling. If the answer is obvious, the question seems so unmotiviated that I wonder why I even spent time on it. If the question really stumps, the answer is usually so remote from a real use case, I wonder if this is the geek version of "Stupid Dog Tricks" and I've just become the dog. Since I don't like either feeling, I mostly ignore stupid stumpers.
Here are some examples of questions I consider "real".
"I thought this should work, but it doesn't...": I like these questions because they are really three questions in one. (a) why might the person be assuming that lead him or her to think X should work? (b) what really will work? (c) how do you get the person from the old way of thinking to the new way of thinking so they don't make the same mistake again? What I also like about these questions is answering them requires a healthy measure of both human and technical skills and the ability to integrate the two. Sometimes making the connection between someone's misunderstanding and the "right way" can be educational in itself - it can help jog me out of standard ways of thinking.
"Is this a bug or is it me?" If you've gotten beyond "it's broken" and come to this question, it means you've thought about the way things do work and the way things might work. Sometimes a second pair of eyes will quickly see a mistake the OP has made. We've all been there and it feels good to help someone get unstuck. But just as often, these turn into discussions about documentation, design, and sometimes a bug report or two. When it really does look like a bug, these questions give us a chance to work together as a team to solve a problem. I love watching that. One monk will contribute benchmarking. Another will try write up some more scenarios and post code. A few monks with different versions of Perl will try to reproduce it. Someone will mine the bug reports and Perl release notes.
"Why is this design better than that one and what are my other options?" These questions can win or lose for me. If they are asked purely in the abstract, I'm not much interested. But if the poster also mentions a real life problem, or some area of design they are learning and trying to get a better handle on or spends time synthesizing diverse opinions and real life experiences into a well-written essay, then my interest perks. A little bit of grounding can start a really great discussion and I get to see the perspectives of many different monks, building on and offsetting each other.
There are, of course, many other types of "real" questions.
The recent run of stupid stumpers has made me realize how much PerlMonks depends on the quality of its questions. Good questions let PerlMonks develop as a community. They keep the teachers-in-spirit among us engaged. They keep the learners (which are often one and the same) growing. Too many of the wrong sort of questions would likely have the reverse effect, causing people to eventually drift away and look elsewhere for entertainment and learning.
It also makes me realize that good questions and "stumping" people have little to do with each other. So the next time you think your question is too "dumb" to ask, think twice. If it is *your* question tied to a real problem and you made a fair effort to check whatever documentation you feel is within your experience level to read, there is a good chance, we'll enjoy answering it. And if you have a "clever" question, think twice. Unless your question is motivated by something more than "This stumped me", it is likely to end up being just another "stupid stumper".
Best, beth
In reply to Stupid stumpers and good questions by ELISHEVA
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |