24 ms·
Hell the attitude in the article evokes strong memories to my last workplace. Almost all development teams tried so hard to build smart software doing the righ
by tetha 9y ago
Hell the attitude in the article evokes strong memories to my last workplace.
Almost all development teams tried so hard to build smart software doing the right thing, recovering from everything, tried to fix so many things. They spent insane amounts of work trying to be smart in error situations. And all of that was useless or harmful - it either didn't work, or it it made things worse.
My team operated under simple principles. Crash early, crash hard, log well, trust the operator. But you know, Ops at that place loved our applications. It took time to get them going, but it was easy to understand what to do whenever they crashed. It was easy to understand why it stopped. It was easy to understand when to file a bug.
- kpil 9y agoGetting good at error handling, queue sizing and writing relevant logs requires some repeated exposure to real world pear-shaped events. Failing early and visible is always good, especially before a program have been taken into production. When things have stabilized for a while, recoverable errors can be ignored, and just logged. It's also important to take the opportunity to improve the error handling and logging first, before fixing the actual problem. Errors are hard to fake "right" so getting a good reproducible error is an opportunity.