how to never write bug 

To stop writing bugs, become a project manager. You'll transcend logic bugs and progress to the realm of misunderstanding whole product visions

"thou code shall not work" had me dying 🤣🤣

"in hell the only programming language they have is java" *will to live immediately restored*

I think this fits here; "if debugging is the process of removing software bugs, then programming must be the process of putting them in" Edsger W. Dijkstra

Another good tip: when you get a massive amount of compiler errors, only look at the first or last error, solve that and try to recompile. This can be a huge help to keep you focused on the right thing when working in languages like C++ and C#, where 1 thing is written wrong, and the compiler keeps chugging along trying no matter how confused it gets. Most of the errors are nonsense, and only 1 needs you to fix it (which I almost always have seen to be the first or the last error).

I was working on a microcontroller project and I had this strange bug that took me weeks to fix. What I learned is that the branch prediction hardware while executing assembly code was different for 2 different chips that were the exact same except for the temperature rating. I looked through the errata for the chips and nothing was documented about it. The way the bug worked was on the chip with the slightly higher temperature rating, only during specific interrupt routines, certain instructions would take 4 clock cycles on 1 chip and only 3 on another chip, making my timing-critical application take 1/3rd longer only during very specific times. I looked through everything, the oscillator, the all the different registers for controlling the clock, the oscillator calibration registers that came factory calibrated with the chip, but in the end the 2 chips acted the exact same at every other time except for in that interrupt routine. One of the few cases I've found where it was literally my chip fabricator's fault my code didn't work.

One of my favourite quotes, kind of fits here: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." (c) Brian W. Kernighan

This guy is so good at sharing info while keeping us entertained. Kudos!

Write no code - write no bugs.

There are 3 things programmers struggle with: 1. Naming variables 2. Off by one errors

I can't stress enough on how important the bonus tip is! There have been a lot of times when I couldn't solve some issue for days, but as soon as I took a break and went out without thinking about it and came back, I solved it instantly!

The biggest thing when debugging you should ALWAYS remember is: don't. assume. ANYTHING. It's when you start assuming things that you start reading over bits that will be important. If there's a really tough bug to squash, just resort to rubber ducking. It'll be worth it in the end.

this is extremely solid advice that should be given to every entry level developer.

Taking a break with an issue helps a lot. I spent forever yesterday trying to determine why something wouldn't work. Took a 5 minute walk. Came back and turns out I forgot a letter.

Plays stock footage of Logging whilst talking about Logging. Simply genius level of content making from Fireship once again!

Great tips, for the first ones around googling your problem, I've used that approach for a long time but I've seen a lot of people that just straight up copy paste everything and then wonder why they haven't found anything.

One useful tip to avoid bugs, never update your IDE in the middle of a project to the latest version, some new "features" usually break your working code

There was a team in a Nordic programming competetition with the amazing name of "the floor is made of Java". Just feelt the world needed to know this.

Can’t have bugs if you don’t have any code. Big brain strategy.

Testing: If you're solving an algorithmic problem, it's good to code a brute force solution as well, if only so you have a reference solution that you know is very likely to be correct. Then you can test your optimized solution(s) against the very likely correct brute force solution. Bonus points if you write a piece of code that generates test inputs, then you can get the expected output by feeding the generated input into the brute force solution.

I spent 5 days trying to debug an issue with one of our file storage methods. In the end it turned out to be a bug from the driver! Felt equally glad and pissed off that it wasn't something I did, but spent 5 days trying to solve it. Especially since you have to convince the code maintainers that is it is, in fact, from their code. I had to write an entire repo that just tests the very particular case where the bug was happening.

I must say you are producing content of high quality: short, concise, funny, engaging, educational (learning new stuff), and well animated. Kudos

Some of your best work. Required viewing for novice and experienced devs alike!

7:12 Best anti-smoke ad I've even seen!

"It's God's will that thou code shall not work" Definitely using this

From powershell I learned a useful rule for naming functions: always to include a verb followed by an (type of) object in the name. E.g.: showElement(elt) verifyIntInputValidity(elt) Array.getSome -> Array Array.ifSome -> bool (same as the existing Array.some) And there is not going to be so much confusion.

I always thought it was: There are only 2 hard problems in CS: 1) Cache invalidation 2) Naming things 3) Off by 1 errors 😂

Very nice XKCD reference 😛 But I believe RFC 1149.5 specifies 4 as the standard random number

1:50 I think that was in a Dilbert comic once

Your meme for overconfident is the perfect absolutely accurate way I see other programmers. I even thought I couldn't make it in this field being kind and humble and reading and asking questions. Although a lot of people at SO disagree with me.

New debugging tip: Copy and paste code to chat GPT 🤣🤣🤣

wait, you guys write code? I just write bugs.

Just a little fix, VSCode doesn't come with a built in debugger. It comes with a built in debugger interface with builtin javascript (or JS-like languages) support. Any other languages will require you to get the appropriate extension

I can't remember the last time I laughed thorough the full length of a programming video.

Last tip is truly priceless. Multiple times I’ve had to try and fail to fix a bug for hours, only to resolve it in minutes after taking a break.

I was working on microcontroller code. I added a function that draws a certain number of squares to a 16x2 LCD. That function drew arrows instead of squares. (Ascii 01111111 instead of the desired 11111111). When I put an if statement to check if the data was 01111111, it started putting boxes. So now there is an if statement thats says if(data== 0x7F){ data=0x7F } It works now and I'm not gonna touch it.

Your video editing skills are simply awesome! Not to forget the content really helps as well.

1:00 there should be 7 zeros after the decimal point, not six

The bonus part is wonderfully working most of the times, thanks.

I expected this to be a tutorial on how to defensively write code. I think the biggest hallmarks to being an experienced developer is that you write less bugs. Mostly because you spot them right away since you've seen them before, but also because you avoid common pitfalls and protect yourself from them before they happen. For example by utilizing design patterns or testing procedures you're unsure about before spaghettiing it into your code.

The first minute or a bit more is why I spent 20 minutes looking for this video in my yt history

If you don't write anything, you won't write bugs.

Thank you for mentioning some of the console methods. I thought I was alone.

how to never write bug? write code do good

That's probably the best opening of a tutorial I've ever seen : )

One thing you didn't mention is the Tanos' method. It's perfect whenever you have no idea how a big chunk of code works, but you need to fix a bug which is ideally producing some error message. The method requires you to comment out half of the code, then check if the error still persists. If it still persist, then you need to call Avengers and bring back that half of the code, but then you need to comment the other half. When you found your faulty half and still don't get where the error is, comment out a smaller half (a quarter to be precise) and so on

Amazing video, amazing humor, amazing advice!

“Thou code shall not work” 10/10 quote

always make sure that the function you are debugging is being called.

“take a break” is the best possible advice. Even just a brisk walk outside with fresh air

Great balance of humor and information👍🏻

Man, I searched for a vídeo like this when I started, and there were none. That's amazing

I've learned in my life as a programmer and a technician that one rule always prevails when it comes to troubleshooting, if your work has caused an issue...., check your own shit out (code, test setup, wiring, installation, etc.), because the mistake is almost always going to be yours.

Or sometimes the bug can be a DI scope bug in a tiny library called the *Azure Functions Runtime* Totally didn't cost me a day and a half of debugging to finally (and correctly) blame the runtime.

"thou code shall not work" lmao 😂😂

so much right about taking breaks when you get a bug or you got stuck progressing. the moment you try to solve a bug/problem in one stretch is going to be a chain of burnout. stay fly. good content

1:10 It should be "thy" instead of "thou" :)

"Oh yea that's my code, but I didn't write it" - Scary accurate quote from coworker

When I am on call, I think my day in life looks like entire video, debugging back to back... Awesome videos Jeff.

I spent two weeks on a bug. Two weeks! Took the weekend off, solved it in 10 minutes on Monday. That is the last time we'll be bringing that up. 😊

a few more, for good measure: • by far the quickest, simplest, and most efficient way to do something is **not to do it.** when writing a complex program, periodically check to see that everything you're doing is truly necessary. you would be surprised how often you find entire swaths of code that can be deleted. • if touching grass for a while and returning to the problem doesn't work, try explaining how your code works step by step to an inanimate object, such as a rubber ducky. very frequently, you will find that you catch the problem as you explain it. • unionize your workplace at the earliest opportunity. this also applies to other jobs. • avoid OOP at all costs. most things do *not* need to be objects. • If the language you're using is dynamically typed, such as Python, pretend that it isn't. don't change the type of data in a variable - do not be tempted. • ensure that your program has as little "state" as possible - keep track of everything that you have to, but no more. • your time is far more valuable than a computer's. don't worry about tiny micro-optimisations unless you *really* need to. • familiarize yourself with your language's standard libraries and save yourself the pain of wasting time writing your own, worse implementations. a lot of this can be summarized with a quote from Jack Diederich - "I hate code, and I want as little of it as possible in our product."

I appreciate these down-the-rabbit-hole explanations of how everything computers-related works

Sometimes bugs come from stackoverflow when you past code in.

Bonus bonus tip - Thinking about the bug in the loo activates strange debugging powers you didn't know you had. Trust me.

I usually work on embedded systems and you wouldn't believe how often I find library bugs

never I have ever got entertained while listening to anything related to coding. I was smiling the whole time. keep it up

cant have any bugs if your code breaks the compiler

After an introduction like that, I will feel ashamed to ever write an obvious bug but will laugh when I remember all the next times I will repeat that

I have had the 0.00000099% thing happen once. It took a team and a half weeks to figure it out.

There's also an edge case that happens 0.000000000000000001% of the times, where some cosmic radiation from outer space somehow made it through the Earth's atmosphere, passed right through your processor or memory and flight a bit from 0 to 1 or 1 to 0.

😂 that ending gave me a good belly laugh; thanks man. Great work as always!

his videos always make my day ngl

Expert level, #8 - Use Rollbar (Note: Co-founder of Rollbar, here)

The video starts here: 0:01 Thank me later

2:23 you shouldn't give away our secrets so readily...

wow, wasn't expecting to getRect by such a simple function

Yeah, I am glad I learn mainly from documentation and critical thinking. 😅 Much easier and better understanding overall. I would rather spend 1 - 3 days researching than 10 days of having to fix bugs with a likelihood of trashing the entire project.

watching this after i spent 5 mins to debug rust errors and 5 hours of nodejs weird errors like "throw foo || bar in main.js:1:123456 at d()" feels such a blessing

At 3:20 😂😂😂😂😂😂 { name : jeff, age :69, sex: true }

the marlboro part killed me!🤣🤣 almost more comedy than information - love it

The last 5 seconds cracks me up bad. Legendary

Half of bugs I deal with are due to edge cases on libraries The other half is due to changes in the product design that are rushed to be delivered

Fireship guy i think your videos are like the act of breathing for the developer world. much needed. I hope you continue this journey.

I'd add that if you are not sure whether a new piece of code will work or be bugged, it is reasonable to make a copy of main file and try it there, in case you add a lot and make a mistake somewhere deep in the code and have to review whole file for all interactions. Or make a separate file to test that specific feature before implementing it in actual file.

Excellent video! Shared it on Twitter!

That randomness joke was solid af. You still got it Fireship lol

Talking about quantum physics, you forgot the Heisenbug. The one which cannot be found when you try to find/debug/log it. 😅 Because the minimal difference in the execution path causes the race condition not to appear. Update: sorry. as mentioned by comments, it’s in the video 4:55 Note for me, watch to the end and then comment 🙈

Adding to #2, don't let yourself get numb to warnings/errors in the console. When a real one comes through it might get lost in the noise

I like the shade thrown at Java. I've been forced to use Java because I work a lot with graphs (neo4j). It constantly amazes me just how ugly the code is. The simple fact that you can't compare strings with the equals signs or overload the operators to fix it is insane to me. Having an extremely dated package manager that barely works (Maven) is the icing on the cake. Java measurably makes my life worse.

I've been scripting in Lua for a few years (JS for only a few months), fully self-taught meaning I make many mistakes. What I've realized works best for my workflow is to just make it work inefficiently first to have an idea of how I want it to work. Looking for alternative ways to run a specific piece of code is easy, since it isn't even close to completion. Then recreate everything in a well documented and well optimized way while adding user friendly debug or logging functionality just in case.

This is so much FUN watching your videos, thanks. Keep going !

At that stock footage of the dude smashing his computer with a hammer, did they really not worry about the lady getting micro shards in her eyes or something?

your sense of humor never fails me

I have recently found the last one very very helpful, just take a break from your code and get back after few minutes

The worst is when the error message have nothing to do with the actual error. Either because there is a try/catch somewhere that rethrow a different error without linking the original error. Or because the error shown was assumed by the developper to be something when it could be something else.

i really love this channel. It really helped me a lot when i wanted to give up coding. Fireship beyond ever more… keep it up

It’s worth mentioning that you can also place breakpoints in the browser itself if you’re trying so debug something that is for example already deployed code.

Great Video! LOL, in my programming experience I progressively "discovered" or "unlocked" each level up to 5 as I ran into increasingly difficult bugs. I'm gonna have to add testing and types/linters to my toolkit. Thanks!

For PHP PsySH is an absolute godsend. I miss it so much when in other languages.

Another best tip Convince the user “It’s not a bug ,it’s a feature “