Ok two personal pet peeves. 1: Check your code 100% before you say someone else is at fault. 2: You should assume the engineer before you had a reason for doi

Ok two personal pet peeves. 1: Check your code 100% before you say someone else is at fault. 2: You should assume the engineer before you had a reason for doing the things he did, do NOT assume they are an idiot until you have conclusive evidence that they are. I say this after having spent a huge amount of time taking over code bases and figuring out that the reason people make engineering decisions sometimes have nothing to do with engineering. Many times the decisions are based upon some business process or "guidance" that led/pushed them down the path. That does not make the engineer or software necessarily bad, it makes the process or guidance faulty. So many times as a consultant I come in and start researching the code and issues, and then work with the business to understand their issues. Then review the code and find that the code does exactly what they asked it to do (as stupid as it may be), but not what they intended. Do not assume an engineer before you made a mistake until you have proven they have. Assume you haven't seen all the facts initially and dig more. 80 or 90% of consulting is asking the questions to find out why more then how, understanding why tells you the how most of the time. Just my 2 cents.