One more struggle, and I am free
因为工作的关系，最近面试了很多软件架构师，遗憾的是真正能录用的很少。很多候选人有多年的工作经验，常见的框架也玩得很溜。然而最擅长的是“用既定的技术方案去解决特定的问题”，如果遇到的问题没有严格对应的现成框架，就比较吃力。这样的技能水平或许适合某些行业，但很遗憾不符合我们的要求。
软件架构师到底应该做什么，又为什么这么难做好，这都是近来的热门问题，我也一直在和朋友们讨论。正巧，最近我看完了新鲜出炉的《微服务设计》，所以大概可以谈谈自己的看法了。因为这类问题比较抽象，也没有统一答案，我努力尝试把思路整理清楚，把表达变得流畅。最终有没有讲清楚，说的对不对，欢迎大家给我留言。
最近有好几个朋友同事问我，一直都在做软件开发，想做软件架构，要如何入门呢？我从一些提问里感觉到，架构有时会被一些人理解为《葵花宝典》、《九阴真经》一类的秘籍，功力不到绝不能碰，功力到了才能专门修行。
可惜这种认知是不对的。架构的工作虽然比开发复杂，但脱胎于开发，它与开发之间并没有绝对的界限。即便只是做开发，也不妨碍你积累架构经验，从架构方面理解和看待问题，而这些，都是未来成为专职“架构师”的必要积累。所以，我现在尝试回答“做软件架构该如何入门”的问题，为各位正在做开发，但未来希望从事架构的同学们提供几点参考意见。
上海的很多朋友可能已经知道了，最近我们（沪江）正在大力招聘架构师和Java工程师。招人过程在紧锣密鼓进行的同时，我们内部也在不断总结数据，收集反馈，提高效率的同时尽力照顾候选人的感受。
我们也注意到，候选人的部分反馈是比较有共性的。经过仔细分析，我们确认这些反馈是可以理解的，但是我们更确认在技术招聘中必须有所坚持，最终才能得到好的技术团队和系统。所以今天我想“私器公用”一把，讲讲我对技术招聘和技术人员成长及评价的若干观点。
之所以写这个话题，是因为最近见了不少的分享，觉得甚为惋惜。这些分享的演讲者往往有很多的积累，在某些领域确实掌握了非常多的知识，也非常真诚，希望把自己掌握的知识和盘托出。可惜的是，分享的效果往往不如人意，哪怕听众本来对这个话题有兴趣，真正聆听的时候也感到枯燥乏味，因而意兴阑珊，听完之后一头雾水。
问题出在哪里呢？在我看来，问题出在演讲者没有重视“演员的修养”。
什么是“演员的修养”？很多人听到这个词会有朴素的想法，觉得无非是虚头巴脑的伎俩，刻意把真实的自己藏起来，巧言令色，迎合其他人的喜好。这种作派对于分享和演讲，真的有什么帮助吗？
确实没有什么帮助。但是，这并不是演员的修养，因为演员的修养包括更重要的内容——移情，也就是放弃自我，进入另一个角色，用完全不同的方式来思考和行为的能力。
之前的《创业不等于职业生涯加成》是我根据最近的面试经历，随手而作，没想到创下了近期阅读和传播的新高。随之也引起了不少讨论，某些反对意见认为“创业并非一无是处”，并列举了创业能给人带来的技能上、性格上、思维上的各种磨练和收益。这些论据当然有道理，但是和我说的观点并无矛盾——“不等于”的意思是，不要以为你创过业，你的职业生涯就自动升华了。
说得更直接点，“创业”绝不是职业生涯中的金字招牌，单纯“为创业而创业”，很可能结果是头撞南墙、遍体鳞伤，却无甚收获。这次我把话题说更详细点，希望理解的人更多，误解的人更少。
前段时间一个工作不久的朋友跟我说，离开了某创业公司，才觉得之前的同事都很苦。他们做的是大量重复性的劳动，却是公司业务发展不可或缺的支柱。但是，公司完全是出于“降低劳动力成本”的考虑在安排这些同事的工作，低廉的待遇，超长的加班时间，唯一能维系大家的，就是公司创始团队对牺牲精神的强调，以及不断吹嘘的愿景，当然那些诱人的长期回报从来都只是若隐若现，没有扎实的落地措施。
面试，无论对哪家公司来说，都是件重要的事。
因此许多公司很重视面试，制定了面试规范，以及对面试官的一系列要求，网上关于面试礼仪的文章更是汗牛充栋。然而，很多面试的效果仍然不够满意。最显然的表现是迟迟没有找到合适的候选人——尽管他们本来合适的，更糟糕的是没有给候选人留下好印象。在这个“人人都有麦克风”的时代，这种印象很可能通过面试官和公司意料不到的渠道传播出去，造成一系列的麻烦。这种情况，相信是任何公司都不愿意看到的。
要如何避免这种问题？怎样才能真正把面试做好？在我看来，规范、技巧、礼仪都不是最重要的，最重要的是公司对待人才的态度，具体落实下来就是面试官的态度。如果面试官能做到“正心诚意”，面试的效果通常不会太差。
正心诚意，用直白的话说，就是两个词：尊重、诚恳。
最近面试了很多技术人员，其中不少之前的工作履历还不错。但是，因为他们之前的创业经历，我并不能发offer。
看到这里先别着急下结论，让我仔细说说理由。
技术领导要不要写代码？这是一个问题。
我刚工作的时候就听说，程序员（那时候还没有“码农”的说法）是吃青春饭的，到30岁就熬不了夜写不动代码了，所以要尽早转管理岗。相应的，如果你走上管理路线成了技术领导，自然就不必干写代码这种低级重复的体力劳动了。所以当时自己代码写得很多，技术能力增长很快，但总感觉有点别扭。那感觉就像，你能把车开得又快又熟练，最终只是为了能按时到达机场赶上飞机。然后，你就再也不用开车了。
不过无论如何，赶上飞机看来是更高级的选择，为了它，放弃苦心修炼的车技也可以接受罢。
但是等我真正走上管理岗位，才发现事实和我想的完全不一样。当时公司的业务增长飞快，支持业务的系统却是几年前“一锤子买卖”的外包项目，更要命的是技术团队的人员组成和工作习惯还处在作坊状态。从我的角度来看，四下里全是大坑，填坑的速度慢得让人着急，在此过程中还经常挖下新坑…… 在我的职业生涯中，我从没有在那么短的时间里写过那么多代码。几年后大家查提交排名，我的名字仍然第一。好在我的努力没有白费，系统终于没有垮掉，顺利回到正轨。
当时我身为技术领导，除去招人、定流程、做运维，还花了大量时间写代码，这样的做法是对的吗？如果是对的，后来我再没有写过那么多代码，好像也与“不称职的领导”无缘，甚至还被夸奖过“忍住放手让下属去做事，锻炼了组织”，这又是怎么回事呢？
我有时会帮朋友们做些工作引荐，所以经常见到一种可惜的情况：有些人明明素质很好、专业很过硬、经验很丰富，偏偏简历做得太过敷衍潦草，一眼看去泯然众人、毫无亮点，甚至让希望引荐的我感到汗颜。看来，有必要认真谈谈简历这件事情。
要想找到好工作，简历是敲门砖，所以怎么重视都不为过，尤其是要提供“抓人”——也就是能给简历阅读者留下深刻印象——的简历。
你知道GPS是怎么发明的吗？
马里兰州罗瑞尔市坐落着约翰·霍普金斯大学的应用物理实验室（APL）的自助餐厅，长期以来都是就职于实验室的物理学家、数学家、技术人员聚会的热门地点。在1957年10月7日的午餐时间，大家讨论得异常热烈，因为苏联刚刚发射了第一颗人造卫星。
两位年轻的物理学家威廉·吉尔和乔治·韦芬巴赫也参与了讨论。他们首先确认这不是苏联的把戏，因为确实收到了来自太空的音乐。继而他们忽然想到，可以利用多普勒效应来计算卫星的移动速度（简单说，多普勒效应就是指信号源或接收器在运动状态时，相对速度与波形频率的固定关系。如果你路过鸣笛的消防车或救护车，会觉得随着它们的远离，鸣笛的音调也下降了）。结果，吉尔和韦芬巴赫用了几个小时，就实现了收听、测量、跟踪的功能。
过了几周，一个无组织的科学家团队在此基础上补充细节，研究关于轨道卫星的理论，提出了改善建议。之后，APL负责人批准了款项。于是APL的科学家们有了一整套算法，能够精密地测算出卫星的运动轨迹。
到了1958年春天，APL的副主任弗兰克·麦克卢尔把两个家伙叫去办公室，神神秘秘地问：如果卫星运动时，可以用固定的地面接收器来计算卫星的方位，那么反过来，卫星固定，地面接收器运动，能够测算出接收器的位置吗？这个问题没有人想过，也没有人评估过。经过几天的紧张计算，吉尔和韦芬巴赫确认：“反向定位”是可行的。
2年后，美国实现了“反向定位”系统，最初用于为潜艇确认位置。1983年，大韩航空的班机因为导航故障误入苏联领空被击落之后，美国向民用领域开放了整套系统。这，就是今天我们熟悉的GPS。