Computers will, 100% of the time, without fail, do exactly what you tell them to do. It's getting them to do what you want them to do that's the real trick.
The gap between what you tell the computer to do and what you want the computer to do is where bugs are born and thrive.
As a moderator on the freeCodeCamp Discord, I frequently see people pop in to say, “I did everything exactly right but my code isn’t working!” These people know what they want their code to do. But they didn’t tell the computer how to do it properly.
To resolve their bug, they must align their desires — their mental model of their code’s behavior — with their code. Assumptions are the truses that preserve that gap.
The Problem with Assumptions
Let’s say that I'm working on a webpage and I want to set an element’s background to be blue. It’s not working as I desire. It’s setting the text color instead of the background color.
I engage my coworker for help. I say to her, “I told the computer to make the background blue. But it’s setting the text color instead!”
My problem is that I didn’t tell the computer to change the background color. I instead mistakenly used the color property. There’s no way that my coworker could know that I was using the wrong property. So my assumption prevented her from helping me.
The Components of a Great Question
Getting help takes effort. The more work you put into seeking help, the more likely you’ll be to obtain the help you need. In my experience, there are 3 components to a great question when you need technical assistance. Great questions contain all of these components.
The code that contains the problem
Any error messages you’re seeing
A description of the issue containing all of the following:
The exact steps to reproduce the issue
The expected result
The actual result
Below, I’ll break down each component in detail in case you’re not sure how to provide it when asking for help.
The Code that Contains the Problem
This is harder than it sounds. Frequently, the reason I fail to fix a bug by myself is that I’m looking in the wrong place. I may be looking in the wrong function, file, or even project! If I go to my coworker for help and only provide her the code that I think contains the problem, then she may not be able to help me out.
This means that it’s important to provide as much context as possible. This increases the chances that the code you share with the people helping you will contain the information they need to help you solve your problem.
Even with decades of experience coding, I frequently have doubts about how certain code will behave. Being able to run the code and experiment with it (add logs, attach a debugger, try different inputs, and so on) is a big part of my process.
There’s lots of ways you might transmit your code to someone to get some help. Here’s some examples:
For Large Projects
If you’re having trouble with a large project (something more than one file or more than a couple hundred lines of code). Then your best bet is to share a GitHub repo containing all the code.
Alternatively, you might create a “minimal reproduction.” If you can make the problem happen in the context of a small amount of code, then you can share that code instead. This can dramatically reduce the amount of work others need to do to help you and increase your chances of getting the answers you’re seeking.
Note: When working on a project for a client or employer, you might not be able to get help from outside sources due to your inability to share the relevant code. Don't share your employer’s or clients’ code publicly unless you have explicit permission to do so!
For Single File Projects
If your project is just one or two files or you’re creating a minimal reproduction of the issue, then you might be able to in-line your code in a chat message or create a GitHub Gist containing the relevant code.
Alternatively, you could use a tool like CodePen or StackBlitz to quickly generate a reproduction of the problem you’re facing.
For freeCodeCamp Lessons
Many of the questions I get on the freeCodeCamp Discord are regarding lessons in the learning platform (the curriculum). When asking a question about one of these lessons, make sure you include:
All the code from the editor panel (that is, all the code you have written or modified)
A link to the step
Without these two things, providing help gets dramatically harder.
Error Messages
When you’re a newer developer, error messages can be very intimidating. It’s understandable that you might skim over them as they don’t make sense and you’re not sure how to leverage them to solve your problem.
Reading your error messages carefully can be one of the first steps you take to becoming a stronger developer. But even if you don’t know what to make of the message, when seeking help, make sure you give others with experience in reading those messages the opportunity to do so. If there are any error messages in your console or terminal, copy/paste them in their entirety to your post asking for help.
Description of the Issue
When asking for help, you should consider that the person or people you’re asking might not have any context on your situation. It’s up to you to give them the context they need. To make sure you have given that context, include each of the following:
Steps to Reproduce the Issue
What, specifically, did you do that led you to encounter the problem you have? Be as detailed as possible here. Include things like, “I clicked the ‘Submit’ button,” or “I opened https://www.example.com in my browser.”
The Expected Result
Me: “My text is blue!”
My coworker: “That’s nice.”
My coworker wasn’t being dismissive of my problem. She just didn’t know whether it was a problem or not. Maybe I wanted the text to be blue. Maybe the blue text had nothing to do with my problem. Maybe the text only turns blue under certain circumstances.
If I had told my coworker that I expected the background to be blue rather than the text, she might have quickly realized what I did wrong and offered up a good suggestion on how to fix it.
The Actual result
Me: “I wanted my background to be blue!”
My coworker: “That’s nice.”
Forgetting to give the actual result is pretty much just as useless as forgetting to give the expected result. The expected and actual result of your code are both critical to a well-composed question.
When it comes to sharing actual results, screenshots or videos can be quite handy. Just make sure you’re not relying on them to the exclusion of the other components of a good question.
Example Question
Here’s an example of what putting all this guidance together might yield:
I'm on this step: https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures-v8/learn-introductory-javascript-by-building-a-pyramid-generator/step-33
I tried putting in this code:
for (iterator; condition; iteration) { }I expected it to pass, but instead, it gave me an error reading:
ReferenceError: iterator is not definedCan anyone help me figure out what I'm doing wrong? Here’s a screenshot of the step and error:
The question isn’t long, but it contains all the elements of a quality question as described by this article. It gives the code that contains the problem (including a link to the freeCodeCamp step), the error message that is shown, and the expectations (that it should pass) and actual result (that an error message is shown). It even includes a helpful screenshot showing how the error and result are presented.
Closing Thoughts
This feels like a whole lot of effort. I just want my problem solved. Do I really need to do all of this???
Short answer? Yes. But only because it’s less effort than engaging in a prolonged back and forth as the people trying to help you attempt to get this information. Not just that, but if you go through these steps and collect this information, you might even find that you solve your problem yourself without needing to engage others.
This process might feel tedious at first, but like many things in life, if you practice it regularly then it becomes easier.
You’ve got this. 😎