Not a one-man job.

As my time at BYU winds down, and I begin to think more specifically about life after graduation, I have spent quite a bit of time talking with programmers at various companies in different fields and areas of the country. One of the most important questions I ask is about their interaction with other people. I like to know what percentage of the day they spend programming, how many people are on their team, how their desks are situated, who they ask for help, what their project manager is like, and more. The conclusion I have drawn from all of these interactions is that programming is not a one-man job. One man does not design systems by himself. One woman does not code, test, and push to production a product with no input from anyone else. And certainly no one ever writes code that has no bugs, conforms to all the documentation, and passes all the tests the first time. Programmers are not perfect. That's why software companies usually provide environments where conversing is comfortable, where you can bounce ideas off each other, where you can update your team on your progress. In doing research on the Gimli Flight Situation, I felt that the summarized documentation given on the website was a bit misleading. In one article I read, I found out that the faulty plane passed through many reliability tests specified by the company and others. Perhaps the software was faulty, but that in no-wise means that one programmer is to blame. Where are the engineers that tested it? Where are the people that wrote the specifications that the program DID pass? Where is the pilot who agreed to fly despite the malfunction? Where are the fuel pumpers who did the conversions wrong? Just as one person did not write the entire code for the system, neither should one person be held responsible for a mistake that passed through many levels of hierarchy before it failed.