有些人不愿意分享，但这是少数
有些人愿意分享，但有些害羞，这是一小部分
有些人非常愿意分享，但公司没有这个氛围。
继续做自己的事，让别人继续折腾去吧。
在开发过程场景中必然需要和同事讨论各种问题，尤其是我们开发的平台的特性使用。在这个过程中，给我印象比较深的就是一个类似的，不断重演的场景：
Q： 我要开发一个xx功能，需要xx，你有么？
A： 我有。
Q： 啊，那个谁，你的那个函数（类，框架，标签）怎么用的？
A． 偶，我给你一个代码。
Q. 看了，偶，原来是这样啊
于是，一片片的代码顺着网线在网络飞鸽之间飞来飞去。
因为常常会说“原来是这样啊”，我们就用日文说“soga shidi”(原来如此)。这个短语因为不太常听到，因此其他组的人也开始跟着学起来。哈哈。真的是一段快乐的日子。
回头来看，大家都在之间用代码来做沟通，效率是非常高的，比高谈阔论来得快的多。
我的手下的程序员这几年都习惯了这样的场景，因为他们发现遇到问题费尽口舌常常也说不清楚，而代码对于很多问题可以不言自明。于是就看到了口语用来起承转合，而代码代码飞起来用来说明实质问题的实际效果。
这样的情况自然而又普遍，遇到的多了，我也就用心的分析了下：为什么程序员懒得讲，而愿意用代码来交流？为什么代码总是不容易讲得出来，往往直接去看反而更加容易懂？
我想原因在于：代码作为计算机语言，和英语或者汉语相比的，很大不同的一点在于计算机语言没有一个对应的口语，并且高度精炼，专门用来表达业务和技术的实现。而同样的业务和技术实现，如果换成口语，可以说必然是一地口水了。
读代码来得快，而通过读代码了解别人的工作，学习新的技术，通常也比单单看书来的快。
作为一个程序员的管理者，要保证和程序员的有效而快速的沟通，了解项目的真实质量状况，保证自己对等甚至比程序员更加清楚代码是必要的。但是考虑到时间上的因素，有不可能100%的投入到代码开发中去，因此大量的阅读代码并给予反馈就是一个简单可行的方法。
有些人愿意分享，但有些害羞，这是一小部分
有些人非常愿意分享，但公司没有这个氛围。
继续做自己的事，让别人继续折腾去吧。
在开发过程场景中必然需要和同事讨论各种问题，尤其是我们开发的平台的特性使用。在这个过程中，给我印象比较深的就是一个类似的，不断重演的场景：
Q： 我要开发一个xx功能，需要xx，你有么？
A： 我有。
Q： 啊，那个谁，你的那个函数（类，框架，标签）怎么用的？
A． 偶，我给你一个代码。
Q. 看了，偶，原来是这样啊
于是，一片片的代码顺着网线在网络飞鸽之间飞来飞去。
因为常常会说“原来是这样啊”，我们就用日文说“soga shidi”(原来如此)。这个短语因为不太常听到，因此其他组的人也开始跟着学起来。哈哈。真的是一段快乐的日子。
回头来看，大家都在之间用代码来做沟通，效率是非常高的，比高谈阔论来得快的多。
我的手下的程序员这几年都习惯了这样的场景，因为他们发现遇到问题费尽口舌常常也说不清楚，而代码对于很多问题可以不言自明。于是就看到了口语用来起承转合，而代码代码飞起来用来说明实质问题的实际效果。
这样的情况自然而又普遍，遇到的多了，我也就用心的分析了下：为什么程序员懒得讲，而愿意用代码来交流？为什么代码总是不容易讲得出来，往往直接去看反而更加容易懂？
我想原因在于：代码作为计算机语言，和英语或者汉语相比的，很大不同的一点在于计算机语言没有一个对应的口语，并且高度精炼，专门用来表达业务和技术的实现。而同样的业务和技术实现，如果换成口语，可以说必然是一地口水了。
读代码来得快，而通过读代码了解别人的工作，学习新的技术，通常也比单单看书来的快。
作为一个程序员的管理者，要保证和程序员的有效而快速的沟通，了解项目的真实质量状况，保证自己对等甚至比程序员更加清楚代码是必要的。但是考虑到时间上的因素，有不可能100%的投入到代码开发中去，因此大量的阅读代码并给予反馈就是一个简单可行的方法。
