Solving Problems and Getting Help
A great benefit of hackathons is having access to mentors who can help you and your team solve a problem if you get stuck. You should definitely utilize this, as it’s a pretty great resource and not always available otherwise.
That being said, whenever you have an issue, try to see if you can figure it out yourself first. Your first instinct should not be to ask for help, it should be to use your favorite search engine to look for answers. Knowing what to search up can be tricky sometimes, but if you’re using a library or a framework, have you looked at the documentation? Popular libraries and frameworks usually have great documentation, and really make sure that if you’re following an example, check your code to make sure you’re following that example line by line. Understanding what’s going on in that code is also extremely important, because it will help you debug later on. Blindly copying and pasting may be faster in the beginning, but when you get stuck, you won’t know why or how. In the long run, it’s going to slow you way down. Looking at example implementations is also a huge help.
If you get an error printed out from executing your code or installing libraries/packages, look for that error on the internet and see if that can help you solve your problem. Look on stack overflow and other articles that pop up, and try those results. Sometimes, search results will not come up if you type in anything too specific to your code; strip out variable names or file paths from your error and see whether that returns more and better results for your issue.
If what you’re trying to solve is not an error that prints out as a result from running code, then try to concisely explain what your problem is and search that up. This is an extremely important skill to have, and you’re going to need it no matter whether you’re doing projects at hackathons or working in industry as a software engineer. I’m a software engineer and have been for the past five years, and a big part of my job is to google issues and figure out how to solve them accordingly. Stack overflow has a great resource of answers, and there are often many suggestions if one does not work.
Other than searching online, learning how to debug is important too. Across all programming, printing out information can be done. Do the arguments that you think are being passed into a function in reality what’s actually getting passed in? Is that function even being called? Put some print statements to see if what you think is happening is actually happening.
Using a debugger and pausing code is a great way to identify the problem too, and many IDE’s support this. Pausing code will allow you to see the local variables at that moment in time, which may or may not align with what you expect to be happening. Look up how to do this for the IDE that you’re using, or look at how to put “debugger” statements in the language you’re coding in if it supports doing so. Putting debugger statements right into the code means your code will automatically stop there if that code is getting run, so you don’t have to manually do it in your IDE. Debugger statements are not the same as print statements; debugger statements will automatically stop the code where you put the statement and not continue until you tell it to, whereas print statements will print but continue on with executing code. For example, in Javascript, if you type in “debugger” into your code, that is different than putting in a console.log().
If you’re doing front-end work, using Chrome debugger tools (right click on your web page in Chrome and choose inspect) is super powerful. With it, you can check what’s on your HTML page and edit CSS in real-time, look at errors that your code may be throwing in the “Console” tab, pause code in execution and look at source code in the “Sources” tab, as well as check network calls in the “Network” tab. Chrome inspector tools are a great way to help debug for front-end work.
After you’ve searched all the phrases you can think of and have tried all the ways you know how to debug yet are still stuck, then you should definitely feel empowered to ask for help from mentors. When you ask for help, don’t just say “I have a problem with [technology]”. Specifically describe your problem in one or two sentences, because from a mentor’s point of view, having a high-level understanding of the problem will allow us to decide whether we have the capacity to help you. It’s also not very helpful to just essentially say “I have a problem”. You’re asking for help; we know you have a question.
In asking for help, you should succinctly describe your problem. What technology are you using, and what’s the specific problem? What is specifically not working? For example, saying “Firebase is not working” is not going to help me help you figure out what’s wrong. What Firebase product are you using? In what way is it not working? “When I use Firebase Authentication, my users cannot log in.” This is better, because it gives me a general understanding of the situation, but can you be even more specific? “When I use Firebase Authentication, my users click on the log in button which successfully calls [function], but the user returned is empty.” This tells me exactly what technology you’re using and exactly what your problem is. Another way to approach asking questions is: if you were the mentor instead and you received the question you asked, would you understand what the problem is?
In receiving a question from hackers, my automatic first question is: have you searched it online already? Have you read documentation? Have you looked at examples of how other people have done what you’re trying to do? Honestly, most of the time after asking those questions, students are magically automatically able to figure it out themselves.
If you have already done all of what I asked in my questions, then I ask what you’ve tried and how you’ve tried to go about debugging. This gives me a better understanding of where you’re at and how we might go forward.
When I help hackers and people in general, I typically do not give answers out even if I already know what’s wrong. I try to help you figure out how to go about figuring out the answer to the problem so you can do it next time. I’ll tell you what I search online. I’ll tell you where we should perhaps print out variables or put debugger statements. I’ll end up asking you a lot of questions, more than I’ll be giving answers.
This is why, and it’s from personal experience. At work, it’s a lot more helpful to know how to arrive at the fix rather than just being given the fix. If someone tells me the fix straight up, I probably will not know how to come up with the fix if I have a similar issue next time. However, knowing why and truly understanding how the person debugged and came to the conclusion of what’s wrong will enable me to solve a similar issue. It may add an additional debugging skill to my toolbox.
My goal in helping you really isn’t to give you a fix on your issue. My goal is to help you learn how to figure out what’s wrong and give you more ideas on how to debug. My goal is for you to figure out what’s wrong for this problem and be able to figure it out again for any similar issues in the future. My goal is to make you a better problem-solver.
I press you to approach learning in this manner, because knowing how to solve problems is crucial. If you decide to pursue computer science and programming, your job basically is to solve problems — identifying exactly what the problem is and then being able to solve it. I’m giving you tools, tips, and ways to solve problems, hopefully to help you learn and gain more skills for the future.
