I would estimate print debugging is usually twice the work for 30% of the effectiveness of step debugging. It's the screwdriver to step debugging's drill. Fundamental and absolutely necessary sometimes but not the first tool you should be reaching for unless there's a specific reason.
The specific reason I reach for print debugging first is it works literally everywhere across all technology stacks. I regularly work with different projects written in different languages. Printing works across all of them and the logs are easy to aggregate across different parts of the stack (microservices or other service composition patterns) giving you a broader range of data than you typically get from a step debugger. I've personally found that step debuggers are more likely to create Heisenbugs. Especially in multi-threaded applications or dealing with race conditions.
Printf works just fine in a lot of languages and domains. Not everyone likes to use a step debugger.
I would estimate print debugging is usually twice the work for 30% of the effectiveness of step debugging. It's the screwdriver to step debugging's drill. Fundamental and absolutely necessary sometimes but not the first tool you should be reaching for unless there's a specific reason.
The specific reason I reach for print debugging first is it works literally everywhere across all technology stacks. I regularly work with different projects written in different languages. Printing works across all of them and the logs are easy to aggregate across different parts of the stack (microservices or other service composition patterns) giving you a broader range of data than you typically get from a step debugger. I've personally found that step debuggers are more likely to create Heisenbugs. Especially in multi-threaded applications or dealing with race conditions.
2 replies →
It feels like the option for people who are too lazy to learn their tools to me.