I actually did watch the video. Don't understand me wrong: I don't have anything against a good IDE and a good debugger. I currently work with C# and use Rider

I actually did watch the video. Don't understand me wrong: I don't have anything against a good IDE and a good debugger. I currently work with C# and use Rider. Still, for me personally, I need to study the code and know what to expect before I start the debugger. It makes the debugging session a lot more useful and efficient. And, actually, like John Carmack said that other people told him, in a way, I do "replay" the code in my head while reading it. And a lot of times, I already figure out what the error is when reading the code. But, I will often still debug the code to verify that what I'm thinking is true: I do trust the debugger more than my brain. Aside from that he also mentioned that nowadays software systems tend to be complex and too big to completely fit into one's mind. I agree with that, but IDEs make it easier to isolate the code in the system that is relevant for the issue at hand: you can find the call sites of a method, the use of results, the origin of input values and so on. I don't know how good IDEs are currently for C/C++, but those things are standard for C# and Java. And with those tools, it really is not that hard to get a rough view on where and how a piece of code is used in a big system. Obviously, this will be easier in a well-designed system than in a spaghetti-code system. It is important to know all the contexts in which the code you are debugging is used. Often people are focused on the one specific context in which a user saw a bug, and they focus on that, start a debugging session for that, fix the code for that and break the usage in the other context... because they do not take the time to read and understand the code. And that is also where unit/integration tests come into play. So, nothing against the use of good IDEs and debuggers, but always be sure to understand the code you are changing.