10

If I determine that you don't know what you're doing from your question, but that a simple answer will allow you to cause yourself some headaches. Should I answer your question and warn you of the potential for issues or answer your question and let you learn by your mistake or not answer your question and berate you for your stupidity?

I'm not talking life or death i'm talking mentoring, self learning programmer interactions.

If you ask a direct question and there is a simple answer you may well know what you're doing and have thought through the consequences...so who am I to deny you the information you seek?

11 accepted

I would say give the warning first, and then give the answer. The reason for giving the warning first is that once they've heard the bit they're really interested in, many people (myself included) will probably start thinking about how they're going to apply that, and not really listen to the rest of what you've got to say.

7

Are you talking about stackoverflow, or in the workplace?

Here on SO, somebody asked how they could run their socket app so it would bind to a port less than 1024 on Linux/Unix. Know, you and I both know that's a prime way to shoot yourself in the foot, but I figured I'd load the gun, point it at his foot, and give him to drink to steady his aim - in other words I told him to make his app setuid. To my surprise, he accepted the answer. Which means I have probably the only accepted answer on the system with a -15 score.

I've taken steps to mitigate the damage since then by adding instructions on other ways to accomplish the same thing, such as the "setcap" functionality (which I only learned about from another question on SO), and cautions about how to drop the privileges after binding to the socket. I think I'm up to -11 now.

2

Generally I'd say:

  1. Give the answer
  2. Discuss why they're asking the question to see if your instinct that they're on to a bad idea is correct
  3. If you think they're going in a bad direction, guide the questioner to why the direction they're on is ill-advised
2

There's usually no harm in doing both. When I answer a question and it seems the person has the wrong underlying architecture, I tell them how to solve their immediate problem, and I suggest taking a different architectural approach. You learn more from a tough defeat than you do from an easy victory, but if someone takes the time to ask a question on Stack Overflow, I feel obliged to take the time to answer them if I can. If they choose to take my architectural suggestions, even better.

2

Both.

Answer first with the one that will let them do damage, but follow it up. Mentoring isn't about being smarter than someone, that's already been established. Mentoring isn't about spoon-feeding either. Mentoring is about letting people learn for themselves but pointing out those places where there is more to learn than Google's first page of hits can provide.

A mentor is a guide through life, not a shepherd to lead the hard of thinking.

2

You mention the keyword yourself, mentoring. I believe in being transparent and honest. Give recommendations rather than answers. Inform about pitfalls you forsee. Give them a good chance to make an informed decision.

1

Just answer the question - you can edit your response later to make it sane. SO is all about getting the answer "right", which does not mean correct. It's all about your rep.

Perhaps I'm just jaded and cranky.

1

Perhaps you need to determine first why they're going down the route they've chosen. Then, if it's out of ignorance I'd point out the pitfalls and explain the better way of handling it and why.

If they're doing it our of sheer bloody-mindedness then let them get on with it!

1

It depends on the asker.

It's often a problem, even for smart developers, to not know what they don't know. If the developer is someone you trust to take the warnings and give them due consideration, then its worthwhile to discuss it with them. That's true mentoring, and its part of being a senior developer.

On the other hand, if the asker is only interested in the now, especially if they're one of the chronic 'ask first, research later' question-askers, then don't waste your time. They're not likely to get much productive done anyway, and now they're wasting your productivity too.

Joel Spolsky has posted about just this topic, though I think he comes down more on the 'give them enough rope to hang themselves' side than I do.

0

As a general rule I just answer the question. This is because I find it extremely annoying when I ask a simple question and end up in a broad discussion.

Your typical programmer is male, doesn't like asking directions let alone for help, will interpret the slightest thing as patronizing or as an insult. Once they've asked a few simple questions and got a few simple answers they might trust you with more open questions.