The coding examples in this article are written in p5.js. But you can still follow along no matter what language you‘re using. 😀
It happens to all of us.
You’re coding along and things are going just fine.
Then you hit a wall in your logic and you start to feel stuck.
Maybe you’ve got a network of other coders who can help you with your problem. Or perhaps you’re reaching out to someone new.
On the TA team for Make School’s RAMP program, we help a lot of beginners.
Whether you’re struggling with untangling a confusing ‘if’ statement or trying to get the basics of using objects and classes, this article is going to help you get better at asking other programmers for help.
The three steps to asking for effective feedback
- Comment: Place clear, detailed comments in obvious places within your code (or accompany your code with a clear message if sending it out).
- Explain: Inform the other engineer what you already understand about the problem (c’mon, I know you understand something about it).
- Try: Let your fellow programmer know what you’ve already tried to solve the problem (make sure you try before you ask for help).
How to think about coding problems
Many times when you are communicating with someone who will read your code later, whether that be another programmer or your future self, you will use comments to leave messages inside of your code.
Every language denotes comments differently.
// ...look like this. Two forward slashes start the comment...
…and block comments (more than one line)…
...look more like this with a forward slash, then an asterisk to start the block. And an asterisk, then a forward slash to end the block. Remember to close the block properly or there might be issues later.
Comments are super fantastic, because they are free spaces where you can write whatever you want. Within a comment, normal coding syntax rules do not apply.
So how can I use a comment to effectively talk about my coding issues?
Let’s use an example to explore this.
In the above snippet, we have some p5.js code with objects and classes. We can see that on line 17, the programmer used a comment to ask for help.
But it is kind of hard to figure out what they already know about their code. And even though the problem with this code is fairly easy to spot, it might still be difficult to understand where their logic falls apart and why they might need help here.
This is where the explain and try portions of our communication comes in. We need to make sure our comments give details on:
- What our code is trying to accomplish
- Where we got stuck and (if you can) what you think the issue might be
- What we’ve already tried to solve the problem
NOTE: Yes, that means that even when you’ve got very few ideas on where to start, you should always give it a try on your own before asking someone else to help.
Explaining does a couple of good things for the person helping you.
- It shows them that you’re dedicated to solving the problem
- It prevents them from spending time explaining concepts that you already know
- It can prevent them from suggesting solutions that you have already ruled out
- It can help them show you different ways to think about the problem that might help you come up with a solution for yourself
And one last amazing thing that commenting this way can do:
It can help you debug your own bugs before you even reach out to another person!
There’s a concept in computer science called rubber duck debugging. Sometimes just by explaining what’s going on in your code in a detailed way to a rubber duck, another person, or in this case by writing it down, a lightbulb goes off in your head and you figure out a solution!
If you practice good comment writing, you might be able to see a solution for yourself before you even hit the send button.
Now that we know we know how to explain problems in our code and we’ve tried to fix them, let’s see how our snippet from above could be improved.
So let’s assume that our programmer here hasn’t gotten their lightbulb moment yet and analyze their changes.
- They moved their comment to the top of the file, so that we don’t have to chase it down. When you’ve got a big, long file with lots of nested code, this can be a time saver.
- They’re using a block comment, since they’ve got more than one line’s worth of things to say.
- They explained the problem clearly even though they’re unsure of the issue and tried solving the bug by looking for answers on the p5.js reference page.
You may have already spotted their typo on line 13, but now we also know that they’re having trouble using the p5.js reference site which is their primary documentation tool.
When I give them feedback to help them find the typo, I can also give them tips on using the p5.js documentation.
Now they will not only have code that produces the expected output (yay!🎉), but they will also be better equipped for more challenging problems in the future by knowing more about the documentation.