Jeff Atwood posted an article about how important it is for every developer to understand the sources of third-party code that contributes to an application or framework. And yet, he admits how hard it is to do so.
The idea that you’d settle down in a deep leather chair with your smoking jacket and a snifter of brandy for a fine evening of reading through someone else’s code is absurd.
Scott Hanselman posted a response to Jeff’s article that basically disagrees with many of the assumptions made by Atwood.
Nearly every programmer I’ve ever spoken to enjoys reading and discovering new code. I’ve been advocating that Developers need to read as much code as they write for at least half the time I’ve been blogging
And then, there is this interesting piece I found today by reading the Morning Brew. The gist of it is that you shouldn’t read the source code like a book (which admittedly does not make sense) but use a mixture of perusing the code “diagonally” and using grep to find stuff when you know exactly what you are looking for.
Interestingly, my conclusion is that I more or less disagree with all of them. For me, using a state-of-the-art debugger is the preferred and, after all, only practicable way to explore foreign source code.
Yes, trying to understand foreign source code but just reading it is possible to a certain extend but if you really need to understand what’s going on it is indispensable to follow the control flow and watch the data unfold as the algorithm executes1.
Plus, the usage of a debugger implies a certain context in which the third-party code is executed and this further contributes to the ability to inspect the semantics of the code. All in all, that’s the way to go. But make no mistake, a debugging session can be anything but a pleasure-trip:
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.