我们经常都会说，要进入到一个高手比较多的地方去学习。一旦你身处一个高手遍地的地方，其实你会发现人跟人差距就是这么大，而且高手做的事情你一点也插手不上，而且其实很多情况下也没法学习到什么东西，很多时候高手最牛逼的地方在于经验和思维。
如果你们只是在一个项目里边分工合作，而你除了干好自己的事情以外没什么其他的目标了，那么很抱歉，你可能压根学不到什么东西。
如果一个集体的共同目标仅限于产品的层次，那并不见得会促使其中的程序员互相学习。而反过来，团队内部的成员不仅目标一致，而且其目标与他们具体开发的产品毫无关系，正式这种目标的引导下，一只团队的成员才会通过互相学习共同提高。
因为就我的经验来看，大部分程序员在一起工作并不会互相学习。如果是导师，那可能会有一些经验的指导。如果是平级，那可能一年下来都不会互相学习。就算是经常有合作，很大可能性都只会在项目功能接口层面进行沟通。一方面是术业有专攻其他领域其实挺难去介入的，另外一方面可能思维上就压根没想能从 A项目、B项目 别人的产出上面学到什么东西。
但是如果，仅仅是如果，如果所有人都有一个评判标准，以及都有一颗想提高自己代码质量的心，我们会进行代码 review。代码 review 过程其实是能产生很多东西的，同时也能学习到很多东西，但是有个大前提，就是大家的对这个事情本身也感兴趣，而不是为了具体的产品。根据以往的经验，这种事情很快就流于形式，也就是随便看一看，就算是精心准备的分享基本也都会被听众忽略掉，这就没什么意思了。但是如果整个团队对分享和代码 review 这个事情本身很感兴趣，还是能从中进行查漏补缺得到非常多的信息的。
把一群程序员放在一起他们很多时候他们并不会互相学习，只有平时有共同理想，愿意唠嗑，愿意一起解决难题，愿意听对方的意见和分享的的一群小伙伴才会在不知不觉中互相学习互相指导。
人类总会本能性地，反对别人对自己的负面评价。
即使面对来自自然地，难以接受的反面证据，人们也往往会认定自己的程序完全正确。
“这不是 bug ， 重启一下试试”
“这不是 bug ， 绝对是使用方式有问题”
我发现很多时候人类都是会逃避对自己的任何负面评价的，无论这个评价是不是从很多人看来都是无可辩驳的，毕竟计算机不会骗人，它只会做我们告诉他要去做的事情，但是人对它结果的解读是可以有主观性的。一个很好的功能，到了另外的场景可能就是 bug 。一个很难解决的bug，到了另外一个场景可能就是一个很好的功能。
有这么一个小故事，很久很久以前，我们的程序有一个 bug 总是找不出来，就是有一段内存总是会随机性丢失。我们就开始查，拼命查，没日没夜地查，程序员走了一波又一波。但是依然都找不到这个问题所在，很是苦恼。突然有一天，咦，有一个地方需要模拟一个场景，就是 内存随机性丢失的场景下对程序进行测试。喔吼!!!这个带 "bug" 的程序比任何人为构造出来的内存丢失更加随机更加可以反映事实，而且在很长一段时间里都非常"稳定"。
现在你还觉得这是一个 bug 吗?
关于团队的高效
有些主管依然会与高效的程序开发团队发生冲突，并进而又以各种毫不相干的借口，将这些团队解散。而有些主管虽然还是搞不懂这些团队的运行方式，但是他们却至少懂得应该容忍这些团队的存在。
在很多的职场，都会出现这么一个现象就是有其中一个团队效率非常非常高，而且交代的事情也能完成得非常非常好，但是主管看不懂啊。很不明白为什么这帮人就行，另外一帮人就不行，也不是能力上的问题啊大家都是同样的标准招进来的。
有的主管能很好处理，不理解就不理解，这些事情交给他们就稳了，我对他们也爱护有加就行了。而有的主管则不能，就是希望掌控全局，任何一个小细节都不放过，对于这些超出认知范围的事情很是扎心，一定要插一手，所以就出现了上边的情况了。
程序开发的社会效应
关于程序开发的社会性。比如程序开发中有其中一个环节就是程序员A口头将信息告诉程序员B，这在以往的运行过程中得到了非常好的效果，这时候你换掉程序员A或者程序员B，都将带来效率的降低。
很多时候我们都以为我们的程序运行都是靠我们完美的产品设计，稳定的系统流程，全链路能 Cover 住。很遗憾不是这样的，我们处在的是人类社会，是人类在使用这些东西。只要有人类介入，那绝对存在一些很迷的东西。
比如，有一个功能开发好了，开发的第一反应不是去系统上点一下完成，而是大吼一声："测试大佬，我那个bug修好了你验收一下"。
又比如，很多程序员都会去找架构师聊事情，但是我们又发现有很多程序员坐在架构师旁边的咖啡小屋那叽叽喳喳，所以老板决定把这个咖啡小屋干掉。好了事情来了，架构师开始忙不过来，大大小小的事情都找架构师解决。
原来有这么一个咖啡小屋，大家看起来叽叽喳喳的很吵，但是其实大家在等架构师空闲的时候，已经在咖啡小屋把很多小事情讨论完了，或者梳理出了一个比较可行的方案，这样会节省架构师的时间，也会节省程序员的时间。
