How to ask a programmer a question without getting "Why" as the answer

Question

We've all had this experience. You go to someone who you know has the answer to a question, ask that person the question and they answer with the typical response: "why?" You explain why you need to know, and they attempt to solve your problem.

It takes time, arm twisting and patience to steer the conversation back to the original question and just get that darn answer.

Why do programmers constantly do this, and why does the behavior get worse the more senior the programmer becomes?

How can you ask a programmer a question in a way most efficient in extracting the answer to the original question?

Answer 1

Why do developers ask "why" when someone asks them how to implement a solution?

Because it requires more knowledge to evaluate whether a solution is appropriate than it does to actually implement the solution.

It's very difficult to believe someone when they say, "I don't know how to do this, but I know for sure it's what I need to do." Programmers constantly insist on probing deeper because people constantly insist on asking the wrong questions. Yes, sometimes it eventually comes back around to your original question, but not always.

As an analogy, imagine if someone walked up to a mechanic and asked him how to replace a car battery. Usually if you're qualified to diagnose a defective battery, you're qualified to change one, so the mechanic will ask how you know it needs replacing.

He knows if he doesn't do this, and it turns out you don't need a battery, then you'll keep coming back asking more and more questions until eventually you figure out that you have to turn the lights off when the engine's not running. By asking you up front, it feels like he's wasting your time, but really he knows from experience that he's potentially saving both of you a lot more time.

So, if you want to avoid the line of questioning, you need to convince him up front that you know what you're talking about.

Answer 2

"The question is specifically how does one engage with another programmer to ask a question, where the other has the answer and skip the debate about why the question is being asked."

You can't, at least not deterministically. The other programmer is a person, not a computer, and not your servant. If you ask them a question they get to choose what they think is the best answer. If they think they need more context they get to ask for it.

You could try prefacing your question with a statement that you are only looking for a short, bottom line answer, but they're still free to answer as they think best.

Answer 3

The question is specifically how does one engage with another programmer to ask a question, where the other has the answer and skip the debate about why the question is being asked.

You can't. Programmers, especially good ones, are wired to solve problems and to be efficient. When a customer or a fellow programmer comes looking for an answer - they will make sure to know the problem they are solving, before presenting a solution. That way they are efficient (they are not wasting your and their time by giving an answer that will not solve your problem) and they are solving real problems (by giving you solutions / answers to questions that you should be asking).

Example - when a client comes to you and says he wants an X feature implemented. Sometimes the client really needs an X feature and sometimes you really have to dig in and interrogate the customer just to find out that they don't want X but something completely different. The more older and experienced the programmers are, the more likely they were burned in the past by not getting to the heart of the problem before presenting a solution.

So to summarize - if you want your questions answered precisely you need to be sure that you're:

• asking the right questions (thus you need to research the problem beforehand)
• providing the context for the problem
• sharing some of you're research to direct them faster to the problem

Most humans I know are just humans and not computers. If you just want answers try googling it.

Answer 4

Why do programmers constantly do this, and why does the behavior get worse the more senior the programmer becomes?

Unfortunately it's as far from general truth as it gets.

That behavior is restricted to the minority of really good ones. And you better should learn it too.

Just answering the damned question skipping over the whys is a good way to drive into a chasm, fast and sure.

---

If you really want to skip the educated part, you can prefix your question with a few sentences on limitations and your desire to skip questions -- you may get some answer or just sent off. Presenting summary your own research is a better idea.

Answer 5

Every answer here is a good answer to the "why" question, but no one has really answered the OPs question.

How can you ask a programmer a question in a way most efficient in extracting the answer to the original question?

The answer is surprisingly simple: tell them why this needs to be done before you ask them how.

The best thing to do is include the developers in some higher level meetings around a product - give them some of the bigger picture so they can see why this particular thing needs to be done. They may even surprise you with coming up with the how first.

Answer 6

Good programmers don't just want to implement any solution; they want to implement the best solution for the specific issue. This requires information. Questions are the way to gather information. Without all the information, the programmer knows he is in jeopardy of implementing a solution that won't fit all the requirements and will be stuck doing it again. Don't hide information from your programmers. Hiding information wastes time, destroys morale, and leads to inferior solutions.

Answer 7

Programmers are "hard-wired" to solve problems.

Good programmers will try to solve the "right" problems.

Just supplying what someone is asking for is [often] the wrong problem to solve.

In the days when MS Office automation was all the rage, you'd get a string of questions, usually over the course of a few weeks, asking how to do "this" in one Office product, then "that" in some other product, then something else again in another one. Each of these are quickly dealt with, but the "problem" - not yet fully stated - isn't solved. They keep coming back for the next "link" in their chain.

If you stop them and ask them "Why?" then they have to back-track and explain more broadly what they want to achieve and not just describe the problem immediately in front of them. (BTW, Programmers suffer from this just as much as (if not more than) anyone else, to which fora like these bear testament).
The user's chain of "Getting the data from the big Database into Access, then into Excel to massage it a bit, then across into Word so they can mail-merge the results and Email these out to people every week" is quickly replaced by a batch job that does all of that, with the results sitting in people's inboxes first thing on a Monday morning, with no manual User involvement at all.

Users like that.

We need to know where you're trying to get to, before we can offer you the best way to get there.

Alternatively, (to paraphrase Monty Python): "Do you want the 5-minute answer or the full half-hour"?

There's no point the Programmer rattling off all the minutiae of a particular function when you only want to know whether it will cope if you feed it a number with three three decimal places.

Knowing your perspective can often radically re-shape the answer you get.

Answer 8

Your final question is "How can you ask a programmer a question in a way most efficient in extracting the answer to the original question?"

You are first confusing "efficient" and "effective". To be most efficient, just write "What's the answer?" on a piece of paper and show it to the programmer. That's a very efficient way to ask a question. It is also very ineffective at getting an answer.

And second, you are assuming that software developers are question answerers. They are not. They are problem solvers. Your attitude shows clearly that you don't understand problem solving. The most effective way to solve a problem is either to understand the problem to the point where you can describe it to a problem solver, and then present it to a problem solver. The other method is to understand the problem partially as far as you can, then present your incomplete understanding to a problem solver, who will first ask you the questions that you dread to turn this into a fully understood problem, and then solve it.

A very inefficient way is the method that you are trying: Get an incomplete understanding of the problem, make a guess how this problem could be solved, and ask a problem solver how this solution can be achieved. The problem solver has seen this behaviour before. 10 times if he is unexperienced, thousand times if he is experienced. So the problem solver knows that you are headed off into a completely wrong direction. And the problem solver does what needs doing to get into the right direction, which is asking questions to understand the actual problem. First questions to understand your incomplete understanding of the problem, and second more questions to understand the real problem.

Answer 9

Start the question by explicitating what you want to achieve and what is the context you are working in. If you give enough context you won't get an "why?", you will get a "is this really necessary?"

Because, statistically, most proposed features suck, and are not worth the hassle to implement.

A typical rebuttal would be "but that's his job." His job is writing good code, and adding features usually goes against that, because most features require a redesign of the working codebase and this "redesign thing:"

1. takes forever
2. adds new bugs
3. breaks things that used to work
4. makes maintenance impervious

That is not good code, good code is minimal.