我在谷歌工作的第七年即将过去。我在那里学到了很多东西，比我写下的要多得多。我想我至少应该和你分享一些只有在有更多经验后才会有的东西。
复杂性是软件的死亡。它的成本很难量化，而且它往往会慢慢潜入，所以它是一个缓慢沸腾的恶化过程，在为时已晚之前很难看到这一点。另一方面，通常很容易看到复杂性增加的好处：新的间接层允许新的功能X，或者将在一台计算机上运行的进程一分为二允许您克服当前的扩展障碍。但是现在您必须在头脑中保留另一层间接层，或者实现一个RPC层并管理两台机器。
以上这些对于新手程序员和资深程序员来说，希望都是显而易见的。我想我在这个行业的几年中学到的是更好地理解平衡是如何实现的；什么时候复杂是正当的，什么时候应该拒绝它。我经常回想起一位朋友对肯·汤普森(Ken Thompson)编写的Go编译器的评论：它很快，因为它做的事情不多，代码非常简单。
事实证明，就像写一篇长篇博客帖子比简明扼要地表达同样的观点更容易一样，要写出直截了当的软件也很难。这在编程语言设计中是最容易看到的；新手编写的新语言往往有许多特性，而很少有C语言那样清晰明了。在今天的程序中，它经常与所涉及的对象数量有关；在分布式系统中，它与运动部件的数量有关。
这个问题的另一个词是聪明：引用另一位C黑客的话说，调试比一开始编写代码的难度要高出一倍。因此，如果你尽可能巧妙地编写代码，根据定义，你就不够聪明，不能调试它。"；
什么能帮上忙？我想知道这是否仅仅归结于经验-被太多的项目咬了一口，在这些项目中，有人认为元编程很酷。但是我发现制定具体的设计目标来评估新代码会有所帮助。如果你可以说这无助于解决项目的最初目标，那么拒绝新代码就更容易了。在Google中，描述新项目设计的模板文档在顶部有一个部分列出了非目标：您打算拒绝的项目的合理扩展。
具有讽刺意味的是，我发现使用较弱的工具可以帮助应对复杂性。写一个复杂的C程序很难，因为它不能做很多事情。C程序倾向于使用大量的数组，因为这是你得到的全部，但事实证明，数组是非常紧凑的内存表示，O(1)访问，良好的数据局部性。尽管如此，我从来不主张故意使用一个软弱的工具。相反，我的教训是：像C一样编写Python代码。