Debugging: Make sure you are seeing the real values
When investigating a problem during a development or debugging session, it is important to make sure that the values we are looking at are the ones we intended to see. Interpreting data incorrectly leads to wrong assumptions and prolongs the time needed to understand and fix the problem.
There are many situations when the “real value” is somehow obstructed or hidden. Consider a classic example of using the JavaScript console.log() printing mechanism to examine objects in web browser development tools:
As you can see, expanding a “printed” object will always show the current object’s values, because the object is just a reference to the values stored. Note that in this case, Firefox kept the original value initial for us on the screen too, but this might not be the case for deeply nested objects.
The above example illustrates how important it is to know what our development tools and libraries are actually doing when displaying data.
Data formatting, especially, can lead us astray. It is easy to print values that are correct, but formatted in such a way that some information is lost:
Has the number been rounded?
Has the datetime been converted to another (local) timezone?
Is the numeric representation converted to something else?
Is the day and month as we expected (MM/DD or DD/MM)?
And by print, I don’t just mean some manual print statements. Do you know what your database data browser is doing when displaying data? Do you know what your programming language runtime or library you are using is doing behind the scenes when asking for output?
Of course, the problem doesn’t lie just with the tools or formatting. For instance, in concurrency scenarios, the printed data can be stale if it has been changed right after.
All in all, making sure that what we see is what we really have is one of the first steps in avoiding red herrings and spending time effectively.
Don’t always trust what you see.
— Petr