别依赖“魔法”
任何的活动、进程或者学科，远观的话总是很简单。没有开发经验的管理者认为程序员的工作很简单，没有管理经验的程序员也同样认为管理者的工作很简单。
编程是一件部分人做的事，其最难的部分——思考，却是最不可见也最不易被外行们欣赏的。几十年来，已经有很多人尝试去除对这种有技巧的思考的需求了。其中最早的也是最难忘的是Grace Hopper为了让编程语言不那么晦涩难懂所做的努力，有些人预测那会消除对专业程序员的需求。其结果（COBOL）却在接下来的几十年为专业程序员创造收入。对了解其中之道的程序员来说，固执地认为软件开发可以通过移除编程来简化明显是幼稚的。但是导致这个错误的心理过程部分是由于人的天性，程序员和其他人也一样倾向于犯这种错误。
任何项目中都可能有很多单个程序员不能充分参与的东西：搜集用户需求，验证预算，配置构建服务器，部署应用程序到QA和产品环境，从旧业务过程或程序升级到新的等。
对于你不能充分参与的事情，你会无意识地倾向于假设它们很简单，像“魔法”一样地发生了。当魔法继续时，什么都很好。但是当，经常是“当”而不是“假如”，魔法停止时，项目就有麻烦了。
我曾经了解到有的项目中开发人员浪费了数周的时间，由于没有人理解他们是怎么依赖“正确”加载的DLL版本。当开始出现间歇性地错误时，团队成员东查西找，直到有人发现加载了“错误”版本的DLL。
另一个部门则运行顺畅：项目按时交递，没有到深夜的调试，没有紧急修复。如此顺畅，事实上，高层们觉得在没有项目经理的情况下，一切可“自行运行”。结果六个月的时间里，部门里的项目看起起来就和组织的其余部分一样：延迟，充满bug，一直在打补丁。
你不必了解让项目运行的所有魔法，但是了解其中的一部分，或者欣赏了解你不知道的部分的人，这并没有什么问题。
