One more struggle, and I am free
在我上大学的时候，除去普通的英语课程，专业课程里还有一门《计算机英语》。当时大家的普遍认为，普通的“英语”是过四六级用的，《计算机英语》才是专业真正需要的。
等到工作了，我发现很多人都持这样的观点：程序员应该学好英语。这样才能方便地查找资料，迅速地学习最新的知识。换句话说，“学好英语”在很多人看来，就是是“学好专业英语”——这项要求已经很高了，我曾经在《程序员要怎样学英语》里提到，不但要能看懂文档，还要知道“黑屏”是blank screen，“死机”是system halt，否则查找就会很费力。
但是今天我想强调的是，对程序员来说，学好“英语”而不是“专业英语”是非常重要的。只学好专业英语，看得了技术文档，但那一大堆专业术语和概念可能会像陨石一样，没来由地坠落下来，只能生吞活剥地硬背。如果学好英语，你才会有融会贯通的感觉，知道那些术语和概念原来是从地里长出来的，底下连着根茎。
我刚刚工作的时候，面试官曾经跟我说：好好干两年，可以迅速从程序员成长为工程师。当时我觉得太诧异了，从很多招聘启示来看，“程序员”不就等于“工程师”吗，只是“工程师”更好听一些而已。等我工作久了，才知道“程序员”和“工程师”真的是不一样的——程序员只写程序，工程师写能在现实世界中创造价值的程序。
可惜，很多软件开发人员未必清楚两者的差别，甚至做了很久也只算程序员而不算严格意义上的工程师。所以我就自己的观察和经验，谈谈程序员和工程师的差别。
前几天和朋友吃饭，听说一件有趣的事情：他们很需要的小语种员工，入职刚三天就辞职了，理由是“感觉不到同事之间的温暖交流”。说起这件事，这个朋友也是非常无奈：业务忙着呢，大家上班都在做自己的事情，尤其是小语种的人本来就不多，和大家交流少，如果因为这个理由辞职，也是没有办法的事情。
离职的理由很充足，但是，这个小语种的员工又确实是公司业务发展需要的。这个问题要如何解决呢？
一般人会说：需要HR做好工作嘛。没错，在成熟的大公司，员工入职的前几天，都会有HR部门安排的培训，内容包括企业历史、企业文化、行为规范等等，同时也是提供机会让新员工互相认识，然后才会派到真正的职能岗位上。这样的安排，有助于消除员工的陌生感，新员工之间的“同病相怜”，也有利于维系员工。
然而，许多公司并没有这么“称职”的HR，要避免新人“入职就离职”的现象，职责只能落到员工所在部门的直线领导身上。尤其在创业公司，直线领导往往必须“既当爹又当妈”，业务行政一起管，加之很多愿意创业的人“天生”就不喜欢和“没事找事”的HR打交道，而更愿意和自己有共同语言的同事沟通。所以，由直线领导来出面，既是责任，也是优势——从我自己的经验来看，直线领导如果愿意出手，通常都能取得不错的效果，前提是不能把入职简单看作一个动作，而要理解“新人入职是一连串事件”。下面，我简单介绍自己的经验，供有兴趣尝试的读者参考。
最近几年不再混战在纯互联网领域，接触了很多与实体有关，尤其是外贸电商行业的生意。见识开阔了不少，也经历了很多，同时也有困惑和思考。在这里我尝试谈谈自己现在想明白的几个问题，有些只与具体的生意有关，有些则与行业有关，虽然比较杂乱，但希望对大家有参考作用。如果大家有意见，也欢迎讨论。
众所周知，日本车在全世界都是很受欢迎的。究其开端，很多人会想到20世纪70年代的石油危机，认为是油价高涨，为尺寸小、油耗低的日本车打开了市场。这固然可以解释一部分原因，但另一方面，为何日本车能够持续受到欢迎，为何日本车能摆脱“价廉质差”的形象，既有优惠的价格又有优异的品质（缺陷率常年很低）。这一切，都与日本汽车厂商所采用的“精益生产”，尤其是丰田开创的“丰田生产方式”（Toyota Product System, TPS）有很大的关联。最近因为与供应链打交道很多，我花了些时间学习这种生产方式。有趣的是，我发现，它的价值不只限于汽车行业，甚至不只限于制造业，对其它许多行业（包括软件行业）。所以下面我讲讲丰田生产方式给我的启示。
“扁平化”大有泛滥之势，似乎一说起企业（公司）的结构，就必提扁平化。按照流行的说法，“扁平化”的好处很多：平等、轻巧、简捷、高效。由其反衬，传统的公司管理结构一无是处，只剩下笨重、麻烦、低效。但是，企业管理这门学问分明诞生在“扁平化”之前许多年，在“扁平化”还没流行之时，企业管理已经取得过相当的成就。那么，“扁平化”到底是何方神器，何以能够横扫四方呢？
依我看，要了解这个问题，首先要了解企业为何需要管理。要了解这个问题，又必须了解企业为何会存在。好在，经济学家科斯曾经有两篇著名的论文《企业的性质》和《社会成本问题》，提供了非常精妙的解答。
“社交网络”或者“社会化”是当下非常热门的概念，由此也诞生了许多“社会化”的应用，比如“社会化问答”、“社会化阅读”、“社会化求职”，看起来既光鲜又高级。但是，“社会化”的应用真的能造福所有参与者吗？
互联网促进了信息的自由流动，社交网络对人之间的互动信息进行组织和沉淀。在互联网上我们可以和千里之外的朋友及时沟通，也不在受到作息时间和时区的限制。社交网络保存了这些沟通和互动，让它们可以被检索，被传播，被分享。这的确让无数人欢欣鼓舞，也让无数人沉醉其中。但如果认为社交网络的价值仅仅如此，未免太过简单。
不知从什么时侯起，“互联网思维”成了热门的名词，不管什么东西，一旦沾上“互联网思维”，就瞬间变得金光闪闪。无数人手握“互联网思维”，雄心勃勃地要改造各种行业，大有大跃进时“向三山五岳要粮”的气慨。然而仔细想想就不难发现，“互联网思维”的最初鼓吹者，只是在事后按照“互联网思维”的路子去解释自己的成功经历，正如同我党用《东方红》来解释从整部革命史一样。其它鼓吹乃至信奉互联网思维的人，我还真没听说有几个在“互联网思维”的指引下取得了成功。所谓“互联网思维”，在我眼里更象一出傲慢的闹剧。
我曾经说过，互联网最大的价值是加速了信息的有效流动，因此大大降低了许多活动的成本，省略很多中间环节（当然，这些中间环节主要作用是传递信息）。一旦深入到现实世界，互联网还是要受到现实世界的制约，要尊重传统积累的智慧。那种以为有了“互联网思维”就可以横扫一切的傲慢，是断然要不得的。
一晃六年，《技术领导之路》要再版重印了。回想刚刚开始翻译这本书时，我还忙碌在程序开发的一线，对领导技术团队并没有太多经验；如今，也能差强人意地带领技术团队支撑年销售额数亿的业务。一路走来跌跌撞撞，所幸没有中途倒下。思考其中的原因，除去运气，除去身边同事朋友的支持，翻译《技术领导之路》也是不容忽视的因素。
很多人都知道，“职场童年”非常重要，一个人最初工作的几年，在什么样的环境里，得到过什么样的锻炼，很可能决定了他整个职业生涯的走向。同样的道理，“领导力童年”也很重要，一个人对领导力的最初接触和认知，也会深深影响他对于“领导”和“领导力”的观点，甚至领导作风。所以，在我还忙于一线开发的时候，通过翻译《技术领导之路》，“生吞活剥”了一整套关于领导力的学说，基本“塑造”了我关于领导力的认知，深深影响了我作为技术领导的管理风格和价值取向，因此也对很多问题有了自己的判断——前段时间和另一位掌管公司技术的朋友聊天，说起那种“执行力超至上”的领导风格，我们都认为，尽管或许能出结果，但不是好的领导风格。
算起来，我从互联网开发投身企业开发已经有四年多时间了。刚刚进入企业开发领域时心里很是忐忑，虽然也读过《企业应用架构模式》之类的书，到底没有做过正经的“企业开发”，好在业务不算太复杂，所以更多是借着之前互联网开发的老底子解决问题。而且，这么做确实能解决问题，只是心里还不太放心，总觉得这不是名正言顺的“企业开发”，以后会有问题。
谈到传统的企业开发，大家通常想到的是“为明确目标（通常由甲方设定）而开发的紧耦合固定系统”，主要元素包括重型框架、长发布周期、严格的限制、海量的文档、对商用软件的倚重等等。谈到互联网开发，大家通常想到的是“为不明确或多变目标而开发的松散多变系统”，主要元素包括轻量类库、迅速迭代、不断试错、简单交流、开源/免费软件的广泛使用。传统上，企业开发和互联网开发俨然两派，你觉得我是杂乱无章的恣意胡闹，我觉得你是傻大笨粗的因循守旧，好在双方“井水不犯河水”，也相安无事。
企业开发和互联网开发的这种区别，让我在以互联网开发的方式应对企业开发任务时，始终有挥之不去的担忧。然而工作得越久，事实却不断证明这种担忧是多余的，或者至少不必高估“企业开发”的正统性。而且，有越来越多的迹象让我相信，企业开发的互联网转向，即在企业开发中越来越多地采用互联网开发的方法，是未来的趋势。按照我的总结，原因大致有以下几点。