先举几个例子。

• ...某段代码提示说“文件不存在”，却不告诉你哪个文件不存在，或者它是在哪里寻找这个文件失败。
• ...某段代码对你的调用请求做了一大堆的条件判断，然后发现某些条件不符合要求，于是调用失败。但压根不告诉你失败的原因是什么（甚至根本就不让你知道调用已经失败）。当然代码本身知道确切的错误点所在；它只是认为你没必要知道这些内部信息而已。
• ...某段代码以一种毫无意义的形式来进行逻辑错误的检查/汇报，这些错误信息让你的代码调试无从做起，或者干脆把你带入歧途。记得曾经碰到过一个外包项目提供的代码，运行了一段时间之后突然页面上显示不出东西，错误日志里面的记录只有一句话：数据库访问异常！一开始以为是数据库的物理访问有问题，或者数据库连接过多之类；检查了半天找不到原因。最后只好让对方再去看详细的源代码一行行调试，结果发现是数据库表出现了一条非法记录，导致了整个逻辑处理异常退出。
• ...某个API抽象到你反复研究也搞不清楚它到底是干什么用的，或者你已经知道是用来干什么的了，可偏偏看不懂怎么去使用它.
• ...某个系统为你节省了几十分钟重复编码的时间，却要求你花上一周的时间来搞清楚如何正确的设置它的配置文件、元数据等辅助信息。
• ...某个API所作的事情就是化简为繁，让本该一目了然的逻辑复杂化；同时在使用这个API的时候，你还得重复这些操作（或许在泛滥的API中成长的程序员还会将泛滥发扬光大）。
• ...某段代码为了解决系统复杂性所衍生出来的问题而在原本就很复杂的系统上再包上一层逻辑。经过几次的包装之后，你或许永远也想不到这些代码的初衷是什么。
• ...某些API看上去就像是八竿子打不到一起的远房亲戚，各自完成一些特殊的功能，却没有任何有机的联系。实际应用中，你根本无法知道他们互相之间会产生什么影响。

类似的现象还有很多。关键在于，你作为开发人员在编写代码的时候是抱着怎样的心态？是“按照我的理解能力来看”、“我这样做是最佳方案”的想法，还是说“在别人的程序中助一臂之力”、“让后来者收益”？要知道当你作为代码提供者在设计开发的时候，为了一时省力或者考虑不周而少花一天/一周在自己的代码上，以后使用你的代码的其他程序员们将不得不花上几倍几百倍的时间来弥补你的缺失。

因此，对于API、库函数或其他各种代码来说，最好就是不要变成“程序员憎恨程序员”的潜台词 -- 你在制造“憎恨”的同时，难保哪天不被别人的“憎恨”代码给扫到。