Debugging is one of the most important skills of a software engineer. Learn 7 techniques, strategies, and tools for debugging as a modern web developer. 

#programming #learntocode #software 

💬 Chat with Me on Discord

https://discord.gg/fireship

🔗 Resources

Testing in 100 Seconds https://youtu.be/u6QfIXgjwGQ
VS Code Tips https://youtu.be/ifTF3ags0XI
Crash Bandicoot Bug https://www.reddit.com/r/Games/comments/1pp4oj/how_a_loadsave_bug_in_crash_bandicoot_took_six/

🔥 Get More Content - Upgrade to PRO

Upgrade at https://fireship.io/pro
Use code YT25 for 25% off PRO access 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font

🔖 Topics Covered

- What tools to engineers use to prevent bugs?
- How do you catch bugs during software development?
- How do you learn debugging?
- How to use VS Code debugger
- How to console log in JavaScript
2024-02-04T05:18:36.785Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
f2a0445a-7bcc-4d77-a348-83d6c07a991a
7710770b67ad3c504419a2ea96d01f07b69868af98718b4ed6b1c002f7f39b29
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
The key to becoming an efficient programmer is to never write any bugs.
Unfortunately, that's virtually impossible.
When your code doesn't work as expected, 99% of the time, it's your own code to blame.
You cannot blame that on me.
However, about 0.99% of the time, it's the fault of somebody else on or team, and you can get pissed off at them accordingly.
But the other 0.0099% of time, it's a bug in some shady library you downloaded from npm, which means you'll have to open up an issue on its GitHub repo, or fix it yourself and open a pull request or just build your own new library from scratch.
However, the other 0.00099% of the time, it's the programming language or compiler itself to blame, in which case you'll need to get in touch with some people much smarter than yourself who determine it's not a bug with the compiler, but it's an edge case that happens point 0 00099% of the time and the actual hardware is to blame, like one transistor was placed just a few nanometers to the left, and that's why your website doesn't look quite right on a BlackBerry.
But the hardware people say it's not their fault, it's actually just an edge case that happens 0.00001 percent of the time where your code is just not compatible with the laws of quantum superposition due to a defect in the simulation in which we live.
In other words, it's God's will that that code shall not work.
Luckily, bugs like this are pretty rare.
And in today's video, we'll look at 7 versal debugging tips that every developer should be familiar with.
The first tip is to read.
That may seem stupidly obvious, but programmers want to get things done quickly tend to be overconfident in their understanding of what the hell the computer is actually doing, what'll often happen is you'll guess what a method or function is doing is based on its name.
But remember, there are only 2 hard problems in computer science, naming things and coming up with new original jokes for YouTube tutorials, like there might be a function called get random number, you automatically think it's always going to return a different number, but when you call it, it returns 3 every time.
It's not a bug because had you read the documentation, you'd know that 3 is a random number that was chosen by the developer in advance, gets who guaranteed that it was 100% random when he chose it with the roll of a die.
Reading documentation in advance is important, but developers also tend to skip right over error messages.
When first learning to code, you get these big cryptic error messages that seem totally overwhelming.
So instead of reading it, you just try to change up your code until the message goes away.
That might work sometimes, but you'd be much better off learning how to understand the error messages and go through a stack trace because that will eliminate the guesswork.
Now, most of the time, even after you read the error, you'll still have no idea what it's talking about.
Luckily, there's a very powerful tool that can help you translate it called Google.
But when it comes to error messages, you don't wanna just paste the entire error message with the full stack trace into Google.
Googling as a software engineer is an art form.
You wanna first parse the error and remove anything that's unique to your actual project, Google is pretty good at ignoring things that are unnecessary, but the more you can do to point it in direction, the better.
If the keywords from the air are pretty generic, you might also want to add the name of your language or framework to the beginning just to limit the number of results.
I couldn't imagine living without Google and Stack Overflow, but at some point you'll hit a wall and have to do some good old fashioned honest programming.
The easiest way to approach bugging is with logging, where you simply print out different pieces of data from your application to manually verify that it's running as expected.
It's not very sophisticated, but it works.
A JavaScript beginner might use console.
Log to print out every single variable, but your logger probably has more tricks up its sleeve.
Like, Java script has console count to keep a running counter in your code or timer to measure time and table to format things in a more user friendly away, you can also log at different levels like info, warning, and error to organize the priority of this data and use console dir to play it as a hierarchy, the bottom line is that logging is a perfectly acceptable way to debug and you should take some time to learn the full API of a logger in your language to maximize its efficacy.
The problem with logging though is that it gets harder and harder to do as your code grows larger and more complex.
Luckily, modern IDEs and editors have tools that can help you observe and execute your code at scale.
L, these tools are called debuggers, and there's one integrated directly into Versus Code.
It allows you to traverse through frames in the call stack, which means you can pinpoint the exact moment a bug occurs.
It's possible to pause the execution of your code at any time using a debugger statement or better yet, you can use the IDE to set up breakpoints that don't require need modifications to the actual code.
In addition, it eliminates the need to pollute your code with console logs everywhere because instead, you can just add log points is by clicking next to the line of code that you want to log.
So basically, a debugger is just a more sophisticated way to run and inspect your code.
Eventually, you'll find a bug that you just cannot fix.
When that happens, it can sometimes help to not focus on a solution, but figure out a way to reproduce the problem with a minimal amount of code.
Like, start an entirely new project where the only goal is to make this problem happen, and bonus points if you can reproduce it somewhere like Stackblitz, where anyone can run it instantly in a browser, creating a reproduction has several benefits.
1, there's a good chance you'll solve the problem when going through it, and 2, if you don't find the root problem, you now have an example that you can share with better programmers.
If you can't reliably reproduce a problem, it's nearly impossible for anyone else to help you out.
Unfortunately, not every bug can be reproduced, which is called a Heisenbug.
There's a great story about the Crash Bandicoot video game, where the load safe feature would work perfectly almost every time, but every once in a while it would time out and wipe out the entire memory card, after 6 weeks of trying to debug this one issue, they were eventually able to reproduce it by wiggling the PS one controller a certain way to corrupt the memory card, it was one of those rare cases where the hardware was at fault.
Another very common type of bug that is very frustrating is one that happens after your code was working perfectly before.
This is called a regression, which means you wrote some new code that something up.
At a certain point, it becomes impossible for a human to verify that everything works properly after every code change, and that's where automated testing comes in or test driven development.
I've made many videos in the past about testing, but the general idea is that you write code 2, make sure that your other code is working as expected.
Most importantly, it gives you the confidence that you're not introducing new bugs when you make changes, but it can also will help in the debugging process, when you encounter a bug, instead of trying to fix it right away, you can go straight to writing a test.
This forces you to be explicit about what you're actually trying to make the code due and in the process, you'll likely learn things about your code that you didn't understand previously.
And finally, after you get the test to pass, you'll be protected from reintroducing the is same bug, another way to catch bugs before they become a problem is to use a tool that performs some type of static analysis on your code.
In the case of JavaScript, the most common way to do that is to use TypeScript, which adds an entire type system on top of the language, which makes it far more difficult to introduce stupid bugs like using the wrong variable name somewhere or assigning the on data type because the TypeScript compiler won't even let you run your code when you make mistakes like this.
The drawback is that TypeScript can be a pretty big investment and you may not want to add it to your code base.
In that case, base, consider adding ESLint by itself to your project.
It also performs static analysis and attempts to improve your code quality and requires very little effort on your part.
Deck gives us 7 different ways to debug code, but I have one more bonus tip for you which is to turn off your computer and take a break.
If I had a dollar for every time I was fighting a bug then went and took a break and came back and immediately solved it, I would have a shitload of dollars.
I like to go outside, get some exercise, is bask in the sun and enjoy a smooth and flavorful Marlboro cigarette.
Marlboro may surprise you.
It's the filter cigarette with the unfiltered taste.
On second thought, you may want to skip the cigarette unless your goal is to die a horrible agonizing death.
And if you go to hell, the only programming language they have down there is Java.
Thanks for watching, and I will we'll see you in the next one.

Speaker 0: The key to becoming an efficient programmer is to never write any bugs. Unfortunately, that's virtually impossible. When your code doesn't work as expected, 99% of the time, it's your own code to blame. You cannot blame that on me. However, about 0.99% of the time, it's the fault of somebody else on or team, and you can get pissed off at them accordingly.

But the other 0.0099% of time, it's a bug in some shady library you downloaded from npm, which means you'll have to open up an issue on its GitHub repo, or fix it yourself and open a pull request or just build your own new library from scratch. However, the other 0.00099% of the time, it's the programming language or compiler itself to blame, in which case you'll need to get in touch with some people much smarter than yourself who determine it's not a bug with the compiler, but it's an edge case that happens point 0 00099% of the time and the actual hardware is to blame, like one transistor was placed just a few nanometers to the left, and that's why your website doesn't look quite right on a BlackBerry. But the hardware people say it's not their fault, it's actually just an edge case that happens 0.00001 percent of the time where your code is just not compatible with the laws of quantum superposition due to a defect in the simulation in which we live. In other words, it's God's will that that code shall not work. Luckily, bugs like this are pretty rare.

And in today's video, we'll look at 7 versal debugging tips that every developer should be familiar with. The first tip is to read. That may seem stupidly obvious, but programmers want to get things done quickly tend to be overconfident in their understanding of what the hell the computer is actually doing, what'll often happen is you'll guess what a method or function is doing is based on its name. But remember, there are only 2 hard problems in computer science, naming things and coming up with new original jokes for YouTube tutorials, like there might be a function called get random number, you automatically think it's always going to return a different number, but when you call it, it returns 3 every time. It's not a bug because had you read the documentation, you'd know that 3 is a random number that was chosen by the developer in advance, gets who guaranteed that it was 100% random when he chose it with the roll of a die.

Reading documentation in advance is important, but developers also tend to skip right over error messages. When first learning to code, you get these big cryptic error messages that seem totally overwhelming. So instead of reading it, you just try to change up your code until the message goes away. That might work sometimes, but you'd be much better off learning how to understand the error messages and go through a stack trace because that will eliminate the guesswork. Now, most of the time, even after you read the error, you'll still have no idea what it's talking about.

Luckily, there's a very powerful tool that can help you translate it called Google. But when it comes to error messages, you don't wanna just paste the entire error message with the full stack trace into Google. Googling as a software engineer is an art form. You wanna first parse the error and remove anything that's unique to your actual project, Google is pretty good at ignoring things that are unnecessary, but the more you can do to point it in direction, the better. If the keywords from the air are pretty generic, you might also want to add the name of your language or framework to the beginning just to limit the number of results.

I couldn't imagine living without Google and Stack Overflow, but at some point you'll hit a wall and have to do some good old fashioned honest programming. The easiest way to approach bugging is with logging, where you simply print out different pieces of data from your application to manually verify that it's running as expected. It's not very sophisticated, but it works. A JavaScript beginner might use console. Log to print out every single variable, but your logger probably has more tricks up its sleeve.

Like, Java script has console count to keep a running counter in your code or timer to measure time and table to format things in a more user friendly away, you can also log at different levels like info, warning, and error to organize the priority of this data and use console dir to play it as a hierarchy, the bottom line is that logging is a perfectly acceptable way to debug and you should take some time to learn the full API of a logger in your language to maximize its efficacy. The problem with logging though is that it gets harder and harder to do as your code grows larger and more complex. Luckily, modern IDEs and editors have tools that can help you observe and execute your code at scale. L, these tools are called debuggers, and there's one integrated directly into Versus Code. It allows you to traverse through frames in the call stack, which means you can pinpoint the exact moment a bug occurs.

It's possible to pause the execution of your code at any time using a debugger statement or better yet, you can use the IDE to set up breakpoints that don't require need modifications to the actual code. In addition, it eliminates the need to pollute your code with console logs everywhere because instead, you can just add log points is by clicking next to the line of code that you want to log. So basically, a debugger is just a more sophisticated way to run and inspect your code. Eventually, you'll find a bug that you just cannot fix. When that happens, it can sometimes help to not focus on a solution, but figure out a way to reproduce the problem with a minimal amount of code.

Like, start an entirely new project where the only goal is to make this problem happen, and bonus points if you can reproduce it somewhere like Stackblitz, where anyone can run it instantly in a browser, creating a reproduction has several benefits. 1, there's a good chance you'll solve the problem when going through it, and 2, if you don't find the root problem, you now have an example that you can share with better programmers. If you can't reliably reproduce a problem, it's nearly impossible for anyone else to help you out. Unfortunately, not every bug can be reproduced, which is called a Heisenbug. There's a great story about the Crash Bandicoot video game, where the load safe feature would work perfectly almost every time, but every once in a while it would time out and wipe out the entire memory card, after 6 weeks of trying to debug this one issue, they were eventually able to reproduce it by wiggling the PS one controller a certain way to corrupt the memory card, it was one of those rare cases where the hardware was at fault.

Another very common type of bug that is very frustrating is one that happens after your code was working perfectly before. This is called a regression, which means you wrote some new code that something up. At a certain point, it becomes impossible for a human to verify that everything works properly after every code change, and that's where automated testing comes in or test driven development. I've made many videos in the past about testing, but the general idea is that you write code 2, make sure that your other code is working as expected. Most importantly, it gives you the confidence that you're not introducing new bugs when you make changes, but it can also will help in the debugging process, when you encounter a bug, instead of trying to fix it right away, you can go straight to writing a test.

This forces you to be explicit about what you're actually trying to make the code due and in the process, you'll likely learn things about your code that you didn't understand previously. And finally, after you get the test to pass, you'll be protected from reintroducing the is same bug, another way to catch bugs before they become a problem is to use a tool that performs some type of static analysis on your code. In the case of JavaScript, the most common way to do that is to use TypeScript, which adds an entire type system on top of the language, which makes it far more difficult to introduce stupid bugs like using the wrong variable name somewhere or assigning the on data type because the TypeScript compiler won't even let you run your code when you make mistakes like this. The drawback is that TypeScript can be a pretty big investment and you may not want to add it to your code base. In that case, base, consider adding ESLint by itself to your project.

It also performs static analysis and attempts to improve your code quality and requires very little effort on your part. Deck gives us 7 different ways to debug code, but I have one more bonus tip for you which is to turn off your computer and take a break. If I had a dollar for every time I was fighting a bug then went and took a break and came back and immediately solved it, I would have a shitload of dollars. I like to go outside, get some exercise, is bask in the sun and enjoy a smooth and flavorful Marlboro cigarette. Marlboro may surprise you.

It's the filter cigarette with the unfiltered taste. On second thought, you may want to skip the cigarette unless your goal is to die a horrible agonizing death. And if you go to hell, the only programming language they have down there is Java. Thanks for watching, and I will we'll see you in the next one.
The key to becoming an efficient programmer is to never write any bugs. Unfortunately, that's virtually impossible. When your code doesn't work as expected, 99% of the time, it's your own code to blame. You cannot blame that on me. However, about 0.99% of the time, it's the fault of somebody else on or team, and you can get pissed off at them accordingly. But the other 0.0099% of time, it's a bug in some shady library you downloaded from npm, which means you'll have to open up an issue on its GitHub repo, or fix it yourself and open a pull request or just build your own new library from scratch.
However, the other 0.00099% of the time, it's the programming language or compiler itself to blame, in which case you'll need to get in touch with some people much smarter than yourself who determine it's not a bug with the compiler, but it's an edge case that happens point 0 00099% of the time and the actual hardware is to blame, like one transistor was placed just a few nanometers to the left, and that's why your website doesn't look quite right on a BlackBerry. But the hardware people say it's not their fault, it's actually just an edge case that happens 0.00001 percent of the time where your code is just not compatible with the laws of quantum superposition due to a defect in the simulation in which we live. In other words, it's God's will that that code shall not work. Luckily, bugs like this are pretty rare. And in today's video, we'll look at 7 versal debugging tips that every developer should be familiar with. The first tip is to read. That may seem stupidly obvious, but programmers want to get things done quickly tend to be overconfident in their understanding of what the hell the computer is actually doing, what'll often happen is you'll guess what a method or function is doing is based on its name. But remember, there are only 2 hard problems in computer science, naming things and coming up with new original jokes for YouTube tutorials, like there might be a function called get random number, you automatically think it's always going to return a different number, but when you call it, it returns 3 every time. It's not a bug because had you read the documentation, you'd know that 3 is a random number that was chosen by the developer in advance, gets who guaranteed that it was 100% random when he chose it with the roll of a die. Reading documentation in advance is important, but developers also tend to skip right over error messages. When first learning to code, you get these big cryptic error messages that seem totally overwhelming. So instead of reading it, you just try to change up your code until the message goes away.
computer science
programming
probability
artificial intelligence
logic
software
documentation
machine learning
software development
That might work sometimes, but you'd be much better off learning how to understand the error messages and go through a stack trace because that will eliminate the guesswork.
Now, most of the time, even after you read the error, you'll still have no idea what it's talking about. Luckily, there's a very powerful tool that can help you translate it called Google. But when it comes to error messages, you don't wanna just paste the entire error message with the full stack trace into Google. Googling as a software engineer is an art form. You wanna first parse the error and remove anything that's unique to your actual project, Google is pretty good at ignoring things that are unnecessary, but the more you can do to point it in direction, the better. If the keywords from the air are pretty generic, you might also want to add the name of your language or framework to the beginning just to limit the number of results. I couldn't imagine living without Google and Stack Overflow, but at some point you'll hit a wall and have to do some good old fashioned honest programming. The easiest way to approach bugging is with logging, where you simply print out different pieces of data from your application to manually verify that it's running as expected. It's not very sophisticated, but it works. A JavaScript beginner might use console. Log to print out every single variable, but your logger probably has more tricks up its sleeve. Like, Java script has console count to keep a running counter in your code or timer to measure time and table to format things in a more user friendly away, you can also log at different levels like info, warning, and error to organize the priority of this data and use console dir to play it as a hierarchy, the bottom line is that logging is a perfectly acceptable way to debug and you should take some time to learn the full API of a logger in your language to maximize its efficacy. The problem with logging though is that it gets harder and harder to do as your code grows larger and more complex. Luckily, modern IDEs and editors have tools that can help you observe and execute your code at scale. L, these tools are called debuggers, and there's one integrated directly into Versus Code.
google
programming
mining
languages
software
It allows you to traverse through frames in the call stack, which means you can pinpoint the exact moment a bug occurs. It's possible to pause the execution of your code at any time using a debugger statement or better yet, you can use the IDE to set up breakpoints that don't require need modifications to the actual code. In addition, it eliminates the need to pollute your code with console logs everywhere because instead, you can just add log points is by clicking next to the line of code that you want to log. So basically, a debugger is just a more sophisticated way to run and inspect your code. Eventually, you'll find a bug that you just cannot fix.
When that happens, it can sometimes help to not focus on a solution, but figure out a way to reproduce the problem with a minimal amount of code. Like, start an entirely new project where the only goal is to make this problem happen, and bonus points if you can reproduce it somewhere like Stackblitz, where anyone can run it instantly in a browser, creating a reproduction has several benefits.
fertility
1, there's a good chance you'll solve the problem when going through it, and 2, if you don't find the root problem, you now have an example that you can share with better programmers. If you can't reliably reproduce a problem, it's nearly impossible for anyone else to help you out. Unfortunately, not every bug can be reproduced, which is called a Heisenbug. There's a great story about the Crash Bandicoot video game, where the load safe feature would work perfectly almost every time, but every once in a while it would time out and wipe out the entire memory card, after 6 weeks of trying to debug this one issue, they were eventually able to reproduce it by wiggling the PS one controller a certain way to corrupt the memory card, it was one of those rare cases where the hardware was at fault. Another very common type of bug that is very frustrating is one that happens after your code was working perfectly before. This is called a regression, which means you wrote some new code that something up. At a certain point, it becomes impossible for a human to verify that everything works properly after every code change, and that's where automated testing comes in or test driven development. I've made many videos in the past about testing, but the general idea is that you write code 2, make sure that your other code is working as expected.
video gaming
games
logic
solutions
gambling
bugs
Most importantly, it gives you the confidence that you're not introducing new bugs when you make changes, but it can also will help in the debugging process, when you encounter a bug, instead of trying to fix it right away, you can go straight to writing a test. This forces you to be explicit about what you're actually trying to make the code due and in the process, you'll likely learn things about your code that you didn't understand previously.
And finally, after you get the test to pass, you'll be protected from reintroducing the is same bug, another way to catch bugs before they become a problem is to use a tool that performs some type of static analysis on your code. In the case of JavaScript, the most
bugs
common way to do that is to use TypeScript, which adds an entire type system on top of the language, which makes it far more difficult to introduce stupid bugs like using the wrong variable name somewhere or assigning the on data type because the TypeScript compiler won't even let you run your code when you make mistakes like this. The drawback is that TypeScript can be a pretty big investment and you may not want to add it to your code base. In that case, base, consider adding ESLint by itself to your project. It also performs static analysis and attempts to improve your code quality and requires very little effort on your part. Deck gives us 7 different ways to debug code, but I have one more bonus tip for you which is to turn off your computer and take a break. If I had a dollar for every time I was fighting a bug then went and took a break and came back and immediately solved it, I would have a shitload of dollars.
I like to go outside, get some exercise, is bask in the sun and enjoy a smooth and flavorful Marlboro cigarette. Marlboro may surprise you. It's the filter cigarette with the unfiltered taste. On second thought, you may want to skip the cigarette unless your goal is to die a horrible agonizing death. And if you go to hell, the only programming language they have down there is Java. Thanks for watching, and I will we'll see you in the next one.
tobacco
languages
marijuana
The key to becoming an efficient programmer is to never write any bugs. Unfortunately, that's virtually impossible. When your code doesn't work as expected, 99% of the time, it's your own code to blame. You cannot blame that on me. However, about 0.99% of the time, it's the fault of somebody else on or team, and you can get pissed off at them accordingly. But the other 0.0099% of time, it's a bug in some shady library you downloaded from npm, which means you'll have to open up an issue on its GitHub repo, or fix it yourself and open a pull request or just build your own new library from scratch. However, the other 0.00099% of the time, it's the programming language or compiler itself to blame, in which case you'll need to get in touch with some people much smarter than yourself who determine it's not a bug with the compiler, but it's an edge case that happens point 0 00099% of the time and the actual hardware is to blame, like one transistor was placed just a few nanometers to the left, and that's why your website doesn't look quite right on a BlackBerry. But the hardware people say it's not their fault, it's actually just an edge case that happens 0.00001 percent of the time where your code is just not compatible with the laws of quantum superposition due to a defect in the simulation in which we live. In other words, it's God's will that that code shall not work. Luckily, bugs like this are pretty rare. And in today's video, we'll look at 7 versal debugging tips that every developer should be familiar with. The first tip is to read. That may seem stupidly obvious, but programmers want to get things done quickly tend to be overconfident in their understanding of what the hell the computer is actually doing, what'll often happen is you'll guess what a method or function is doing is based on its name. But remember, there are only 2 hard problems in computer science, naming things and coming up with new original jokes for YouTube tutorials, like there might be a function called get random number, you automatically think it's always going to return a different number, but when you call it, it returns 3 every time. It's not a bug because had you read the documentation, you'd know that 3 is a random number that was chosen by the developer in advance, gets who guaranteed that it was 100% random when he chose it with the roll of a die. Reading documentation in advance is important, but developers also tend to skip right over error messages. When first learning to code, you get these big cryptic error messages that seem totally overwhelming. So instead of reading it, you just try to change up your code until the message goes away. That might work sometimes, but you'd be much better off learning how to understand the error messages and go through a stack trace because that will eliminate the guesswork. Now, most of the time, even after you read the error, you'll still have no idea what it's talking about. Luckily, there's a very powerful tool that can help you translate it called Google. But when it comes to error messages, you don't wanna just paste the entire error message with the full stack trace into Google. Googling as a software engineer is an art form. You wanna first parse the error and remove anything that's unique to your actual project, Google is pretty good at ignoring things that are unnecessary, but the more you can do to point it in direction, the better. If the keywords from the air are pretty generic, you might also want to add the name of your language or framework to the beginning just to limit the number of results. I couldn't imagine living without Google and Stack Overflow, but at some point you'll hit a wall and have to do some good old fashioned honest programming. The easiest way to approach bugging is with logging, where you simply print out different pieces of data from your application to manually verify that it's running as expected. It's not very sophisticated, but it works. A JavaScript beginner might use console. Log to print out every single variable, but your logger probably has more tricks up its sleeve. Like, Java script has console count to keep a running counter in your code or timer to measure time and table to format things in a more user friendly away, you can also log at different levels like info, warning, and error to organize the priority of this data and use console dir to play it as a hierarchy, the bottom line is that logging is a perfectly acceptable way to debug and you should take some time to learn the full API of a logger in your language to maximize its efficacy. The problem with logging though is that it gets harder and harder to do as your code grows larger and more complex. Luckily, modern IDEs and editors have tools that can help you observe and execute your code at scale. L, these tools are called debuggers, and there's one integrated directly into Versus Code. It allows you to traverse through frames in the call stack, which means you can pinpoint the exact moment a bug occurs. It's possible to pause the execution of your code at any time using a debugger statement or better yet, you can use the IDE to set up breakpoints that don't require need modifications to the actual code. In addition, it eliminates the need to pollute your code with console logs everywhere because instead, you can just add log points is by clicking next to the line of code that you want to log. So basically, a debugger is just a more sophisticated way to run and inspect your code. Eventually, you'll find a bug that you just cannot fix. When that happens, it can sometimes help to not focus on a solution, but figure out a way to reproduce the problem with a minimal amount of code. Like, start an entirely new project where the only goal is to make this problem happen, and bonus points if you can reproduce it somewhere like Stackblitz, where anyone can run it instantly in a browser, creating a reproduction has several benefits. 1, there's a good chance you'll solve the problem when going through it, and 2, if you don't find the root problem, you now have an example that you can share with better programmers. If you can't reliably reproduce a problem, it's nearly impossible for anyone else to help you out. Unfortunately, not every bug can be reproduced, which is called a Heisenbug. There's a great story about the Crash Bandicoot video game, where the load safe feature would work perfectly almost every time, but every once in a while it would time out and wipe out the entire memory card, after 6 weeks of trying to debug this one issue, they were eventually able to reproduce it by wiggling the PS one controller a certain way to corrupt the memory card, it was one of those rare cases where the hardware was at fault. Another very common type of bug that is very frustrating is one that happens after your code was working perfectly before. This is called a regression, which means you wrote some new code that something up. At a certain point, it becomes impossible for a human to verify that everything works properly after every code change, and that's where automated testing comes in or test driven development. I've made many videos in the past about testing, but the general idea is that you write code 2, make sure that your other code is working as expected. Most importantly, it gives you the confidence that you're not introducing new bugs when you make changes, but it can also will help in the debugging process, when you encounter a bug, instead of trying to fix it right away, you can go straight to writing a test. This forces you to be explicit about what you're actually trying to make the code due and in the process, you'll likely learn things about your code that you didn't understand previously. And finally, after you get the test to pass, you'll be protected from reintroducing the is same bug, another way to catch bugs before they become a problem is to use a tool that performs some type of static analysis on your code. In the case of JavaScript, the most common way to do that is to use TypeScript, which adds an entire type system on top of the language, which makes it far more difficult to introduce stupid bugs like using the wrong variable name somewhere or assigning the on data type because the TypeScript compiler won't even let you run your code when you make mistakes like this. The drawback is that TypeScript can be a pretty big investment and you may not want to add it to your code base. In that case, base, consider adding ESLint by itself to your project. It also performs static analysis and attempts to improve your code quality and requires very little effort on your part. Deck gives us 7 different ways to debug code, but I have one more bonus tip for you which is to turn off your computer and take a break. If I had a dollar for every time I was fighting a bug then went and took a break and came back and immediately solved it, I would have a shitload of dollars. I like to go outside, get some exercise, is bask in the sun and enjoy a smooth and flavorful Marlboro cigarette. Marlboro may surprise you. It's the filter cigarette with the unfiltered taste. On second thought, you may want to skip the cigarette unless your goal is to die a horrible agonizing death. And if you go to hell, the only programming language they have down there is Java. Thanks for watching, and I will we'll see you in the next one.
The
the
key
key
to
to
becoming
becoming
an
an
efficient
efficient
programmer
programmer
is
is
to
to
never
never
write
write
any
any
bugs.
bugs
Unfortunately,
unfortunately
that's
that's
virtually
virtually
impossible.
impossible
When
when
your
your
code
code
doesn't
doesn't
work
work
as
as
expected,
expected
99%
99%
of
of
the
the
time,
time
it's
it's
your
your
own
own
code
code
to
to
blame.
blame
You
you
cannot
cannot
blame
blame
that
that
on
on
me.
me
However,
however
about
about
0.99%
0.99%
of
of
the
the
time,
time
it's
it's
the
the
fault
fault
of
of
somebody
somebody
else
else
on
on
or
or
team,
team
and
and
you
you
can
can
get
get
pissed
pissed
off
off
at
at
them
them
accordingly.
accordingly
But
but
the
the
other
other
0.0099%
0.0099%
of
of
time,
time
it's
it's
a
a
bug
bug
in
in
some
some
shady
shady
library
library
you
you
downloaded
downloaded
from
from
npm,
npm
which
which
means
means
you'll
you'll
have
have
to
to
open
open
up
up
an
an
issue
issue
on
on
its
its
GitHub
github
repo,
repo
or
or
fix
fix
it
it
yourself
yourself
and
and
open
open
a
a
pull
pull
request
request
or
or
just
just
build
build
your
your
own
own
new
new
library
library
from
from
scratch.
scratch
However,
however
the
the
other
other
0.00099%
0.00099%
of
of
the
the
time,
time
it's
it's
the
the
programming
programming
language
language
or
or
compiler
compiler
itself
itself
to
to
blame,
blame
in
in
which
which
case
case
you'll
you'll
need
need
to
to
get
get
in
in
touch
touch
with
with
some
some
people
people
much
much
smarter
smarter
than
than
yourself
yourself
who
who
determine
determine
it's
it's
not
not
a
a
bug
bug
with
with
the
the
compiler,
compiler
but
but
it's
it's
an
an
edge
edge
case
case
that
that
happens
happens
point
point
0
0
00099%
00099%
of
of
the
the
time
time
and
and
the
the
actual
actual
hardware
hardware
is
is
to
to
blame,
blame
like
like
one
one
transistor
transistor
was
was
placed
placed
just
just
a
a
few
few
nanometers
nanometers
to
to
the
the
left,
left
and
and
that's
that's
why
why
your
your
website
website
doesn't
doesn't
look
look
quite
quite
right
right
on
on
a
a
BlackBerry.
blackberry
But
but
the
the
hardware
hardware
people
people
say
say
it's
it's
not
not
their
their
fault,
fault
it's
it's
actually
actually
just
just
an
an
edge
edge
case
case
that
that
happens
happens
0.00001
0.00001
percent
percent
of
of
the
the
time
time
where
where
your
your
code
code
is
is
just
just
not
not
compatible
compatible
with
with
the
the
laws
laws
of
of
quantum
quantum
superposition
superposition
due
due
to
to
a
a
defect
defect
in
in
the
the
simulation
simulation
in
in
which
which
we
we
live.
live
In
in
other
other
words,
words
it's
it's
God's
god's
will
will
that
that
that
that
code
code
shall
shall
not
not
work.
work
Luckily,
luckily
bugs
bugs
like
like
this
this
are
are
pretty
pretty
rare.
rare
And
and
in
in
today's
today's
video,
video
we'll
we'll
look
look
at
at
7
7
versal
versal
debugging
debugging
tips
tips
that
that
every
every
developer
developer
should
should
be
be
familiar
familiar
with.
with
The
the
first
first
tip
tip
is
is
to
to
read.
read
That
that
may
may
seem
seem
stupidly
stupidly
obvious,
obvious
but
but
programmers
programmers
want
want
to
to
get
get
things
things
done
done
quickly
quickly
tend
tend
to
to
be
be
overconfident
overconfident
in
in
their
their
understanding
understanding
of
of
what
what
the
the
hell
hell
the
the
computer
computer
is
is
actually
actually
doing,
doing
what'll
what'll
often
often
happen
happen
is
is
you'll
you'll
guess
guess
what
what
a
a
method
method
or
or
function
function
is
is
doing
doing
is
is
based
based
on
on
its
its
name.
name
But
but
remember,
remember
there
there
are
are
only
only
2
2
hard
hard
problems
problems
in
in
computer
computer
science,
science
naming
naming
things
things
and
and
coming
coming
up
up
with
with
new
new
original
original
jokes
jokes
for
for
YouTube
youtube
tutorials,
tutorials
like
like
there
there
might
might
be
be
a
a
function
function
called
called
get
get
random
random
number,
number
you
you
automatically
automatically
think
think
it's
it's
always
always
going
going
to
to
return
return
a
a
different
different
number,
number
but
but
when
when
you
you
call
call
it,
it
it
it
returns
returns
3
3
every
every
time.
time
It's
it's
not
not
a
a
bug
bug
because
because
had
had
you
you
read
read
the
the
documentation,
documentation
you'd
you'd
know
know
that
that
3
3
is
is
a
a
random
random
number
number
that
that
was
was
chosen
chosen
by
by
the
the
developer
developer
in
in
advance,
advance
gets
gets
who
who
guaranteed
guaranteed
that
that
it
it
was
was
100%
100%
random
random
when
when
he
he
chose
chose
it
it
with
with
the
the
roll
roll
of
of
a
a
die.
die
Reading
reading
documentation
documentation
in
in
advance
advance
is
is
important,
important
but
but
developers
developers
also
also
tend
tend
to
to
skip
skip
right
right
over
over
error
error
messages.
messages
When
when
first
first
learning
learning
to
to
code,
code
you
you
get
get
these
these
big
big
cryptic
cryptic
error
error
messages
messages
that
that
seem
seem
totally
totally
overwhelming.
overwhelming
So
so
instead
instead
of
of
reading
reading
it,
it
you
you
just
just
try
try
to
to
change
change
up
up
your
your
code
code
until
until
the
the
message
message
goes
goes
away.
away
That
that
might
might
work
work
sometimes,
sometimes
but
but
you'd
you'd
be
be
much
much
better
better
off
off
learning
learning
how
how
to
to
understand
understand
the
the
error
error
messages
messages
and
and
go
go
through
through
a
a
stack
stack
trace
trace
because
because
that
that
will
will
eliminate
eliminate
the
the
guesswork.
guesswork
Now,
now
most
most
of
of
the
the
time,
time
even
even
after
after
you
you
read
read
the
the
error,
error
you'll
you'll
still
still
have
have
no
no
idea
idea
what
what
it's
it's
talking
talking
about.
about
Luckily,
luckily
there's
there's
a
a
very
very
powerful
powerful
tool
tool
that
that
can
can
help
help
you
you
translate
translate
it
it
called
called
Google.
google
But
but
when
when
it
it
comes
comes
to
to
error
error
messages,
messages
you
you
don't
don't
wanna
wanna
just
just
paste
paste
the
the
entire
entire
error
error
message
message
with
with
the
the
full
full
stack
stack
trace
trace
into
into
Google.
google
Googling
googling
as
as
a
a
software
software
engineer
engineer
is
is
an
an
art
art
form.
form
You
you
wanna
wanna
first
first
parse
parse
the
the
error
error
and
and
remove
remove
anything
anything
that's
that's
unique
unique
to
to
your
your
actual
actual
project,
project
Google
google
is
is
pretty
pretty
good
good
at
at
ignoring
ignoring
things
things
that
that
are
are
unnecessary,
unnecessary
but
but
the
the
more
more
you
you
can
can
do
do
to
to
point
point
it
it
in
in
direction,
direction
the
the
better.
better
If
if
the
the
keywords
keywords
from
from
the
the
air
air
are
are
pretty
pretty
generic,
generic
you
you
might
might
also
also
want
want
to
to
add
add
the
the
name
name
of
of
your
your
language
language
or
or
framework
framework
to
to
the
the
beginning
beginning
just
just
to
to
limit
limit
the
the
number
number
of
of
results.
results
I
i
couldn't
couldn't
imagine
imagine
living
living
without
without
Google
google
and
and
Stack
stack
Overflow,
overflow
but
but
at
at
some
some
point
point
you'll
you'll
hit
hit
a
a
wall
wall
and
and
have
have
to
to
do
do
some
some
good
good
old
old
fashioned
fashioned
honest
honest
programming.
programming
The
the
easiest
easiest
way
way
to
to
approach
approach
bugging
bugging
is
is
with
with
logging,
logging
where
where
you
you
simply
simply
print
print
out
out
different
different
pieces
pieces
of
of
data
data
from
from
your
your
application
application
to
to
manually
manually
verify
verify
that
that
it's
it's
running
running
as
as
expected.
expected
It's
it's
not
not
very
very
sophisticated,
sophisticated
but
but
it
it
works.
works
A
a
JavaScript
javascript
beginner
beginner
might
might
use
use
console.
console
Log
log
to
to
print
print
out
out
every
every
single
single
variable,
variable
but
but
your
your
logger
logger
probably
probably
has
has
more
more
tricks
tricks
up
up
its
its
sleeve.
sleeve
Like,
like
Java
java
script
script
has
has
console
console
count
count
to
to
keep
keep
a
a
running
running
counter
counter
in
in
your
your
code
code
or
or
timer
timer
to
to
measure
measure
time
time
and
and
table
table
to
to
format
format
things
things
in
in
a
a
more
more
user
user
friendly
friendly
away,
away
you
you
can
can
also
also
log
log
at
at
different
different
levels
levels
like
like
info,
info
warning,
warning
and
and
error
error
to
to
organize
organize
the
the
priority
priority
of
of
this
this
data
data
and
and
use
use
console
console
dir
dir
to
to
play
play
it
it
as
as
a
a
hierarchy,
hierarchy
the
the
bottom
bottom
line
line
is
is
that
that
logging
logging
is
is
a
a
perfectly
perfectly
acceptable
acceptable
way
way
to
to
debug
debug
and
and
you
you
should
should
take
take
some
some
time
time
to
to
learn
learn
the
the
full
full
API
api
of
of
a
a
logger
logger
in
in
your
your
language
language
to
to
maximize
maximize
its
its
efficacy.
efficacy
The
the
problem
problem
with
with
logging
logging
though
though
is
is
that
that
it
it
gets
gets
harder
harder
and
and
harder
harder
to
to
do
do
as
as
your
your
code
code
grows
grows
larger
larger
and
and
more
more
complex.
complex
Luckily,
luckily
modern
modern
IDEs
ides
and
and
editors
editors
have
have
tools
tools
that
that
can
can
help
help
you
you
observe
observe
and
and
execute
execute
your
your
code
code
at
at
scale.
scale
L,
l
these
these
tools
tools
are
are
called
called
debuggers,
debuggers
and
and
there's
there's
one
one
integrated
integrated
directly
directly
into
into
Versus
versus
Code.
code
It
it
allows
allows
you
you
to
to
traverse
traverse
through
through
frames
frames
in
in
the
the
call
call
stack,
stack
which
which
means
means
you
you
can
can
pinpoint
pinpoint
the
the
exact
exact
moment
moment
a
a
bug
bug
occurs.
occurs
It's
it's
possible
possible
to
to
pause
pause
the
the
execution
execution
of
of
your
your
code
code
at
at
any
any
time
time
using
using
a
a
debugger
debugger
statement
statement
or
or
better
better
yet,
yet
you
you
can
can
use
use
the
the
IDE
ide
to
to
set
set
up
up
breakpoints
breakpoints
that
that
don't
don't
require
require
need
need
modifications
modifications
to
to
the
the
actual
actual
code.
code
In
in
addition,
addition
it
it
eliminates
eliminates
the
the
need
need
to
to
pollute
pollute
your
your
code
code
with
with
console
console
logs
logs
everywhere
everywhere
because
because
instead,
instead
you
you
can
can
just
just
add
add
log
log
points
points
is
is
by
by
clicking
clicking
next
next
to
to
the
the
line
line
of
of
code
code
that
that
you
you
want
want
to
to
log.
log
So
so
basically,
basically
a
a
debugger
debugger
is
is
just
just
a
a
more
more
sophisticated
sophisticated
way
way
to
to
run
run
and
and
inspect
inspect
your
your
code.
code
Eventually,
eventually
you'll
you'll
find
find
a
a
bug
bug
that
that
you
you
just
just
cannot
cannot
fix.
fix
When
when
that
that
happens,
happens
it
it
can
can
sometimes
sometimes
help
help
to
to
not
not
focus
focus
on
on
a
a
solution,
solution
but
but
figure
figure
out
out
a
a
way
way
to
to
reproduce
reproduce
the
the
problem
problem
with
with
a
a
minimal
minimal
amount
amount
of
of
code.
code
Like,
like
start
start
an
an
entirely
entirely
new
new
project
project
where
where
the
the
only
only
goal
goal
is
is
to
to
make
make
this
this
problem
problem
happen,
happen
and
and
bonus
bonus
points
points
if
if
you
you
can
can
reproduce
reproduce
it
it
somewhere
somewhere
like
like
Stackblitz,
stackblitz
where
where
anyone
anyone
can
can
run
run
it
it
instantly
instantly
in
in
a
a
browser,
browser
creating
creating
a
a
reproduction
reproduction
has
has
several
several
benefits.
benefits
1,
1
there's
there's
a
a
good
good
chance
chance
you'll
you'll
solve
solve
the
the
problem
problem
when
when
going
going
through
through
it,
it
and
and
2,
2
if
if
you
you
don't
don't
find
find
the
the
root
root
problem,
problem
you
you
now
now
have
have
an
an
example
example
that
that
you
you
can
can
share
share
with
with
better
better
programmers.
programmers
If
if
you
you
can't
can't
reliably
reliably
reproduce
reproduce
a
a
problem,
problem
it's
it's
nearly
nearly
impossible
impossible
for
for
anyone
anyone
else
else
to
to
help
help
you
you
out.
out
Unfortunately,
unfortunately
not
not
every
every
bug
bug
can
can
be
be
reproduced,
reproduced
which
which
is
is
called
called
a
a
Heisenbug.
heisenbug
There's
there's
a
a
great
great
story
story
about
about
the
the
Crash
crash
Bandicoot
bandicoot
video
video
game,
game
where
where
the
the
load
load
safe
safe
feature
feature
would
would
work
work
perfectly
perfectly
almost
almost
every
every
time,
time
but
but
every
every
once
once
in
in
a
a
while
while
it
it
would
would
time
time
out
out
and
and
wipe
wipe
out
out
the
the
entire
entire
memory
memory
card,
card
after
after
6
6
weeks
weeks
of
of
trying
trying
to
to
debug
debug
this
this
one
one
issue,
issue
they
they
were
were
eventually
eventually
able
able
to
to
reproduce
reproduce
it
it
by
by
wiggling
wiggling
the
the
PS
ps
one
one
controller
controller
a
a
certain
certain
way
way
to
to
corrupt
corrupt
the
the
memory
memory
card,
card
it
it
was
was
one
one
of
of
those
those
rare
rare
cases
cases
where
where
the
the
hardware
hardware
was
was
at
at
fault.
fault
Another
another
very
very
common
common
type
type
of
of
bug
bug
that
that
is
is
very
very
frustrating
frustrating
is
is
one
one
that
that
happens
happens
after
after
your
your
code
code
was
was
working
working
perfectly
perfectly
before.
before
This
this
is
is
called
called
a
a
regression,
regression
which
which
means
means
you
you
wrote
wrote
some
some
new
new
code
code
that
that
something
something
up.
up
At
at
a
a
certain
certain
point,
point
it
it
becomes
becomes
impossible
impossible
for
for
a
a
human
human
to
to
verify
verify
that
that
everything
everything
works
works
properly
properly
after
after
every
every
code
code
change,
change
and
and
that's
that's
where
where
automated
automated
testing
testing
comes
comes
in
in
or
or
test
test
driven
driven
development.
development
I've
i've
made
made
many
many
videos
videos
in
in
the
the
past
past
about
about
testing,
testing
but
but
the
the
general
general
idea
idea
is
is
that
that
you
you
write
write
code
code
2,
2
make
make
sure
sure
that
that
your
your
other
other
code
code
is
is
working
working
as
as
expected.
expected
Most
most
importantly,
importantly
it
it
gives
gives
you
you
the
the
confidence
confidence
that
that
you're
you're
not
not
introducing
introducing
new
new
bugs
bugs
when
when
you
you
make
make
changes,
changes
but
but
it
it
can
can
also
also
will
will
help
help
in
in
the
the
debugging
debugging
process,
process
when
when
you
you
encounter
encounter
a
a
bug,
bug
instead
instead
of
of
trying
trying
to
to
fix
fix
it
it
right
right
away,
away
you
you
can
can
go
go
straight
straight
to
to
writing
writing
a
a
test.
test
This
this
forces
forces
you
you
to
to
be
be
explicit
explicit
about
about
what
what
you're
you're
actually
actually
trying
trying
to
to
make
make
the
the
code
code
due
due
and
and
in
in
the
the
process,
process
you'll
you'll
likely
likely
learn
learn
things
things
about
about
your
your
code
code
that
that
you
you
didn't
didn't
understand
understand
previously.
previously
And
and
finally,
finally
after
after
you
you
get
get
the
the
test
test
to
to
pass,
pass
you'll
you'll
be
be
protected
protected
from
from
reintroducing
reintroducing
the
the
is
is
same
same
bug,
bug
another
another
way
way
to
to
catch
catch
bugs
bugs
before
before
they
they
become
become
a
a
problem
problem
is
is
to
to
use
use
a
a
tool
tool
that
that
performs
performs
some
some
type
type
of
of
static
static
analysis
analysis
on
on
your
your
code.
code
In
in
the
the
case
case
of
of
JavaScript,
javascript
the
the
most
most
common
common
way
way
to
to
do
do
that
that
is
is
to
to
use
use
TypeScript,
typescript
which
which
adds
adds
an
an
entire
entire
type
type
system
system
on
on
top
top
of
of
the
the
language,
language
which
which
makes
makes
it
it
far
far
more
more
difficult
difficult
to
to
introduce
introduce
stupid
stupid
bugs
bugs
like
like
using
using
the
the
wrong
wrong
variable
variable
name
name
somewhere
somewhere
or
or
assigning
assigning
the
the
on
on
data
data
type
type
because
because
the
the
TypeScript
typescript
compiler
compiler
won't
won't
even
even
let
let
you
you
run
run
your
your
code
code
when
when
you
you
make
make
mistakes
mistakes
like
like
this.
this
The
the
drawback
drawback
is
is
that
that
TypeScript
typescript
can
can
be
be
a
a
pretty
pretty
big
big
investment
investment
and
and
you
you
may
may
not
not
want
want
to
to
add
add
it
it
to
to
your
your
code
code
base.
base
In
in
that
that
case,
case
base,
base
consider
consider
adding
adding
ESLint
eslint
by
by
itself
itself
to
to
your
your
project.
project
It
it
also
also
performs
performs
static
static
analysis
analysis
and
and
attempts
attempts
to
to
improve
improve
your
your
code
code
quality
quality
and
and
requires
requires
very
very
little
little
effort
effort
on
on
your
your
part.
part
Deck
deck
gives
gives
us
us
7
7
different
different
ways
ways
to
to
debug
debug
code,
code
but
but
I
i
have
have
one
one
more
more
bonus
bonus
tip
tip
for
for
you
you
which
which
is
is
to
to
turn
turn
off
off
your
your
computer
computer
and
and
take
take
a
a
break.
break
If
if
I
i
had
had
a
a
dollar
dollar
for
for
every
every
time
time
I
i
was
was
fighting
fighting
a
a
bug
bug
then
then
went
went
and
and
took
took
a
a
break
break
and
and
came
came
back
back
and
and
immediately
immediately
solved
solved
it,
it
I
i
would
would
have
have
a
a
shitload
shitload
of
of
dollars.
dollars
I
i
like
like
to
to
go
go
outside,
outside
get
get
some
some
exercise,
exercise
is
is
bask
bask
in
in
the
the
sun
sun
and
and
enjoy
enjoy
a
a
smooth
smooth
and
and
flavorful
flavorful
Marlboro
marlboro
cigarette.
cigarette
Marlboro
marlboro
may
may
surprise
surprise
you.
you
It's
it's
the
the
filter
filter
cigarette
cigarette
with
with
the
the
unfiltered
unfiltered
taste.
taste
On
on
second
second
thought,
thought
you
you
may
may
want
want
to
to
skip
skip
the
the
cigarette
cigarette
unless
unless
your
your
goal
goal
is
is
to
to
die
die
a
a
horrible
horrible
agonizing
agonizing
death.
death
And
and
if
if
you
you
go
go
to
to
hell,
hell
the
the
only
only
programming
programming
language
language
they
they
have
have
down
down
there
there
is
is
Java.
java
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
we'll
we'll
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speakers emphasize the importance of efficient programmer and the use of a framework for better code performance. They recommend reading and downloading documentation, checking error messages, and logging to debug. The speakers also suggest using a language and a framework for better code performance. Debuggers and tools are recommended for finding the perfect developer and avoiding unnecessary error messages. Different techniques and tools are used, including machines learning, code optimization, and the use of debuggers. Breaks are suggested to ensure code quality and the perfect developer.
how to never write bug
The key to becoming an efficient programmer is to never write any bugs. Unfortunately, that's virtually impossible. When your code doesn't work as expected, 99% of the time, it's your own code to blame. You cannot blame that on me. However, about 0.99% of the time, it's the fault of somebody else on or team, and you can get pissed off at them accordingly. But the other 0.0099% of time, it's a bug in some shady library you downloaded from npm, which means you'll have to open up an issue on its GitHub repo, or fix it yourself and open a pull request or just build your own new library from scratch. However, the other 0.00099% of the time, it's the programming language or compiler itself to blame, in which case you'll need to get in touch with some people much smarter than yourself who determine it's not a bug with the compiler, but it's an edge case that happens point 0 00099% of the time and the actual hardware is to blame, like one transistor was placed just a few nanometers to the left, and that's why your website doesn't look quite right on a BlackBerry. But the hardware people say it's not their fault, it's actually just an edge case that happens 0.00001 percent of the time where your code is just not compatible with the laws of quantum superposition due to a defect in the simulation in which we live. In other words, it's God's will that that code shall not work. Luckily, bugs like this are pretty rare. And in today's video, we'll look at 7 versal debugging tips that every developer should be familiar with. The first tip is to read. That may seem stupidly obvious, but programmers want to get things done quickly tend to be overconfident in their understanding of what the hell the computer is actually doing, what'll often happen is you'll guess what a method or function is doing is based on its name. But remember, there are only 2 hard problems in computer science, naming things and coming up with new original jokes for YouTube tutorials, like there might be a function called get random number, you automatically think it's always going to return a different number, but when you call it, it returns 3 every time. It's not a bug because had you read the documentation, you'd know that 3 is a random number that was chosen by the developer in advance, gets who guaranteed that it was 100% random when he chose it with the roll of a die. Reading documentation in advance is important, but developers also tend to skip right over error messages. When first learning to code, you get these big cryptic error messages that seem totally overwhelming. So instead of reading it, you just try to change up your code until the message goes away. That might work sometimes, but you'd be much better off learning how to understand the error messages and go through a stack trace because that will eliminate the guesswork. Now, most of the time, even after you read the error, you'll still have no idea what it's talking about. Luckily, there's a very powerful tool that can help you translate it called Google. But when it comes to error messages, you don't wanna just paste the entire error message with the full stack trace into Google. Googling as a software engineer is an art form. You wanna first parse the error and remove anything that's unique to your actual project, Google is pretty good at ignoring things that are unnecessary, but the more you can do to point it in direction, the better. If the keywords from the air are pretty generic, you might also want to add the name of your language or framework to the beginning just to limit the number of results. I couldn't imagine living without Google and Stack Overflow, but at some point you'll hit a wall and have to do some good old fashioned honest programming. The easiest way to approach bugging is with logging, where you simply print out different pieces of data from your application to manually verify that it's running as expected. It's not very sophisticated, but it works. A JavaScript beginner might use console. Log to print out every single variable, but your logger probably has more tricks up its sleeve. Like, Java script has console count to keep a running counter in your code or timer to measure time and table to format things in a more user friendly away, you can also log at different levels like info, warning, and error to organize the priority of this data and use console dir to play it as a hierarchy, the bottom line is that logging is a perfectly acceptable way to debug and you should take some time to learn the full API of a logger in your language to maximize its efficacy. The problem with logging though is that it gets harder and harder to do as your code grows larger and more complex. Luckily, modern IDEs and editors have tools that can help you observe and execute your code at scale. L, these tools are called debuggers, and there's one integrated directly into Versus Code. It allows you to traverse through frames in the call stack, which means you can pinpoint the exact moment a bug occurs. It's possible to pause the execution of your code at any time using a debugger statement or better yet, you can use the IDE to set up breakpoints that don't require need modifications to the actual code. In addition, it eliminates the need to pollute your code with console logs everywhere because instead, you can just add log points is by clicking next to the line of code that you want to log. So basically, a debugger is just a more sophisticated way to run and inspect your code. Eventually, you'll find a bug that you just cannot fix. When that happens, it can sometimes help to not focus on a solution, but figure out a way to reproduce the problem with a minimal amount of code. Like, start an entirely new project where the only goal is to make this problem happen, and bonus points if you can reproduce it somewhere like Stackblitz, where anyone can run it instantly in a browser, creating a reproduction has several benefits. 1, there's a good chance you'll solve the problem when going through it, and 2, if you don't find the root problem, you now have an example that you can share with better programmers. If you can't reliably reproduce a problem, it's nearly impossible for anyone else to help you out. Unfortunately, not every bug can be reproduced, which is called a Heisenbug. There's a great story about the Crash Bandicoot video game, where the load safe feature would work perfectly almost every time, but every once in a while it would time out and wipe out the entire memory card, after 6 weeks of trying to debug this one issue, they were eventually able to reproduce it by wiggling the PS one controller a certain way to corrupt the memory card, it was one of those rare cases where the hardware was at fault. Another very common type of bug that is very frustrating is one that happens after your code was working perfectly before. This is called a regression, which means you wrote some new code that something up. At a certain point, it becomes impossible for a human to verify that everything works properly after every code change, and that's where automated testing comes in or test driven development. I've made many videos in the past about testing, but the general idea is that you write code 2, make sure that your other code is working as expected. Most importantly, it gives you the confidence that you're not introducing new bugs when you make changes, but it can also will help in the debugging process, when you encounter a bug, instead of trying to fix it right away, you can go straight to writing a test. This forces you to be explicit about what you're actually trying to make the code due and in the process, you'll likely learn things about your code that you didn't understand previously. And finally, after you get the test to pass, you'll be protected from reintroducing the is same bug, another way to catch bugs before they become a problem is to use a tool that performs some type of static analysis on your code. In the case of JavaScript, the most common way to do that is to use TypeScript, which adds an entire type system on top of the language, which makes it far more difficult to introduce stupid bugs like using the wrong variable name somewhere or assigning the on data type because the TypeScript compiler won't even let you run your code when you make mistakes like this. The drawback is that TypeScript can be a pretty big investment and you may not want to add it to your code base. In that case, base, consider adding ESLint by itself to your project. It also performs static analysis and attempts to improve your code quality and requires very little effort on your part. Deck gives us 7 different ways to debug code, but I have one more bonus tip for you which is to turn off your computer and take a break. If I had a dollar for every time I was fighting a bug then went and took a break and came back and immediately solved it, I would have a shitload of dollars. I like to go outside, get some exercise, is bask in the sun and enjoy a smooth and flavorful Marlboro cigarette. Marlboro may surprise you. It's the filter cigarette with the unfiltered taste. On second thought, you may want to skip the cigarette unless your goal is to die a horrible agonizing death. And if you go to hell, the only programming language they have down there is Java. Thanks for watching, and I will we'll see you in the next one.
The speakers emphasize the importance of efficient programmer and the use of a framework for better code performance. They recommend reading and downloading documentation, checking error messages, and logging to debug. The speakers also suggest using a language and a framework for better code performance. Debuggers and tools are recommended for finding the perfect developer and avoiding unnecessary error messages. Different techniques and tools are used, including machines learning, code optimization, and the use of debuggers. Breaks are suggested to ensure code quality and the perfect developer.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : how to never write bug 
        and a small summary : The speakers emphasize the importance of efficient programmer and the use of a framework for better code performance. They recommend reading and downloading documentation, checking error messages, and logging to debug. The speakers also suggest using a language and a framework for better code performance. Debuggers and tools are recommended for finding the perfect developer and avoiding unnecessary error messages. Different techniques and tools are used, including machines learning, code optimization, and the use of debuggers. Breaks are suggested to ensure code quality and the perfect developer.
        [/INST]
        
        Generate the video : The key to becoming an efficient programmer is to never write any bugs. Unfortunately, that's virtually impossible. When your code doesn't work as expected, 99% of the time, it's your own code to blame. You cannot blame that on me. However, about 0.99% of the time, it's the fault of somebody else on or team, and you can get pissed off at them accordingly. But the other 0.0099% of time, it's a bug in some shady library you downloaded from npm, which means you'll have to open up an issue on its GitHub repo, or fix it yourself and open a pull request or just build your own new library from scratch. However, the other 0.00099% of the time, it's the programming language or compiler itself to blame, in which case you'll need to get in touch with some people much smarter than yourself who determine it's not a bug with the compiler, but it's an edge case that happens point 0 00099% of the time and the actual hardware is to blame, like one transistor was placed just a few nanometers to the left, and that's why your website doesn't look quite right on a BlackBerry. But the hardware people say it's not their fault, it's actually just an edge case that happens 0.00001 percent of the time where your code is just not compatible with the laws of quantum superposition due to a defect in the simulation in which we live. In other words, it's God's will that that code shall not work. Luckily, bugs like this are pretty rare. And in today's video, we'll look at 7 versal debugging tips that every developer should be familiar with. The first tip is to read. That may seem stupidly obvious, but programmers want to get things done quickly tend to be overconfident in their understanding of what the hell the computer is actually doing, what'll often happen is you'll guess what a method or function is doing is based on its name. But remember, there are only 2 hard problems in computer science, naming things and coming up with new original jokes for YouTube tutorials, like there might be a function called get random number, you automatically think it's always going to return a different number, but when you call it, it returns 3 every time. It's not a bug because had you read the documentation, you'd know that 3 is a random number that was chosen by the developer in advance, gets who guaranteed that it was 100% random when he chose it with the roll of a die. Reading documentation in advance is important, but developers also tend to skip right over error messages. When first learning to code, you get these big cryptic error messages that seem totally overwhelming. So instead of reading it, you just try to change up your code until the message goes away. That might work sometimes, but you'd be much better off learning how to understand the error messages and go through a stack trace because that will eliminate the guesswork. Now, most of the time, even after you read the error, you'll still have no idea what it's talking about. Luckily, there's a very powerful tool that can help you translate it called Google. But when it comes to error messages, you don't wanna just paste the entire error message with the full stack trace into Google. Googling as a software engineer is an art form. You wanna first parse the error and remove anything that's unique to your actual project, Google is pretty good at ignoring things that are unnecessary, but the more you can do to point it in direction, the better. If the keywords from the air are pretty generic, you might also want to add the name of your language or framework to the beginning just to limit the number of results. I couldn't imagine living without Google and Stack Overflow, but at some point you'll hit a wall and have to do some good old fashioned honest programming. The easiest way to approach bugging is with logging, where you simply print out different pieces of data from your application to manually verify that it's running as expected. It's not very sophisticated, but it works. A JavaScript beginner might use console. Log to print out every single variable, but your logger probably has more tricks up its sleeve. Like, Java script has console count to keep a running counter in your code or timer to measure time and table to format things in a more user friendly away, you can also log at different levels like info, warning, and error to organize the priority of this data and use console dir to play it as a hierarchy, the bottom line is that logging is a perfectly acceptable way to debug and you should take some time to learn the full API of a logger in your language to maximize its efficacy. The problem with logging though is that it gets harder and harder to do as your code grows larger and more complex. Luckily, modern IDEs and editors have tools that can help you observe and execute your code at scale. L, these tools are called debuggers, and there's one integrated directly into Versus Code. It allows you to traverse through frames in the call stack, which means you can pinpoint the exact moment a bug occurs. It's possible to pause the execution of your code at any time using a debugger statement or better yet, you can use the IDE to set up breakpoints that don't require need modifications to the actual code. In addition, it eliminates the need to pollute your code with console logs everywhere because instead, you can just add log points is by clicking next to the line of code that you want to log. So basically, a debugger is just a more sophisticated way to run and inspect your code. Eventually, you'll find a bug that you just cannot fix. When that happens, it can sometimes help to not focus on a solution, but figure out a way to reproduce the problem with a minimal amount of code. Like, start an entirely new project where the only goal is to make this problem happen, and bonus points if you can reproduce it somewhere like Stackblitz, where anyone can run it instantly in a browser, creating a reproduction has several benefits. 1, there's a good chance you'll solve the problem when going through it, and 2, if you don't find the root problem, you now have an example that you can share with better programmers. If you can't reliably reproduce a problem, it's nearly impossible for anyone else to help you out. Unfortunately, not every bug can be reproduced, which is called a Heisenbug. There's a great story about the Crash Bandicoot video game, where the load safe feature would work perfectly almost every time, but every once in a while it would time out and wipe out the entire memory card, after 6 weeks of trying to debug this one issue, they were eventually able to reproduce it by wiggling the PS one controller a certain way to corrupt the memory card, it was one of those rare cases where the hardware was at fault. Another very common type of bug that is very frustrating is one that happens after your code was working perfectly before. This is called a regression, which means you wrote some new code that something up. At a certain point, it becomes impossible for a human to verify that everything works properly after every code change, and that's where automated testing comes in or test driven development. I've made many videos in the past about testing, but the general idea is that you write code 2, make sure that your other code is working as expected. Most importantly, it gives you the confidence that you're not introducing new bugs when you make changes, but it can also will help in the debugging process, when you encounter a bug, instead of trying to fix it right away, you can go straight to writing a test. This forces you to be explicit about what you're actually trying to make the code due and in the process, you'll likely learn things about your code that you didn't understand previously. And finally, after you get the test to pass, you'll be protected from reintroducing the is same bug, another way to catch bugs before they become a problem is to use a tool that performs some type of static analysis on your code. In the case of JavaScript, the most common way to do that is to use TypeScript, which adds an entire type system on top of the language, which makes it far more difficult to introduce stupid bugs like using the wrong variable name somewhere or assigning the on data type because the TypeScript compiler won't even let you run your code when you make mistakes like this. The drawback is that TypeScript can be a pretty big investment and you may not want to add it to your code base. In that case, base, consider adding ESLint by itself to your project. It also performs static analysis and attempts to improve your code quality and requires very little effort on your part. Deck gives us 7 different ways to debug code, but I have one more bonus tip for you which is to turn off your computer and take a break. If I had a dollar for every time I was fighting a bug then went and took a break and came back and immediately solved it, I would have a shitload of dollars. I like to go outside, get some exercise, is bask in the sun and enjoy a smooth and flavorful Marlboro cigarette. Marlboro may surprise you. It's the filter cigarette with the unfiltered taste. On second thought, you may want to skip the cigarette unless your goal is to die a horrible agonizing death. And if you go to hell, the only programming language they have down there is Java. Thanks for watching, and I will we'll see you in the next one.
        