I am dealing with this now, having taken over a project from someone who thought this way. Yes it works, but is full of bad error handling, cryptic exceptions, race conditions (particularly TOCTOU bugs), non-atomic database updates, and more.
"But it works" they say, which is true. But a simple SQL query shows duplicate or missing data where there shouldn't be and other violations of basic assumptions.
Looking at code and knowing what could possibly go wrong is an extremely useful skill. Unfortunately it usually takes running head first into those issues to actually learn and comprehend those lessons (which I have done more than my fair share of :))
I have also seen the other extreme. Where people are overly paranoid about the app throwing any exception and try to capture everything that could possibly go wrong until the heat death of the universe. Handling every error somehow, often without understanding what is supposed to happen in this case. So you end up with things being in weird states and secondary effects for what would have just thrown a fairly easy to troubleshoot exception otherwise.
Preach it!
I am dealing with this now, having taken over a project from someone who thought this way. Yes it works, but is full of bad error handling, cryptic exceptions, race conditions (particularly TOCTOU bugs), non-atomic database updates, and more.
"But it works" they say, which is true. But a simple SQL query shows duplicate or missing data where there shouldn't be and other violations of basic assumptions.
Looking at code and knowing what could possibly go wrong is an extremely useful skill. Unfortunately it usually takes running head first into those issues to actually learn and comprehend those lessons (which I have done more than my fair share of :))