工作日志：高筑墙、广积粮，练好内功最重要
按：
这是在公司内部社区写的。本意是为别人而写，但我想，它也正好记录了我自己的认识。所以，以后若有类似不涉及公司、产品及同事隐私的日志，也会将其记录在我的个人日志里。
Hello Everybody,
我一直在思考两个问题：
对于个人，我们的技术如何更快地成长？同样的技术能力，如何才能工作生活得更有效率？
对于团队，如何才能更有效地沟通、协作？如何形成舒适的工作氛围？如何达到能力互补，具备强大的整体战斗力？每当观察到一个相关的现象，我都会把它记下来，待到下周一时与大家分享。可是，看到大家那么严肃的样子，我又反思自己是不是说得太过份了……。
我想，不如我换一种做法，把它写下来吧。恰巧现在是我们年中总结的时机，那么，就从这次开始。
下面是随机记录的一些事情，没有多大的逻辑关系，也不一定是正确的，只是我一时的想法，和大家共勉。:-)
————————————————————————————
珍惜时间：
并不是说大家不珍惜时间，相反，都很努力。我只是感叹时间真的太宝贵。在学校的时候，我们常说青春、青春易逝，那个时候只是在无病呻吟；如今，像是真的能看见时光在眼前流逝。一晃之间，一个星期就没了，一个月也没了，不小心就到了年底。好在我们还没有七老八十，还有一丝资本可供挣扎，我愿与大家共勉：不徒费了光阴，努力使它过得有点意义。倒不是说，要大家多加班，努力工作自然是好事，工作之外有意义的事情也是好的。譬如，钻研跟工作关系不大的技术，或是提高提高自己人文方面的修养。重要的是，我们是清醒的，并且是高效的！对自己的作品负责：
实话说，这是我对大家不太满意的地方，特别是两位新同事。你们已经转正了，我希望你们在学校或者别的地方养成的敷衍的习惯，能够到此终止。
一件事情交给我们，我们就要对它负全责。首先思考，应该采用什么方法，有多少种可能，它们的优缺点是什么，怎么选择。考虑了，拿不定主意，那只是经验的欠缺；但如果什么都不想，就等着别人来给我们画好条条框框，那就太没有追求了。
特别是，做完的东西，自己要把好关。这个作品，它代表了你的态度品味、技术水平，你自己是否满意？举个明显的例子：代码评论那个，难道开发完了，不会自己试一下的！？要知道，我是真心地相信它完成了，实实在在地在使用，并不是来做边界测试挑刺的，结果第一次用就出了问题。类似这样，我拿到手里随便看一下就发现无数问题的例子太多了……。
我们是一个靠谱的团队，这是得到公司其他部门认可的。我希望，靠谱的人不要做出不靠谱的事来；更希望，这个靠谱，不是经过我加工出来的。每个人，他的作品直接拿出去，都应该是自豪的、经得起推敲的。细节的讲究：
我看到很多重复的、无意义的 commit log，有人可以解释一下你为什么这么懒吗？我看到有文件名是 js.js、css.css，请问，取个有意义的名字真的这么难吗！？不光如此，也包括目录名、类名、方法名，以及很多其它的细节。将各种细节问题揭示给大家，确是我的职责，但我更希望大家自己能有发现这些细节的眼光。学习借鉴、拓展视角：
有时候，我们做的东西在公司内部或者市场上已经有可借鉴的案例。大家不妨多参考一下。当然，并不是说看得越多越好，重要的是我们看的时候要有思考。先要有自己的构思，在构思的过程中，就可能会对产品的概念、特点、设计、实现技术、实现形式等等产生疑问。带着我们的疑问去看案例，才能“内行看门道”，否则只是流于浮表，看了也白看。对于案例中与我们想法不一致的地方，应该思考它为什么这样设计/实现，哪种方式更优。以及案例整体的逻辑结构、用户体验等等，是否合理，是否有改进的余地。
另外，有的产品会在宣传中声称“遵循国际xxx标准，实现国内yyy规范”。我想，应该有这个敏锐，第一步就是去搜这所谓的标准、规范到底是个什么东西（如果还不知道的话），它针对的是什么行业、试图解决什么问题、大概概念是什么、有什么启发、是否适合我们、是否要具体跟进……。这对拓 宽我们的视角是很有帮助的。抽象能力、把握全局：
作为一名程序员，如果搞不懂某项具体的技术，自然是很不爽。但我们也很容易陷入技术的细节当中，以致只见树木不见森林。抽象能力，是我们应该自我训练的重要能力。除了基本的对事物的抽象，还有对复杂系统提纲挈领的理解。了解一个软件产品，我们首先需要了解它对用户意味着什么、具备什么功能；然后，从技术架构上，大体上分为几个部分。有了大的概念之后，再进一步深入技术细节。这样，系统总体上是什么样子、我们当前处于哪一步，在脑海中就有一个清晰的印象。主动反馈：
有的同事，好像从来不曾主动向我反馈过他的工作状态。你现在在做什么？有什么进展？遇到了什么问题？……。我已经在工作流程和其它地方强调过多次了，我的职责要求我知道整个团队现在处于什么状态。告诉我一下工作进展，没那么难吧？你不说，我只好去问了。其实我不想问的，我不想给大家太大压力。下回，当你觉得我老逼问你，很讨厌的时候，请反思一下，你是不是太久没让我知道你的进展了。我觉得 leask 同志有时候做得很好，吃饭的时候简单交流两句，即交流了工作，又有了闲聊的谈资。工作中有数不清的细节，如果靠一个人，一个个去检查，会累死人。希望大家在自己的工作责任范围内，做到主动反馈，给我留点时间做别的事情。积极讨论，踊跃发言：
头脑风暴的时候，就是要随便说，想到什么说什么，大家不用那么严肃。。。平时多思考、多积累，当你有了自认为很好的想法的时候，就会自信很多。有时候就算是不太合适的方法，说不定也能启发别人的思路呢。我的经验，我经常会在讨论中蹦出不错的想法，这些想法并不是讨论之前准备的，而是在讨论中受了别人的启发。不是搞定一项技术，而是解决一个问题：
解决方案，用来满足用户需求的一个方案，说白了，就是解决一个问题的方法。技术，都是试图用来解决具体问题的，当我们面对技术迷雾的时候，不妨问自己一句：我要解决什么问题？这并不一定是纯业务的，技术上也一样。
比如我们前段日子搞 NBGit，其实 NBGit 并非我们的目标，我们真正的需求，是建立一套规范合理、简单好用的 Git 工作流程。有了这个概念以后就知道，我们不能简单地宣布 NBGit 不好用，放弃之，我们必须得寻找到一个好用的方案。NBGit 的作者若遇到问题，需要跟它死磕到底，直至觉得无法解决，放弃项目，终止；寻找 Git 工作流程解决之道的人，只要发现有更好的办法，马上可以放弃 NBGit，放弃之后也并非像前者一样，是任务的终止，他需要确定新的方法。
我知道，搞技术的人，对所谓的业务、解决方案都很头疼，觉得拐弯抹角，不直截了当。这是另外一种看问题的角度，习惯之后，我们就能从另外一个角度看到另外一种风景。也会发现，跟非技术人员交流，变得简单了很多～。不要未加工的资料：
有时候，我需要大家帮忙调查、对比一些技术/工具，可是结果有时有点无语，是原生生地从 Google 抄下来的资料。我自己不会搜么？优秀的做法，是认真去看这些资料，看明白咯，搞懂咯，写出你的理解。它们各自有什么优势、劣势，建议采取哪个方案，为什么，它的优点有多大的意义，缺点应该怎么避免……？理清逻辑，找到问题的根源：
同事之间多讨论是好事情，更好的，是我们在讨论之前先把问题想明白。有时候，我们把同事叫过来，却又说不清楚自己的问题。最好，在讨论之前，先自己跟自己对话，或者假设桌上的笔筒是你的小听众。把问题的逻辑搞清楚，我要做什么？做了什么？怎么做的？遇到了什么问题？有什么可行的方法？怎么选择？……若是问题太多、脑子太乱，就拿出纸笔把它写下来。
我想，我这些字大家很可能轻轻地一看而过。但是如果你没试过，我强烈地建议你试一试。我的感受，这个方法简单却很管用。很多时候自己跟自己一对话，逻辑清楚了，问题就随之解决了；有时候脑子里想不明白的问题，在纸上简单地写一下，结果就很明了。总结 而非 汇报：
总结是为自己而做，沉下心来，安静地思考自己的成长。
有些同事，贴一段代码就算完成任务。代码，版本库里不是有么？重要的，是要解释清楚。假设你面前是一个完全没听过这个概念的人，整理好你的思路、说辞，要尽量让不懂的人看后觉得清晰明了。这样，我们写的东西对团队其他成员才有帮助。更重要的，是在这个过程中，理清楚自己的思路、加深对技术的认识。这对我们的逻辑概括能力、总结表达能力也都是很好的自我训练。把工作安排得井然有序：
有时候，我给大家说的是一些比较大的任务，实际上可以细分成更具体的内容；或者，你自己在开发过程中又想到了很多的问题。光靠大脑是不够的，太多太乱太疲惫、丢这忘那。我建议大家在项目管理系统中记录下来，建一个任务，分派给自己。这样，有多少事情、状态怎么样，一目了然。当然，是记在 issue tracker 里，还是记在本子上，要看个人喜好，但是没有记录肯定是很容易出问题的。我个人，是把所有想到的事情记在 issue tracker 里（大家可以去围观），但把当前最重要的两三件事情记在本子上，摊在面前。提问题、证实自己的想法：
老总说的听说读写几个方面，我觉得都很实在、很有道理。其它几个属于个人素养，需要自己慢慢悟。我觉得听这方面，提问题的方法，尤其有现实意义。我们已经出现过几次这种情况：我说的时候对方表示很好，做完了却发现不是我想要的。当你不太有把握的时候，不妨多问几个问题。是不是我理解的这样？几个问题下来，我们就能达到理解的一致，或者发现存在的误差。注重积累，Wiki 是不断改进的：
我们的 Wiki 现在已经有了不少内容，但请不要觉得 Wiki 写完了就完成任务了，若是发现有可改进之处请毫不犹豫地更新！特别是在我们工作的过程中，重复处理 or 重复回答的问题，记在 Wiki 里沉淀下来也许是个不错的方法～。愉快的心情、健康的身体：
我是个爱运动的人，可是安排得不太好，实际上运动很少，肩膀和腰都经常不舒服。大家好像比我更少运动，时间久了也会不舒服的。我有时候去游泳，完了之后觉得浑身通畅，像是小说里说的打通了任督二脉。建议大家，根据自己的爱好，做个规律的运动计划。共勉！:-)记录的主要的内容终于写完了……，个别具体的事项再当面讨论。
stay hungry, stay foolish!
————————————————————————————
既然说是年中总结，我也总结一下自己半年来的主要工作。
团队建设：
从人员的招聘到相互的了解，团队的风格，以及思考各个成员及团队整体的能力塑造。我的指导原则，是要以个人鲜明的影响力保证团队在一条正确的道路上快速前进；同时做到中庸与无为，即，在具体的工作中淡化个人的作用，给团队其他成员发挥能力的空间。工作机制与工作流程：
我们工作的各个环节，基本上都形成了适当的机制。除了开发，其它像招聘时的面试、笔试、评价这样的行政工作，我也都总结出了通行合理的做法。使得第一遍做过的事，以后在此成果与经验基础之上，用少得多的时间即可完成。努力的目标，就是使我们的工作流程，在“最优的机制+最优的工具“的帮助之下，达到“优雅、高效、智能、惬意“。需求理解与技术设计：
这指我们已有的三个产品。广泛涉猎：
作为职责，我可以不进行具体的开发，但如果我对产品与相关技术没有整体的把握，则是失职。涉猎的内容，有的是与产品技术直接相关的，有的则是更底层的基础技术，或是大一点的概念如企业IT建设的方方面面，都是我关注的内容。技术之外，像需求、规范、设计等等也是涉猎的内容。视角的广度与深度，决定了决策的优劣。作为个人目标，我希望自己能做到：一手拿RFC、一手拿国家发展计划纲要；脑袋里构思出一套解决方案，一半想的是纲要里的战略需要、一半想的是RFC 里的技术实现。。。总的来说，这半年来，虽然细节上做得还不尽完美，但实质上没有遇到大的挑战。所需的种种能力，都是自己多年来努力培养的目标。
————————————————————————————
我对自己不满意的地方，是整体的工作效率不够高，自己寻找原因：
客观原因：
如身体、距离、设备等，不细述。并发而琐碎的工作事项：
相对来说，以前主要还是搞技术，具体的技术，一沉进去就是数个小时。现在，更多的是一些小块的工作事项。频繁地在任务之间切换，一会是技术问题、一会是业务问题，以及一会思考团队、一会执行行政任务，适应起来还是有点问题，有时候把自己搞晕了，不知道在做什么。偏重逻辑的思维方式：
有时候需要参考一些文章，类似企业IT战略、产品的介绍资料之类的。这样的文章往往写得十分的概念化，几年前初看这种文章时，我会感到非常气愤，觉得全是废话，直接说用到了什么技术、什么标准、什么工具不就得了吗？！现在好多了，能够平心静气地看下去，试图从中挖掘出一些有价值的观点、策略或技术。但有时候还是会头大。行政工作：
行政工作耗费了我比想象中多很多的时间。除了必要或者不必要的往复交涉，以 Word 为核心的工作流也是一个原因。大部分同事交上来的资料，或者管理部发过来的模板，格式都不够好，而我又不希望从我手里出去的东西有太大的瑕疵。我以前不太用 MS Word 的，因为以上原因，不得不在页眉、行距、表格属性……以及各种疑难杂症上耗费了不少时间。希望我们的工作流产品完成之后，能先在自己公司成功部署。Web 化是我的目标，它不仅仅简化了表面的格式设置，也为数据的收集、搜索、统计等再利用提供了方便。————————————————————————————
完了。感谢阅读（滚动到最后…）！
![Email & GTalk: lovelywcm[ at no_spam ]gmail.com](http://wangcongming.info/wp-content/uploads/mail.png "Feel free to send me a mail, or GTalk with me :)")
