有些事情作为一个程序员在被问及时是解释不了的，比如程序当中出现了Bug，当被问：“这种错误你怎么能犯？”时，一般而言程序员都会选择沉默不语。因为遇到这种问题，根本就无法解释，因为作为程序员但凡能够知道会出Bug也不至于会写出Bug来。
但是，出现Bug，有一些程序员会选择“强行解释”。意思就是通过一些别人听不懂的术语，将自己因为不细心而产生的Bug归咎于其他方面。
但是，别人不懂技术虽然有时候能够蒙混过关，可是当技术有了参照，那就不一样了。所以，程序员在跟老板、产品经理或者甲方在沟通需求的时候，当需求实现起来比较难的时候，最怕的就是他们说：“为何别的软件能实现的功能，你实现不了？”。
一般而言，甲方提出的一些需求基本上其他软件都是能找到参照的。所以，当他们问及这个问题时，作为程序员很难回答。
如果坚持说做不了，但是别人的软件都实现了，自己却实现不了会很难堪。所以，有时候作为程序员，我们只能给出一个不确定的回答：“我试试看！”。
这个回答的意思其实也很简单，那就是目前我是实现不了的，但是我可以去百度一下，看看有没有其他的可以作为参考的方案。有的话还则罢了，没有的话，那只能拎包走人了！
可是类似“别人能做，为什么你做不了？”这样的问题问得真的合理吗？我认为从某种角度上来说，这问题或者说质疑是很不合理的！
很多时候，这并非技术问题导致的程序员无法做到，而是受制于认知和知识储备。试想，如果别人能做，那么所有程序员就应该都能做的话，那程序员就不应该被分为初级、中级和高级了！
我们首先从认知层面来说！一个项目，程序员做得顺畅不顺畅，首先就得看程序员对于项目流程的认知，也就是我们常说的业务逻辑。
打个比方，就好比我们要开一个手动挡的汽车，把车子开起来的逻辑顺序应该是踩刹车、点火、踩离合、挂挡、松离合、汽车开走。这其实就是大多数手动挡汽车从点火到开动的业务逻辑，如果一个程序员要写一套相关逻辑，那么这个程序员对于手动挡汽车从发动到开走的每一步都得清楚。
所以，看似对于可以开手动挡汽车的程序员，这是很简单的业务逻辑，但是一个连驾照都没有的程序员，他对于离合、挂挡这些东西是一点概念都没有的，更别说要把整套业务逻辑写出来了。
所以，认知是取决于程序员是否有能力完成一个功能的前提。
然后就是知识储备！这个其实就很好解释了！最典型的情况就是对于算法的掌握。
大多数程序员其实跟普通人一样，只会写一些简单的算法，也只能看懂一些简单的算法。但是，很多软件之所以优秀，那就是程序的底层算法优秀的结果。
当一个程序员对于数学的知识储备不够的时候，即使有人把一套数学公式放在这个程序员面前，他也无法将这些数学公式转换成代码，因为他完全看不懂！要知道，人和人是不一样的，否则就不会有那么多被称之为“大家”的人了。
所以，虽然别的软件能实现的功能，我实现不了，其实这并没有什么丢人的地方。我以前也遇到过几次这样的事情，最后通过各种验证，证明我真的无法做到时，只能跟我的研发经理说：“以我的能力，我实在做不了！”。