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
Programming is not just writing code alone. What we mean by programming is bugging the pc to do something. Debugging is the process to undo mistakes made by humans or circumvent hardware limitations and Issues. Programming is the whole thing. And being good at it is a whole other topic. ~Me XD
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).
oh god the issues I've run into with windows defining something such as "DELETE" in winnt.h, that then break multiple files with weird errors, when it all worked perfectly on linux or mac
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
That isn't even that far off... Whenever I started a new project, there were times where I literally went overboard with writing the new code bug free, trying to prevent past mistakes. What actually happened was that simply I created new bugs I had to learn to fix, because I didn't even understand how the fuck I created them in the first place.
Which is why I always try to simplify everything and if I feel that some approach is getting way too complicated I either restructure the entire thing or get more money to get the subsystem guys to change the way they are sending us data. I mean we could do it but I'll come back 3 months later trying to add a feat or fix a bug and curse myself for 2 days before figuring out what to do
exactly, you should only write code that is up to 33% of your capabilities of complexity, if it exceeds that you will be able to code it but not to debug it
no-code development is a thing... it either means you write *data* (configuration) instead, or you use GUI tools to build the behavior graphically instead of writing code
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.
@@undefinedvariable8085 Yes, if you even have a slight assumption, test it. Beat my head against a wall for ~20 minutes trying to fix one thing with a correct assumption, but assumed it was wrong so went way around it until it was all I had left.
I genuinely thought I was the only one who tried talking to myself when debugging hard stuff… ends up this rubber ducking is a commonplace in our field… 😐
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.
innit lol. i taught a friend to code like some basics and then check in with him some time later dedbugging somethin and catch him copying the PROBLEM from a stackoverflow question and trying to run it 😂😂 bro variable is not defined coz this is code is nothing to do with wtf u are doing lol 😭
Google-fu is a black art few learn well, but those who do, will find the exact stack overflow answer they need every time (unless it doesn't exist). But seriously, learning what parts of an error are worth using and when and how to use keywords in your search make finding answers much easier. I don't do js, but someone messaged me about a problem that involved settimeout inside a while loop. All I needed to google was "settimeout inside while loop js" and boom, the answer.
@@Bobbias sometimes it's almost baffling to me that apparently so few can't use google properly. It's the ultimate game changer if you also keep learning with each search and don't just try to copy paste answers.
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.
Relatable. It is like the more you push your brain to work harder to solve the bug the dumber it gets and creates more bugs. I always tell myself: next time something like this happens I am not gonna mash my keyboard with rage but take a break but I almost never comply.
I can not overstate how imporant taking a break is. I had an issue with my code yesterday for 3 hours searching every nook and crany in stack overflow for solution. Then i went to get lunch and on the road i figured out the solution. I only needed to add and modify a couple lines of code and voila the whole schmuck works.
I think I see another small joke/bug in the title how to never write bug < the original title how to never write "a" bug < missing the word "a" how to never write bug"s" < or missing an "s" at the end of bugs
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
Another tip that is very helpful in some situations especially when developing firmware. There is a type of breakpoint that fires when program accesses data. It is called watchpoint and you put it on variables. It is a life saver when some variable changes for no apparent reason and you have zero idea where this happens.
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.
@@vibaj16 Valid concern. In many cases, the test code can be as simple as assert solution_optimized(a) == solution_bruteForce(a) Of course, I'd do this for many inputs, a, to test the code on as many inputs as possible.
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 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.
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.
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.
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
Another thing to help you debug with logs is structural logging where you add context to each log statement - having context can help so much and it has saved us so much trouble because we assumed something that simply wasn’t true - the log itself didn’t contain enough of info but the surrounding data was able to give us so much context
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
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.
And not just because we know design patterns and test-driven development but simply because we've faced the same problems many times so we've learned how to solve them effectively.
@@charlesm.2604 I really hate it when the previous dev doesn't write tests though. Or writes tests for coverage without actually defending the purpose of their code with assertions. Bonus negative points when English is their second language or they are crap at naming their functions.
Unit testing is the best tool you'll ever get. Don't forget to test for errors and not for passing results. Sure it seems to slow your coding high, but if your project gets large, it's the contrary. It forces you to break your code into relevant testable components. Mocking data for tests helps understanding your code deeper. Time saver: It's also wonderful once you automate all tests. Example of a mono repo with a lot of common dependencies. Update one dep, rerun all tests for all modules in your repo. If anything breaks or changes, the unit tests will catch it for you. Documented clean tests can also serve as documentation for personal projects.
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.
I love the detailing at 0:36, Shows a picture of Bjarne Stroustrup, when he says "it's the programming language or compiler itself to blame" It's an insider joke of an insider joke. Bjarne Stroustrup's video has some one hilarious comments, two of which are "He lost his hair each time he got a bug while coding in cpp" and "If you can't code in other programming language, just write your own compiler to compile it" (or similar) It makes me genuinely laugh and smile to see such nerd and insider jokes, which i can't even share with anyone i know.
You can't write bugs if you don't write code ! More seriously, excellent video ! That's great advice. The use of loggers, linters and debuggers do save a lot of my time almost everyday.
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
often, commenting out an arbitrary section of code will cause more bugs further on in the program. that's why the Logging strategy is preferable, because there is (almost) no chance it will cause additional bugs.
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.
i am not a programmer and I watch all your videos the minute i see a new one... the more you can understand why a programmer hates life, the more friendly they are when you ask for their help... its awesome
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'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.
A few years ago I was watching my then-three-year-old while trying to get some work done. Kid goes, "There's a bug!" and I mutter instinctively "not a bug, it's a feature." Pause. Kid replies, "There's a feature crawling on the wall." Born PM, that nugget.
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.
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 first heard about functional programming from a joke in xkcd: "Code written in Haskell is guaranteed to have no side effects" / "...because no one will ever run it?" Nowadays, I defer execution like I'm the California penal system and am less willing to give things state than a Republican voting on DC or Puerto Rico.
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.
@@sergeyson423 After first few experiences when learning (specifically losing several days of updates in a solo project) I prefer to make several copies kept in different places just in case. We never know how software update or noob tampering can affect source control, especially one made hastily.
@@RandomizerYevhen But then again, that's exactly what source control helps you mitigate and avoid. Feature branching, separation of concerns, encapsulation, commit and blame histories; all of this makes it possible to revert, restore, stash, and switch around contexts. With the right git workflow for the right team, you should never have to store any physical backups locally.
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
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.
That part about a fault in our simulation, I literally just remembered a bug I once encountered that was baffling to me, but upon running the code again, it didn't happen. I can not remember where it was, but what I do know is the code that had a bug was never changed and is still being used today, and has been for years. I guess it really was God's will.
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 🙈
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.
0:16: It has happened to me twice, once with FFMPEG when manipulating audio or audio from videos that are in a certain format, it turned out that it is a fairly deep error in the engine
To stop writing bugs, become a project manager. You'll transcend logic bugs and progress to the realm of misunderstanding whole product visions
Lmao
Misunderstandings are bugs when we conmsider the human brain the hardware.
woah. I dream of this opportunity
"thou code shall not work" had me dying 🤣🤣
;)
Message to do things correctly or else you will eventually go to hell and be doing Java 🤣
@@harshsharmax25 Scala has saved me :)
unless thou runs on temple os
Should be “thy code shalt not work”
"in hell the only programming language they have is java"
*will to live immediately restored*
new Set(willToLive) 🤣
cobol programmers suddenly wanna die
The afterlife ain't looking so bad anymore :)
*suddenly become religious
I love Java
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
That Dijkstra guy cant tell me shit. I introduce another bug while debugging one.
Programming is not just writing code alone.
What we mean by programming is bugging the pc to do something.
Debugging is the process to undo mistakes made by humans or circumvent hardware limitations and Issues.
Programming is the whole thing.
And being good at it is a whole other topic.
~Me XD
Therefore, we have our answer: stop programming.
If debugging is the process of removing software bugs, isn’t bugging the process of introducing them in ? 😏
True. But most people add useful stuff too, hopefully with less new bugs 😅😂
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).
Thanks for the tip
I hate fixing bugs in c++ there are alot of linking errors and it's a nightmare to fix them
And if there's an insane amount of nonsensical errors, it means that the C header is missing a semicolon.
Same here I also use to do that same
oh god the issues I've run into with windows defining something such as "DELETE" in winnt.h, that then break multiple files with weird errors, when it all worked perfectly on linux or mac
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.
That’s such an obscure bug! Nice job on finding it
Please write about it somewhere! That sounds like hell to debug. Congratulations!
Problem is your boss watched this video and now he won't believe you.
Wow!
Zilog or Motorola?
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
That isn't even that far off...
Whenever I started a new project, there were times where I literally went overboard with writing the new code bug free, trying to prevent past mistakes.
What actually happened was that simply I created new bugs I had to learn to fix, because I didn't even understand how the fuck I created them in the first place.
Which is why I always try to simplify everything and if I feel that some approach is getting way too complicated I either restructure the entire thing or get more money to get the subsystem guys to change the way they are sending us data. I mean we could do it but I'll come back 3 months later trying to add a feat or fix a bug and curse myself for 2 days before figuring out what to do
exactly, you should only write code that is up to 33% of your capabilities of complexity, if it exceeds that you will be able to code it but not to debug it
Damn. That's some truth right there.
@@NeroDefogger why 33% why not 50?
This guy is so good at sharing info while keeping us entertained. Kudos!
He is very sarcastic ri8
Write no code - write no bugs.
no problem, manager will give you a lot of bugs...
no-code development is a thing... it either means you write *data* (configuration) instead, or you use GUI tools to build the behavior graphically instead of writing code
Write no code -- get no pay.
They're basically paying you to write bugs when you think about it.
@@u4yk Become a rock -- Don't NEED pay. Don't NEED food.
@@prathamshenoy9840 that... ROCKS!🤘
There are 3 things programmers struggle with:
1. Naming variables
2. Off by one errors
this is hilarious
5 things we struggle with:
1. 0 indexed arrays
10. Naming variables
11. Off by one errors
01. Binary
Very clever 😂
in another tale
There are only 3 hard problems in software engineering:
cache invalidation and off by one errors
don't forget errors with recursion
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.
Test your assumptions.
@@undefinedvariable8085 Yes, if you even have a slight assumption, test it. Beat my head against a wall for ~20 minutes trying to fix one thing with a correct assumption, but assumed it was wrong so went way around it until it was all I had left.
Well, I usually assume that all input may be faulty and this worked out pretty well for me so far :)
I genuinely thought I was the only one who tried talking to myself when debugging hard stuff… ends up this rubber ducking is a commonplace in our field… 😐
The only assumption I make is that the computer doesn't make mistakes, but I do.
this is extremely solid advice that should be given to every entry level developer.
This is extremely hackneyed advice that every entry level developer learns within the first 20 hours of sitting down in front of a compiler.
@@sanjaymatsuda4504 false
0:01 Introduction (the funny part)
1:20 Read
2:22 Google
2:55 Logging
3:45 Debuggers
4:25 Reproduce
5:33 Testing
6:10 Static analysis
Thanks
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.
innit lol. i taught a friend to code like some basics and then check in with him some time later dedbugging somethin and catch him copying the PROBLEM from a stackoverflow question and trying to run it 😂😂 bro variable is not defined coz this is code is nothing to do with wtf u are doing lol 😭
Google-fu is a black art few learn well, but those who do, will find the exact stack overflow answer they need every time (unless it doesn't exist).
But seriously, learning what parts of an error are worth using and when and how to use keywords in your search make finding answers much easier.
I don't do js, but someone messaged me about a problem that involved settimeout inside a while loop. All I needed to google was "settimeout inside while loop js" and boom, the answer.
How do you ever copy code when all the stack overflow answer will tell you is the meaning behind an exception ?
fr sometimes i just turn off my brain automatically when visiting stackoverflow idk why lol
@@Bobbias sometimes it's almost baffling to me that apparently so few can't use google properly. It's the ultimate game changer if you also keep learning with each search and don't just try to copy paste answers.
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.
Relatable. It is like the more you push your brain to work harder to solve the bug the dumber it gets and creates more bugs.
I always tell myself: next time something like this happens I am not gonna mash my keyboard with rage but take a break but I almost never comply.
I can not overstate how imporant taking a break is. I had an issue with my code yesterday for 3 hours searching every nook and crany in stack overflow for solution. Then i went to get lunch and on the road i figured out the solution. I only needed to add and modify a couple lines of code and voila the whole schmuck works.
Crazy how often the biggest bug is that I forgot to have lunch yet.
Plays stock footage of Logging whilst talking about Logging. Simply genius level of content making from Fireship once again!
somehow that went over my head nice
Timestamp?
3:30 - That completely went over my head until you mentioned it
I think I see another small joke/bug in the title
how to never write bug < the original title
how to never write "a" bug < missing the word "a"
how to never write bug"s" < or missing an "s" at the end of bugs
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
Good idea, especially since vscode is owned by microsoft
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.
Another tip that is very helpful in some situations especially when developing firmware. There is a type of breakpoint that fires when program accesses data. It is called watchpoint and you put it on variables. It is a life saver when some variable changes for no apparent reason and you have zero idea where this happens.
@markstein2845functional programming is great
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.
We made a sorting algorithm I'm Python for University. I tested it against the sorting algorithm of Python.
but what if your test code has a bug?
@@vibaj16 Valid concern. In many cases, the test code can be as simple as
assert solution_optimized(a) == solution_bruteForce(a)
Of course, I'd do this for many inputs, a, to test the code on as many inputs as possible.
7:12 Best anti-smoke ad I've even seen!
Can’t have bugs if you don’t have any code.
Big brain strategy.
Instead you'll have the worst error of them all: 404 Not Found
@@aikslf It’s not a bug if it’s intentional
I must say you are producing content of high quality: short, concise, funny, engaging, educational (learning new stuff), and well animated.
Kudos
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 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.
sounds like a bad week
Some of your best work. Required viewing for novice and experienced devs alike!
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.
That's probably the best opening of a tutorial I've ever seen : )
Thanks!
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.
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.
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
1) Read Doc - 1:21
2) Google && StackOverflow - 2:26
3) Logging - 2:58
4) Debuggers - 3:49
5) Reproduce The Bug - 4:31
* Heisenbug - 4:54
* Regression - 5:18
6) Automated Testing - 5:34
7) Static Analysis - 6:10
0) Take a break - 6:47
"It's God's will that thou code shall not work"
Definitely using this
This is why I always develop using TempleOS.
Another thing to help you debug with logs is structural logging where you add context to each log statement - having context can help so much and it has saved us so much trouble because we assumed something that simply wasn’t true - the log itself didn’t contain enough of info but the surrounding data was able to give us so much context
I always thought it was:
There are only 2 hard problems in CS:
1) Cache invalidation
2) Naming things
3) Off by 1 errors
😂
Don't forget off by 2 errors!!!!!
NullRef's are a PITA.
@@user-dh8oi2mk4f no, that's a double one by of error
I thought it was:
There are only 10 hard things in programming:
1) Naming things
2) Making new jokes about binary
@@jimread2354 do you mean:
I thought it was:
There are only 10 hard things in programming:
1) Naming things
10) Making new jokes about binary
never I have ever got entertained while listening to anything related to coding. I was smiling the whole time. keep it up
I can't remember the last time I laughed thorough the full length of a programming video.
I swear, my man has the best programming humor imo hahaha most people tell the same jokes from 20 years ago
@@alfredogonzalez9420 Hes the embodiment of r/programmerhumor, but only good.
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
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.
And not just because we know design patterns and test-driven development but simply because we've faced the same problems many times so we've learned how to solve them effectively.
@@charlesm.2604 I really hate it when the previous dev doesn't write tests though. Or writes tests for coverage without actually defending the purpose of their code with assertions. Bonus negative points when English is their second language or they are crap at naming their functions.
The bonus part is wonderfully working most of the times, thanks.
Very nice XKCD reference 😛
But I believe RFC 1149.5 specifies 4 as the standard random number
I thought they were both referencing something I didn't know about
Your video editing skills are simply awesome! Not to forget the content really helps as well.
Great balance of humor and information👍🏻
Unit testing is the best tool you'll ever get.
Don't forget to test for errors and not for passing results.
Sure it seems to slow your coding high, but if your project gets large, it's the contrary.
It forces you to break your code into relevant testable components.
Mocking data for tests helps understanding your code deeper.
Time saver: It's also wonderful once you automate all tests. Example of a mono repo with a lot of common dependencies. Update one dep, rerun all tests for all modules in your repo. If anything breaks or changes, the unit tests will catch it for you.
Documented clean tests can also serve as documentation for personal projects.
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.
wtf
It's a timing thing when sending the data to the lcd. The if statement introduced a delay which corrected the timing.
I appreciate these down-the-rabbit-hole explanations of how everything computers-related works
Amazing video, amazing humor, amazing advice!
I love the detailing at 0:36, Shows a picture of Bjarne Stroustrup, when he says "it's the programming language or compiler itself to blame"
It's an insider joke of an insider joke.
Bjarne Stroustrup's video has some one hilarious comments, two of which are "He lost his hair each time he got a bug while coding in cpp" and "If you can't code in other programming language, just write your own compiler to compile it" (or similar)
It makes me genuinely laugh and smile to see such nerd and insider jokes, which i can't even share with anyone i know.
You can't write bugs if you don't write code !
More seriously, excellent video ! That's great advice. The use of loggers, linters and debuggers do save a lot of my time almost everyday.
(Your first sentence) Now that's my approach!
@@squidwardfromua Hahaha wish you fortune on your quest :D
😂 that ending gave me a good belly laugh; thanks man. Great work as always!
1:00 there should be 7 zeros after the decimal point, not six
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
The thumbnail is sadly a short sentence describing most of JavaScript programmer's lives
When I am on call, I think my day in life looks like entire video, debugging back to back...
Awesome videos Jeff.
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
Isn't it just a binary search algorithm?
often, commenting out an arbitrary section of code will cause more bugs further on in the program. that's why the Logging strategy is preferable, because there is (almost) no chance it will cause additional bugs.
@@rumfordc it's not a method to fix the bug, it's a method to locate it. You don't change any code eventually
“take a break” is the best possible advice. Even just a brisk walk outside with fresh air
1:50 I think that was in a Dilbert comic once
It's xkcd 221
xkcd showed the code but Dilbert pioneered the concept of "random" numbers
Fireship guy i think your videos are like the act of breathing for the developer world. much needed. I hope you continue this journey.
3:43 I see what you did there.. 😏🤣
the marlboro part killed me!🤣🤣 almost more comedy than information - love it
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.
The first minute or a bit more is why I spent 20 minutes looking for this video in my yt history
always make sure that the function you are debugging is being called.
i am not a programmer and I watch all your videos the minute i see a new one... the more you can understand why a programmer hates life, the more friendly they are when you ask for their help... its awesome
I usually work on embedded systems and you wouldn't believe how often I find library bugs
embedded is a small world, also very commercial and binary-only, so nobody can snoop around in your stuff and laugh at the mess
As is a Dutch (translated) expression: The venom is in the tail. That is certainly the case in this vid. Well done.
his videos always make my day ngl
That randomness joke was solid af. You still got it Fireship lol
1:10 It should be "thy" instead of "thou" :)
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.
wait, you guys write code? I just write bugs.
We*
I sit in meetings listening to people misinterpret requirements and bikeshed over stuff.
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.
I like to consider my bugs as additional unintentional features.
A few years ago I was watching my then-three-year-old while trying to get some work done. Kid goes, "There's a bug!" and I mutter instinctively "not a bug, it's a feature."
Pause.
Kid replies, "There's a feature crawling on the wall."
Born PM, that nugget.
"Eliminate the guesswork" is a very powerful mantra for the young dev grasshopper. Thank you!
how to never write bug? write code do good
Man, I searched for a vídeo like this when I started, and there were none. That's amazing
"thou code shall not work" lmao 😂😂
С каждым использованием этой связки я все больше впечатляюсь её эффективностью.
Bonus bonus tip - Thinking about the bug in the loo activates strange debugging powers you didn't know you had. Trust me.
cant have any bugs if your code breaks the compiler
This is so much FUN watching your videos, thanks. Keep going !
The craziest thing just happened to me, my computer crashed at 0:51
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.
Edge's dev tools is always tempting me to move over and make it my daily.
@@TheRighteousDawn You can do that in Chrome too; they're both chromium based browsers.
@@undefinedvariable8085 Yup, firefox has the option to add a breakpoint too.
How debugger works for compiled (or bundle) script? Like minified js or compiled Typescript?
Sometimes bugs come from stackoverflow when you past code in.
A "Copy-paste bug".
“Thou code shall not work”
10/10 quote
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."
Good points, TTT.
I first heard about functional programming from a joke in xkcd: "Code written in Haskell is guaranteed to have no side effects" / "...because no one will ever run it?"
Nowadays, I defer execution like I'm the California penal system and am less willing to give things state than a Republican voting on DC or Puerto Rico.
bonus tip is true, many times I figured out how to write the code was right before falling asleep or short after waking up
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.
But source control removes the need of copying any file
@@sergeyson423 After first few experiences when learning (specifically losing several days of updates in a solo project) I prefer to make several copies kept in different places just in case. We never know how software update or noob tampering can affect source control, especially one made hastily.
@@RandomizerYevhen But then again, that's exactly what source control helps you mitigate and avoid. Feature branching, separation of concerns, encapsulation, commit and blame histories; all of this makes it possible to revert, restore, stash, and switch around contexts. With the right git workflow for the right team, you should never have to store any physical backups locally.
@@RandomizerYevhen I suggest you to learn git
To learn git is a valid point, thanks.
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
I have had the 0.00000099% thing happen once. It took a team and a half weeks to figure it out.
Are you allowed to discuss it? Without disclosing confidential info or anything of course. I'm just super curious
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.
New debugging tip: Copy and paste code to chat GPT 🤣🤣🤣
I think they should build an ai debugger
there are a few,a good one is bito
but it is for VScode mainly
That part about a fault in our simulation, I literally just remembered a bug I once encountered that was baffling to me, but upon running the code again, it didn't happen. I can not remember where it was, but what I do know is the code that had a bug was never changed and is still being used today, and has been for years. I guess it really was God's will.
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.
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 🙈
He mentioned it at 4:55
It's literally here: 4:54
Excellent video! Shared it on Twitter!
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.
0:16: It has happened to me twice, once with FFMPEG when manipulating audio or audio from videos that are in a certain format, it turned out that it is a fairly deep error in the engine