I cant stop thinking about how amazing your advice and Taro is. Its unimaginably helpful. (Although tough to implement practically in this case so far but its still the best)
Not 100% relevant to debugging others' code, but when *writing* debuggable code: - Don't duplicate similar code (DRY), all relevant logic should run through a single bottleneck in functionality. A bug for a single thing should happen consistently, should expose itself fast, and should be fixed everywhere by only fixing it once. - Don't do declarative programming on complex things with many side-effects. Gratuitous declarative programming is a fast way to launder bugs with working code by mixing them all together on the same debug line-step (and a way to make it easy to gloss over using the wrong algorithms and data structures). - Break out code into multiple lines instead of having functions nested in functions (nested in ternaries, nested in linq calls, nested in linq calls). - Feel free to put temporary data into temporary variables. You get to describe it with a variable name (self-commenting code), a debugger step to see its value, and it'll be optimized away when the time comes to release build. - Asserts and defensive programming. And prefer static asserts when possible. These make stepping through code with the debugger (breakpoints, conditional breakpoints, watchlist, callstacks) an order of magnitude easier.
Pretty well explained. ChatGPT might not always work due to two reasons: 1. Overall complexity is too much to explain it to an AI. 2. Its simply proprietary information. But other than that chatgpt can surely help to understand some basic flows. Like you could say the function executed like this, what could have possibly gone wrong
Even more so than learning to code, learning to debug is best done by doing the act. Just start debugging (if you're totally new, start with pair programming/debugging)
@cmg575 this is a paranoid statement, they can't make the next Facebook based off 0.00002% of the code in it. Infosec has other actual problems to worry about
3:36 mentions bisect then revert. Wouldn't this make the commit history really dirty if every bug fix requires adding a revert commit? Is this revert commit later editted/renamed to be the actual fix? Also are such reverts done on local copies of the system, or on dev/staging environments? What if the bug only happens on production and is not reproducible on dev/staging (does this ever happen?), how do you integrate locally running services, with production during the bug fix process?
My actual advice for debugging is to play 'Everything Has Changed' by TSwift on repeat
Just started video, not yet completed, but can say - 100% right - debugging is best skill as you said.
Yea brotha, your RUclips channel is gonna blow up. Very high quality content here. Thanks
Great video!
Unfortunately in some companies it's not allowed to input company code into ChatGPT or similar software
True, although this will certainly change over time as companies start to leverage AI more and more
I love debugging. It’s like being a detective or figuring out a puzzle
Few things match the elation of fixing a challenging bug :)
nobody talks about how painstakingly diffuclt it is to truly debug. you have no idea how much pain it is
I cant stop thinking about how amazing your advice and Taro is. Its unimaginably helpful. (Although tough to implement practically in this case so far but its still the best)
Thank you Aldrin!
Not 100% relevant to debugging others' code, but when *writing* debuggable code:
- Don't duplicate similar code (DRY), all relevant logic should run through a single bottleneck in functionality. A bug for a single thing should happen consistently, should expose itself fast, and should be fixed everywhere by only fixing it once.
- Don't do declarative programming on complex things with many side-effects. Gratuitous declarative programming is a fast way to launder bugs with working code by mixing them all together on the same debug line-step (and a way to make it easy to gloss over using the wrong algorithms and data structures).
- Break out code into multiple lines instead of having functions nested in functions (nested in ternaries, nested in linq calls, nested in linq calls).
- Feel free to put temporary data into temporary variables. You get to describe it with a variable name (self-commenting code), a debugger step to see its value, and it'll be optimized away when the time comes to release build.
- Asserts and defensive programming. And prefer static asserts when possible.
These make stepping through code with the debugger (breakpoints, conditional breakpoints, watchlist, callstacks) an order of magnitude easier.
Would like to see a video explaining bottom up and top down debugging
Pretty well explained. ChatGPT might not always work due to two reasons:
1. Overall complexity is too much to explain it to an AI.
2. Its simply proprietary information.
But other than that chatgpt can surely help to understand some basic flows. Like you could say the function executed like this, what could have possibly gone wrong
True, although #1 will almost certainly get resolved over time as AI becomes more advanced
Thanks for the video Rahul i love it ❤
Are there some good books/tutorials/courses to learn the art of debugging ?
Even more so than learning to code, learning to debug is best done by doing the act. Just start debugging (if you're totally new, start with pair programming/debugging)
good advice
what was the step 1 before chat gpt?
Understand the relevant part of the codebase, and ideally be able to repro the issue.
I'd be careful pasting in your companies code to chatgpt for interpretation. InfoSec at your company may not like that
Yeah that's true
There are probably 10+ startups that are working to solve this problem!
@cmg575 this is a paranoid statement, they can't make the next Facebook based off 0.00002% of the code in it. Infosec has other actual problems to worry about
Solid
I love you man
😘😘
Haha, I'm glad I saw the original thumbnail 😂
you were here early!
3:36 mentions bisect then revert. Wouldn't this make the commit history really dirty if every bug fix requires adding a revert commit? Is this revert commit later editted/renamed to be the actual fix?
Also are such reverts done on local copies of the system, or on dev/staging environments? What if the bug only happens on production and is not reproducible on dev/staging (does this ever happen?), how do you integrate locally running services, with production during the bug fix process?
wow the production value of these videos has gone up dramatically. super sick!