Good vs Less good questions
From Twitter to StackOverflow to DEV to Developer Slack Channels, one thing I consistently see across all these platforms are questions from developers. Not all questions are created equal, however - consider these examples:
A good question
I'm getting an error in my console when trying to render my doc information in a component's template that [Vue warn]: Property or method "doc" is not defined on the instance but referenced during render. in my Vue (2.x) SFC file.
I'm expecting the doc JSON object to show in my HTML but nothing is showing.
<template>
<div>
{{doc}}
</div>
</template>
<script>
export default {
name: "documentCard",
data() {
return {
ddoc: {
name: "Document 1",
date: "08/25/2021",
},
};
},
};
</script>
<!-- Style removed -->
This question is great because even though the fix is correcting the typo of ddoc to be doc (or {{doc}} to {{ddoc}}) the question outlines what error is occurring, where the error is located, what framework is being used, and the relevant code is provided.
A less good way to ask this question
My code has an error! How do I fix it?
<template>
<div id="app">
<img alt="Vue logo" src="./assets/logo.png" />
<HelloWorld msg="Welcome to Your Vue.js App" />
{{ doc }}
</div>
</template>
<script>
import HelloWorld from "./components/HelloWorld.vue";
export default {
name: "App",
components: {
HelloWorld,
},
data() {
return {
ddoc: {
name: "Document 1",
date: "08/25/2021",
},
};
},
};
</script>
<style>
#app {
font-family: Avenir, Helvetica, Arial, sans-serif;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
text-align: center;
color: #2c3e50;
margin-top: 60px;
}
</style>
As the person asking the question, it's easy to assume certain information about your issue is obvious to anyone looking at your code - but this is rarely true. By not outlining more information, you are making it hard for someone (let alone someone experienced with your potential issue) to jump in and help debug the issue.
Asking better questions
Note: You won't always be able to perfectly identify these initially, but as you work more with code and gain more experience asking questions, your questions will continue to get better and easier for others to interpret. It's all part of the learning process, so the only thing that really matters is trying your best to ask the best question you can 😊
1. Include the Error
Error messages are (often) a lot more helpful than you may think, especially as a beginner when it seems like a big scary blob of red text being thrown in your face that you're WRONG. As you continue to use a language, you'll become more and more familiar with the error messages generated by that language. When asking a question, someone that already has a lot of experience with the error message you're getting will be able to quickly trace back to the root of the issue! Just be sure to include the full error (I know, I abbreviated it above to make reading it easier) and where it's appearing - there's a big difference between a console error and an ESLint error!
2. What Language/Framework/Libraries are you using?
While it might be easy to determine in the example above that it's a Vue file, if it was using the new Vue 3 composition syntax and I was trying to run it in Vue 2.x it could take a while to figure out the root of the issue!
I'll dare say that for libraries versions are usually less important unless you know you're on an older version - when in doubt, share though! Having a version number that adds nothing is preferable to not having the version number that ends up being the problem!
3. Code Please 🙏🏻
Any of the following are acceptable - Codepen, Github, Code Snippets, CodeSandbox, replit, etc...
Sometimes it won't be possible to share code in a meaningful way - at least not easily. Do the legwork though and you're going to be significantly more likely to get a response to your question/problem! An added benefit is that by trying to recreate the issue you may end up finding the solution in the process!
4. What is happening/what should be happening
This is usually going to be what you need to outline if you're not actively getting an error in your code (but can also go hand-in-hand with an error message!).
By describing the behavior that is happening vs the behavior you're expecting in as much detail as possible, you'll be providing a map to anyone that is answering your questions while also functioning as a good opportunity to ensure that any misunderstandings are available to the person answering your question (see #5 below).
5. Learn in Public
I'm a huge fan of the CodeBuddies' Slack Channel - especially the approach of encouraging learning in public. Because the slack is asynchronous, it can be frustrating to ask a question that isn't answered quickly, but someone will usually get to it when they have time (often multiple users will help answer!).
Unless invited to, don't just send your question via DM to someone if you don't have rapport with them. They may not have the bandwidth to respond, or may not even know the answer. If you ask in a public area, not only are there more people that will be able to see and potentially answer your question - it can also answer the question for someone else that may be wondering the same thing!
6. Don't expect a direct answer from me (although sometimes you'll get one)
This is something I do that comes from my time working as a tutor in college - I like to provide guides toward the answer and not outright answers to questions (Teachable Moments™).
For example, if someone's loop isn't working as expected I would guide them to try adding a console.log() to their code to try and help them understand the issue instead of simply looking for the problem to disappear. In coding I think this is particularly helpful for building a toolbox of debugging approaches over time to be able to quickly solve your own problems 🥳
Top comments (1)
Great article, it's really an underrated skill. As a maintainer of a pretty large open source online learning community, this is something we have to sort of drill into folks once they get the courage to ask :) thanks for this!