If you think you’ve found a bug on freeCodeCamp, please follow these steps to resolve your problem:

Reset the Code in the Editor

Try resetting the code in the editor using the reset button on the page. This will solve most of the issues if somehow you changed some code that is affecting the challenge in some way.

Resetting clears the code to its original state as it was when the challenge was first presented to you.

Use a Coding Keyboard or the App on Mobile

Try reading this article about How to use freeCodeCamp on a mobile phone. Or if you are using an Android device, check if the freeCodeCamp App has the feature you are wanting to use.

Do a Hard Refresh

If the page seems broken in any way, try to do a Hard Refresh of the page. This will update any old code that may have been cached in your browser.

If the freeCodeCamp website was recently deployed, and the issues come from that, this will be enough to fix it.

How to do an Hard Refresh

While on the problematic page, use the key combination below to trigger a hard refresh depending on your operating system:

• Windows: CTRL + F5
• Mac/Apple: Apple + Shift + R or Command + Shift + R
• Linux: F5

To learn more about this read: http://refreshyourcache.com/en/cache/ 73

Try Clearing Your Browser's Local Storage

Removing all your locally stored challenges will solve many problems related to the browser crashing on freeCodeCamp

In Chrome:

• On freecodecamp.org open your console
• Windows: Ctrl + Shift + J
• Mac OS: Cmd + Opt + J
• Go to resources tab (Chrome).
• There, click on the “Local Storage” link in the nav bar on the right.
• Delete all the entries on the right side, or run this command in your browser’s console to clear all entries from your localStorage: localStorage.clear();
• See if this solves your issue

How to remove a single challenge from Local Storage

Maybe you don't want to lose the code from other challenges or something like that. This method will remove only the problematic challenge from your browser's Local Storage.

In Chrome:

• On freecodecamp.org, open your developer tools.
• More tools > Developer tools (or Ctrl + Shift + I (Windows), Cmd + Opt + I (Mac))
• Navigate to the Resources tab
• Expand the Local Storage item in the left pane
• Select http://www.freecodecamp.org
• Find the challenge for which you wish to delete data in the right pane
• Right click the desired challenge and select Delete

In Firefox:

• On freecodecamp.org, open your web console with
• Ctrl + Shift + K
• From there, using directly the console:
• Type console.log(localStorage); and hit Enter .
• Click in Storage link.
• The Storage panel will appear at right.
• Filter the results to find the Algorithm, Front End Project or Challenge causing the problem.
• When located, mouse over it and click the x at right.
• Once removed, check if the problem was solved. Refresh or close and open the browser if necessary.

Note: This can also be done with the Storage Inspector, but seems like Firefox hangs out when there are so many values.

Check if the issue is caused by one of your browser extensions

Try deactivating your browser extensions, or try to open the page in your browser private mode.

If in this way the issue is fixed, you will need to put in an exception for freeCodeCamp in the guilty extension, or keep it switched off while you are using the freeCodeCamp website.

Read the Support FAQs

The support FAQs offer solutions for many common issues. Try reading through that article if the steps above didn't work or were not related to your issue.

Ask for Help on the Forum

You may have arrived here and still have your issue. Now it's time to ask for help from other humans.

Open a topic on the forum describing your issue. Try to give as much info as possible, including your code and the challenge link, or the link to the page affected, and your operating system (if you are on a challenge, you can use the "Ask for help" button to create a precompiled post with these issues already included, to which you can add your description of the issue and eventual screenshots).

There may be something going on with your code, or there may be a briefly occurring issue with freeCodeCamp in general.

How to format code on the Forum

When you enter a code block into a forum post, precede it with a separate line of three backticks and follow it with a separate line of three backticks to make it easier to read.

You can also use the “preformatted text” tool in the editor (</>) to add backticks around text.

Create an Issue on GitHub

The forum may be able to help you, or may send you to GitHub.

Before creating a new issue on GitHub, try searching around the existing issues to see if someone has already reported something similar.

How to search an issue on GitHub

1. Go to freeCodeCamp’s Github Issues page.
2. Use the search bar to search for already filed issues that may be related to your problem.
3. If you find one, read it! You can subscribe to get updates about that specific issue by clicking on Subscribe in the sidebar. You can add a reaction on the posts that best describe your issue, or you can also comment on the issue if you have something to add.
4. If you cannot find any relevant issues you should create a new GitHub Issue.

How to create a new Issue on GitHub

IMPORTANT:
Before you report a new issue always get a third party confirmation from someone in the chat rooms or the forum. Remember that the issue tracker is strictly for reporting bugs or enhancements, it’s not a place to seek any help with solving the challenges.

Crafting a good issue will make it much easier for the dev team to replicate and resolve your problem. Follow these steps to do it right:

• Go to freeCodeCamp's GitHub Issues page and click on New Issue .
• Select the correct Issue type from the list

• Have a useful title. Write a meaningful title that describes the issue. Some good examples are Logging in from the News and Field Guide pages doesn't redirect properly (using e-mail) and Typo: "for" instead of "while" loop; bad examples include A bug, HELP!!!11 and I found this bug in a Challenge .
• Keep the title relatively short, as the description is for further information. One example is to shorten long Challenge names, so instead of writing Test case bug in 'Challenge: Check Radio Buttons and Checkboxes by Default' , you might want to write Test case bug in 'Radio Buttons' Challenge .
• In the body, provide a link to the page on which you encountered this issue.
• Describe the problem and provide steps so that a developer can try to replicate the issue. Include your operating system and browser version. When referencing other issues or pull requests, simply write #issue/pr-number.
• Paste in any relevant code using proper code formatting
• Take a screenshot of the issue and include it in the post.
• Click Submit New Issue and you are done! You will be automatically subscribed to notifications for any updates or future comments.

How to format the code on GitHub

You need to use three backticks before your code block, and three backticks after your code block.

You can also select your code block and use the button "Add code" in the GitHub editor.

In this way your code will be formatted and more legible.

Resources compiled and edited by Ilenia Magoni, freeCodeCamp author and Italian localization and community leader.

‌‌Whether you are a beginner or expert software developer, you probably find bugs in your code.

‌‌We all have bugs in our applications because no one knows everything about coding, and we sometimes make mistakes. After all, there is no way to stop being human.

‌‌Or can you show me how to develop a superpower? Ah alright then, never mind. :)

‌‌We can only study ourselves, our tools, and our bugs to find solutions that can help us be more efficient in reducing the bugs we create.

How can we deal with bugs?

There are three major ways to deal with bugs:

1. Prebugging: the reduction of bugs before they're created
2. Debugging: identifying, fixing, and removing bugs once you find them
3. Post-debugging: expecting unexpected or unknown bugs

Let's look at each one in detail.

What is Prebugging?

‌‌The late computer scientist Edsger W. Dijkstra said,

“If debugging is the process of removing bugs, then programming must be the process of putting them in.”

‌‌If we introduce bugs to a program through programming, that means we need to guide ourselves to reduce the number of bugs we introduce. I call this process of guiding ourselves "Prebugging".

‌‌I searched "define: debugging" on Google and the definition I saw from the Oxford Dictionary got me thinking.

‌‌This is the definition:

"[Debugging is] the process of identifying and removing errors from computer hardware or software."

‌‌What? Is that the only thing we do?

‌‌The definition got me thinking because I am sure a lot of software developers are proactive about debugging. They improve their tools and themselves to reduce the number of bugs they create in the first place.

Some ways we can do that:

1. Write program specs.‌‌
2. Learn to really understand the tools you use.‌
3. Learn to type accurately.‌
4. Familiarize yourself with error messages and their probable solutions.‌‌
5. Always make sure you have setups that are stable for most of the tools you use.‌‌

And a lot more!

‌‌The definition doesn't reflect all these aspects of debugging, and that forced me to think "Oh, no! Someone has to share all the things software developers do to reduce bugs."

‌‌Though the definition is acceptable for debugging, it downplays every other thing software developers do to reduce bug creation.‌‌ So let's go over those things now.

💥Learn the basic of the tools you use often

‌‌It is important to learn the basic of any tools you often use, because this helps you reduce the number of bugs you create while coding.

‌‌There is no way to avoid bug creation completely, but you can avoid creating some bugs if your knowledge of the basic of the tools you use is very sound.

‌‌For example, many JavaScript users can't remember what splice() returns. And some can't remember the difference between the map() and forEach() array methods.‌‌ What is the difference, anyway? Never mind! We're all guilty of it now and then.

‌‌If you are not a JavaScript user, just pick a built-in method or function from the language you use and ask yourself:

‌‌What kind of argument does this take? ‌‌What does this return? ‌‌What happens if an invalid argument is supplied?

‌‌Asking yourself the above questions about each of the built-in parts of whichever tool you use often can influence you to learn further and stay up to date.

‌‌That is how to keep yourself updated on the basics of the tools you often use especially if you don't have much time to read actively.

💥 Plan Before Coding

Programming can seem like a trial and error sport where you do it until you get it right.

‌‌Many beginner software developers don't truly understand the programs they are working on and some of them don't actually try to understand error messages before googling them.

Everybody now seems to feel that programming is always about "Code, Code, code, Search, Debug".

‌‌But it is necessary to really understand what you are doing so that you can quickly write out:

• What we expect to take as inputs as well as the structure and features of such inputs.‌‌
• What we expect to do with the inputs.‌‌
• What we expect to return or do in the end in relation to the inputs or other things.‌‌
• What we expect to do if the expected inputs are not given.

‌‌In short, planning the inputs, processes, and outputs of a function or program doesn't only help you reduce bugs but also helps you write efficient tests.

💥 Familiarize yourself with common error messages

It is often very easy to fix an error or a bug if you have familiarized yourself with that bug.

That is why it is important to take time to study some common errors and learn how to go about fixing them. Let's talk about some common errors now:

1. Syntax Errors

Every programming language has its own rules, and developers are liable to violate those rules.

‌‌Programming languages are strict about their rules and they will throw errors whenever those rules are violated.

Imagine, for example, that you omit the parentheses of a function or method like this:

function {}

An error will be thrown.

Familiarizing yourself with the error message of a syntax error and how to fix it will give you an edge while debugging it.

Personally, I have noticed that most syntax errors always mention some keywords that help you figure out the part of your code that is faulty.

let school = { 
name: "Harvard", 
location: "Heaven On Earth", admit: function() { return "weeew! You are admitted" } 
} 
console.log(school.names); // undefined

The "undefined" that's returned tells us whether the object or property we are accessing is not available. We can figure out where the problem is if we pay keen attention to the error message.

‌‌Now, let's take the example a bit further.

console.log(school.locations.address); // Uncaught TypeError: Cannot read property 'address' of undefined.

‌‌If we pay close attention to the error message, we can easily figure out where the bug is.

‌‌From the error message above, "Cannot read property 'address' of undefined" means that address is a property and a property is known to be in an object (in JavaScript). But in this case, the object is said to be "undefined".

‌‌The more you code the more you get better at avoiding syntax errors. You can also simply use code editors, linters, or IDEs that highlight syntax errors. Using these tools can help you a lot.

You can check out these code linters to see which one works best for your use case:

ESLint for JavaScript

PyLint for Python

Checkstyle for Java

PHP_CodeSniffer for PHP

Also, most of the popular code editors like VSCode can be configured to use the code linters above.

2. Logic/Semantic Errors

Logic errors are very tricky to deal with because they always seem like there is no error – but you still don't get the expected result.

For example, a simple way to confirm this kind of error is to check the code below in the browser's console.

‌prompt("enter number") + 3;

You may expect a number as an output, but it will return a string. In short, you will not get the expected result.

Planning before coding and understanding the basics of the programming language you use can help you deal with logical errors – provided you understand the program requirements given to you.

3. Compilation Errors

Your program may not compile because you might have violated some rules the compiler expect you to stick to. So, the program you are working on may not compile.

For example, writing a string without the usual quotes, as in const name = Ayobami, will lead to a compilation error because a string must be quoted. So, the code will not compile.

‌‌This is similar to syntax errors, and the more you code, the more you get better at dealing with compilation errors.

You can be more effective and reduce these errors by compiling or testing your code often.

4. Resource Errors

Sometimes, your program may exceed its memory limit or use up the available resources. That may lead your application to go out of service or malfunction.

The code below is a real-world example of code that leads to resource errors.

function factorial(num) {
  var result = 1;
  for(var i = num; i > 0; i--){
    result = num * factorial(num-1);
  }
  return result;
}

factorial(5);
factorial(10);
factorial(20);
factorial(0);

The function factorial() crashes or slows down the browser because the ‌‌stack space, that is the memory the browser allocates to the function call chain, is used up. The error, in this case, is a resource error because it occurs as a result of using up the allocated memory (resources).

5. Interface Errors

‌‌Sometimes we design program APIs to be used in certain ways but users use the programs differently and cause errors. Such errors are referred to as interface errors.

‌‌For example, let's say that the method go(string) expects a string but we call it with a number instead. That will lead to an error if the creator of the program doesn't expect and manage how the program should respond in such a case.

‌‌Most things in software follow standards. If your defined standards are not followed, you need to provide your users with error messages or guides to help them figure out they are using the application wrongly.

Documenting your APIs can help a lot in this case.

💥 Makes sure your setups are suitable for your tools

It is important to have a setup that is suitable for your tools. Sometimes, your OS may not be compatible with your applications – maybe because it requires a newer version of the OS or it requires a certain software.

For example, WampServer may not run properly on Windows OS if some Microsoft VC runtimes are missing on the computer. Similar things can also happen with Linux and macOS.

You just have to be sure your setup is suitable for whatever you do.

💥 Be deterministic about the functions of your program

‌‌"In mathematics, computer science and physics, a deterministic system is a system in which no‌‌ randomness is involved in the development of future states of the system.

A deterministic‌‌ model will thus always produce the same output from a given starting condition or initial state." - Source

‌‌Then, the question is, how do we make a deterministic program? ‌‌You have to be certain about the type of data that's acceptable in your program and reject any data that doesn't fit in.

‌‌In short, you need to take the expected data and reject unexpected data or notify your users about expected data.

💥 Don't use it if you don't understand It

‌‌One of the best ways to reduce the creation of bugs is to only use approaches, methods, and classes you understand. If you have to use any approach or style you don't understand, research it and be sure of what you are about to do before doing it.

‌‌It is easy to introduce unnecessary bugs to your application whenever you make use of things you don't understand.

💥 Learn to type accurately

Typing accurately is underrated, because programming is more about thinking than typing. But being accurate while typing may help you reduce some syntactic errors, type errors, or typos.

Many programming bugs are caused by simple typographical errors. Your ability to type accurately gives you an edge in reducing bugs.

💥 Watch fellow developers while debugging

‌‌Another interesting way to improve your debugging skills is to watch fellow developers while they are debugging. It helps to see different debugging methods, especially through their lenses.

‌‌There will always be tools or approaches we don't know about or use for debugging.‌‌ Watching others gives us the chance to discover the tools or approaches we may not be aware of.

Or even if you are aware of those different approaches, you might not know why or how to use them.

‌‌Watching others can influence us to revisit these approaches and tools that may eventually improve our debugging skills.

What is Debugging?

Debugging is at the core of programming, because it takes up the largest percentage of your time while coding.

There are three major phases involved in debugging:

1. Finding bugs.
2. Analyzing and understanding why bugs occur.
3. Fixing or removing bugs.

How to find bugs

Finding bugs starts with understanding the error messages you see.

It goes without saying that an error message is a pointer to a bug. If you understand the error message, you can track down the location of the bug with precision.

But some errors can be tiring because they may not have explicit error messages. We just may not get an expected result.

To find bugs, you need to:

• Be clear about your expectations.
• Check the results you get.
• Compare your expectations and the actual result to see what is missing.

You can use a debugger or other useful tools to find those errors fast.

You can then check different parts of your code against your assumptions and perform trial and error to find the bug.

How to Understand Why Bugs Occur

‌‌After finding a bug, you need to figure out why the code is behaving the way it does. Doing this helps you build an efficient system.

‌‌Instead many developers will just google and use the answers they get directly from StackOverflow.

‌‌That is fine in certain circumstances, but it is better to understand the cause of a bug and why the solution works.

‌‌Understanding the cause of a bug is an important step on the path to fixing it or removing the bug.

How to Fix or Remove Bugs

‌‌After finding and understanding the cause of a bug, we have to fix that bug. Sometimes, once you understand what the bug is, you'll simply find a solution without stress.

‌‌However, there are times when our understanding yields no solution no matter how hard we try.

‌‌Instead of wasting time, it is okay to Google the error message or whatever you feel is appropriate.

‌‌You can also ask another person because others tend to see things differently. They are neutral and that neutrality does help in fixing some bugs.

‌‌So, Google it!

‌‌Ask questions on StackOverflow, Twitter, or wherever you're connected to other developers.

‌‌It's okay! We all do those things a million times.

‌‌Fixing a worrisome bug always brings about great excitement. But don't get caught up too much in the excitement, as fixing a bug may cause another bug. So first make sure you have not introduced another issue to the program. That is why automated tests are important.

What is Post-debugging?

"Post-debugging" is about anticipating unexpected bugs in programs you've already written.

It refers to all the mechanisms you might use to ensure that unknown bugs are easily tracked down or managed before they harm the system or company.

The question now is how do you do that? Well, with an error tracking system.

You should have an error tracking system in production so that you can easily discover bugs as they emerge after pushing your application to production.

There are a lot of error trackers out there and they are just a bit of googling away. But here are a few you can check out:

• www.sentry.io
• www.honeybadger.io
• www.pypi.org
• www.airbrake.io
• www.logrocket.com

There are so many error trackers out there, you'll just have to research to discover what is best for you.

Conclusion

Debugging is a major skill that all software developers must cultivate. It is at the core of coding, and if you do it well, it can make you a better developer.

To be great at debugging, you must learn as much as you can about various debugging methods, many of which I've discussed here in this article.

It is time to be a great software developer and debugging can help you along the line.

Now, you only need to put everything into practice to be great at debugging and your software development skills will not be the same again.

About the author

Ayobami loves writing history with software development and is currently helping those who are struggling to understand and build projects with JavaScript through You Too Can Code.

"Fail to prepare, prepare to fail"

What better way to start an article than with an old cliche! Bug's and issues are going to pop up. There is simply no way of getting away from this (sorry). With some simple planning, there are ways in which we can minimize the complexity and number of problems we face.

Break the task up into smaller tasks

Now, I get it, we all like to get very excited and dive straight into our coding projects. The thing is, without some sort of plan we are creating problems for ourselves before we even start!

If I said to you, "you have to build a shopping list app", and you started coding straight away, what would happen? You would end up staring at a blinking cursor wondering how or what to do first, cursing my name under your breath for asking you to do such a task.

It's always easier to take a large problem and break it up into many smaller problems. For example, we can break the shopping list project into smaller tasks:

• Create a form to add an item to the list
• Allow a user to remove an item from the list
• Display a total number of items in the list

You can even break these tasks up into more detailed tasks. For example, for the first task in our list, our first, "little mini task" (should I trademark that term?) could be:

1) Create an input field to capture the item name

2) Create a button that calls a functions addToList() when clicked

3) Write logic within the addToList() function that adds the item to the list

And so on. You get the idea. I prefer breaking work up like this as it really makes me think about the problems I'll encounter early and the solutions (I've written an in-depth article about this here) before I've written any code. It also helps me understand what I'm trying to do, and puts me in the "zone". It's much easier to solve problems that arise when you understand what you are trying to achieve.

Be prepared to purge your code

To make an omelet, we have to break a few eggs. This means being prepared to completely re-write our code to get it working.

I bet you're thinking, "oh man, it took me days/weeks/millennia to get this far with my code, and now I have to delete it?!" Um, yeah. Sometimes. Sorry. The reality with web development is that code will change all the time, for various reasons - bugs, code reviews, changes in requirements, boredom, etc.

Sometimes we feel so precious about our code and can't bear to delete it, that we try and overcome problems by trying to "fit a round peg into a square hole". We think "NOO! I can't possibly delete this method. It took me forever. There has got to be a way!" This mental block causes our own problems - because by simply rewriting what we currently have, we could find the solution to our problems.

Now that we're nice and prepared, let's look at what happens when things do go wrong.

Error messages are good

What's worse than seeing an error message when something goes wrong? Not seeing any error message when something goes wrong. Even though it's a daunting feeling to see a big red stack trace when we run our carefully crafted code, error messages are there to say "yeah, things are messed up right now, but here are some places you can look to start fixing it".

If we have a look at this example:

let animals;

function addAnimal(){
    animals.push('elephant');
}

addAnimal();

Now let's have a look at the error:

TypeError: Cannot read property 'push' of undefined
at addAnimal (https://vanilla.csb.app/src/index.js:8:11) 
at evaluate (https://vanilla.csb.app/src/index.js:11:1) 
at $n (https://codesandbox.io/static/js/sandbox.acff3316.js:1:148704)

I've left out some of the stack trace as most of it is, well, gibberish. Depending on how your frontend project handles error messages, you may even see the error in your browser:

Look at that beauty of an error!

The important parts of the stack trace are usually at the top - the message, the function, and the line number, and our browser shows us this as well. So the interpreter does it's best to tell us what's wrong. It's a shame it can't solve the problem for us, eh?

So, we've finished having our panic attack at seeing the error and have picked some information from the error message. If we break it down we can see this line:

Cannot read property 'push' of undefined

This usually means that there is a variable not defined or initialized somewhere. BUT WHERE?!?

If we continue reading the stack trace, we see the error occurs within the addAnimal() function. We can see that we are trying to push a new animal to an array - ah! I forgot to initialize the animals array. Doh! Our fixed code looks like this:

let animals = [];

function addAnimal() {
    animals.push("elephant");
}

addAnimal();

The error thrown in the browser will show you the problem quicker, but not all frontend projects will be configured to do this, and backend developers do not have this luxury. This is why I recommend learning to read the stack trace.

To defeat the bug, you must think like the bug

The stack trace gives you an idea of what the error is. Well, sometimes it does and sometimes it doesn't. What if you see an error message that looks more like cave glyphs than English? Or what if there is no error, but your code is simply not acting as you thought?

It's time to get the debugger out. Let's walk through another example. But first some context!

Mr. Bob CEO (who is a CEO, who would have thought?!) approaches you and says,

"Hey, I have an amazing idea for a product.

• I want a web app that allows the user to enter a number.
• If the number is less than 5, the message should read "UNDER".
• If the number is equal to or more than 5, the message should read "OVER".

This is a million-dollar idea and I want you to build it for me".

"OKAY!" You say, and you get to work.

Coding montage with dramatic music plays as time fast forwards

You've completed the code for your web app. Huzzah!

<!doctype html>

<html lang="en">
<head>
  <meta charset="utf-8">

  <title>My super awesome number app</title>
  <meta name="description" content="The HTML5 Herald">
  <meta name="author" content="SitePoint">

</head>

<body>
    <input id="number-input"></input> <button id="number-input-submit-button">Submit</button>
    <div id="number-display">0</div>
    <script src="./index.js" type="text/javascript"></script>
</body>
</html>

(function () {
    const numberInputSubmitButton = document.getElementById("number-input-submit-button")

    numberInputSubmitButton.addEventListener("click", function () {

        const numberInputValue = document.getElementById("number-input").value;

        let text;
        if(numberInputValue > 5) {
            text = "OVER";
        } else {
            text = "UNDER";
        }

        document.getElementById("number-display").innerHTML = text
    });
})();

(Note: You may have spotted the bug already. If you did, let's pretend you didn't. If you haven't noticed the bug, that's OK.)

Time to start testing. Let's run through some use cases for our business logic.

1) User enters 3:

2) User enters 7

So far so good! But what happens if we enter 5?

OH NO! A bug! The text displayed is incorrect, it should display "OVER" but instead displays "UNDER". Hmm, no error messages, and I can't seem to see in the code what is wrong. Let's run the debugger and step through the code.

Using the debugger

Note the "variables" panel on the left - this can be a life saver

A good place to start is to put a breakpoint as close to the buggy code as possible. You can determine this by reading the code, error messages, or if you have that "ah-ha! I know which method is causing this" moment. From here, it's a case of stepping through the code, inspecting the variables, and checking if the correct code branches are run.

In our example, I have put a breakpoint at the start of my if statement - as this is where the failing logic is.

Once I start debugging, chrome opens and I can replicate the issue by entering "5" and clicking submit. This hits the breakpoint, and immediately there are a few things to note:

• The debugger stops at the breakpoint, so this means I'm on the right track
• This also means that the function is being called correctly, and event handlers are working as expected
• I can also see that the user input is being captured correctly (from the "variables" panel on the left-hand side, I can see that "5" was entered)

So far so good, no immediate issues to worry about. Well, code related ones anyway. Next, I'll press F10 to step through the code. This runs each statement individually, allowing us to inspect elements, variables, and other things at our own pace. Isn't technology just fabulous?

Remember since I expect the message "OVER" to appear when the user enters "5", I'm expecting the debugger to take me into the first branch of the if statement...

BUT NO! I'm brought into the second branch. Why? I need to amend the conditional to read "more than or equals to" as opposed to "more than".

if(numberInputValue >= 5) {
    text = "OVER";
} else {
    text = "UNDER";
}

Success! Our bug is fixed. Hopefully this gives you an idea on how to walk through the code, making use of VSCodes awesome debugging tools.

More Debugging tips

• If your breakpoints aren't being hit, this could be part of the issue. Make sure the correct functions or event handlers are being called in the way you expect
• You can step over functions you want to skip. If you want to debug any functions you come across, use the step into command
• Watch out for variables, parameters, and arguments as you are stepping through your code. Are the values what you expect?
• Write code in a way that is easier to read/debug. It might look cool to have your code on one line, but it makes debugging harder

Google is your friend

Ok so we've looked at the stack-trace, tried debugging, and we're still stuck with this bug. The only thing left to do now is make a sacrifice to the coding gods and hope things fix themselves!

Or I guess we could use Google.

Google is a treasure trove of software development problems and solutions, all at our fingertips. It can be sneakily difficult to access this information though, as you have to know how to Google the right things to get the right information! So how do we effectively use Google?

Let's look back to our first example - you've read the stack trace, looked at the code, but the message Cannot read property 'push' of undefined is still driving you mad. Bewildered, you take to Google in hopes of finding an answer. Here are some things to try:

Copy and paste the error message. Sometimes this works, depending on how "generic" the error message is. For example, if you get a Null pointer exception (who doesn't love those?), Googling "Null pointer exception" might not return very helpful results.

Search for what you are trying to do. For example, "How to create an array and add an item to the end". You might find some generous developer has posted a solution using best practices on StackOverflow, for example. You might also find this solution is completely different from yours - remember what I said about being comfortable purging your code?

A side note on using someone else's code - try and avoid blindly copying and pasting, make sure you understand what the code does first!

Ask for help the right way

Hopefully, after a mix of debugging, stack trace investigating, and Googling you have seen the light at the end of the tunnel and solved your problem. Unfortunately, depending on what you are trying to do, you still might be a bit stumped. This is a good time to seek advice from other people.

Now, before you run into the street screaming "my code is broken please help me!", it's important to know the best way to ask for help. Asking for help in the right way makes it easier for people to understand the problem and help you solve it. Let's look at some examples:

Bad - "My code is broken and I don't know what's wrong."

Good - "I'm trying to add an item to the end of an array in JavaScript, and I'm getting this error message: Cannot read property 'push' of undefined. Here's my code so far."

See how the "Good" example is much more informative? More information makes it easier for other kindhearted devs to help you out. This is a good habit to get into as it not only benefits you when you are learning to code but also in your first job when you need to ask for help.

So where can you ask for help?

• StackOverflow
• Twitter
• Slack groups
• Colleagues or developer friends

Quick Tip: You can use a tool like CodeSandbox.io or CodePen.io to recreate your problem and share it with people.

Practice, practice, practice

Just like Rome wasn't built in a day (well, it could have been for all I know) you will not become king bug squasher overnight. As your career goes on and your experience grows, you'll be armed with a wealth of knowledge that helps you solve bugs and issues faster. I regularly find myself saying "ah, I've solved that before" or "oh yeah, I have a StackOverflow link that helps me here" and the whole thing becomes a lot easier. So keep practicing, and this skill will grow naturally.

Thanks for reading! If you enjoyed this article, why not subscribe to my newsletter?

Every week I send out a list of 10 things I think are worth sharing — my latest articles, tutorials, tips and interesting links for upcoming developers like you. I also give out some free stuff from time to time :)

Didn’t we already fix that?

The question that you or your teammate would ask after the product manager posts a snapshot of the bug.

This whole event feels like a Deja Vu. You try to retrace the time you fixed that bug in the commits, but what’s the point?

The reality is if you don’t get to the root cause of the bug, it will come back like the Hydra of Lerna.

_Source: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Hercules_and_the_Hydra_of_Lerna-_Hercules_grasps_his_club_with_both_hands_and_confronts_the_seven-headed_hydra,_from_theseries%27The_Labors_of_Hercules%27_MET_DP832529.jpg" rel="noopener" target="blank" title=")

Here are some patterns that lead to immortal bugs.

Hardcoding a value

When we’re doing front-end development, we often use dummy data to build out the user interface quickly. That’s fine.

The problem is having dummy data at multiple locations. Then it’s easy to forget one or two when you push your code.

Here are some tips:

• Use a single variable for your dummy data and share it across different components
• Write a comment like // TODO: remove later to allow easy search later
• Don’t rely on backend data to always be the same

// ?

<img src={require(`./assets/${backendData.fileName}.png`)} />

// This will break if fileName is an unexpected string

// ?

let img;

try {

  img = require(`./assets/${backendData.fileName}.png`)

} catch(e) {  // Catch error if file doesn't exist

}<img src={img} />

// ?

<img src={backendData.imgUrl} />

Let’s Refactor Later

Your codebase will only grow larger and larger as you work on it. Your client or your boss won’t know the negative effect of not refactoring the code, because everything looks fine on the surface.

Plus, it’s always more satisfying to write something new and show it to other people. “Hey, check out what it can do now.”

So how do we know when to refactor the code?

According to [Refactor Guru](http://2018-10-28 14:00 21:00 2018-10 ¥300.00 7:00:00 -¥2,100.00 David Front-End Bug fixes: speaker/headphone control. Countdown timer based on start_time plus duration. Update call status from in_progress to ended), follow the Rule of Three

1. When you are doing something for the first time, just get it done.
2. When you are doing something similar for the second time, cringe at having to repeat but do the same thing anyway.
3. When you are doing something for the third time, start refactoring.

Keep everything in one file

This goes along with code refactor. When the project is fresh, it’s difficult to predict how large a feature will become.

In the past, I had a file that grew into thousands of lines of code. Refactoring that code is like performing surgery, delicate, but rewarding at the end.

Most people have a principle of how their project is structured. Separation of files by pages, features, dev. or production, private or public method, MVC model, etc.

How to structure a project folder is a large discussion by itself. I will save that for another article.

Don’t write specs for API

“Wait, why don’t the pictures show up anymore?” the product manager asks the front-end developers.

“Wait, why doesn’t the data have the picture_url anymore?” The front-end developer checks the console for network response.

“Oh yea, now the pictures come in three sizes. large_pic_url, med_pic_url, small_pic_url.” The back-end developer heard the discussion and jumped in.

Sounds familiar?

Everyone is trying to do their job. But synergy won’t happen in the silo. It’s everyone’s job to communicate what’s needed.

Here are some simple solutions to start.

• Before building an API, start with a JSON file of the data that both front-end and back-end developers have access to.
• When the API is completed, generate the document with https://github.com/apidoc/apidoc
• Notify of breaking changes before deployment

There are more sophisticated approaches to writing specs and handling documentation. And I would love to hear about what approach your team uses in the comment section.

Merge code without reading conflicts

Breaking things is less of a worry since you can always revert back to the previous commit.

It’s your or your teammate’s code disappearing during the process that’s the problem.

This often happens when you want to “save time” and move forward.

When in doubt, get in contact with the developer who made the commit that conflicts with yours.

When you mess up, git merge --abort or git-reset --hard.

When it breaks beyond repair, remove the project and clone it again.

Think twice when doing git push -f.

Fix a reusable component without testing

Reusable components are the magical trick up every developer’s sleeve. Like when the client pitches you the wireframe that contains the same date picker across several pages.

In your mind, you think, “I am going to make an awesome date picker component. Write less code. Do more.”

A few months later, the client says, “I want the date picker in this page to explode with fireworks and on other pages, different kittens to represent months”. Now you need the date picker to be more dynamic than it was.

Then after you make the changes, you discover that fireworks are coming out of the kittens.

If you are on a larger team, you can defer quality assurance to a different team.

But if there is no such functionality in your organization, you will have to do a global search for your component’s name to see what your component affects.

Make a note to yourself of those files. Test those file visually and functionally depending on what they do.

Anytime you say, “It’s fine for now”

You know you will have to go back to it later. The key is “don’t forget”

When you decide between speed of development and stability of the software, we must be careful not to always put speed as a top priority. It’s similar to driving a car without ever checking the condition of the car.

You can decide a ratio between speed and quality assurance. Maybe it’s two speedy iterations and one quality assurance iteration, whichever makes sense for your team.

Conclusion

• Avoid hardcoding a value if you can. If you have to, leave a note for yourself.
• Refactor when you’re doing the same thing for the third time.
• Split code and refactor often
• Front-end and back-end engineers must work together to agree on the data being passed around.
• If merge conflicts does not make sense to you, double check with the person who wrote the commit.
• When making changes to a reusable component, test for the location(s) where it’s being used.
• Find a healthy balance between speed and quality for your team.

While we’re here…

If you want to reach the 1 billion users of WeChat, you have to understand it first. Here’s a free glossary to get started.