助人
作为一个热情洋溢的程序员，不谈技术，为什么要谈助人？从三个最近的体验谈起。
年初，参加了一个培训，主题是非暴力沟通。参加它，是因为一次和同事讨论，互不妥协，挣的面红耳赤。培训完，我牢记了一句话，”连接在先，方案在后”。互相倾听，互相挖掘对方需求，而后讨论解决方案。接连的好，其实就有了一半的解决方案。培训后，一向信仰技术的我，开始思考人的重要性。
上个月，在三番的JavaOne里，接触到了很多时髦技术，还参加了一个经验交流会。会里，业界的顶级人才分享了影响他们职业生涯最关键的事情。其中Edson Yanaga分享了他的转折点，“和人们建立连接，做一些改变人们生活的事情。由衷的感激，全心的帮助人们”。这段话，对于开始思考人重要性的我来说，就像遇到了知己。
这两天在Hackernews上读到了一篇超过2000分的文章，Be Kind。这么多年几乎没见过超2000的。作者分享了他的故事，说是，有次，他做错了事，准备好被炒。结果老板不但没训他，还友善的问他学到了什么，之后还鼓励他，相信他会做的更好。作者受到触动，如今带新人，他时刻提醒自己要友善助人，看到他人的潜力。看完这个故事之后，我又产生了一次共鸣。
作为程序员的我，往往被对技术的执着和信仰蒙蔽了的双眼。看到了屏幕上的代码，却没有看到电话的那头，有一个止步不前，需要帮助的人；没看到邮件的那边，有一个想得到回复，早点回去接孩子的父亲；没有看到身边的新人，刚起步，渴望点拨。
把出发点放到人上，接电话，回邮件，带新人都是快乐的事情，因为助人。
延伸阅读
推荐文章（由hexo文章推荐插件驱动）
代码的历史局限性
越来越多的人在谈极限开发，结对编程，测试驱动。人们以今天的标准，审视着往日的代码，嗤之以鼻。然而，当今的规范并非横空出世，它是经历了计算机科学，互联网技术发展的不同阶段，而逐渐演变成如今的样子。一个时期的代码，有着那个时期的历史局限性，不是人们不想写单元测试，而是根本不知道什么是单元测试。
一天，我和一特别执着的程序员聊工匠精神，说他执着，是因为头发都白了，他还在写代码。话不到两句，就开始抱怨代码中的种种不是。因为他开始的早，我好奇的问，你刚开始写代码的时候知道单元测试吗？他说，谁去管单元测试，内存那么丁点，先把代码写进去，能运行再说。
虽然我的问题略显愚钝，我却突然想通了一件事。因为我身边的这位执着的程序员，不是他不懂得工匠精神，也不是不知道单元测试，而是那时候，它们根本不存在。我们不能因为今天有高铁，就看不起当初的小推车。所处的历史环境不同，满足的需求不同，实现的方式当然也就不同。因此我们得去学会体谅这些历史局限性。
然而，懂得体谅并不意味着忽视问题。小推车被高铁取代了，而没有单元测试的代码，却依然充斥在我们的软件中，阻碍着我们前进的步伐。而谁又能确定，我们如今所崇尚的编程方式，设计原则，不会成为明天大家的笑谈？我们是不是也活在我们的局限性里？文字到这，我只看到了四个字，与时俱进！
推荐文章（由hexo文章推荐插件驱动）
积累的效果显现了
最近发生的两件事，让我很欣慰，它们让我看到了积累的效果，给了我继续积累下去的信心。
第一件事，法国最佳程序员竞赛。在近千人的比赛中，我取得了初赛第一，决赛第十四的成绩。赢了一个免费去荷兰度周末的机会。
最终得到通知是比赛开始的三天前。因为之前报名晚了，被放在了等待列表里。因此，我并没有对这次比赛进行针对性的训练。然而，我还是有所准备。从2015的Google Hashcode的比赛失利受到激发后，我就开始锻炼算法的基本功，看算法书，上算法课，参加公司的coding dojo。
初赛，一共三题，45分钟。前两道，基本功扎实的选手都可以解出来，只有第三道，突然增加了难度。看完题之后，我认出来了，这是一道基于动态规划的经典题目的变形，word distance的加强版，这个模型见过。面对这个经典问题，我没多犹豫，直接在网上搜出了解决方案，word distance with swap。提交，通过！这时离比赛结束还有十分钟。
比赛哨声吹响了，裁判开始宣布结果，说只有一个人做满了三题。在他喊出我名字之前，我已经开始澎湃了，因为我知道肯定是我。在众人面前脱颖而出是一种很奇妙的感觉，几个其他参赛选手向我走来，百思不得其解的问我，你怎么可能在这么短的时间里做满了三题。
决赛的第一题，有经验的人很快可以看出来是minimum spanning tree的问题。第二题，难度更大了(据我推断，是一道balanced graph partition的模型)，没有一定功力的人是解不出来的，其实所有的参赛者中只有一人攻破了它，他成了最终的冠军。
平日的积累，一点一滴的，很难看到效果，但到了一定阶段，到骨子里之后，在一些不经意的时刻，它们的功效就会显现出来。就像一个习武的人，突然有一天他发现，它好不经意的躲过了别人的进攻，好不经意的发现可以跳的很高，练成了轻功。
第二件事，我给公司的另外一个组和一些主管做了关于spark和storm的报告。
有一天，公司里的一个大boss给我打电话，问我有没有空。我当时很惊讶，因为他的级别比我高很多，并且工作没有交集。我以为他要挖人给我升级呢。后来，他带我到了他办公室，想让我给他讲讲spark。我说为什么是我呀，他说，因为我写的内部博客他看到了，很感兴趣。他问我有没有时间给他讲一下，我就必须有时间的给他讲了一遍。他感觉很好，没过两天，我就把这些东西给他手下的一个组外加其他组的几个管理者，讲了一遍。
其实，对spark和storm的研究是一年前的事了，当时只给一小部分人做了汇报。可即使是一小部分人，我也是很认真的做了幻灯片，没放松报告的质量。讲完之后，我延续了写作的习惯，写成博客给大家分享了。没想到，后来还真有人看上。这件事，一方面证实了写作的各种好处，第二就是说明事情不论大小，不论受众面有多大，只要认认真真的做好，就可能会有惊喜。
平时看到一些杰出的人把一些事做到了完美与极致，很崇拜他们，也很向往成为他们那样的人。这两件事，虽然不是什么可以值得吹嘘的大事，但毕竟给我带来了一些成就感，也更加坚定了我的信念，任何能把事情做到极致的人，肯定不仅仅因为幸运，他们平日里默默的积累，给了他们抓住机会的实力。
当程序员老了
之前类似这种题目的文章很少去读，可最近这种想法经常闯进我的思考范围。可能是人马上要三十，到了要想这个问题的年龄了。和其他关于衰老的话题一样，谈起来难免有些淡淡的忧伤。可认真的琢磨之后，发现未雨绸缪是件好事，能看到忧伤背后的从容和坦然。
程序员也是人，所以有人的共性。十几二十的时候，很少会想到老。一是忙着学习考试，没时间。即便有点时间，搞搞对象，打打游戏，也不会轮到它。说白了，还是因为年轻，可塑性强，没什么好怕的。到了快三十的时候，就不一样了。工作之余，时间有了。人闲了，就容易琢磨事儿，还老爱自己吓自己。其次，三十岁的人，慢慢意识到老为何物，爷爷奶奶听不清看不明了甚至走了，爸爸妈妈白发多了。最后，想再折腾的时候，发现已经到了生育培养下一代的年龄，担的责任越来越重，不敢再冒险了。在这种情形下，如果还找到良方来从容应对年月带来的冲击，就会有危机感，害怕老无所用。
经验和精力
一个人随着年龄的增长，经验会更丰富，同时，精力也会减少。所以上了年纪后，要学会利用积累的经验去创造价值，而不是单纯的用精力去和年轻人拼。
明白了这一点，就应该注重经验的积累。如何积累呢？首先，得从自身找出路。做同样的一件事，有的人爱观察，爱思考，可以了解事物的本质和内在联系。也有的人，只注重事物的表面，不加深究，只获取看得见，摸得着的果实。日积月累，前者的经验当然会越来越多。其次，要借助外力。有的环境利于经验的摄取，而有的环境只会单纯的让人变老。一个充满挑战需要开拓创新的环境，和一个整日复制粘贴的环境，它们所蕴含的经验有天壤之别。
所以，作为程序员的我们，要勤于观察，善于思考，特别是在这个各种框架、语言、技术日新月异的年代。拿大数据这个炙手可热的新名词来讲，从之前的Hadoop和到之后的Spark框架，技术革新速度是令人无法想象的。然而，爱思考的程序员们会发现，有些东西，的确变了，而有的东西是没有变的。比如说基于图的数据结构和算法，分布式系统的扩展性和可靠性问题，以及系统性能的测试和优化方法，这些基础通用的懂事是没有变的。Spark的核心思想RDD是一个创新，不求甚解的人只会学习如何使用它，爱思考的人会摸清它的来龙去脉，知晓它的优势和局限。这样一来，牢固的基础和丰富的经验可以帮助很快的掌握新的技术。
谈完思考的重要性，再看看环境，上面说到的开拓创新的环境，是很好，可没有怎么办？答案是看你想不想要。环境是可以争取的，甚至可以自己创造的。
我在现在的公司，在同一个职位干了快有五年了。干了三年后，工作开始漫漫变得重复乏味起来。大部分的时间是我帮别人解决问题，而不是我去请教别人，输出大于输入。为了能创造一个更加开拓创新的环境，我曾经“威胁”老板说，如果再找不到具有挑战性的项目，我就要走人了。后来，在我的推动下，终于找到了让我满意的项目和环境，争取到了和公司架构师们一起做项目，向他们学习的机会。除此之外，我还去参加编程比赛，程序员见面会，主动做演讲。这些都是为了创造互相交流学习的环境。
说了这么多关于经验积累方面的见解，我想简单的谈一下精力。精力会随着人的衰老而减少，这是无法阻挡的自然进程。我们能做的，就是放慢它的脚步。唯一方案，就是运动。相信大家都明白生命在于运动的道理，我就不多说了。
潜心治学
上面说那么多关于经验的事，只是想从职业竞争的方面说明，老并不可怕，只要方法得当，经验可以转化为不可或缺的优势。加上运动的好了，可以老将出马，一个顶俩。
接下来，说说潜心治学的态度。很多人程序员做了两三年，就想着转行，转产品，转客户，转管理，就好像那些行业不需要养老一样。如果是对编程失去了热情，那么如此做便是无可厚非。但如果仍热情饱满，却因为担心程序员的未来，而转行，那么就没有必要了。
首先，从专家程序员的市场价值来说，他们能够解决别人解决不了的问题，他们能够看到别人看不到的深度。再某些难题面前，一个专家，不能被十个初学者换掉。因为这不是一个搬砖的过程，而是一个修行达没达到深度的问题。除此之外，潜心治学，可以满足人们对知识上的追求，有的快乐并不是金钱所能买得到的，刻苦钻研，攻克难关本身就是一个可以给人以巨大成就感的事情。
潜心治学，成为大家，并非易事，也正因为如此，它是一条可以让人实现巨大自我价值的道路。这样的人，从小的来讲，可以是某些项目的带头人，可以是专利的获得者，可以是书的作者，可以是一个讲师。往大的讲可以是图灵奖的获得者，可以是改变整个世界的人。
结语
哗哗啦啦用了好几天的时间讲了这么多，一是想告诉自己，要沉下心来，做自己喜欢做的事，并且享受这个过程。其次，是要记录下，处在三十岁的这个关口，我对程序员人生的看法。也分享给其他的程序员朋友，共勉。
我是热情洋溢的程序员，王辉。
延伸阅读
执着的创业者
我们约好的是十二点见面，后来被推迟了，因为他要见客户。中午饭没能在一起吃，下午两点和他见着了，在分别了三年之后。
我们是老乡，都生在河南商丘。也是在法国求学时的校友，他读博士，我攻工程师。他自己动手作过馒头，从和面，发面，揉馒头，到下蒸锅，确实有一手。后来他学成回国了，带回去了一个媳妇，在法国认识的北京妞。走的时候，他把蒸锅留给了我。我学完直接留在法国工作了。
后来，从朋友圈里得知他创业了。我又找到了他。因为我也有一颗不安的心，即使工作三年之后的我已经过上了小康生活。
两点多见着他的时候，他的面庞依旧是那么的棱角分明。此刻的棱角分明，已不是青春小说里俊美男生式的棱角分明，而是经历过风雨雕琢后的分明。略高的颧骨，加上头上冒出的几撮白发，不禁让我想到沙漠中经受风蚀的石头，几分凉意侵入心中。他的穿着很朴素，要不是知道，我万万不会把他和电视里光鲜亮丽的CEO联想在一起。
他把我们带到了大厦后的星巴克咖啡馆里。我要了杯咖啡，他只点了一杯白水。三年，可以发生很多事情在一个人身上，也可以只简简单单的让他老三岁。不知不觉聊了三个小时，听完他创业的故事，我觉得他的白开水比咖啡浓。
后来，到了大厦的十五楼，他们的办公室，地方不大，四五十平米的样子，摆满了办公桌。进门的时候，大家纷纷把目光投向了我，我看到的是一群年轻并且富有朝气的面孔。一一握手后，我给他们讲了一些我工作中学到的知识和总结的经验。他们听的很认真，不少人拿着小本做着笔记。可以感受到他们学习的积极性。
讲完，大家所有人到楼下吃了西少爷，来自西安的快餐，豆花加肉夹馍。吃完饭，七点了，他们又陆陆续续回到了办公室，赶任务。
我又和他聊了许久，他讲到了他遇到的困难，高高的股份，低低的工资，家人对他的不解，商场的黑暗，技术上的困惑，招人留人的烦恼，管理上的摸索，国外国内的落差。但他很坚定，千难万苦，不曾动摇。
这就是我看到的一个创业者，一个可敬的创业者。
你需要的是一个承诺
工作了四年以后，我升职为高级软件工程师。这里的升职不是管理上的提升，其实我现在只需要管好我自己，而是对一个软件工程师成熟度的认可。一个高级工程师，较之一个刚毕业的新手而言，他应该能够独立的推进一个项目，从技术，到和其他组的交流协作，都能够独当一面。我最近遇到的一个难题，就是如何和产品经理有效的协作来保证项目的进度。后来学习到一个秘诀，就是要别人的承诺。
具体的故事，是这样发生的。我和项目经理，一起制定使用者剧本(user story)，会议结束的时候，我们分了工。我的项目经理，要先在这些剧本里，加入验收测试，然后，我再预估它们的复杂度。换句话说，我的任务依赖着他的，他做不完，我就起不了步。
当天下午，大家很高心的散会了。第二天，我问他测试写明白了吗。他说他明天给我，我说好吧。可第三天，依旧没写好。我问他，他又说再等一天。三天过去了，剧本没写好，没测试，我没开工。
后来我的上司看到了，略有不爽，他说，怎么都第四天了，还没有开工。我当时想辩解，说不是我的错，因为我得等别人的活完了才能开始自己的，我是被别人耽误了。后来想辩解也没有意义，特别是这种推卸责任的辩解更没有意义。我的产品经理，当时也意识到自己确实没做好，在第四天，他写了测试。
后来，我找到了老板，高级高级工程师，问他我在这种情况下，应该怎么办？他给我讲了一下他作为新手时犯的错误，也给我说了一个解决办法。
在他是新手的时候，如果他依赖的人太慢，我老板就自己替他人把活做了。这样进度会有，但不是长久之计。首先，替他人把活做了，僭越了不说，到时候万一你做的并不是人家的本意，之后还得重头再来，特别是这种产品经理写验收测试的活，程序员一定要让他们从产品，从用户的角度来写测试，不能以程序员对产品的理解去写。其次，即便替人做的好，可自己的精力毕竟有限，不能作为长久的打算。
所以不可取，那么什么可取呢？回到我的经历中来，第一天，大家高兴散会的时候，不能就那么散了，而要问清楚，你什么时候能给我一个满意的答复，我们需要对方的一个承诺。承诺的远近并不是问题。远了，说明他有优先级更高的事情要做，要么，我不能干等，要么，我们把问题上传给决策者来重新讨论优先级。近了，更好。承诺的重要性在于明确各方的责任点和责任段，是为了更有效的交流，不至于把时间用在等待里。