There are some little tells you are probably aware of that let you just know whether or not someone is a geek. The person who looks at a train departure board showing an error message probably isn’t. The person who sees the error message, gets his camera out and waits five minutes for the error message to appear again before taking a photo of it so he can blog about it to illustrate a point about error messages probably is.

In this case, while at first glance the error message isn’t obviously going to be of much use to someone catching a train, it might well be of use to someone who is tasked with fixing the problem.

CHU indicates that it’s at Cheadle Hulme station; you’re also told that it’s on platform 1. That’s a good start. It means someone reporting the error message, even if they didn’t know where it was, would be directing the engineer to the right point.

Because a good error message should do these things:

• indicate the location of the error
• indicate the cause of the error
• indicate possible remedial action
• indicate potential workarounds

Obviously, which of these you do depends on the program: you don’t want to output source code to public users, but you do want to tell them what other actions they can take.