当一个低级问题，第一次解决时，你会感受到成就；第二次解决时，你感受到责任，第三次解决时，你可能更多的感受到无力（转）

　年轻的同学喜欢按学习曲线来看自己过去的每一年，但是这种方式很快就会步入到瓶颈，学习曲线增长突然会变得缓慢。在 2013 年圣诞节时，Tim 还在每天花上 10-30 分钟玩一款叫 Clash of Clans 的游戏，并邀请身边的朋友都加入了部落，当时每天的升级成长也很快。但不知道从哪一天开始，发觉升级越来越慢了，需要 2 周或者更长时间才能将一些对象升级，所以慢慢的对其失去了成就感、耐心与好奇心。

　　工程师对于技术的关系也是如此，刚接触第一门编程语言时候，对每一个细节充满了好奇心，发现一种新的语法糖也会兴奋不已。当使用这些技能之后，慢慢的发现工作中只会重复的使用其中 20% 左右的领域，就这样月复一月的过着。当然学习的习惯还继续保留，工作之外的东西也会去看看其他一些东西，比如花一周学习媒体炒得火热的 Swift 语言。但较常见的情况是，大家学的这些新潮技术工作中一般不会立即使用，几个月之后 Swift 怎么写可能一点也不记得了。几次类似经历之后，当再有新的某项技术出来，如果看不到有使用的需要，你已经不打算再学了。毕竟花很大力气学会某项东西，又注定在几个月后会忘记，这种做无用功的感觉很不好。因此最终学习曲线会停滞在某个点。

　　前几年在新年来临之际 Tim 也会去给一些技术媒体投稿，彻夜不眠写出一篇技术圈宏大的总结与展望，希望能给从业人员指出一条明路。但是这种凭借个人视野有感而写出来的东西，最终指导不了自己也指导不了别人。技术领域太广太深，即使图灵奖得主也很难去评论另外一个专业领域未来一年的发展趋势，能看到的各种预测无非是主流媒体的观点汇集而已。于是后来就不写（也不看）这种总结展望了。尽管技术领域内盲从的心理还是非常显著，很需要这种指南类的东西（比“干货”受欢迎多了）。

　　在 2014 年日常感悟比较多的，就是对昨天文章技术团队的标准化与可复用文化所说的技术群体里面的无序感到有些悲观。当一个低级问题，第一次解决时，你会感受到成就；第二次解决时，你感受到责任，第三次解决时，你可能更多的感受到无力。当你观察一个小的团队时时，这些情况不会明显；但当你把目光聚焦在一个稍大的团队，比如 50 人以上时，这种问题会更容易发现。

　　有人倡导自组织团队，包括各级大佬 BOSS 们也给我们指出这是前进的方向，但是完全具有自组织特征的团队不是很容易见到。Tim 身边更多情况是靠各级管理者强有力的执行力去推动。想想如果没有领导的角色可以自运作起来，还是很有挑战的一件事情。当然挑战不包括各种技术大会的那些敏捷教练们。

　　开源这个词有些滥用，我个人去评价一个项目时候更多的是看它解决的问题以及带来的价值。国内业界的问题不是开源不够，而是能创造价值的软件太少。单纯去讨论开源运动我觉得和讨论”跑步运动“或者”站立办公“没什么区别，虽然我也尝试站立办公，但是我觉得没必要天天挂在嘴上。

　　运营开源最重要的是社区（指贡献你项目代码的群体），先是有了社区，然后有了你的开源 project。否则你的项目最多会成为一个带源代码的一款工具软件。经常的误区是一些人觉得将内部的一堆不再维护的代码上传到 github 上，然后就期望一夜成名，或觉得船到桥头自然直，这就有点 naive 了。

　　虽然大数据很热，但是我认可大部分 engineering 方向的工程师不适合做大数据这个观点。不是说这些人不够聪明，而是当你已经 25 岁左右时候，你已经用了3-5 年“最好的编程语言”之后，来决定踏入大数据算法这道门，时机有些晚了。大数据的算法是稍微和计算机科学的“科学”二字最搭边的一门学科，这个算法和 CS 学的那些快速排序算法有很大的区别，通常这些半路进入的 engineering 类的工程师，最终的天花板可能是一个数据统计工程师或者是协同过滤工程师。即便如此，一代又一代工程类的技术人员义无反顾走了进去，经过半年一年狂热的学习之后，在一些大 BOSS 不理解的岗位上默默的发挥着作用，并坚信自己已经是迈向金矿的康庄大道上。大部分没有 Critical thinking sense 的工程师，习惯在因与果之间用“自然而然”推理并联系起来，比如“只要我进一步学好大数据算法，自然而然，就能挖到金矿”。

　　2013 年元旦时候也写了一篇谈分享、创新与开源，和目前想法也有些明显的区别。

 

http://news.cnblogs.com/n/512212/