新翼博客 记录学习点滴

让一个研究生男收集一份资料，快下班了问结果，竟然毛也没有。见我要怒，他慷慨激昂地说：”我已经很努力找了，但真的查不到。”

作为主管，“我已经努力”这话我不知听过多少次，每次都要面对一张无比诚恳的脸。但我要说：你的“努力”一文不值！

【一】

工作以后还把“努力”当免死金牌的人，都是混入职场的“学生党”。当年他们考试没考好的时候，因为已经头悬梁锥刺股地努力了，所以父母心疼，老师同情，摸摸他们的小脑袋说“没关系，下次继续努力嘛”。而到了职场上，你最好不要再嗑这些从学校带出来的药丸。如果你还是没有脱瘾，那建议你问自己三个问题：

1）你可以不“努力”吗？

当然不行。

因为“努力”这两个字，本就应该是每个人站在职场起跑线时的觉悟。这是最基本的角色设定。一个整天把“我已经努力”挂在嘴边的人，就像警察喊着“我要见义勇为”、医生嚷着“我要救死扶伤”，不是很可笑的事吗？

2）你的工资是按“努力”来计算的吗？

当然不是。

绩效的构成，无非是任务完成的数量和质量，也就是你做了多少和你做得多好，与你流了多少臭汗没有半点关系。“努力”了一天却没有像样的结果，那你今天对公司的贡献就是零。如果一家公司全是像你这样“努力”的人，你说前景会是如何？

“工作是否完成”是基数，“你有多么努力”是系数。残酷的事实是，当基数为零时，系数再大也没有任何实际价值。试想，如果成龙没有那些好作品，他一身的伤还有意义吗？如果爱迪生没有找到钨丝，那他之前的上千次失败，还有谁会去在意？

3）甲乙两个人，甲每天加班到半夜十二点，连老婆生孩子都是请假一小时去瞄一眼然后回来继续玩命干活，但任务还是完不成；乙每天上班喝咖啡看杂志，准时下班零延误，但交代的任务却完成得妥妥的。请问，你更欣赏哪一个？

当然是乙！

不用“努力”就把工作做好的人，才是精英。如果你“努力”了还是做不好，那你干脆辞职吧——既然你完全燃烧了小宇宙都还是不行，那你实在不能胜任这份工作。所以按照这个逻辑，如果你还想干下去，那越是工作没做好，就越不能声称自己“努力”了，反而要说“我还不够努力”，才能隐藏自己能力的天花板，让别人对你还抱有希望。

【二】

“努力”这样的褒义词，最好留给别人去评价，而不是自已来标榜。就像别人说“你好帅”，那才是真的帅；自己说“我好帅”，那是真的不要脸。

可为什么很多人还是忍不住要说呢？一是看得见的成绩拿不出来，所只好拿无形的“努力”来充数；二是知道自己的“努力”肉眼无法识别，不喊出来就被当空气——其实不过是“此地无银三百两”。

“我已经努力”这话，无非是掩饰自己叫苦、认怂的熊样：“我已经累到不行了，这活儿还是别找我了吧。”这样的情况出现三次，基本就耗光主管对你的信任。

有的人嘴上说“我已经努力”，但身体却很老实，坐得慵慵懒懒，戴着耳机，吃着水果……心理学家说，肢体动作占印象分的55%。所以，如果主管看不见你努力的身姿，又怎么相信你努力了呢？

如果是一个团队项目，上级问责的时候，抢先说“我已经努力”的人，注定要遭众怒——“就你一个人努力了，我们都是懒羊羊是不？！”而你看那些明星，每天收工后都要对片场里的所有人说“你辛苦了”——因为肯定别人的努力，才能得到更多的支持。

越是把“我已经努力”挂在嘴边的人，其实越难成功。因为成功者懂得保持优雅，而隐藏努力的狼狈。就像天鹅在水上轻松优雅地游着，但其实它们的脚在不停运动，只是藏在别人看不到的水下。

【三】

如何体现“努力”的价值？一是取得实质的成绩，二是要增加“努力”的可见度。尤其是碰上不可能完成的任务，再怎么努力也不可能有好的结果，这时更要让主管能看到你的“努力”。L是我带过最得力的手下，同样是搜集资料这样简单的工作，这个充满灵气的姑娘，第一次就给我很大惊喜。她是这样做的：

1）列出已搜索的关键词组合，附上关联性最强的结果。

以往我和研究生男的对话往往这样：

“各种关键词都试了吗？”

“都试了。”

“这个试了吗？”

“……没有。”

“那个呢？”

“……没有。”

于是，我的脸色越来越难看，语气越来越严厉。

L的做法避免了这样绝望的对话。我一眼就能看出她已做了各种努力的尝试，而且一目了然地就能发现她存在的问题，做出明确的指导。其实L和研究生男存在同样的盲区，但我面对她时，语气是正向的，态度是和蔼的。为什么会有这样的不同？因为她把自己的工作过程记录下来，让我看到她努力的轨迹；而研究生男的“努力”口说无凭，叫我如何信他？

2）把搜集的资料汇编成精炼的提要。

这是在我指令之外的主动升级，所以让我格外欣赏。按要求完成工作，只是六十分的努力；超乎要求地完成工作，才能获得超乎期待的评价。就像你为老公切水果，那叫做家务；但如果你懂得把切好的水果摆成心形，那就叫创造生活的惊喜，应该得到一个吻。

研究生男偶尔也会找到一堆资料，意气风发地把几万字发我邮箱，让我看到吐血（吐血的主管，只能对你狠狠吐槽）。而L的做法好处有二：一是表明这几万字资料她全部看过，因为编出的提要就是她努力的证明；二是节约了我的时间——你花一天搜集的资料，难道还要主管再花一天看一遍？下属最重要的职责，就是要为主管减负，郁郁不得志的诸位不妨自我考评。

3）积极请求他人援手。

有个教育经典故事是这样说的：父亲让孩子移走花园里的石头，孩子想了各种办法，石头纹丝不动。父亲问：你用尽全力了吗？孩子说是。父亲说：不，你还没有尽全力，因为我就在你旁边，你却没向我求助。

很多人把“努力”与“埋头苦干”简单划上等号，其实，努力求助他人，也是一种努力。有时你抓耳挠腮也解决不了的问题，坐在你隔壁的人早知道答案，你要做的就是带上谦虚的微笑和动听的话语，请这位高人指点迷津。L就请公司编译部的同事，帮忙查找了国外的资料，这样善于协作的下属，实在是每个主管所乐见的。她还及时求教了我——主管往往掌握了完成指令的究极钥匙，只要你的问题有足够的含金量，没有理由得不到指点。所以看着研究生男那憋屈的脸，我很想说：“你还没有努力，因为我就在你旁边，你却没向我求助。”

【四】

台北著名的欣叶餐厅，早年有一招传遍业界：老板明知座无虚席，还要叫自己儿子在候位的客人面前，反复去看有无空位。他儿子看似白跑了整个晚上，其实客人感受到了这家店待客的热忱和满满的努力。

“努力”是越说越不值钱的东西，只有做出来才能变现。努力是一种精神，但要让你的努力有价值，既需要智商，更需要情商。

（来源）

仿佛就在一夜之间，朴树又重新回归人们的视线，社交媒体上疯传的电影主题曲《平凡之路》，似乎宣告着记忆中的那个不羁青年又回来了，但这个青年如今已逾不惑之年，青春不在，只留下那熟悉的旋律响彻耳旁。也许是一个巧合，就在人们热议着朴树的新作之时，他的昔日伴侣周迅也传出婚讯，可能也算是另一种支持吧。

记得刚开始接触朴树还是他的那首成名作《白桦林》，要说到真正开始喜欢这个歌手还是在他第二张专辑（也是到目前为止他的最后一张专辑）发布之后，而这张卡带也被珍藏到了现在。成名之后的朴树也未像一般的歌手那样活动频繁，演出不断，一段时间之后，竟逐渐淡出人们的视野，之后听闻的也就是他和张悬以《树与花》为名的巡演。再这一等就是十年之后的这首新作，歌曲还是延续了朴树的一贯风格，但歌曲的内在含义远比歌曲本身重要的多，这首歌更像是朴树十年的心得体会，平凡之路才是生活的最真实写照。

关于朴树有太多不同的看法，他似乎也从不属于主流的歌手，跟多的是被贴上文艺青年的标签，南方周末上的一篇歌手朴树成长史对他的生平做了一个比较详尽的介绍，生活中的他从来都是活在自己的世界中，唱着属于自己的歌，我想这也是为什么有那么多人喜欢他的原因吧。

《平凡之路》的火爆一点都不出人意料，朴树和韩寒风格气质有些过分的相近，两人的合作似乎再合适不过了，加上《后会无期》在媒体上不断地造势宣传，再加之歌曲本身的品质和其传递的深意，可以说这首歌想不火都难。但这首歌是不是预示着朴树要重回主流视野之中，我想未必，最主要的原因还是朴树本身的气质和他的性格，他注定不是媒体的宠儿，他注定是在自己的世界里唱歌的那个人。

十年恍若隔世，但朴树似乎还是那个朴树，那个不受世俗约束的少年，人虽老去，歌声不老，感谢他的那些动人旋律和充满情感的内心，就像《生如夏花》歌词中写到的那样：

• 我从远方赶来恰巧你们也在

• 痴迷流连人间我为她而狂野

• 我是这耀眼的瞬间

• 是划过天边的刹那火焰

• 我为你来看我不顾一切

• 我将熄灭永不能再回来

• 我在这里啊

• 就在这里啊

• 惊鸿一般短暂

• 像夏花一样绚烂

作者是Rails/Angular开发者，企业家& YC alum。早先创建了Clickpass.com网站并出售。目前担任Brojure.com的OTO（唯一O（only）TO），兼职entrepreneur first。

如果有一件事是开发者都关心的，那就是成为更优秀的开发者。那你应该从哪里开始呢？你是否应该积累一些附加的卖点：比如专研Node知识和no-sequel？或者你应该死记硬背专业的网关问题答案，并能按要求立即写出冒泡排序算法和短连接算法吗？或者有其他更基本和关键的东西更值得你投入?

我相信，作为一个程序员的资历和价值并不是以你所知道的东西来衡量的，而是通过你做出多少成就来衡量的。这两者是相关的，但又有本质的不同。你的价值是你如何推动项目前进，如何鼓励你的团队也这样做。在我十五年的开发生涯中，我从来没有需要实现一个冒泡排序算法和短链算法。不过，我花费了成千小时来编写和重构账户管理工具，编辑套件，缓存逻辑，邮件接口，测试套件，部署脚本，JavaScript分层，分析架构和文档。这些都是有价值的事情，完成了这些事情推动了我们的前进。

那些微小的组件是构建项目的砖瓦和沙砾，需要成百上千小时的辛劳工作来组建。尽管它们被用来组装复杂系统，它们本身却不应该是复杂的。你应该将简化这些组件作为目标。多年来，我学会简单可以通过假以时日的不断工作和重构来达到，而这比纯粹“灵感一闪”的思考更容易得多。

简单和卓越通过一些事情或者任何可以让工作完成并从回头重新审视这样的过程来不断完善，这是最可靠的路径。这也是那些公司和MVP试图深入我们意识观念的真谛，软件也是如此。从一些可工作但丑陋的解决方案开始，你不断应用这个丑陋和怪异的方案，不断重构它为最简单的形式。简单从工作中比“灵光一闪”来得更为可靠。通过写代码比费力思索更加可预期。简单来自努力。

衡量一个开发人员的价值，不是通过你能达到的某个点的高度值，而是在于你表现线下的面积值。— Peter Nixey (@peternixey) April 22, 2014

对于聪明的懒人来说，他们可以轻易展现自己的卓越才华，亮瞎同龄人的双眼，然而公司却不能建立在这些人之上，产品也无法落实在那些“卓越的才华”上。公司是由那些每天进出办公室，提交良好的代码，并且也让其他人也干同样的事情的团队和个人。伟大的产品由勤奋的驭马驱动，而不是由那些盛装的舞步马推动的。

多年之前，Joel创造了“明星程序员”这个词多，它依赖公司对需要这样缺乏合作的极客来完成所有事情的误解。的确存在拥有这样特质的人，但是人数不多。你发现他们的聪明缺乏规律——让他们感兴趣的事情表现得惊人的聪明，然而在和其他人协作或与团队无缝合作时，又显得无法抱有期望。

他们的成果是无法预期的，但是他们的成就又让人艳羡，而且更具传染性。他们的傲慢可能伤及到团队的其他人员。它大声而且响亮地释放这样的信号：如果你够聪明，你可以选择你何时工作和你干什么。你成为了一个“Developer in Residence”。你不但吸取了薪水，也扭曲了你周围工作人员的价值。

所以现实是，你和你的团队更可能依靠或者说应该依靠于那些值得依靠并可靠工作的人，而不是那些自认为是“明星程序员”或者“编程忍者”的人。

卓越的开发者不是那些上手就可以写出冒泡排序或者短链接算法的人。他们是你一旦将其安排在项目中工作，就会不停推动和鼓舞周围每一个人来做到一样的人。让明星程序员滚蛋，雇佣那些可以驾驭的驭马（Fuck Rockstars. Hire workhorses），下面一些方法值得借鉴：

为你的函数和变量取个好名字（编写见名知意的代码）

这是一个难以置信的简单开始，但是我认为它是编程中最重要的技巧之一。函数命名是问题定义直接表现，坦白的说，是编程最难的部分。（编注：ITWorld 在2013年发起的一个投票，结果显示：《程序员最头疼的事：命名》）

名字是你代码的的边界条件，命名是你应该解决的首要问题。

如果你的命名是正确的，也解决了边界条件，使用这样的名称，你几乎不可避免编写出了高功能的代码。

考虑这样的函数：

def process_text string
…
end

它几乎没有透露它准备做什么或者是怎么实现的，但是：

def safe_convert_to_html string
...
end

它告知了接下来会发生什么，通过这个函数你可以预期它会完成什么，并且你可以多大程度重载这个函数。

开发者可能会很高兴重构一个“process_text”函数，同时将字符串转换为HTML标签并自动嵌入视频。不过，这在一些使用这些函数地方时可能是完全不期望的。一旦你改动了它，你就制造了bug。一个清晰的名称，不但保住函数会做什么，也表明了它不会做什么。

函数名称为函数和调用它们的代码之间创建了契约关系。好的命名定义了好的架构。— Peter Nixey (@peternixey) April 22, 2014

一个好的函数，承诺了它会交付什么并如期望地交付了。好的函数和变量名称，不但使得代码更加清晰易读，也为你纵横交错的代码库建立了成千上万的约束。草率的命名意味着草率的约束，缺陷，甚至建立在它们之上更加草率的契约。

不仅仅是函数命名可以衡量你的代码质量，变量命名也应该加强。有时为了简化，值得创建一个变量名来自注释代码逻辑。

以下面的内容为例：

if (u2.made < 10.minutes.ago) 
&& !u2.tkn 
&& (u2.made == u2.l_edit)
...

糟糕的变量名称使得你很难弄清楚到底正在发生，甚至哪怕你这样做了（成功了），你也难以保证100%清楚原作者意图是做什么。它什么也没告诉你。

“and not”声明经常让人困惑（请永远不要编写“and not”与名称结尾的代码），如果你的工作是重构这样的代码，你不得不做一些复杂的猜测来推断它原始的含义。

不过：

if (new_user.created_at < 10.minutes.ago) 
&& !new_user.invitation_token 
&& (new_user.created_at == new_user.updated_at)

我们将这些变量修改为一些更有意义的名字，代码的含义立马就变得更清晰了：

user_is_recently_created = user.created_at < 10.minutes.ago
invitation_is_unsent = !user.invitation_token
user_has_not_yet_edited_profile = (user.created_at == user.updated_at)
 
if user_is_recently_created 
&& invitation_is_unsent 
&& user_has_not_yet_edited_profile
...

我们还可以进一步要求对 if 语句声明中的每一部分进行分离，命名组件并做文档注释。

需要一些勇气来写像“user_is_recently_created”的变量名，因为这样的命名逻辑模糊。不过我们时不时这样做了，并且承认这告知了代码阅读者你做了什么假设。

注意，这些方法比使用注释要更加有效。一旦你改变了代码逻辑就会要求你改变变量的命名，而使用注释却无法强制这一点。我很认同DHH，注释是危险的并且容易腐朽——最好是编写自注释的代码。

代码自注释越充分，其他人就更可能按照其初始的意图来实现它，代码也会有更好的质量。记住，在计算机科学中只有两类问题最难：缓存失效、命名和off-by-one错误。（我怀疑作者是写错了，这是三个…）。

如果你想成为一个伟大的开发者，请确保你写的代码让人见名知意：也就是说代码精确地完成了它名字告诉的东西— Peter Nixey (@peternixey) April 22, 2014

在学习广泛之前先精深某一方面——从里到外学习你选择的技术栈。

只有非常少的编程问题是真正新的。很多公司所做的技术工作，是之前的许多团队已做过的。在Stack Overflow上吸引眼球的问题很少没有在其他地方遇到过。

因为这个确切的原因，你正在努力做的大部分事情，已经被你当前使用的技术栈解决过了。我有一次使用了Rails自带的简单而强大的方法，将其他人写的60多行Rails代码重构为一行语句。

大多数程序浪费了大量的时间，用于重新实现那些现有的功能。— Peter Nixey (@peternixey) April 22, 2014

这不仅浪费了他们的时间，而且他们新构建的代码冗长且含有很多错误。新的代码需要新的文档注释，新的测试来检查，也让代码充满噪杂，并且难以阅读。和其他新代码一样，也容易产生bug。使用技术栈经过严谨测试并且实际验证的代码，很少产生bug。

如果你是一个Ruby的开发者，请花时间好好学习Ruby，尤其是数组的那些惊人多的方法。如果你是Node的开发者，请花时间了解它的架构、方法及理念体系。如果你是一名Angular的开发者，你应该敢于挑战，并理解正由核心团队锤炼的那不可思议的架构背后的逻辑。在你重新发明之前先询问。你行走在巨人的阴影下，花费一些时间找到他们的踪迹，然后你会对他们已经建立的东西感到惊叹。因为，如果你不这样做，你只是把问题推给了后面的人，别人会指出为什么你偏偏选择了你自己的小路走。

学会辨识糟糕的代码

有时候，我注意到一些程序员挺不错的，只不过他们趋于安逸，并没有意识到他们的代码其实可以写得更好。这对于你个人的发展是一件极为糟糕的事情，在你知道如何改进之前，先要知道什么是需要改进的。知道好的代码应该是怎么样的，坏的代码长得怎么样。据说，象棋大师比普通棋手花费多得多的时间，来学习其他优秀棋手的如何下棋。我非常确信这对于开发者来说也是对的。

能觉察到代码异味，是提升你能力的重要的武器之一——哪怕只是有一点点异味或者闻起来可能有点异味。异味代码，你可能不知道为什么，仅仅是觉得哪里不对的代码。

你可能做某件事情用了60行代码感觉这很简单，这也可能让你觉得应该交由语言本身来处理却被程序员手动处理了的感觉，也可能是你觉得这段代码糟糕透顶且难以阅读。这就是代码异味。

这不是件容易的事情，但是经过一些年，你会发现哪些代码存在异味，漂亮的代码应该是怎么样的。你会开发出对代码的审美观，对于丑陋事物所带有的丑陋理论会让你感觉很不舒服。简单即是美，而简单正是我们所需要的。

真理是，真实有时候是丑陋的，但是你应该不断地追求美丽，并且当你感觉丑陋无法避免，你知道如何优雅地展示它。如果你不能编写出优雅的代码，最少创建一个史莱克式的代码，而在这之前，你需要培养出对代码异味的感觉能力。如果你不知道好的代码是怎么样的，坏的代码看起来是怎么样的，那你怎么会想到去改进它呢。

编写可读性良好的代码

我有一次听Joel Spolsky说，Stack Exchange不是针对提出问题的人进行优化，而是对阅读答案的人进行优化。为什么呢？因为相较于提出问题的个人，有多得多的人会去查看答案——应用最大化原则应该对读者进行优化，而不是提问的人。

我觉得你可以同样的方式对待代码。它可能只是由你一个人写一次。但是它可能被其他许多人阅读和编辑。你的代码具有两个功能：其一是满足你当前的工作，其二是面对在你之后的每一个人，因此代码应该始终对可读性和可理解性进行优化。

“代码编写一年后，从原作者眼光来说，也是全新的代码” — Peter Nixey

你代码里面假定什么？你的方法实际返回什么？这个四层嵌套的 if/else if and not/unless 声明究竟是在区分什么？

有时候你需要的不仅是好的变量名，你也要围绕着代码进行测试，看它究竟需要什么，并使得代码经久耐用。有效的代码是可以工作的代码，并且始终工作，即使被公司里每一个人都改过，都还能如常运行。

写的每一行代码，其读者会是那些对此不感兴趣的，或者时间紧迫的团队成员，他们可能要在接下来一年时间扩展这些代码。请记住，那个不感兴趣，或时间紧迫的人，或许就是你自己。

根据代码的生命周期来评估特性价值，而不是它的实现成本。

新的开发者总是喜欢探索和发挥。他们喜欢最新最炫的东西。无论是Nosql数据库，还是高并发的移动服务，他们想尽快了解和掌握所有这些东西，用完这些玩具，就撇下一堆垃圾给下一个开发人员来擦屁股。

狗不是为圣诞节准备的，特性也不是为下一个发布版本准备的。— Peter Nixey (@peternixey) April 22, 2014

功能和架构的选择，会影响所有你在这之上构建的东西。一旦抽象泄露，你在抽象中陷得越深，就有越多的东西会被玷污，或者这个泄露导致很多东西都“中毒”。

实验性的架构和某些很炫的特性应该极为谨慎采用。优先添加你需要的功能，而不是你想要的功能。同时请注重架构。把一些实验玩具留给边缘项目。你创建的每一个组件，每一个前沿模块合并到你的项目，会快速地改变你的软件，也会让你的项目受伤或直接破坏项目。如果你不希望在项目后期除了止血而干不了其他事情，请不要首先将上述应用到你的项目中。

了解和评估技术债务

技术债务是你写的代码但没有达到最优化或你想要的。它包含一些错误，虽然烦人，不过还是可以用的。它可能是一个单应用程序，不过你知道它可能发展为面向服务的程序，也可能是一个20分钟的计划任务需要被重构为20秒。

这些成本不仅仅是累加的，而且是复合累加。爱因斯坦曾经说过：宇宙中没有什么比复利更强大的力量了。同样，在大型软件开发中，也没有什么比复合技术债务更具破坏性的了。我们见过或构建的大部分项目，哪怕最小的改变也会花费数月的时间。针对码基（code base），人们已经放弃了编写更好代码的想法，只是希望在修改的时候不至于导致站点整个崩溃。

技术债务是项目中一个可怕的负担。

除非没有技术债务。

和所有其他债务一样，应用合理的话，技术债务也会给你带来巨大的杠杆效应。— Peter Nixey (@peternixey) April 22, 2014

不仅是这样，技术债务可能是世界上最好的债务，因为你不一定每次都需要偿还。当你开发一个功能结果发现它是错误的，或者当你开发一个产品结果不能正常工作，你可以丢弃掉它们然后继续。你可能丢弃功能相关的所有优化，测试和重构。因为这些不是必须的，那就不要去写这些。这个时候就应该最大化你的杠杆，留个空白，避免错误，仅仅为你需要的测试而进行测试。

在一个产品和功能的早期，很可能你现在做的是错误的。你还处在探索阶段。你要同时以产品和技术实现为核心。这期间可以大量借用技术债务。这不是修改零星错误和进行大量重构的时候，这时候你应该集中火力猛攻直到你达到（成果的）另一边。

不过当你发现，你确信你已经到了正确的位置并走出了另外一边，这个时候需要进行梳理，并加强你的地位。把事情做得足够好来推动你前进，偿还足够的技术债务来进入下一个阶段。

对于初创公司来说，技术债务和其他许多事情一样是一场跨越式的游戏。初始的代码是试探性的代码，它应该让你快速前进，发现问题和解决方案，给你恰当的空间来建立营地。你呆的时间越久，营地系统就需要更多内容，而你需要构建更大更强来支撑 它。如果你仅仅只需要停留一周时间，不要浪费时间来构建一个可以支持十年的基础设施。

检查，再检查你的代码，你的问题由你来修复。

“把代码扔过篱笆”的工程师都是可怕的工程师。你应该保证你的代码是可以工作的，这不是测试人员或者你同事的工作，这是你的工作。懒洋洋写就的代码会拖延你，延迟周期时间，产生bug，有让每个人恼火。

如果你一直提交破坏性的代码，那么你就在对团队其他成员不断征税。— Peter Nixey (@peternixey) April 22, 2014

不要拿自己不当回事，觉得你只是个负担，问题应该自己解决。

每天至少（只）花4个小时做实际工作

对于讨论自我进步，关注和使用在开发者之间流行的生活技巧，简单的真理是：你不需要做大量的工作，就可以实现高效。真正重要的是，你能持续地做到这一点。每天花费最少完整4个小时来做恰当（proper）的事情，日复一日，你会成为团队中最有贡献力的成员。

不过，每天都抽出4个小时来工作比看起来要难得多。

恰当的工作意味着没有邮件，没有新闻，没有会议，没有杂七杂八的琐事。意味着一小时最少45分种的时间专注于（你正在做的事情）。一天4小时的工作意味着一天没有会议，没有漫长的午餐和休息时间讨论足球。我相信，一天扎实工作八小时几乎是不可能的。每天四小时也意味着你应该瞄准工作五或者六个小时，这样你才可能得到四小时的认真工作时间。

这也意味着你可以拥有丰满人生的同时，成为团队中一个卓有成效的贡献者。这意味着你不需要在HN上发表一个自我放弃“我忙死了，快来帮帮我”的帖子，这意味着你只要持续工作，你就能被重视和获得尊重。

软件团队并不因为人们每天工作四小时而比工作七小时的团队进展慢（持续这样的方式是非常疯狂的）。他们慢下来是因为人们几周都没有找到方向，或者那些响亮而空乏的嗓子，决定花费时间讨论 google vs facebook 的获取策略而导致的无止境的咖啡休息时间。

只要能工作就好，不要在乎你的进步看起来是如何缓慢或平庸…

每天工作四个小时，日复一日你会成为团队中最优秀的人员之一。— Peter Nixey (@peternixey) April 22, 2014

记录已完成的事情，并和团队成员分享

不管你是如何记录文档，是通过类似Copyin的邮件列表，wiki 或者是代码中的内嵌注释，你应该花时间来解释你的架构方法，和团队其他成员一起学习。

在安装Postgres或者ImageMagic时遇到了问题？如果你觉得这解决起来比较困难，团队的其他成员可能也会遇到这样的困难，花费一些时间记录下来并告诉团队其他人你是如何做到的，节约他们下一次遇到问题时的时间。

程序开发时最糟糕的事情是，整天和bug作战或者处理安装问题。如果你花费时间来记录和分享你找到的方法，你可以从预先为你同事准备中赢得五倍你花费的这些时间。

理解和欣赏处理太多测试和太少测试之间的微妙平衡

测试是一个强大的工具。它允许你设置一个发布基准，你可以信赖你的发布，让你不那么害怕制造它们。对发布的恐惧越少，你越这样做你改进得就越快。

不过，这也可能过头。测试需要时间编写，运行和更多的时间来维护。

可以想象测试是盔甲，你穿得越多你受伤的可能性就越小，不过也让你更难进攻。— Peter Nixey (@peternixey) April 22, 2014

你负重太多而无法前进，阻碍你弯曲四肢，无法移动。太少的话，第一次跨过混凝土地板的滑动就会伤到你，让你流血。

关于如何进行适量的测试，没有直观的答案，某些项目需要比其他项目更多的测试，测试是你专业化需要学习的一个全新的领域。

花时间去理解什么是真正需要测试，如何编写一个良好的测试。花时间去查看当测试添加值，或者最起码你期望它们是怎么样的。不要害怕进行测试，也不要害怕不进行测试。正确的处理方式是平衡，花时间去探索平衡点在哪里。

让你的团队更出色

这不同于其他点，这不是你可以独自采取行动，也没有明确的指标告知你其他行动是否有效。

你的存在，是让你的团队变得更好还是更糟呢？你的代码质量，你的文档和你的技术有米有帮助到你周围的人。你是否激励和鼓励你的队友成为一个更优秀的开发者？或者你就是那个导致bug的人，或者你坚持自己的观点浪费数小时讨论架构无关的废话，因为它有助于掩饰你没有做实际工作的事实？

你应该让你的团队变得更好，总是有一两种方法你可以让你的团队变得更好，通过你素养的熏陶而帮助其他人变得更强。然而，成为一个孤独的“智者”可能是最缺乏价值的，或者说你能选择的最有破坏价值。事实上，如果你选择的维度并没有让你觉得厌烦，这可能不是一个好的选择。

It’s not who you are on the inside that defines you

这是一个谦卑的智慧，在蝙蝠侠开篇就有这么一句，这句也一直伴随着我。在电影的某个时间，蝙蝠侠在闲逛，表演着一个亿万富翁的花花公子。克里斯蒂安·贝尔恳求凯蒂·赫尔姆斯相信：他内在仍然是一个好人，她只是说了：不是你穿了什么，而是你做了什么展现你的价值。

你作为一个开发者的贡献，不是由你有多聪明或你知道多少来衡量的。这不是由你简历上的技术名称缩写，你工作的公司和你上过的大学决定的。它们暗示你能做什么，但是你的价值是由你做过什么，以及这些如何改变了项目和你周围的人决定的。

如果你想变得更好，请做好准备。

（via：伯乐在线）

诸如Apple、Facebook及Google这样的大公司正在开发他们自己的编程语言，开发者们被迫只有适应。

前不久的世界开发者大会上，Apple公布了它的新开发语言Swift。这是最近大型技术公司们开发的一大波新语言中的最新成员，这些新语言某种程度上都是专门应用于他们自己的平台。

对iOS开发者，Apple有Swift；而Facebook 有 Hack —— 一门用于后端开发的语言。与此同时，Google已经拥有了它自己的Javascript替代者 Dart，以及一门新的通用编程语言Go。

这一波又一波的新语言，给开发者们带来了许多问题。也许其中最严重的问题正如我一位同事Adriana Lee在Apple发布Swift后所说：

（开发者们到底还得学习多少门语言？） ——Adriana Lee (@adra_la) June 2, 2014

计算机语言的通天塔

目前已经存在的编程语言有数百种，同时还有更多的语言正在涌现。其中许多都是被设计用在相对较窄的应用程序范围内，大多数甚至从未走出过项目小组的范围。

与此类似，大技术公司开发的新语言其实也是伴随着公司一起成长的。通用语言的鼻祖，C语言，就源于上世纪70年代初的AT&T贝尔实验室。Java，目前作为Android app开发的主要语言，诞生于上世纪90年代Sun公司的Microsystems系统。

发展到现在，不同之处在于，公司们拥抱新语言、从而想要延伸的特定商业目标的范围不一样了 —— 这一过程同时建立了一个忠心耿耿的开发者基础，他们被牢牢锁定在了某个公司的特定平台上。这类一石二鸟的战略，最早可以追溯到Sun对Java的采用，当时公司就将其作为了挑战微软PC桌面统治地位的一种手段。（事情虽然没有像Sun计划的那样发展下去，但在Google转向Android之前，Java大体上也算是在企业中间件系统中找到了自己的一席之地。）

这么看来，Apple的Swift其目标也就很明确了。Swift应该不会辜负公司前期的大肆宣传，通过磨平Objective-C那粗糙的毛边，看起来它能够成功简化iOS app开发者的开发过程。但是同样还是这些开发者，他们却需要学习一门新语言的输入和输出，而这些功能很可能在其他地方都不会用到。

大公司们为什么要重复造轮子

“不要重复造轮子”这一哲学在绝大多数开发者心中根深蒂固，大公司们对此却并不买账。那他们为何不只是修改下现有语言用于新的用途呢？

答案很简单，公司们发明他们自己的语言，是因为他们有这个能力。设计一门新语言可能很复杂，但对资源要求却并不很高。困难之处也就在对其提供支持，包括提供软件资源（共享代码库、API、编译器、文档等）以及赢得开发者的支持。大公司们在这两方面尤其擅长。

还有一个事实，现有语言通常很难硬塞进如今的复杂代码框架中。举个栗子，Facebook决定发明的Hack，就是一个普遍适用于Web开发的脚本语言PHP的超集合（superset）。

Facebook的Hack最近已经比较普遍，其主要目标就是改进代码的稳定性，针对这一目的，它强制在程序运行之前对数据类型进行检测。这样的检测确保了一个程序，比方说，不会将一个整数解析为一个字符串，这样的错误如果捕获不到很可能会导致不可预知的后果。在Hack中，这些检测会预先执行，以便程序员能够在程序上线前早早发现这样的错误。

据Facebook的Hack项目组核心成员Julien Verlaguet透露，公司之前尝试过用一门现有语言实现更高效的编程。但是Facebook的大部分代码都是由PHP编写的，公司实际上已经建立了一个支持PHP及其分支的软件架构。即使能够让PHP同其他语言编写的代码协同工作，实现的难易程度和运行速度都无法满足要求。

“比如说我们尝试用Scala重写PHP代码库，”Verlaguet说。“Scala是一门设计优秀的漂亮语言，但是它与PHP完全不兼容。每次我需要从Scala的代码库部分调用PHP的时候，都会损失性能。我们很愿意使用一门现有语言，但是对于我们来说，这条路行不通。”

于是，Facebook发明了Hack，它与PHP一样能够共用公司现有的架构。Verlaguet介绍说，Facebook的代码库主体已经从PHP迁移到了Hack，同时公司将Hack开源，希望独立开发者们能够帮公司找到Facebook以外的用途。

“你仍然可以使用PHP，”他说，“但是我们希望你有使用Hack的欲望。”

谁说了算

公司和开发者之间有一种微妙的平衡。公司可以按照自己的喜好发明语言。但是如果开发者都不愿使用这门语言，那就没人用了，公司以外的人也就没人愿意将自己的职业生涯托付给这家公司。

公司在开发过程中同时使用不同的语言，这并不少见。例如，你可能用Objective-C开发iOS app，但却用Java开发Android app。对开发者来说，这从来都不是症结所在，因为Objective-C和Java都是通用面向对象语言。它们用途广泛适用于很多场合。

然而，Hack、Dart、Go和Swift，到目前为止，仍然只适用于严格特定公司的编程解决方案，往往和公司选择的编程环境相对应。诚然，现在下结论可能还太早。比方说Hack，就可以用在一些后端的实现中；它只是太新了，以至于Facebook还没有任何数据供人们如此使用。

不是开发者不能学习多门语言。事实上，大多数人已经掌握了多门语言。这好比罗曼斯语（一种由拉丁语演变而成的语言），如果你会说西班牙语，再去学法语就比那些不会西班牙语的人简单许多。与此类似，如果你已经会Java，再学Ruby或Perl就简单得多。如果你会PHP，基本上就已经学会了Hack。

与此相反，学习多门语言更多的是一个习惯问题。如果Java已经解决了你的问题，你就不再有动力去学Ruby。如果你用Objective-C编写iOS app感觉很爽，你就不会有强烈的意愿去学Swift。

另外，对于一些开发者来说，封闭生态系统的语言只会使每个人的生活变得更糟。例如，自由设计师Jack Watson-Hamblin就告诉我说，像Apple这样强势推出Swift，其实是在冒险增加程序员的负担，同时将开发者社区割裂开来：

程序员掌握多门语言固然重要，但是不断强迫他们紧跟新语言，却是行不通的。如果我正在开发一个简单的跨平台app，我可不想被迫掌握四门语言再来完成它。如果真的需要，我也只想使用一门语言。

Watson-Hamblin就主张说，当每家公司都为了自家需要发明自己的语言时，程序员的注意力被分散，开发的视野也局限于一种，这只会拖慢整个开发进程。他说，“如果拿公司负责一门语言与负责一个开源社区相比较，这两者的区别就好比一家大企业与一个初创小公司的区别”。社区生来就更加灵活，适应能力更强。

当然，Apple有许多非常好的理由推出Swift从零开始，就像当初Facebook发明Hack的时候一样。我并不是说，大公司不会强迫开发者接受这种改变，在这方面，有些公司一直都很让人讨厌。

“新语言的发明，伴随着霸权的支配，”Verlaguet说，“被迫不停追赶，确实令人沮丧，但另一方面，你又多了一种解决问题的新语言。反过来想想，要是全世界的程序员都用同样一门语言做所有事情，即使啥都凑合着能干，这门语言也一定干得不怎么样”。

题图来自于Flickr user Ruiwen Chua，CC 2.0

via: http://readwrite.com/2014/06/17/apple-swift-facebook-hack-google-dart

译文：http://linux.cn/article-3327-1.html

一个程序员在考虑增值时无法回避的一个根本问题是到底是做技术还是做管理。当然也有些职位会介于两者之间，比如架构师，但我们暂时不去做细分，而是用简单的二分法。

这种基本方向上的选择对后续很多细节上的取舍有关键影响，所以在考虑其他之前，最好先回答一下这个问题。这就和修炼时要选择少林、武当、华山还是魔教一样，一旦选择，基本上是回不了头。

当然选择管理不意味着不需要掌握编程技能，毕竟当下大多公司还是信奉“宰相拔于州郡，将军起于行伍”的。但当技术达到一定水平后，管理还是技术这种方向性的选择将对下一步做什么有比较大的影响。在考虑那个方向前，则要先弄清楚管理和技术的关键差异。

技术与管理的关键差异

到了30几岁后，转为管理人员的程序员经常会调侃自己的技术能力：当年解决这种有时出、有时不出的Bug时，我常常在其前后都加几条调试输出，这招很管用很可能立刻就把它搞定了。结果多年后维护这代码的人困惑了，还来问我，这句为啥不能去掉，看着也没用啊，其实我也不知道，只能说运气和人品在程序里也是很有影响力的。

这是管理人员的一种真实写照，大家都知道，一旦走上管理岗位，那就和ppt越走越近，和代码越走越远了。虽然他仍然要跟踪最新技术的动向，但他很可能已经无法深究很多技术细节了。

据说微软这样的公司推崇一个人要想走上管理岗位，那要先把自己的代码用远少于别人的时间写好，省下来的时间才用来做管理工作。这很好，也不是完全不可能，但大多时候很难，需要很强大的天分，大多数人是做不到的。

主要原因是管理和技术所要处理的问题有根本上的差异。

管理者往往需要处理许多与人相关的事情，这导致要处理的事情是碎片化的，如果坚持编码，那么每天的打断往往会大幅降低写代码的效能，大家都知道编码是需要专注的。

管理工作总是需要面对大量的琐碎工作的，比如：老板对项目不满要赶紧去说明，免得发酵成大问题；人力缺了要赶紧协调，一是要能要到人，关键还得能要到合适的人；工具缺了，要赶紧购买；兄弟们有情绪了，要赶紧安抚；PPQA了有抱怨了，要赶紧改正。如果工作进一步泛化，还要涉及到预算、评估、职业路径规划等。

我们很难让这些事情按照自己的节奏发生，如果管理人员做编程，最终这些都会变成一种对编程工作的随机性干扰。所以一般来讲很难把它们很好的与编码结合在一起。想象一下，一个管理人员负责某个项目中影响关键路径的某个模块，接下来上面所列的意外发生了，那这个管理者怎么办？

唱歌的时候常说到Key或者调门这个词。同样是《花心》这首歌，周华健的用的Key和原本的冲绳民谣《花》的就不同，这导致两首歌听起来差别就很大，完全不一个感觉。也许可以说管理也是一种技术，但管理和设计编码这种技术的Key不一样。做技术需要面对的是程序，程序是讲道理的，Stack Overflow时它一定会崩溃；而做管理时需要考虑技术因素，但更需要面对的是各种人，人则只在一定程度上讲道理，所以管理不只是一种技术。因此基本上可以认为管理和技术时完全不同的两个方向。

如果大家细心观察周围，就会发现，做技术（编码）的往往可以转去做管理，但做管理的再转回做技术（编码）就难了。这意味着技术背景对做管理往是很有帮助的，而管理背景对做技术则几乎没用。

了解到这种差异后，要想做出自己的那份选择，还需要考虑三件事情：一是既定环境下技术路径究竟有多长，也就是说做技术有前途么；一是个人的性格适不适合做管理工作；一是做管理工作可能会有什么负面影响。这三点将在接下来的三个小节中分别进行探讨。

技术路径长短对前途的影响

程序员往往自嘲自己是“码农”，不知道这词是那里出来的，但听起来“码农”和“农民工”已经有点近似了。而“农民工”往往是收入低，工作时间长的代名词。这就折射出了一个很尴尬的事实，在很多公司中，单纯从收入的角度来看管理职位是要高于纯粹的技术岗位的。

这并非是一个绝对规则，前文就曾经提到早在20年前，微软的超级程序员就可以拥有比管理人员更高的工资，可以拥有多辆保时捷。但在技术路径短的公司里，管理人员收入偏高这事情却具有必然性。

当一个公司的核心技术并没有创生多大价值，而是需要靠人力规模、商业模式等来支撑业务的时候，那么我们可以称之为技术路径短的公司。想象一下，如果一家公司专门承接本地化工作，那么也许也会需要程序员编制某些工具，但对程序员而言技术路径无疑是短的。

如果暂时把眼光从程序的世界移开，那么事情就可以看得更清楚。

在盖楼的时候，只要达到基本的质量，一个人每天砌200块砖，固然比砌100块要好的多，但相对于大楼而言，多砌100块砖，所多带来的价值有限。再进一步由于砌每块砖的价值是固定的，同时一个人每天所能砌的砖也是有限度的，这就会导致砌砖工人，不管多么努力，其收入水平必然会被限制到某一个较低的水平，只要他的工作还只是砌砖。这种限度是由这一工作的内涵所决定的，倒不是谁遭到了歧视。

再类比到软件行业里，单纯的在既定接口下实现已定义的业务逻辑就是技术路径比较短的工作，是体力密集型的；而分析业务逻辑，控制整体架构或者去研究TTS的算法则是智力密集型的，技术路径较长。

在选择方向时关键要避免的是选择了技术方向，但身处的现实中技术方向却路径较短，或者喜欢管理但跑到了纯粹技术流的公司里，这种选择其内部所蕴含的矛盾会给当事人的人生造成极大的困扰。比如说开发小型信息管理系统时，其所需要的技术含量并不高，公司的主营如果是这个，单纯的做技术可能会直接影响收入。这是一个需要考虑的很现实的事情。

什么样的程序员适合转管理

《黑客帝国》的动画片中有一集叫做“Matriculated”，在这一集里有个机器人被逮住后，人类通过各种场景让他相信自己是个人类，计划看似成功了，但实际却不是。这个动画的启示意义在于，先天带来的很多东西，比如性格等实在很难改变，更多时候选择顺应自己的天性比选择对抗更加明智。

从先天性格来看，确实有的人天生适合做管理多一点，有的人天生适合做技术多一点。

比如说：

有的程序员天生有点被动，不喜欢主动学习很多东西，不喜欢与人沟通，但对工作所直接关联的领域研究较深，做事情兢兢业业，一丝不苟。

有的程序员非常聪明，理解东西很快，但不愿意搭理别人，总感觉别人水平比较差，脾气也比较暴躁。

有的程序员精力充沛，对技术狂热，但并不仅局限于技术本身，有大局观，有理想，能坚持。

单从性格而论前两者都不太适合做管理工作的，一旦做了管理工作，接触各种性格的人，容易造成人际关系紧张，反倒对自己形成一定的压力，极端情形下就会精神失常。

单纯的因为收入而选择管理工作，并不总是明智的，你可能无法适应，反倒导致事业出现起伏—不要低估这点的影响，现实中非常多的人因为这种错位而使人生走入低谷，甚至生病。

在大五模型里用五个因素来考察人格特质：

外倾性（extroversion):

外倾者者倾向于喜欢群居，善于社交和自我决断。内倾者则比较内向，胆小害羞，安静少语。

随和性（agreeableness）:

高随和性的人是合作的，热情的和信赖他人的，低随和性的人是冷淡的，敌对的和不受欢迎的。

责任心(conscientiousness):

高责任心的人是负责的，有条不紊的，值得信赖的，持之以恒的。低责任心的人则容易精力分散，缺乏规划性，且不可信赖。

情绪稳定性(emotional stability):

积极的情绪稳定性者倾向于平和，自信；而消极情绪稳定性者（神经质的人）倾向于紧张，焦虑，失望和缺乏安全感。

经验开放性(Openness to experience):

开放性高的人富有创造性，凡事好奇，具有艺术的敏感性；开放性低的人则保守对熟悉的事物感到舒适和满足。

总的来看，外倾性和经验开放性好的人更适合走上管理岗位。

千万不要忽视这种错位的力量。金山的求伯君先生就直承自己不擅长做管理。他认为人的一生之中最关键的是对自己能够有所了解，不是说自己什么都能干，是万能的。在雷军走后的4年里，做CEO有些力不从心，快50岁的他精神压力太大，多次想退休，请雷军出山。最终求伯君先生在不到50岁的时候退出江湖，不知道是不是和这个有关。

当然很多人可能远走不到求伯君先生的高度，但终究类似，可以打个比方形容错位的中层管理者。上司和下属员工像两块板子，管理这门功夫没练好的话，中层管理者就被搓球了：上司说，你做的这叫什么事儿，脑子大大的坏了。下属说：你瞎答应什么，这事儿怎么做，我不干，要干你自己干，爱咋咋地。

管理这功夫练好了，情形就变了：上司尊重你的意见，下属把你视为旗帜。一处天堂，一处地狱，核心差别其实不大，根本还在天生的人格特质。待管理人群的特质也很有影响，但这是运气所管理的范畴。

是不是适合做管理者的简明判断方法

假设说团队里两个兄弟吵起来来了，你愿不愿意去调解？

假如有一个人脾气很坏你愿不愿意和他沟通，即使你不喜欢？

假如有一个人问题很多，你愿不愿意面对面批评他？

假如有一个人屡教不改，你愿不愿意采取直接的惩罚措施，那怕关系紧张？

这个列表还可以增长。一旦做管理工作，这类需要抛开个人视角，而从组织的视角去看待问题并行动的地方很多。

如果对这类问题的回答是否定的，那么最好是不要往管理的方向上走。

上面这几个问题，纯走技术道路的还可以作壁上观，但如果是发生在自己团队里，管理者却保持逃避的态度，那么管理者就失职了。

由于人的世界很复杂，所以期望坏的事情一件也不发生，那是不现实的。我个人感觉管理者面对这类事情的几率是100%，区别是遇到多少件，而不是遇不遇得到。

其实故事到这里还没完，如果往深了考察，就会发现，即使一个人愿意去搞定吵架中的两个人，那还有你怎么去搞定，搞不搞得定的问题。

捣糨糊、各打五十大板这类简单粗暴的方法往往只能有效于一时，等价于埋下定时炸弹，长线来看不是什么高明方法。但把这个展开就需要另外一本书，这里就不进行展开了。

管理工作的负效应

从日常很多人发表的言论来看，管理工作似乎被无限美化了，很多人都认为管理工作似乎是一条彻底金光大道，但这并不完全正确。为了让事情回归本来面目，这里说一点管理方所可能带来的负效应。

同纯技术工作相比，管理工作（特别是中层管理）的可流动性可能会非常低，形象来讲很多公司并不会愿意请外来的中层管理者来管理已有的员工，而更愿意请技术上有专长的人来解决具体的问题。这是由管理工作的几个特质所决定的：

管理工作和人打交道比较多，所以对人员的特质有很强的依赖性。如果一个团队的人都非常像机器人，那么在不同公司间管理技能是完全通用的—只要有PMP，CMMI这类东西就够了。但关键问题是人员的特性是多样的，这导致管理人员和被管理人员需要较多的磨合和适应。形象点讲就是，如果无法搞定特定人群，你考5个PMP证书，该不管用还是不管用。

同时长时间在管理岗位的话，即使是做技术出身，技术能力也会退化，沟通技能、与上级的信任程度反倒会提高。而这些东西，到一家新公司后，一定会被归零，，其价值并不明显。反倒不如擅长算法，擅长某类业务的技术人员可流动性好。

这也就意味着，管理人员往往与公司的利益绑定的更紧。尤其是中层管理人员，达到一定年纪后（比如：40岁），很可能会失去流动的可能性，一旦所处的公司出现问题，那就可能会面临非常尴尬的局面—直接讲就是，如果你选择了管理方向，却缺乏相应的人脉，35岁之后基本不具备可流动性，换工作会很难，至少比纯技术的高端人员难。

这点的一个旁证是各个初创期公司的人员构成。如果你用心观察就会发现对于初创期的公司而言，它需要创始人把握方向和寻找资金，也需要工程师来完成具体事务，但不太需要中层管理人员。比如：Pinterest曾经公开了自己的数据，在2010年是2个创始人，1个工程师；2011是3个工程师；2012年是6个工程师；2013年是40个工程师。这种情况下，只有到2013年后中层管理人员才有存在价值，而一般情形而言这种情况并不会社招，而是会从现有人员中选拔。这最终导致纯管理人员的可流动性并没有想的那么好。

当然什么事情都有例外，如果你是成功运作几个产品的产品经理，那么也可不在流动性上受到限制。因为那些产品就是你最好的名片，他们使你在江湖里有了一席之地。

小结

考虑上述三个方面，大多时候可以判明自己是应该做技术还是做管理。比如说：如果一个人日常很容易和人产生冲突，但脑子很好使，也能静下心来钻研技术。这种情形大致上应该努力找一家技术路径长的公司做技术，否则可能会人际关系紧张。而与此相反，一个人如果技术能做的还不错，也愿意与人沟通，同时已经身处一家技术路径不是很长的公司，并不太能够换工作，那么就很可能需要尽早转向管理方向。

总之，别太为了点钱过度难为自己，走不远的话，最终还是吃亏。

（via：理想流的博客 程序员生存定律系列）

如何写一封「用户体验」更好的求职邮件，让 HR 或是招聘者对你顿生好感。

我之所以要写这个话题，是因为我在处理求职邮件的时候，就深受「用户体验」不好的困扰，很是头痛。从求职者的角度上说，你的目的是让招聘方(一般是 HR)从数十封甚至上百封简历里把你筛选出来；从招聘方的角度上看，则是如何从数百封简历里筛选出感兴趣的人。其中的关键就在于，你的求职邮件要传递足够丰富恰到好处的信息。

我给出的一些注意事项如下：

1.先注意收件人用什么邮箱。举个例子，如果收件人留了 Gmail 的邮箱，标题怎么写? 写多长合适? 正文第一句话应该是什么? 不明白为什么，打开你的 Gmail 看一下，如果你有 Gmail 的话。

2.如何避免求职信进入收件人垃圾箱?

3.你的邮件发送出去，收件人收信之后，看到显示的名字会是什么? 中文名? 英文名? 还是火星文? 不知道怎么设置的话，翻看一下邮箱的帮助。为什么有人讨厌求职者用 QQ 邮箱? 我想主要的原因就是因为用 QQ 邮箱的人「名字」那个地方显示的都有问题。

4.你谋求什么岗位? 如果是 HR 处理你的邮件的话，每天面对很多种岗位的求职信，怎么知道你是针对哪一个岗位求职?

5.针对谋求的岗位，你最关键的优势是什么? 最关键的技能是什么，最关键的经历是什么? 用一两句话写出来，写在邮件正文里。

6.你的简历能够让接收者方便的打开么? 你用的是 Word 简历还是 PDF 格式的简历? 如果对方电脑没安装 Word 怎么办? 你用的简历文档是怎么命名的? 是简单的写了「简历.doc」还是「你的名字-技能-求职职位.doc」，你知道类似后者的格式会让 HR 节省多少时间么?

7.你还在用前程无忧那种老掉牙的简历模板么? 说实话，那个模板真的已经让无数招聘者审美疲劳了。尤其是有些人根据那个模板填写的还不够认真。

8.你有必要在正文里深情款款的贴你的所谓求职信么? 还是以「尊敬的公司领导」作为开头? 很多时候都没必要。以我个人的经验来看，我很少去看简历中的求职信。当然会看邮件中的正文，如果看到不那么肉麻又令人感兴趣的内容，而且还没什么错别字的话，肯定会加深印象。

9.你的邮件，接收者在手机上也能很方便的阅读么? 不确定的话，自己发给自己，然后测试一下。你邮件里的附件，接收者在手机上也能方便的查看么?

10.如果招聘方终于打开你的简历看了，对你感兴趣，准备通知你面试。你猜，通知你之前他/她最关心什么? 当然，你可能猜不到。绝大多数人会需要确切的知道你现在在哪个城市的哪个区，是否能方便的过来面试。问题是，你写清楚了么? 没有的话，那就写明你现在在哪个城市发展，当下，人在哪里。你是否愿意到招聘方所在的城市或是区域发展。

怎样算是「用户体验」良好? 就是你做的事情必须为对方考虑，而且，你的确考虑到了。

原文ByFenny