Summary: Learn how to properly answer a technical question in a presentation in this step-by-step post by PowerShell MVP June Blender.

Today we have another blog post by PowerShell MVP June Blender. June is an Honorary Scripting Guy and a technical evangelist for the SAPIEN Technologies, Inc. She has been working with PowerShell for a long time. When she worked for Microsoft, she wrote the PowerShell help documentation. If you have ever used Get-Help in your life, more than likely you have seen some of her work.

Take it away June …

How to Answer a Technical Question

Like many people, I look forward to the PowerShell Summits (plural) all year. It’s my time for intense learning and deep collaboration. This year, I was honored to be a speaker along with true greats, like Don Jones, Jason Helmick, Mike Robbins, Ed Wilson, and Jeffery Hicks. I spent months on the research for my Pester talk, weeks writing the code, and many days practicing the delivery so that I covered the most important concepts in the allotted time.

But, I didn’t practice answering audience questions. And, when the time came, I flubbed an answer. I didn’t get it wrong, but I went off on a tangent because I focused on what was interesting to me instead of what the questioner needed to know.

So, I spent some time thinking about best practices for answering technical questions. It turns out that it’s very similar to best practices for writing help. It begins with listening, considering the questioner’s point of view, and answering the question that the questioner asked.

The Question: Is #Requires a comment?

The question arose when I showed a #Requires directive in my integration test script.

The questioner asked: “Isn’t that #Requires just a comment?”

“No,” I said, and went off about all of the #Requires directives including my favorite new thing, which is using a module specification object as the value of the #Requires -Module directive.

I didn’t even think to run my script in an unelevated session to show the error that results. I didn’t mention the about_Requires help file.

Step 1: Listen

Whether you’re at your desk reading forum questions or in the middle of a presentation while your adrenaline is spiking, it’s important to take a deep breath, clear your mind, and listen carefully to the question.

Before jumping to a conclusion, be sure that you understand what the questioner wants. It might not be exactly what they say. Examine the context of the question, if it’s available, or ask followup questions to clarify the question.

When you’re answering in a public venue, there might be many people with the same question, and they might have different perspectives. Consider your answer carefully, remembering that you are likely to be answering not just this questioner, but many others.

A “Why did you do it that way?” might mean that the questioner has thought of a different way (“Why did you do it that way instead of this way?”), or it might mean that the questioner doesn’t understand the technique that you’re using (“What are you doing?).

A “Can I do this?” might be a question about whether it’s possible to solve this problem by using PowerShell (or a different technology), or it might be a request to validate that path of inquiry, in which case, the complete answer might be “Yes” or “No.” Most importantly, it might not be a request for you to tell them everything that you know about the topic, although you might suggest a technique.

Step 2: Don’t get defensive

If someone questions your technique, especially when you’re on stage or on a public forum, it’s easy to get defensive. But the goal is to share information so everyone ends up wiser. I’d rather learn something new and take a little hit to the ego than to ignore the question and miss the opportunity to learn.

If the suggested technique is better, celebrate! And thank the questioner. My user group presentations have improved significantly because participants have shown me new and better ways to do things. The result is truly a community product, even though I’m the presenter.

But, if the suggested technique is flawed, acknowledge and affirm, and then correct.

Step 3: Acknowledge and affirm

People ask questions for many reasons. They might be missing information. They might be confused or stuck. They might have a different idea. But, by speaking up, they’ve contributed to the conversation and might have made themselves a bit vulnerable.

Begin by acknowledging the question. Repeat or rephrase it to show that you’ve heard and understand. Empathize with the questioner. (“Yes, you’re right. It looks like an unnecessarily complex approach.”) Compliment or thank them. (“Great question. Thanks for raising that issue.”)

Affirm that the suggestion might sound reasonable or might work in particular circumstances. Explain the advantage of your technique. But, be sure that you never shame or discourage the questioner. You want to encourage them to participate because their next suggestion might be the one you really need.

Step 4: Correct any misconceptions

A questioner might have an incorrect conclusion because of a flawed assumption. If you think that you know the root cause of the error, try to correct it. But, be careful that you don’t assume incorrectly, or you’re likely to further confuse the questioner.

Step 5: Answer clearly and demonstrate

A great answer is like a great help topic in that it starts with clear, simple language. Keep the verbs simple. Avoid technical jargon. Don’t be clever.

If you can, demonstrate. That’s not always possible in a presentation that’s strictly limited by time. But, in a forum or a user group with more flexible time boundaries, back up and show the effect of using the questioner’s idea.

Keep it simple. Learn when to stop. Do not give an academic or technical lecture on an entire field of inquiry, as I’m prone to do. Just answer the question. An answer that has too many details is as unhelpful as an answer that has too few details.

Step 6: Suggest references

Follow up with good information sources for the questioner. When I ask a question, I love when the answer includes a reference to content that has a full and detailed explanation of the context and the solution.

Help files are a great start, but there are also excellent blog posts and videos.

The Answer: Isn’t #Requires just a comment?

This time, I’ll do it right.

Isn’t #Requires just a comment?

Step 1: Listen

Take a deep breath. This person is likely to be a PowerShell beginner. Prepare a respectful answer that doesn’t embarrass them. They probably know a lot about something else than I do.

Step 2: Don’t Get Defensive

No reason to get upset about this one. Next step.

Step 3: Acknowledge and affirm

Ah, yes! You’re right. It does look like a comment. The #Requires statement begins with a pound or hash sign (#) just like a comment. In fact, the text turns green just like a comment, which shows that this confused the syntax coloring logic, too.

[Aside: It turns green because the pound sign fools the PowerShell syntax tokenizer. But, don’t go there. This is my indulgence. It would distract the questioner, who is a beginner. Do Not do this demo.]

Step 4:  Correct any misconceptions

However, despite the obvious similarity, it’s not a comment. It’s a directive.

#Requires is a special string that establishes requirements for running a script or module file. If the requirements aren’t met, Windows PowerShell won’t run the script; it throws a terminating error.

Notice that there’s no space between the ‘#’ and the ‘Requires’. That’s a required element of the #Requires syntax that makes it different from a comment.

Step 5: Answer clearly and demonstrate

In this case, I’m using #Requires with its -RunAsAdministrator parameter, which requires the script to run in a session that has administrator privileges.

Demo #1

Let’s run this test script without the required privileges and see what happens.

When I run a script or module file with #Requires -RunAsAdministrator in a session that does not have ‘Run as administrator’ permissions, the script fails. The error, although grammatically incorrect, is pretty clear.

“The script <scriptPath> cannot be run because it contains a #requires session is not running as Administrator. Start Windows PowerShell by using the Run as Administrator.”

Demo #2

Unlike a comment, the # and the Requires cannot be separated by spaces. If you add even one space, it becomes an ordinary comment. The script runs without the required permissions and generates all sorts of errors as a result.

That’s enough. Stop right there. Smile.

[Do Not confuse the questioner (or the audience) with your dalliances into the abstract syntax tree. The questioner is likely to be a PowerShell beginner who does not share your delight in the language parser.

I’m showing this to you, because I can’t help it. Do Not include this in the answer.]

Step 6: Suggest references

Isn’t that cool? In fact, #Requires has other parameters that let you require a version of Windows PowerShell, a snap-in or a version of a particular module, and a shell. You can read about it in the about_Requires help topic.

That’s better. I’ll keep this in mind the next time I’m answering a question.

Thank you, June, this an awesome blog post.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. Also check out my Microsoft Operations Management Suite Blog. See you tomorrow. Until then, peace.

Ed Wilson Microsoft Scripting Guy