编程哲学（三）：是什么影响了我们的开发效率

工作量是实际工作任务或可达工作任务，
而工作效率，一般指工作投入与产出之比。

在进行某项任务时，工作效率是取得的成绩与所用时间、精力、金钱等的比值。
产出大于投入，就是正效率；产出小于投入，就是负效率。

软件是一个神奇的行业，
不同的工作方式，在工作效率上可能会产生15倍甚至100倍的差距。

因此延长工作时间，变成了一件不是特别重要的事情了，
人们更多考虑的是如何在有限的时间内效率更高。

在提高工作效率方面，每个人都有自己的办法。
“不要重复造轮子”就是其中一个，
它使我们看到了重复劳动，这在一定程度上确实提高了我们的工业水平。

然而，另外一些方面，就不是那么直观了。

我经常看到很多人在忙着写代码，却没有意识到，
我们确实有很多事情要做，但是却未必有那么多代码要写。
更多的代码，意味着更高的开发成本，测试成本和维护成本。

因此，当我们需要动手实现很多功能的事情，
不妨问一下自己，为什么我们不得不写这么多东西。

难道我们真的走在了业界的前沿，做一些发明创造吗？
这个问题的答案通常是“否”。

没有在专业性上保持谦逊

某个领域的专家，会更倾向于喜爱自己所在的领域，
认可自身领域专业性的价值，否则当初就难以成为专家了。

这是一件利弊参半的事，
专业性使得一些工作被巧妙的解决掉，也使得一些工作被解决的过于勉强。

软件也是如此，
只有极少数情况下，用户是不得不需要软件的，
虽然我们听到和感受到的都是他们的确需要。

商业软件要解决的问题，通常在于缓解当前已有的工作压力，
或者说对现有方案做出改善，
却很少创造出全新的解决方案，虽然我们不是这么宣传的。

因此，带着专业领域的自豪感，我们很容易绑架用户，
或者帮用户做太多只能由他们做的事情。
这会在不经意间给用户带来新的负担，还会极大的增加软件的功能范围和复杂度。

所以，我理解的专业性，并不是在专业领域给用户寻找方案，
而是专业性的给用户寻找方案，结果可能是用户并不需要我们做那么多事情。

没有把自己变成信息源

人们对工程师的认识可能带有成见，
认为工程师一定是内向的，不善言辞的，
因为他们觉得只有这样才会显得更专注。

然而，别人这么认为，并不代表着这样做就是好的，
仅仅代表着如果这么做会给自己带来较小的阻力。

事实上我们应该反思一下，
内向和不善言辞是不是真的有助于自己把工作做好。

沟通问题在任何行业都会存在，并不是软件行业所独有的。
缺乏沟通，人们都被动的接受信息，会降低团队的工作效率。

这件事大家都是知道的，
然而却很少有人肯站出来，主动汇报自己的工作，变成信息源。

人们腼腆的不分享自己的成功案例，这可能算是一种谦虚，
但是因为没有机会得到反馈，而坚持自己的错误就很难被定义为谦虚了。

软件工程师需要主动得到工作反馈，确认待解决问题的动向，
向团队汇报自己的工作内容，向显然已经知道答案的同事学习经验。

不要自己扛下所有的事情，不要自己研究。

没有吃自己的狗粮

Eating your own dog food，直译为“吃你自家的狗粮”，也称为dogfooding，
是一句英语俚语，常用于描述公司（尤指软件公司）使用自己生产的产品这一情况。

好的工匠常常拥有自己的工具箱，
工程师也会思考如何利用团队的产出反哺团队自身。

我们有哪些工具是完成业务目标之外的副产品？
哪些副产品可以在后期当做产品来发布的？
我们做事情的方式是不是可以总结下来？

这是产生技术产品的一个有效办法，
而那些立志于只产出技术产品的团队，却往往难以存活下来，
因为他们并不用自己的产品。

吃自己的狗粮，让我们把一部分注意力放到了副产品和历史积累上面。
这些积累才是一个团队赖以生存的根基，
也是工作效率不可能被新团队取代的根本保障。

下一篇：编程哲学（四）：把控间接性