吃自己的狗食（ eat your own dog food）是一种比喻的说法。对于软件开发公司而言，意思就是自己要尽量多用自己开发的软件。
唯有这样，才能知道它是不是存在问题；而唯有重度的使用，我们才知道它到底方不方便使用。
现实情况
而令人遗憾的是，软件开发人员常常不是自己开发软件的用户。有很多情况下，可能就是上司交给我们一个任务，需求往往也是客户拟好的。作为一名开发人员，我们只是把开发当作一项任务，一项“工作”而已。
经常的情况是我们对软件的使用场景不熟悉，也不知道软件为什么设计成这样，我们常常只是机械地完成客户交给我们的任务。
如果某个特性客户提到了，那它才会出现在最终的产品中；如果很不幸的客户没有提到，又或者我们与客户之间存在沟通不良（这种情况太普遍），那么这个特性就在我们的产品中消失了！而这个对最终的用户来说可能是很重要的，而我们之所以对这样一个特性的遗漏毫无感觉，一个很重要的原因就是我们并不吃自己的狗食！
一个坏的事例
我曾经用过 XX 词典，它有个单词本，能让你加入在阅读过程中加入的新词，然后它会安排你复习，但是它总是按照你加入这些单词的顺序来呈现它们。
那么这会有什么问题呢？我相信很多经常使用背单词功能的人是不难注意到这样一个事实，那就是一个固定的顺序会强化你的记忆，使你很容易在这种顺序的呈现过程中回忆起某个单词的意思，然后你会觉得自己记住了这个单词，但实际上并没有！
但一旦脱离这种顺序呈现的环境，比如你在另一篇文章中再次看到这个单词，你很可能想不起来它是什么意思。
所以，复习过程中的好的做法应该是打乱顺序，每次都使用随机的顺序。
另外一个问题是，你只能加入单词，却不能自行添加一个与之相关的例句，它会在它的例句库中找一个句子与其配对。很多情况下，我在阅读中，碰到一个句子有一个生词我不能理解，查了这个生词后，对我而言，其实最好的例句也许就是这个句子本身，但它却不能让我加入这个例句。
而一个单词常常有很多意思，它配的句子往往不是我原来看到的意思。我经常看一些技术的文章，我也许只关心某个单词在技术领域的狭隘意思，对于它的其它意思我可能并不关心。
所以有些时候，当我复习时，我都想不起来我为啥要加入这样一个奇怪意思的单词，它配的例句与我原来看的差别很大。但我在另一篇技术文章中看到这个单词时，我可能还是想不起来它在技术领域的意思，尽管我可能对它复习了很多次！
事实上，就这个两个问题，我还给软件的开发方发过 email 去反映，因为很多的软件总是说欢迎你给它们提意见，所以我就去提了。
然后我就收到一个热情洋溢的回信（当然也很可能是机器自动回复的），说：“非常感谢你的来信，我们会积极考虑你的提议”之类云云。
其实我给蛮多的软件提过建议，都会收到类似的回信，是不是真的采纳了我就不知道了。
过了一段时间以后，我再去看它们的新版本，没有发现任何改进；再后来，我也没有去关注了，而且我也很少用到它了，因为的确感到不好用。
当然了，我估计他们还是看了我的建议，但是并没有引起他们的共鸣，或许在他们的眼中这些建议是无足轻重的，那么原因是什么呢？我想到的最大可能的原因就是：团队本身很可能就不怎么重度使用这个产品，他们并不吃自己的狗食。
当然，也可能是我以小人之心度君子之腹，又或者我的需求确实比较奇葩，没有代表性。
在他们眼中，或许产品已经是足够好了，不需要再改进了。而如果他们真的是积极地使用自身的产品呢？我想或许都不需要我去提什么建议，这些特性也许就已经在产品中有了。
一个好的事例
必须说，很多时候很多软件都不那么令人称心如意。如果有那么些软件让人用上去感觉很惊喜，作为一名程序员来说，那 IDE（集成开发环境） 可以算一个。
而原因自然也不难明白，因为这程序员开发给自己用的工具！
事实上，很多新的 IDE 版本就是在老版本的 IDE 中开发的，然后这个过程不断迭代。所以这其实或许是一个吃自己狗食的最好例子。
没有比程序员本身更明白自己对 IDE 需求的人了。他们不断在使用这个产品，也最清楚自己还需要什么、产品还有什么不足，而且他们也有这个能力去改进它！
尽管由于复杂性的原因，使用过程还是可能遇到 bug 或不稳定等现象，但必须承认，在 IDE 运行良好的时候，它的确是一个很贴心的工具！
启示
那么，从以上一些事例中我们能得到什么启示呢？
假如你要开发一个比如说炒股的软件吧，你想招聘一个人来负责。有一个人技术很牛逼，基本明白股票的业务，但本身对炒股不太感冒；而另一个人技术也还可以，而同时是一个资深股民，使用过很多类似的软件，甚至能说出许多它们的痛点来。
而你作为负责人，你会招聘谁呢？如果你选择那位技术牛逼的，很大可能你会得到一款很稳定但与此同时也很平庸的产品！