Ok, so this is pretty much counter to my experience. I've spent a significant chunk of my career just diagnosing errors based on error codes. It does work. W

Ok, so this is pretty much counter to my experience. I've spent a significant chunk of my career just diagnosing errors based on error codes. It does work. When the kernel tells you some data is not found, permission is denied, or the filesystem is corrupt, or I/O failed, it really isn't kidding, it gives you specific advice and you should pay attention. You can also do things like look in kernel source to see when that error occurs, and depending on the error get really specific ideas about the problem. Keep in mind not every job will have you with total control of a machine as in a server use case. In many domains deploying code to someone else's device you won't know that you're running somewhere short of disk space, or whatever, until you see it in the error code. Further, I suspect you are working in higher level languages where somebody has already wrapped the error codes in exceptions, and already logs unhandled exceptions to stderr. So what I would call very basic "error handling" is already done for you. When talking about C, if this more manual work is not done, ignoring error codes and continuing to keep on chugging is just stupid in a lot of cases, will cause you to silently lose customer data if you don't stop yourself on the error, etc., which is bad times.