After having written about writing errors thoughtfully the other day I had a work related incident yesterday which, coupled with a conversation with a friend last night, made me think about the idea that the context in which you communicate the error message and the method you use makes a difference as well as just the content.

Part of the automated system I run is a module that sends emails to our consumers. Our prime recipient’s email provider was having problems and emails were being rejected. The message that was in the bottom of the email was:

Remote Server returned ‘< #5.7.6 smtp; 551 5.7.6 [internal] STARTTLS required but not advertised>’

This message was definitely not a thoughtful error message targeted at the consumer. Neither had any consideration been given to how this message would be communicated back to the person/organisation. I had to phone my contact, and recite this to them. It was a moment of amusement to my colleagues as I was saying “left angle bracket space hash five dot…” etc. down the phone to a somewhat baffled contact.

As a result of this, I realise that not only do I need to continue to make sure that my error messages are easy to read but I also need to consider the method that may be used to tell me about that error as well.