You might not know that you can solve most of your software or coding problems yourself and it is important that you do so rather than seek help directly from others. So the first thing to become more aware of is that it is possible to solve your own coding problems, and for many coding problems you can solve them easily and quickly. You just need to know how and practice and get better at debugging. It can actually be fun and rewarding.

It is important to know how to debug code. It is a skill that can be developed and improved. The more you debug code the better you get at it. It is like a muscle, the more you flex it and use it the better and stronger and faster you get at it.

Why is being good at debugging important?

The old fish story is applicable here:

Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.

If your code doesn't work you could ask a senior developer about it. So the senior developer uses his time to look at, understand and debug your code for you. He finds the problem and gives you the solution. You learn from it. That's good. But a bit later your code stops working and so you ask the senior developer about it and the senior developer looks at it, understands and debugs your code and you learn from it. And the cycle repeats. You do learn this way but it is not a good way to learn. You are reliant on others when you get stuck. You are stuck and stopped and have to wait until someone else can help you. You can't do anything new without someone else to help you. You are using up the valuable time of a senior developer. You might be a developer that was hired to solve problems, not find or create problems for others to solve. It doesn't have to be this way. If you are good at debugging then you can solve your own problems and be self-reliant. You will save tons of time and you won't be stopped when you start working on new things or using new technologies. The good thing is that debugging is a skill that you can learn and get better at.

You might have excuses for not solving problems or successfully debugging things, or maybe others have given you excuses. You will have to give up excuses. Notice you have excuses, if you have them, and let them go. The more you work on your debugging skills and work on debugging things yourself, the better you will get at debugging and solving things.

The benefit of being good at debugging goes beyond getting code to work. Debugging makes you more familiar with your code, other people's code, documentation and tools. Debugging increases your general knowledge and competency and confidence. All these things make you a better developer.

How do you actually debug?

The primary, fundamental thing about code that is not running as expected is that it means you don't know something.

Debugging means finding out what you don't know so you can know it and get your code working right.

Another way to say this is this:

Debugging is increasing your understanding with what you are working with so you make it work right.

Some people make random changes to code in hopes that it works now. That is not debugging. That's a waste of time. That indicates that a person doesn't understand the code in the first place, which is terrible. Nobody should be dealing with code they don't understand. The first step is to understand what you are dealing with. Anything that is done that helps you to understand more is valuable. Experimenting or changing code to see different outputs or results that helps you understand something better is valuable. Always aim for increasing your understanding. When you understand then you can solve with certainty.

I'm going to separate debugging into two separate areas: Lacking Knowledge and Oversight.

Lacking Knowledge

Lacking knowledge means that your code isn't working because you lack knowledge about the tools you are using. There could be code in your script you don't understand, a smart contract you are interacting with that you don't understand or you don't understand something about the execution environment (Hardhat or nodejs) or a library you are using, or configuration or other software running with your script, such as Hardhat Network. Or maybe you don't understand the error message you are getting.

The thing to do is increase your understanding of the code and tools you are using so you can use them correctly.

Any tradesman, musician, mechanic, technical person is expected to know his/her tools. A programmer is no different. Take some time everyday, if you can, to learn more about your programming language, libraries, smart contract standards, smart contracts, programming editor/IDE and other tools. Read documentation and buy and read books about your tools. Watch videos if you like to learn that way.

If your code throws an error then look at every part of the error and if there is an error message then ask yourself if you understand it or not. If you don't understand the error message then your next step is to find out what the error message means.

If you understand what the error message means but still don't understand why it is being thrown then look through your code and see if there is any code you don't understand or might not understand. You should understand all the code in your scripts and if you don't you should take action to understand it.

The best and easiest and most accurate way to learn about functions and features about your programming language and libraries and tools is to read the documentation about them.

Documentation is your best friend. For something you don't understand read the documentation about it. Here are the documentation sources for the tools and software we use:

• Javascript: https://developer.mozilla.org/en-US/docs/Web/JavaScript
• nodejs: https://nodejs.org/en/docs/
• Hardhat: https://hardhat.org/getting-started/
• Ethersjs: https://docs.ethers.io/v5/
• Solidity: https://docs.soliditylang.org/en/v0.8.4/
• Polygon: https://docs.matic.network/docs/develop/getting-started
• Aavegotchi: https://wiki.aavegotchi.com/
• AavegotchiDiamond: https://docs.aavegotchi.com/

Notice that Stack Overflow and other forum software is not on this list. Usually the documentation from a project is better, more accurate, than other sources so first seek the documentation of a project.

But sometimes what you need to understand or learn is not in the documentation of a project. That's when to use google or other search software and Stack Overflow and forums to find data that you need.

Sometimes the documentation or information you need isn't found searching it on Google or on forums etc. So search the Github issues for the project. It is also possible to look at the source code of the project to understand or get the data you need.

If you still can't find the data you need then there are a number of things you can do. You can create a github issue for the project. You can find the discord server for the project and ask your questions there.

If you still can't find the data you need then you can ask a senior developer. Don't say your code doesn't work and give little data. Ask for data that you need to solve and debug your own code. If you ask for data that is already in the documentation then a senor developer is going to wonder why you are asking him/her about something that is already answered in the documentation. So if you can't find answers in the documentation then it is good to say so. You could say something like this: "I could not find in the documentation [the question], do you know where documentation is for this?" If there isn't documentation for your question then it signals to the senior developer that he/she or someone should write documentation for that thing, which is useful.

Going to a senior developer for things that are already answered in the documentation for a tool is wasting the senior developers time and is wasting the time and effort of the person who wrote the documentation to answer or solve your problems. In addition getting things hand fed from a senior developer doesn't strengthen your debugging muscle and makes you dependent on others. It might save time but it doesn't make you as good as you could be.

Oversight

Sometimes code doesn't work not so much because we don't understand tools but because of some little mistake in code that we missed. Syntax errors and logic errors are examples of this. Sometimes these mistakes are very easy and fast to find and fix and sometimes they take longer to find and fix. The various debugging techniques can be used to find the source of code not working so it can be fixed.

Debugging Techniques

All debugging techniques should help you discover the cause for software not working correctly. It is not enough to just get software to run correctly. You need to understand why it wasn't working correctly. You need to know the cause, source of it working incorrectly. Only then can you be sure that you really fix the problem so it doesn't happen again.

Many debugging techniques help you find where in code a problem is. Once you know where in code a problem is you can focus your attention there to really understand the code there and find the source of a problem.

There are many debugging techniques. These are some of them. Please contact me about adding more if you have some good techniques.

Look at the Error Message

If you get an error then look at the error message. Often somewhere in the stack trace there is an error message that states what the error is. Use that. Also the error may say or indicate where in the code the error is. Looking at and using error messages is one of the most common and first approaches for debugging something.

Program a Little at a Time

When working with unfamiliar code or tools it is important to program a little at a time. Write a small amount of code. It could be a few lines of code. Then run the code. Use some print or console.log() statements to the show the results of your code execution to prove to yourself that your code does what you expect. If your code works then write a little more code and print out the results. If your code stops working correctly then you know where the problem is -- in the little amount of code you just wrote. Focus your attention on and increase your understand of that little bit of code you just wrote to find the source of the problem.

If you are handed code or script you are unfamiliar with and it doesn't work and you don't know why then you can use the "program a little at a time" technique to debug it. Create a brand new, blank script to start from. Copy a little amount of code from the start of the script you are debugging. Add some print/console.log statements and run the code. If it works then copy a little more code into your new script and run it. Keep doing this, little by little, until something breaks and then increasing your understanding of what breaks and fix it and continue programming little by little.
Also, make sure you understand any code you copy into your script. Perhaps the biggest sin in programming is writing or copying code you don't understand. Don't do that.

Follow the Logic

Sometimes code does not execute correctly because there is a logic error, meaning the code does something other than you think or expect. The way to solve this is to read the code of the script line by line starting at the beginning. Understand what each line does and see how each line logically follows the next line. This is executing a program in your mind.
Sometimes running the program in your mind as you read it is enough to notice that the code does something that does not make sense. Sometimes it is not enough because you don't understand the code well enough to do that. When it isn't enough to execute it in your mind then you can add print or console.log statements to the code to show the output and progress of the script. Check that the output corresponds to what you expect it to be. Prove to yourself that you understand what each line of code is doing by getting the expected output of print or console.log statements in your code.

Your script may call code or functions from another script or from a library or a third-party smart contract. Sometimes it is necessary when following the logic to jump to the source code of another script or library or smart contract to follow the logic there. This is necessary because the bug may be in the script or library that you are using or you need to follow the logic there so you understand what the script or library or smart contract is doing and how it affects the code you are writing.

Follow the logic can be used in combination with other debugging techniques like program a little at a time or divide or conquer.

A debugger can be used to follow the logic.

When things don't work follow the logic. The better you can follow the logic the more capable you are at finding out what is wrong.

Divide and Conquer

Sometimes you can have a bug or problem in your code but you don't know where it is. This can be solved by the divide and conquer approach. This approach is used to find where in code a problem is.

Comment out the last half of the script or code. Or add a statement in the middle of the code that kills the process. If the first half of the code runs correctly then you know that the bug/problem lies in the second half of the code. So if the first half of the code runs correctly then find the middle of the second half of the code and comment out the code from the middle to the end. Run the code. If the code runs correctly then you know the problem is in the commented out code. Or if running the code now shows up the bug then you know the section where the bug is and can further divide and conquer to further pin point it.

If the bug or problem shows up when running the first half of a script or code then you know the bug is in the first half of the code. Now you need to use the same approach on the first half of the code. Find the middle of the first half of the code and comment out from the middle to the end. See if the code works. If it does work then you know that the bug or issue is in the section that you just commented out and can further divide and conquer. If the code doesn't work then you know the problem or bug is in the first half of the code you just ran and you can further divide and conquer.

Once you have pin pointed much more closely where in the code the bug or problem is you can focus your attention there to find the bug or problem. You can write console.log statements to look at output to better understand what is happening. Look and increase your understanding of the section of the code where the bug is to find it and fix it.

There are other ways to debug by dividing and conquering. When you want to find out where a bug is look for ways to remove or divide code and run isolated code to see if the bug shows up.

Compare Code that Doesn't Work to Code That Works

If you have code that doesn't work but you don't know why and you have read the documentation about the code involved but it still doesn't work then one approach is to find code that does the same or similar thing that does work. Compare your code to code that works to find out what you are doing different.

There are many scripts and smart contracts in our repos that can be looked at. Google can be searched to find code that does something.

Change of Behavior

Sometimes code can be debugged by making changes to code and running it and observing changes or differences in results. This method of debugging gives you information about what the code is doing. It can give you clues to what is happening and the source of the problem. Remember that debugging is about increasing your understanding of the code and software so you can determine the cause of a problem.