how to never write bug

Key Takeaways

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 all me however about 0.99 of the time it's the pulse of somebody else on your team and you can get pissed off at them accordingly but the other .0099 of the 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 point zero zero zero zero nine nine percent 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 a compiler but it's an edge case that happens .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 point zero zero zero zero zero zero one 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 thou code shall not work luckily bugs like this are pretty rare and in today's video we'll look at seven universal 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 and tend to be overconfident in their understanding of what the hell the computer is actually doing what will often happen is you'll guess what a method or function is doing based on its name but remember there are only two 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 three every time it's not a bug because had you read the documentation you know that 3 is a random number that was chosen by the developer in advance 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 want to just paste the entire error message with the full stack Trace into Google Googling as a software engineer is an art form you'll want to 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 the right direction the better if the keywords on 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 debugging 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 JavaScript 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 way you can also log at different levels like info warning and error to organize the priority of this data and use console dir to display 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 these tools are called debuggers and there's one integrated directly into vs code it allows you to Traverse through frames in the coal 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 any 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 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 stack Blitz where anyone can run it instantly in a browser creating a reproduction has several benefits one there's a good chance you'll solve the problem when going through it and two 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 Heisenberg there's a great story about the Crash Bandicoot video game where the load say 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 six weeks of trying to debug this one issue they were eventually able to reproduce it by wiggling the PS1 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 to 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 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 do 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 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 may makes it far more difficult to introduce stupid bugs like using the wrong variable name somewhere or assigning the wrong 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 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 that gives us seven 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 and 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 see you in the next one