> Regarding the comment about the debugging. For me personally, I always take the time to study the code first before I start debugging. A lot of times I already find the problem by just reading the code and even if that is not the case, I have a much better understanding about how the code is supposed to behave and that makes the debugging session a lot more useful.
> And I say that because I have the impression that it is common for developers to dive straight into a debugging session without a good understanding of what the code is doing or trying to do. It's like they see the sympton and want to fix the sympton instead of fixing the core cause.
Did you watch the video? He spends a significant amount of time talking specifically about why he thinks what you are saying here is misguided.
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.
> And I say that because I have the impression that it is common for developers to dive straight into a debugging session without a good understanding of what the code is doing or trying to do. It's like they see the sympton and want to fix the sympton instead of fixing the core cause.
Did you watch the video? He spends a significant amount of time talking specifically about why he thinks what you are saying here is misguided.