I know - there is a lot we need to change in tech about "perceptions" of what a good programmer or coder is. I know folks who believe that good coders are those who can reduce code to 1 line of dense (unreadable) semantics in the name of efficiency, and who think knowing all the available debug tooling and being a power user is the key.
It's not.
Like everything in life, programming is about adapting to context and personalizing to preference. And being able to have short, fast, "iterate-test" cycles is key to agile development. And print statements are still the most common way to validate your thinking and keep making progress. Tools are awesome too - and everyone will get to the point where they will use the right tools for the right job and it's okay to get there in your own time.
Lately, I've seen quite many people defend print statements for debugging because they're dumb, but they get the job done and I really think they're missing the point.
Print statements are the most versatile debugging output available; they can communicate every last bit of information that is programmatically available from a given state of the application, whereas "advanced" debugging features, while often incredibly useful, provide a much narrower insight into certain aspects of the state of the application.
But even beyond debugging, printing some meaningful application state can help, as you said, to validate the programmers assumptions. Validating your assumptions in short implement-validate-fix-cycles helps in detecting both bugs based on technicalities (typos, syntax, etc.) as well as those based on incorrect assumptions (wrong order of arguments, less information returned from a function than expected, etc.) and, in the latter case, can prevent spending much more time chasing down a path that, as it later turns out, doesn't work because it only works for an incorrect assumption (like wanting to use information that an API just doesn't provide, etc.)
"Print statements are the most versatile debugging output available;"
I couldn't agree more - and it is definitely one of those hills I am willing to die on. I think there is a reason we all "print Hello World!" as the starting point for every new learning journey.
Thank you for this!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I know - there is a lot we need to change in tech about "perceptions" of what a good programmer or coder is. I know folks who believe that good coders are those who can reduce code to 1 line of dense (unreadable) semantics in the name of efficiency, and who think knowing all the available debug tooling and being a power user is the key.
It's not.
Like everything in life, programming is about adapting to context and personalizing to preference. And being able to have short, fast, "iterate-test" cycles is key to agile development. And print statements are still the most common way to validate your thinking and keep making progress. Tools are awesome too - and everyone will get to the point where they will use the right tools for the right job and it's okay to get there in your own time.
Lately, I've seen quite many people defend
printstatements for debugging because they're dumb, but they get the job done and I really think they're missing the point.Print statements are the most versatile debugging output available; they can communicate every last bit of information that is programmatically available from a given state of the application, whereas "advanced" debugging features, while often incredibly useful, provide a much narrower insight into certain aspects of the state of the application.
But even beyond debugging, printing some meaningful application state can help, as you said, to validate the programmers assumptions. Validating your assumptions in short implement-validate-fix-cycles helps in detecting both bugs based on technicalities (typos, syntax, etc.) as well as those based on incorrect assumptions (wrong order of arguments, less information returned from a function than expected, etc.) and, in the latter case, can prevent spending much more time chasing down a path that, as it later turns out, doesn't work because it only works for an incorrect assumption (like wanting to use information that an API just doesn't provide, etc.)
"Print statements are the most versatile debugging output available;"
I couldn't agree more - and it is definitely one of those hills I am willing to die on. I think there is a reason we all "print Hello World!" as the starting point for every new learning journey.
Thank you for this!