Found this link on a skydiving website I frequent. It was given up as an example on how things can go horribly wrong when we become complacent in things like gear checks.<p>I've always tried to draw parallels between what I learn in my hobbies and what I do in my professional life. Granted, the stakes are a bit higher in skydiving and they were certainly high in this story (the person involved died), but the lessons are still valid. Ignore them at your own peril.<p>When I read this post one of the things it reminded me of was a time when a coworker chased a crash bug for about two days. He scoured his code. He became convinced that he had exposed a bug in the compiler....he started to doubt the stability of glibc even! After many lost hours he asked me to look at his code and I saw the error in five minutes; two lines after calling free on a variable he called free on it again.<p>Before you jump to your keyboard and start typing about how this would not happen to you, realize that people in situations with higher stakes than the mere survival of an insignificant startup have made similar mistakes. The mind sees what it wants to see, and when the mind is reading code that it wrote it wants to see that code as being perfect.
It's hard to find a routine check-list that doesn't have this sort of problem. We've investigated the idea of inserting deliberate errors in the diagnostics systems used by our engineers for exactly this reason. Sometimes even though a reading is OK we could show red. The system logs would show that this has been done, and if the engineer report doesn't, we know the check-list hasn't been followed properly.<p>But it's hard. We have intelligent, clever people, and mundane checks don't come easy. In some cases the more clever and capable someone might be, the worse the problem becomes.