您现在的位置：首页
--> 奋斗
• 入静和入世
人有两种思考状态，我将一种称为入境，另一种称为入世。 程序员和作家需要的是一种入静的状态。他们需要整段的，不被打扰的时间才可以工作。一个下午三点种的会议，哪怕仅仅持续15分钟，一个下午就会因此废了。问题不是会议占据的时间，关键问题是会议把一个下午分成了两块，让每块都不够大，都不足以入静。因为对于下午废掉的担心，上午的工作也受到影响，不太敢开始解决真正困难的问题。所以整天都在一种心神不宁的状态。 人的大脑远没有我们想象的那么简单。那是非常精密的，需要我们细心体会的工作状态。一个典型的程序员的一天是这样的： 早上想到今天有一整天的整块时间，能够躲在一个不受打扰的地方开始写代码，想想就是件高兴的事情。
• 享受职业素养
我在招聘时常问的一个问题是：在你过去的工作中，遭遇过哪些印象深刻的困难，最后是怎么解决的？依我的经验，简历写得再漂亮的人，如果这个问题答不好，大都可以直接忽略。为什么会有这种结论？因为我们需要招聘的不是“经历丰富”的人，而是“有职业素养的人”。你遇到的问题可能很容易也可能很难，但我看重的并不是问题的难度，而是解决问题的方式、步骤，以及反思的深度。拿恢复误删数据来说，这可能算非常简单的任务，我更感兴趣的是怎样分析问题，找了怎样的资料，采取了怎样的步骤，此后做了哪些措施来避免这种错误再次出现。在我看来，相比问题本身的难度，解决问题的方式和步骤，以及反思的深度，都体现出一个人的职业素养。 是的，上面我两次提到了“职业素养“。
下班回家路上，偶遇一个同事，刚好一起步行回家，路上聊了一些问题，激发了一些思考。回去之后，抓紧时间进行了一些整理。主题比较杂，所以仅当做记录而已。也欢迎读到的朋友一起讨论。一. 频繁的职业变化如何做个人的职业规划与沉淀假设小A在公司短短2年不到，可是已经变化了4个工种，5个老大，这样的事情稀奇吗？至少据我了解，经常发生。频繁的换岗，有可能不是自己的选择，也不是因为能力的问题，而是战略调整，业务重组，业务线合并等等“不可抗力之因素”。员工换工种，本来可以拓展横向的技能和经验，提升综合能力，但是频繁的变化，若不是出于主动，而是被动，却真的会被职业规划，个人能力沉淀形成障碍。
很早之前就想总结一下技术面试中的非技术元素。最近张邵刚很火，网民愤很大，正好借个机会写点东西。 本文一不讨论节目本身；二尽量不评价主持人和参赛者个体；三不上纲上线。我自己面试和被面试的经验都有限，观点难免偏颇狭隘，只希望管中窥豹，抛砖引玉。欢迎补充指正。 目的 面试唯一的目的是衡量求职者是否满足职位要求，尽可能全面的收集相关信息。一切无关活动都应该避免或减少。 例如，评价求职者的表现应该在面试结束后综合各种信息完成，尽量不要当场透露给对方。有经验的面试官会在过程中做动态评估，灵活更换问题或方向，目的是获取更多更可靠的信息。即便如此，当面批评求职者的表现，哪怕只是面露不屑，也是非常糟糕的。求职者一般都很紧张和忐忑，面试官的任何负面评价乃至表情语气都会直接影响他们的表现，降低整个面试甚至接下来其他面试的价值。
年轻是任性的资本。在你面前的路可以有无数条，只要行路的过程能有所积累，不断的尝试会让人生经历丰富，回忆缤纷多彩，或许也会帮助你找到命运花园。这和“产品试错”其实是一个道理，更多试错，更多发现。而渐长的年纪会像KPI一样压垮你试错的勇气。
• 认识自己的未知
不知道自己不知道，知道自己不知道，不知道自己知道。以前很傻、很天真地觉得自己是第二类的。将近一个月的工作后，猛然发现自己是第一类。 不知道自己不知道。譬如说吧，目前主要做iPad应用的设计。你知道iPad吗？iPad，谁不知道啊，那不是乔布斯家的掌上明珠吗，有iPad 1， iPad 2， new iPad。恩，只要对数码有爱好的或者是关注过的人，都能说出一二。那三四呢？其实我并不知道iPad。一来，大学四年都没有把玩过iPad（手头只有一个iPod touch 4代），自然对于iPad的使用习惯和特性等没有直观的把握和体会；二来，移动产品信息的多面性和宽泛性，导致了当时的我没有将注意力过分聚焦iPad的相关信息。自己总觉得看过这么多的科技报道，对于iPad不应该理所当然的了解吗？ 自己实际参与设计的时候，才发现不是这样的。我还不熟悉那个众所周知的iPad。
就像是“怎样追求到女神”的攻略秘籍一样，如果你是一个很有魅力的男子，很容易追求到女神，甚至有可能女神反过来追求你。如果你是屌丝，天天看泡妞真经也没啥用。虽然通过“技巧”来增加求爱成功率也是有可能的，大约增加1-3%的概率吧——说白了还是概率么。1-3%在我眼中跟“没效果”没两样，只是自我逃避罢了。因为提升魅力如此难，所以才想走捷径，我觉得这就是屌丝之所以是屌丝的本源。
• 浅谈领导和领导力
如今，市面上关于“领导”和“领导力”的文章、书籍已经数不胜数，大家似乎并没有厌烦的感觉，新的资料仍然层出不穷；另一方面，对相当一部分人来说，“领导”和“领导力”又确实难以捉摸，看书似乎明白了，做起来却全然不对劲。为什么会出现这种情况呢？据我的观察和思考，主要的原因是：领导和领导力，都是主要与人有关的学问，一旦与人有关，就不能依靠简单的条条框框来行事。下面，我结合自己的经验和思考，谈谈领导和领导力的若干问题。 首先的问题是，为什么要有领导呢？或者说，什么样的人是领导呢？一个人被上级任命为“领导”，他就是领导了吗？不。他如果做得好，才可以成为领导，做不好，不过是“空有个领导的架子”而已；相反，民间的很多“领导”（领袖、领头人物），并不需要任命，大家都认可他。
• 意识流
我自己绝对是一个顽固的意识流的人。以往的各种内部或外部的分享，谈的最多的也是前端开发的各种concept。 2009.12 – D2上我说“库”时代过去了，以后不会再有类似jQuery、Dojo、YUI这种大而全的库了。堆积“库”的开发方式将会演变为按需加载更细粒度的模块（http://www.slideshare.net/kejun/yui2yui3）。框架提供的插件机制会把单一功能的库整合到一起。同年1月Mozilla发起一个叫ServerJS的项目，8月改名为CommonJS。CommonJS定义了一整套Javascript模块(module)、包(package)、promises、io等规范，目的用于服务器端、桌面应用的Javascript开发。
• 庇护所
回想起来，我也是从检察院辞职7年后，才摆脱了“如果失业怎么办”的心理阴影，自信可以靠能力挣得“衣食无忧福利丰厚”。这倒不是说7年后我才有此能耐，只是机关生涯烙下的心理疾患，此刻方才治愈罢了。
• 什么是好的行业？
了解互联网分支行业，可以从关注某个细分领域里的TOP3或TOP5入手，选择你感兴趣的角度去观察。比如拆分了解产品模块设计，从新闻中挖掘分析运营策略，或是技术研究等等。一定要作对比评测笔记——这非常重要，可以帮助你从一团乱麻中梳理思路。
问题1 对于创业公司，尤其是需要外包前端的互联网公司，根据产品的迭代更新过程，产品经理如何提需求是会对前端设计的依赖是最少的。问题2 对于我这样的一个角色，(真心话是今天突然不知道自己算是干什么的，把自己搞糊涂了)，您觉得我在这样的一个位置上我的核心竞争力以及给产品能够创造的最大的价值/不可替代的价值在哪里。我不是计算机或者设计系的纯科班出身，目前在一个3个全职人员，10个非全职销售的互联网创业公司里面负责网站。 产品的流程和大方向是团队里一个co-founder负责，我算是向他不定期汇报，负责流程以及大方向被口头敲定之后的跟产品相关的一切。我们的整个开发团队都是contractors，创业团队重销售与推广胜过产品，这个是我们的business性质决定的。
以下的文章发生在2008年，当时我还未到杭州，也未入职阿里巴巴，UCDChina开始传播，交互设计这个名词还未大面积传播，我当时不是交互设计师，也不是产品经理，也不是在大公司，而是在一家百人规模的软件公司，在一支做在线汉语教学的项目组里。彼时，刚刚从设计岗位转到承担产品策划一职(当时的称呼，或许相当于现在的产品经理？)，某个午后，新有所得，遂总结成文。当时我还未依赖于搜狐博客，而是发布在“忙吧”这个产品上，结果如今，“忙吧”已经不复存在，回顾多年，似乎当时很多创新性的产品都已经湮灭，幸而酷勤网当时不经允许转载本文，也没有被湮灭掉，所以无意中遇到，才又想起当年这篇长文。本人不经常转载文章，但是转载自己老文一篇，也算存档留念吧。
• 降级论
• 乱谈技术线的成长
很多做技术的人都希望能坚持做技术，而不是转管理。但在当前国内的环境下，能提供坚持做技术的氛围的公司却寥寥无几。技术做的好一些后，除了设计技术方案并推动实现以外，不可避免的要开始带团队，开始跟项目或推项目，开始盯需求讨论，开发进度，测试，bug修复等等。最终，我们做的是 Architect + Team Leader + Project Manager 的混合体，而不是我们原来期望的 Researcher 。在这里我们不讨论如何回到 Researcher 的道路上去，只讨论如何提升自己，做一个合格的 Architect + Team Leader + Project Manager 混合体 1. 保持对技术的关注和热情 不管到什么时候，在什么地方，技术是技术人的立身之本。即使这段时间里自己在忙的事情，跟技术一点关系都没有，但我们还是要时刻保持对技术的关注，广度和深度并进，在需要的时候才能给出
应人民邮电出版社图灵公司的邀请，我有幸参与了Bob大叔所著Clean Coder的翻译。 与前作Clean Code不同，这本书着重讲述的是开发人员的“职业素养”，也即职业开发人员应当如何做事。在阅读中，我时常会忍俊不禁，也会拍案叫绝，感叹Bob大叔把深刻的道理讲得这样通透。我虽然没有Bob大叔那样好的文笔，不过对“开发人员的职业素养”这个话题，仍然有很多话想说，索性分几个方面写下来。 学习 开发人员在工作之前，一般都已经经过大学阶段的专业学习。众所周知，大学的很多课程已经相当落后，教材也非常保守，所以我见过的好开发人员，不少都是自学成才。但是，这些问题并不能否认通过专业课程学习知识的意义，职业开发人员理解的“学习”，应当明确地区分知识、课程、教材：知识是重要的、稳定的，课程和教材是不那么重要的、变化的。
如何和“老板”沟通 我们是一线工程师的时候，和我们的直接技术管理者沟通是非常容易的。我们的技术架构、代码风格、系统扩展性、工程化全局考虑就是我们赢得信任和信赖的名片。但是随着我们的经验的日渐丰富、层级的提高，我们要面对更高层级的管理者的时候，沟通不是一件容易的事情，需要我们做更多的准备和精炼。 我们要获取资源，要获取执行方向的认同，我们必须建立和高层级管理者建立信任，给与他们持续并一致的事实称述。 只给事实 人不是机器，不是代码，我们有时候会不自觉的扭曲一些描述或者信息，让我自己看起来更能干或者让别人看起来不是那么好，有的时候甚至会在背后痛斥别人的不足。经过一次次的个人经历和重复犯上面的错误后，我知道了那样做是小人所为而已，古人说“君子之交淡如水”，从另外一个角度来解读，我认为君子间的认同和信赖，就是建立在相互沟通“事实“之上，而不是个人好恶。
再谈沟通的策略 什么叫做策略，我的认识就是做事情的方法，有些时候光有很好的原则，而没有好的方法也是不行的。比如淘宝的”十月围城“事件。 哪些策略是我们在进阶之路上需要注意的呢？第一条，也是我感受最深的一条： 说”Yes“而不是”No“ 我在做一名开发工程师的时候，尤其是处理需求的时候，我是经常被鼓励说”No“的。但是后来我慢慢发现，随着我越来越‘老’，我需要更多的说”Yes“了。因为当我是一个按图索骥进行开发的一线工程师时，我的擅自行动不加考虑的说”Yes“会让整体项目受到拖累，但是当我逐渐介入整体设计、架构设计和可行性分析的时候，我要做的事情更多是作为产品业务或者销售人员的咨询师，所以更多的情况是在深入分析需求后，站在尽可能覆盖需求的角度给出，尽可能合适的方案进行选择。 换句话说，我们的角色要求就是”找到一条可行的道路“。
谈谈沟通能力——沟通的准则 如果一名工程师要成长为资深专家或者是架构师或者是技术管理者，沟通是必不可少的技能和工作的工具。 对于资深专家或者架构师，对沟通能力的要求甚至大于技术管理者，因为他们没有行政权力，但是却往往需要主导、指导、控制跨小组、跨团队乃至跨公司的项目，怎么能够把各个组织里面的人有效的驱动起来，沟通能力非常重要。 但是我们工程师在成长过程中，往往不注意或者没有收到这方面的训练，当他技而优则”升“成为专家的时候，问题就来了，尤其是他作为团队中坚，既要和一线工程师交流又要向老板汇报，真的是压力山大啊！ 沟通方式和技巧往往是因人而异的，但是我们还是可以总结出一些基本准则供大家参考。 先说一下沟通的准则： 先听后说 古罗马哲学家Epictetus曾经说过很有意思的一句话，人之所以要少说多听，是因为我们只有一个嘴巴但有两个耳朵。
最近这本书给了我启示《12 Essential Skill for Software Architects》。那就慢慢写下读书笔记吧。 那么怎样才能做到泥？ 保持关系，而不是一味的纠正别人 工程师由于每天都在和大量的程序、机器打交道，工作的重心之一就是订正各种各样的错误，但是人不是软件更不是机器，一味的去订正别人的错误是非常有害的（而且我们当时认为的“错误”其实更多情况下是我们没有全面审视而得出的结论，随着社会压力、生活节奏加快，这点尤其突出）。在纠正别人之前，先学会问自己两个问题？ 1. 这个“错误”是不是非常重要？ 2. 暂时忽略这个错误会不会给公司或者组织带来重大影响？ 如果答案是“NO！”，那么我们应该停止：打断别人去纠正”错误“的行为。
近3天十大热文
-
[635] Go Reflect 性能 -
[24] 正态分布的前世今生(一)
-
[15] rsync同步的艺术
-
[14] Cuckoo Filter：设计与实现
-
[13] 什么是DNS劫持和DNS污染？
-
[13] Linux Used内存到底哪里去了？
-
[12] 深入浅出选择类排序算法(简单选择排序,堆排序
-
[12] 关于RDS只读实例延迟分析
-
[11] Mac下.apk的反编译
-
[11] jQuery性能优化指南
赞助商广告
