Debugging: 95% Of Software Engineers Are Lacking In This Skill

Показать описание

Debugging is a huge part of the job for any software engineer. Despite best intentions, software engineers waste tons of time when trying to fix a bug -- it's not just about diving into the code!

Hi! I’m Rahul, a software engineer and founder with a passion for teaching.

#techcareergrowth

Timestamps:
0:00 - Why debugging is important
0:30 - The proper mindset for debugging
2:04 - Understand the context around the bug
3:45 - Understand the steps behind the bug
5:40 - Generate a paper trail
6:23 - Top down vs bottom up
7:45 - Take a break!

Рекомендации по теме

Комментарии

My actual advice for debugging is to play 'Everything Has Changed' by TSwift on repeat

RahulPandeyrkp

Just started video, not yet completed, but can say - 100% right - debugging is best skill as you said.

gdthegreat

Great video!
Unfortunately in some companies it's not allowed to input company code into ChatGPT or similar software

mnchester

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)

aldrinseanpereira

Yea brotha, your YouTube channel is gonna blow up. Very high quality content here. Thanks

patrickglinski

wow the production value of these videos has gone up dramatically. super sick!

coofzilla

I love debugging. It’s like being a detective or figuring out a puzzle

michaelalls

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?

Han-veuh

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.

Reavenk

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

premalsingh