Asking Technical Questions

Back

Learning Goals

  • Use effective key words in a Google search to find answers faster
  • Ask technical questions that are both clear and concise

Effective Googling

Throughout Mod 0 (and your remaining time at Turing), you will encounter thousands of questions with unclear answers. Often, the first place we go when we have questions is Google! This is an excellent source to find answers to your questions, but it helps to follow a few guidelines when looking for answers on the internet.

  1. Take out unnecessary words. Leave out small common words, such as “how” or “what”. Google automatically ignores them anyway! You only want to include the necessary keywords in your search. Instead of "How to update my Slack profile", use “Update Slack profile”.
  2. Include the programming language in your search. When you’re searching for support with a particular programming language (Markdown, Ruby, JavaScript, etc.), you definitely want to include the language in your search. The same concepts often transcend a single language, so you’ll want to be specific about the language you’re working with. Instead of "Array methods", use “JavaScript array methods”.
  3. Use technical terms. If you received an error message, include the exact message in your search! Instead of "JavaScript change a word to upper case", use “JavaScript string method upper case”.
  4. Rephrase your search terms. If it’s not on the first page of results, it’s probably not there. It’s wise to try a slightly different search term before giving up altogether. For example, if you remember that you’ve heard both of the terms if statements and conditionals to describe a similar concept, try using the other one in your search.
  5. Look for a reliable source. There are websites that house the documentation for each language, also known as the docs. For Ruby, you’ll want to bookmark and reference often the Ruby docs. For JavaScript, Mozilla Developer Network is your go-to resource and W3Schools is usually reliable as well. If you see those sites in your search results, take a look at those first!

If you followed those guidelines and still can’t find what you need on the first 1-2 pages of search results, it’s probably time to use another resource… like your Turing community! In the sections that follow, we’ll discuss how to ask technical questions and a few best practices to keep in mind as you develop this skill.

Best Practices for Asking Technical Questions

It’s easy to ask a question, but effectively asking a question is a skill. It takes a lot longer than you expect to write a good question, but you are guaranteed to get a better answer when you ask a better question. This skill will be essential in your success - not just at Turing, but on the job hunt and on the job. During your time at Turing, you will continue to hone this skill.

Information to include in every question:

  1. What were you trying to do?
  2. What were you expecting to happen?
  3. What happened instead?
  4. What have you attempted/googled/read to find a solution?

Your goal is probably to get an answer ASAP, and a secondary goal should be to document this issue/challenge to help someone who may encounter the same thing in the future (including your future self!). Formatting your question well supports both of these goals. Some things to consider:

  • Code snippets should not be formatted as plain text. Very short snippets should be formatted as inline code and …
    longer snippets 
    should be formatted 
    in code blocks.
    

    When asking your question in Slack, to write the inline code, use a single backtic (next to the 1 on your keyboard) on either side of the word or phrase. For a longer snippet of code, use three backtics on either side of the code block.

  • Screenshots are usually helpful. On your mac, the keyboard shortcut cmd + shift + 4 will allow you to select a part of your screen to capture and save the screen shot on your desktop. You can then drag and drop this image to Slack.
  • It’s also a good idea to format your question in easily digestible chunks. You can use the keyboard shortcut shift + return to create a new line without sending your message in Slack. If you have a lot of context to provide, give a TL;DR in the main channel, then thread your details in manageable chunks. Another strategy is to use bold text and/or emojis strategically to highlight key information or questions.

Examples and Non-Examples

Robyn & Arrays

The question that follows, from Robyn, isn't specific and puts a lot of work on the people potentially answering the question. Not only will people not completely know how to answer this question, the answers also won't help Robyn's learning much. If an employer saw a question like this from Robyn, they'd learn that they aren't resourceful and don't communicate their needs well. An employer might conclude that Robyn will be a costly employee who won't contribute much.

Bad Question 1

After receiving some feedback, Robyn re-wrote their question. They provided a code snippet, shared the error message in their Terminal, and told the group what they'd tried. This question is quite easy for someone to read and answer quickly, demonstrating Robyn is an effective communicator in a technical environment.

Good Question 1


Kaitlyn & Homework Help

Kaitlyn's initial question for help on her homework puts a big demand on the reader, and probably doesn't set her up to learn a lot. Most companies prefer asynchronous communication until live communication is necessary; seeing that Kaitlyn isn't communicating a clear question in writing could be a flag that she won't work independently.

Bad Question 2

After she didn't get any responses, Kaitlyn DMed her instructor, who gave her some feedback about why she likely didn't get responses. She re-wrote her post to make a specific ask, demonstrating she did her due diligence to learn a concept but wanted to confirm her understanding. This type of message demonstrates that Kaitlyn can problem-solve and communicate her needs for technical support.

Good Question 2

Asking Questions

As you prepare to ask questions—in written form or in live communications—think about how you can best present the necessary information to get your question answered and to demonstrate that your are an effective communicator in a technical environment. Things to be prepared for, and ok with:

  • It’s not always easy to write up a question. It might take several minutes to find the words to describe the scenario. Part of the job as a developer is asking questions, so it’s ok to take time on it. Budget this into your time estimates for projects and work.
  • This usually prompts what we call “rubber ducking”—or talking through the problem to yourself or an inanimate object. The act of talking or writing through the 4 components of a good question will often help you answer it yourself. In that case, it’s definitely something to celebrate and not a waste of time. If you didn’t answer the question yourself and still need to ask, that’s ok too!

Check For Understanding

In your Mod 0 Gist, please create a section called Asking Technical Questions and answer the following questions:

  1. What are the steps you will take when asking a technical question?
  2. We lay out these steps in a particular order. What do you think the reasoning behind this might be?
  3. How will you refer back to this question-asking strategy while in Mods 1 and beyond? (ex: add these steps to your notes, write them on a sticky note, etc.)





Back