How to Solve Technical Problems by Asking Thoughtful Questions

Preface

This article summarizes a separate guide showing those wanting technical help how to ask for it. Please note that the referenced guide is somewhat dated (updated May 21, 2014, at the time of this writing). It also uses terms whose meanings vary depending on where you’re reading about them.

The guide considers those answering technical questions “hackers,” and there’s a separate page defining what a “hacker” is and how it differs from a “cracker.” That page summarizes typical definitions of “hackers” as follows:

… technical adeptness and a delight in solving problems and overcoming limits. If you want to know how to become a hacker, though, only two are really relevant.

I’m not sure what the “newsprint term” would be for them these days — perhaps “the technically inclined?” As mentioned in the guide, software programmers often volunteer their time to answer questions, so they could even be “developers.” Industry often calls them Subject-Matter Experts (SME); that’s what we’ll go with here.

Then there’s the type of questions: “smart” vs. “stupid.” The guide mentions that since SMEs volunteer their time, they “ruthlessly filter” out “stupid,” or low-effort, questions in favor of “smart,” or thoughtful questions. Thoughtful questions often follow the Four Cs of Effective Writing: clear, complete, concise, and correct, which we’ll also review.

The guide also mentions how to answer questions, but that’s outside this article’s scope.

Finally, the guide has some SSL cert issues that raise warnings in modern browsers about certificate mismatches or simply not being secure. The website doesn’t ask for any personal information, so it’s safe to ignore the warnings (this one time!). However, it’s also available on the Internet Archive’s Wayback Machine as a cached, static page.

Now, let’s get into how to ask thoughtful questions.

Introduction

Now that 50% of the world’s population has a miniature computer in their pocket, there are many technical problems. However, how effectively could anyone resolve an issue described as, “Plz halp! See this, what do?” without the implied screenshot?

When asking questions, it helps to meet midway by first taking steps to diagnose the issue to help narrow down the cause. Asking “thoughtful” questions that follow a structured format instead of “low-effort” one-liners helps organize a dense amount of information in an easy-to-read format. Combining prediagnosis and structured reporting solves technical problems efficiently and, therefore, faster.

This topic is so common that there’s a frequently referenced guide dedicated to showing those seeking help how to ask for it:

Warning

This link is not for technical support! Instead, it’s a guide on how to ask questions. It also contains mild language (but still PG-13-ish).

https://www.catb.org/~esr/faqs/smart-questions.html

I’ll defer to the guide for all the extreme details. This article will summarize some of the guide’s concepts and provide a structured format when asking for help.

Prediagnosis

Due diligence often separates low-effort questions from their more thoughtful counterparts. In some situations, there’s a team of Engineers or SMEs to turn to for answers to technical problems. Otherwise, the only options are finding the solution or asking in a public forum. In any situation, meeting the SME halfway facilitates promptly addressing the question, and we accomplish this with prediagnosis. So, what are the best ways to find a solution?

Test

There are many undocumented questions that no one’s thought of, but anyone can test them. In these situations, testing is often faster and easier than the process of formulating a question.

An hour is a good rule of thumb: if a test takes longer than an hour, it’d be better to research and ask a thoughtful question in that time.

For example, does Gmail support the triple-byte character set (TBCS)? It’s undocumented, but it should be possible to send an email to oneself with characters from the TBCS.

Tip

Using TBCS instead of Unicode is very rare. For example, the Microsoft Foundation Classes library doesn’t support characters encoded with more than two bytes.

If testing is impossible or involved, we must prepare a thoughtful question. As with all things done in a public forum, it’s important to follow etiquette.

Politeness Isn’t a Substitute for Courtesy

There is a distinction between being “polite” and “courteous.” Generally, being “polite” is in the way one asks for help, like including “please” and “thank you.” Being “courteous” is considering others when asking for help. In this case, it’s doing due diligence when asking a question.

Note that pleading and being self-deprecating aren’t part of either. Many forums have areas for those new to the topic to ask basic questions, but the same level of courtesy applies there.

Aside from due diligence, another less-mentioned but important courtesy is updating a question with a solution after finding one. Following up with the solution helps those searching in the future and demonstrates fellowship.

Sometimes, politeness only goes in one direction, but don’t be discouraged. The guide links to a Tact Filters opinion piece on the communication gap between the technically inclined and disinclined.

For instance, the technically inclined can have issues interpreting paraverbal communication or how we say something.

An example of paraverbal communication is the phrase:

I didn’t say you were stupid.

Whose meaning changes depending on the emphasized word:

I didn’t say you were stupid. (Read: But I thought it.)

The technically inclined often have minimal experience with non-verbal communication, so it’s best to remain direct and unambiguous while speaking to avoid miscommunication.

Now that we’re familiar with Internet etiquette, where should we ask our question?

Location, Location, Location

The search didn’t uncover a solution, and it would take too long to test, so where is the best place to ask for help?

The search should’ve uncovered some places where others asked questions. It’s frequently a forum or, sometimes, a bug-reporting process. Many products have a FAQ or dedicated Support pages.

Before posting in the forum, consider the audience and the types of questions asked. For example, asking questions about Windows in a Linux forum won’t get meaningful answers. Similarly, filing a bug report or asking questions in a technical forum might require logs or detailed information.

Now that we have what we need to ask a question, how do we formulate it?

Form a Structured Question

The Four Cs of Effective Writing is another famous concept applicable to many written subjects, even writing questions. This concept makes writing more thoughtful by focusing on four core criteria: clear, complete, concise, and correct. Ensuring a question meets these criteria organizes a dense amount of information into an easy-to-read format. Occasionally, following this process leads to a solution, as we’ll demonstrate in an example later.

Clear

The goal of clarity is to ensure that anyone can read the question and understand what the question is asking. Therefore, we can achieve intelligibility by making the question easy to understand.

Some tips to make a question easy to understand are not using slang or jargon and being explicit. For example, would everyone understand what “It should work because the VoIP service is up and connected to PoE, so what’s wrong?” is referencing? Instead, it’s clearer to say, “The phone should work because the Voice over Internet Protocol (VoIP) service is up and connected to Power Over Ethernet (PoE) for power and data. Is there anything else I can check?”

Another tip to make a question legible is to outline. Part of an outline is structuring the flow of the topic. For example, providing errors without first explaining the steps taken that resulted in those errors is confusing.

However, it’s crucial to remember outlining includes formatting. Not using an ordered list for actions taken and not putting errors in code blocks make them tough to read.

Clear text is a vast improvement, but what if something is left out?

Complete

The goal of completeness is to ensure all the information needed to explain the problem is present. Forums often have templates or minimum requirements for questions to help ensure they’re complete. Generally, completeness answers the following questions: who, what, where, when, and why? However, technical questions often require more specific information.

For example, including steps to reproduce the issue, errors, and a screenshot or video help describe the issue. Including troubleshooting steps taken helps narrow down the cause of the problem. Additional information about the environment, like the operating system, browser, and software version, helps confirm it’s not a known problem.

Complete questions are vital in helping SMEs identify the issue, but it’s a slippery slope to information overload.

Concise

Being concise is intended to improve comprehension and efficiency by removing unnecessary information. For example, providing test results from Internet Explorer (IE) 11 isn’t necessary since Microsoft ended IE support on June 15, 2022.

We can also achieve conciseness by saying the same sentence with fewer words. There are many “non-content” words, like were, with, what, this, that, and them, whose function is to connect other words. Eliminating these non-content words is a large part of conciseness.

Another way to remove non-content words is to write in the “active voice.” We can consider “voice” as a way to visualize nouns and verbs. When the verb acts on the subject, that’s “passive voice.” By contrast, when a noun does the verb to the subject, that’s “active voice.”

There are clear examples of passive and active voice, like:

  • The report was written by Helena.
  • Helena wrote the report.

However, there are also more subtle examples, like:

  • When the verb is acting on the noun, that’s “passive.”
  • When the verb acts on the noun, that’s “passive.”

The subdued examples only save one word, but those add up with each passively voiced sentence.

With technical issues, it’s easy to provide too much information. However, would you rather have a feast or famine? Too much is better than not enough, but we can remain concise by omitting unnecessary information and maintaining minimalist sentences.

Conciseness prevents us from writing a novel, but what determines whether our writing is fiction or non-fiction?

Correct

Incorrect information leads to either duplicated efforts or looking for non-existent answers.

Proofreading helps ensure questions are correct. For example, questions filled with grammar and spelling errors are difficult to read. A classic example is using “they’re, there, and their” interchangeably when they have entirely different meanings. Proofreading also includes fact-checking. Confirming version numbers, error messages, and steps to reproduce the issue for accuracy are vital to troubleshooting.

Correctness also includes being objective by only stating facts. By contrast, subjectiveness often has opinions or emotions. For example, saying “the processor is screaming hot” is subjective, while saying “the processor is probably over 100 degrees Celcius” is more objective. Finally, saying “the temperature sensor reports the processor is 122 degrees Celcius” is a fact. A reproducible problem is straightforward, but more detail is better for an intermittent one.

Now that we know the hows and whys of the Four Cs of Effective Writing, do they work?

A Practical Example

For my bitburner-scripts-js project, I use a portable Node.js environment with VSCodium. After upgrading VSCodium from version 1.65.2 to 1.66.1, VSCodium stopped opening. I reinstalled version 1.65.2 to confirm that it still worked, which scoped the issue to the software.

VSCodium has a template for filing bug reports. One of the steps is checking whether the problem happens on VSCode because VSCode is the source of VSCodium. Sure enough, the issue also happened on VSCode. VSCode also has a bug report template, but it’s included as part of VSCode when selecting the Report Issue option from the Help menu.

After a few hours of figuring out how to consistently reproduce the issue and get error logs, I filed a bug report on GitHub.

When I started researching the error logs, I found a similar issue that the reporter found to be a problem with Electron because VSCode uses Electron. The related issue also had a workaround that worked for me.

After all my findings, the bug report was ready for a quick review for confirmation and then subsequently closed as a duplicate by the reviewing SME.

All the effort in testing and researching the issue for the bug report saved the reviewing SME many hours and solved the problem with a workaround.

Conclusions

Technology simultaneously created our most substantial advancements and problems. Solving these problems requires some troubleshooting and describing the issue succinctly.

We can troubleshoot these issues by following a few basic prediagnosis steps to narrow them down. We can describe the problem by asking thoughtful questions with the Four Cs of Effective Writing and, if we’re lucky, find the solution ourselves. If not, we’ve given the person helping us solve the problem a head start, which leads to a faster solution.

It’s important to remember that technology is complex, and no one is an SME overnight. However, we’re one step closer with each question asked and problem solved.

Sep. 24, 2022 Update: Added more examples because I’m a firm believer that examples help explain abstract concepts (yes, that’s subjective).