del

极客时间专栏/geek/职场求生攻略/加餐/28 | 沟通中的冲突：什么时候应该妥协，什么时候应该坚持？.md

@@ -0,0 +1,98 @@
+<audio id="audio" title="28 | 沟通中的冲突：什么时候应该妥协，什么时候应该坚持？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ce/6c/ce518112b1edb7fdb79c16e108241b6c.mp3"></audio>
+
+你好，我是臧萌。本专栏进入到加餐模块啦，第一篇加餐，我们又来谈沟通了。
+
+按照我们之前谈沟通的顺序，先是从工作的基本素质上，我们要重视沟通，主动沟通。然后从职场情商的角度，我们要重视沟通的方式方法，重视沟通的效果，尊重沟通的对象。从这两个方面来看的话，沟通还是正面与合作为主。但是我们在日常沟通里，面对的远不止这些和谐画面。
+
+很多时候，我们还会遇到很多观念观点的冲突。如果冲突可以通过短时间的讨论达成一致，那就不能算有冲突。当然，也有可能大家心里的想法都不是很明晰，讨论下来也没有一个明确的结果，这也不能算冲突。我们这里说的冲突，是双方或者多方的想法都非常明确，然后经过反反复复的讨论，大家的想法也无法达成一致的情况。
+
+接下来在这一节里，我们就从处理冲突的角度来聊聊沟通。
+
+## 有些冲突，程序员要主动退到一边
+
+发生冲突的一个很大的原因，是有直接的利益冲突。比如谈地盘、谈系统归属、谈责任等等。这些情况是经理等管理者的主要战场，我们程序员打好辅助就可以，一般不需要主动露面谈。如果遇到这些相关的讨论找上自己，可以先简单应付，但是真正到了讨论核心问题的时候，一定要记得把自己的经理拉进来。
+
+需要强调的一个点，千万不要做超出自己权利范围的承诺。大白话就是，自己说了不算的话，不要跟自己组之外的人说。
+
+一般来说，大家都是会找对等的人来交流。比如说，如果这个会议上有对方的经理，那么自己组的经理也是要出面的。这不是排场面子的原因，而是对等的人，才能聊得下去，把事情敲定。举个简单的例子，一个国家的总统，和另一个国家的经济部长，是没办法聊的，因为很多事情经济部长无法拍板。
+
+## 如何应对沟通中的冲突
+
+属于我们程序员相关的冲突和争论，一般都是与技术和架构相关的。那么我们程序员应该如何应对沟通中冲突呢？我下面举几个例子，我们一块来看一下。
+
+### 代码方面的个人偏好
+
+每个人都有自己的偏好，比如说，有人喜欢用Lambda，有人喜欢用for循环，有人喜欢这样去命名方法和变量，有人喜欢另外一种风格。从我个人的建议来说，谁负责写code，谁就有权利决定用自己喜欢的风格写代码。只要功能可以完成，代码足够鲁棒，那外人就没权利多加干涉。毕竟我们不是流水线上的工人，不可能生产出一样的代码。
+
+当然，不是说代码就没有标准。就Java来说，Java编译器有warning，还有Sonar、PMD、Findbugs、Checkstyle等工具。这些工具里有很多检查代码的规则，这些都是业内实际的标准和共识。从这个角度来说，你没必要用自己的个人偏好去指点别人。当然，如果被人指点，你也可以拿这个反击。毕竟行业内的标准都没说什么，你有什么资格说我？
+
+### 接口的设计
+
+接口的设计其实非常考验一个人的能力。它比具体的实现代码更抽象，但是比架构设计更具体，是连接两者的桥梁。
+
+简单来说，接口就是程序世界的标准。标准的规定有一个公认的原则，就是要足够的包容。比如Iterator、Collection和List作为参数，兼容性逐渐降低。当然这个例子没什么大问题，大不了调用方自己转一下。但是如果用了File做参数，而实际上只需要InputStream读取数据，那调用方如果没有把数据存在File里，就不好弄了。
+
+从参数的角度说开去，接口就是这样一个越包容，越优秀的东西。如何能用最少的约束，把事情描述清楚，就是接口的一大目的。面临接口设计的争论时，大家可以就这个点展开，各抒己见。最终得出结论，也不是难事儿。
+
+### 系统架构
+
+系统架构上的争论，则更是因人而异。因为做系统架构的过程，其实是每个人对一件事情理解和建模的过程。就好像扔给两个人一堆积木，让他们每人搭一个大楼，肯定俩人搭建的大楼不会一样。即使你指出方向，比如一个商业摩天大楼，外表也会不一样。即便是再规定得详细一点，比如要有广场、要有裙楼等等，细节部分也不会一样。那就更别说软件架构设计了，俩人架构的系统肯定不一样。
+
+如果在软件架构上有冲突，应该怎么处理呢？软件架构结果的冲突只是表象。根源是大家对问题的理解，对系统如何应对问题的方式理解不同。这时候，如果只是纠结于架构的不同，是无法得出一个结论的。所以，为了解决冲突，应该大家都回退一步，先从问题入手，让大家对问题的理解能够统一，对解决问题的方式能够统一。这样，即使架构上有所不同，也是容易解决的。
+
+当然，我在前面也提到过：令出多门，兵家大忌。如果就是不能统一呢？这种情况下，就得有一个总的架构师，能够维护整体解决方案的统一性，避免因为彼此的认识不同，导致系统无法统一。其实很多时候，系统架构很难说谁对谁错。但是如果各个子系统的风格不统一，那大概率就会有问题。
+
+### 功能现在就要
+
+很多时候，需求方会提出很多现在架构下不支持的功能。这时候我们就有两个选择，一个以快糙猛的方式，放弃遵循现在的架构，把功能怼出来。一个呢，是从长计议，深入理解需求、升级架构，然后支持新的功能。
+
+我来打个比方，系统架构就像是一张交通图。普通的需求就像是走高架，不需要绕路，没有红绿灯，可以用最短的时间到达。特殊的需求就像是走地面，甚至是走单行道，需要走走停停，甚至需要绕路，虽然费点劲，但是也能到，而且不和架构冲突。
+
+架构不支持的需求，则是交通图上根本没有路的情况，就好比需要跨过一条河，但是河上并没有桥。这时候，第一种选择就是硬怼，比如放下车、找条船、甚至直接游泳过去。
+
+第二种选择是先深入了解用户过河的需求，包括过河干什么、频次是多少、运载量是多少、能够接受的交通时间是多少等等。然后再根据需要来选择是修建码头、修建跨河大桥、还是修建隧道。
+
+看似第一种选择是客户至上。但其实很多时候，第一种选择是短视的表现。一方面，你快糙猛做出来的东西，很可能无法完成用户接下来的需求。比如说，随着需求的发展，用户要求一天来回1000趟，每趟不能超过3分钟，游泳自然不可能。坐船的话，你去哪里找这么多的快船呢？换句话说，违背现有架构，快糙猛地实现客户的需求，是对客户的溺爱，而非真的的客户至上。
+
+另一方面，没有深入理解用户的需求，其实会错过和客户一起深入理解系统和业务的机会。系统架构不支持，确实是系统本身的限制。但是如何让系统更完美呢？就是你要通过这样的机会，深入思索业务模型的限制，通过升级系统来让系统建模更加通用，可以应对客户以后的新需求。
+
+## 方式方法可以妥协，原则和目标必须坚持
+
+上面的几个例子中，一个共性是大家先后退寻找共识（common ground），然后以此为基础，把事情向前推进。这里我总结一下上面几个例子里所说的共识。
+
+1. 代码偏好：findbugs等业内标准。
+1. 接口设计：接口设计应该包容。
+1. 系统架构：大家对问题的理解要统一。
+1. 新功能：理解新需求，升级架构，以支持新功能。
+
+回到我们标题上提出的问题，我们在交流中遇到冲突时，什么时候应该妥协，什么时候应该坚持呢？这里我给出一个自己的标准，那就是做事情的方式方法可以妥协，但是目标本身必须坚持。
+
+对比上面的四个例子你就能发现，所谓的标准，越来越模糊。什么是包容、什么是对问题的理解、什么又是新功能的本质，越来越没有绝对的正确。每个人，在自己不同的阶段，都会有不同的理解，更不用说在不同的人之间。
+
+这就带来一个实际的问题，就是冲突的情况不可避免。这时候我们程序员千万不要怕冲突，只要你是冲着做事情去，而不是冲着搞事情去，就一定要将自己心中的疑惑说出来。
+
+说出来的好处，首先是可以互相切磋，提升彼此的认识。正所谓不打不相识，很多时候大家的认识都不够全面，通过冲突的方式，可以让彼此都拓展自己的认识。
+
+其次，要说出来可以逼迫自己深入思考。想和别人刚，自己得先把自己的想法理清楚。很多时候，自己的想法是想当然的，当这种想当然和别人发生冲突的时候，就需要自己深入思考，或者找出自己的理由，或者放弃自己的成见，接受别人的观点。无论是哪种，对自己来说都是成长。
+
+最后，有疑惑就说出来，可以让彼此合作更默契。我们经常说一个团队有默契，其实默契就是这样磨合出来的。不磨合，只是表面的迎合，并不能让一个团队里的成员配合无间。
+
+## 总结
+
+我想特别强调的一点是，程序员不要一味地逃避冲突。你如果用妥协来避免冲突，这绝对不能很好地解决问题。当然，我不是说要做一个“杠精”，而是要在做事情的基础上，充分表达自己的观点和认识。
+
+如果自己明知道别人的做法有问题，但是你选择不表达自己的看法，长久下来，只会让别人觉得你没想法。和自己有关的东西，更要在自己不认同的时候发声。如果你只是一味地委屈自己，成全别人，其实只会让人觉得你软弱。
+
+很多程序员不喜欢交流，不喜欢拒绝别人，更不要说和人争论、冲突。说实话，我也非常不喜欢和人冲突。但是正是自己这种避免冲突的倾向，让我吃了不少亏。举个例子，我之前觉得架构设计有问题，我也不会说什么，觉得只要能做出来，实现功能就可以。后来发现，这些架构设计的问题，会慢慢变成坑，变成阻碍一个组发展的绊脚石。
+
+现在我只要在工作中遇到觉得有问题的事情，马上就会要求展开细聊。如果其他人时间不够，就另外找时间聊。我从原来逃避冲突的人，变成了主动制造冲突的人。
+
+根据我的观察，这种冲突，往往都能够让事情得到更好的结果。如果一味地为了避免冲突而保持缄默，其实长期来看，是无法融入到一个团体的。当然，如果一个团体里经常就相同的事情冲突来冲突去，那很可能说明大家就是无法磨合得很好。在这种情况下，如果你不打算离开这个团体，在面对冲突的时候千万别打退堂鼓。
+
+<img src="https://static001.geekbang.org/resource/image/33/ab/331fd86e302702ee867c195564abb7ab.png" alt="">
+
+## 思考题
+
+你在工作中，有遇到过哪些让你记忆深刻的冲突？这些冲突是以双方都满意结束，还是以双方不欢而散结束呢？你有哪些处理冲突的经验和教训？
+
+好了，今天的课到这里就结束了。欢迎你在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/加餐/29 | 加班：加班逃不过，如何用正确姿势加班？.md

@@ -0,0 +1,97 @@
+<audio id="audio" title="29 | 加班：加班逃不过，如何用正确姿势加班？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/94/82/94c34033bceac63205700fa7c520d682.mp3"></audio>
+
+你好，我是臧萌。咱们程序员，尤其是互联网行业的程序员，都基本逃不过加班这件事。加班的原因，我总结了三个：任务太多，有紧急的事情以及强制加班。今天我就根据不同的加班原因，来仔细和你聊聊加班这档子事儿。
+
+## 任务太多
+
+首先就是任务太多，事情做不完。大部分情况下，造成工作任务繁重的原因，都是一些现实因素。
+
+比如说系统的架构，已经不能够高效地应对现在的业务，每次增加新的业务用例都很繁琐，而且容易出错。又比如公司里各种系统都不好用，工作中用到这些系统，就费时费力，还可能来来回回折腾很多次。这些现实情况，让本来听上去没太大工作量的工作，实际做起来要用的时间却会多很多。
+
+### 提高自己的效率
+
+如何应对这种情况呢？我们要去思考这些让自己效率低下的原因。为什么会效率低下？根据我的观察和切身体验，其实很多时候，加班并没有让自己的产出更多。程序员的产出是不能用代码量来衡量的。
+
+如果非要衡量的话，可以用代码完成的功能这个维度来简单衡量。很多时候我们加班，并不是完成了更多的工作，而是用更长的时间，去完成自己本应该用作时间就可以完成的工作。这就是效率低。
+
+回到增加业务用例的情况，我们可以问自己这样一个问题：如果系统重新设计重新做，是否可以让增加业务用例的时间大大缩短？如果是的话，现有系统架构陈旧就是效率低的原因。再看工具的问题，你能不能找到一个合适的工具，让系统更加简单自动化？
+
+这里我举一个自己工作中遇到的例子。我曾经参与过一个系统的开发，系统的输出是一条条互不相关的key-value记录，总数大概五百万到七百万条。
+
+为了验证输出的结果是否正确，要和上次系统运行的结果做对比。但是这个对比工作没有很好的工具，当时的做法就是将两份数据导入MySQL数据库，然后对于怀疑有问题的数据，用key去查询两份数据，逐个字段地进行比较，找出数据有差异的原因，再分析原因是否合理。
+
+这是一个纯人工的工作，每一步都需要人来操作，如果有这么十几二十个记录要核验，那基本上半天就搭进去了。这种事情如果是偶尔搞一次，那也无妨。但是随着系统的发展，这个事情几乎每周都要来个几次，甚至有时候一天就要搞好几次。那这就完全是一种低效率的工作方式了。
+
+我当时思来想去，觉得几百万的数据量也并非一定要用数据库。于是我写了一个程序，可以将两份数据文件做对比，自动找出变化大的数据，并自动对比各个字段。这样，生成的对比文件，就可以直接用来判断这次运行的结果是否有问题，并且可以很方便地，对每个差别比较大的数据进行查找和比对。最后我再把这个程序对接到生成系统输出的任务上，做到自动化执行。
+
+当然，在很多时候，系统重构也是很好的方式。举个例子，如果数据的schema经常需要根据业务需求做改变，但是查询条件就只是根据key来单条查询，那就可以考虑搞一个text字段，把动态增加的业务字段转成JSON来存储，当然，也可以考虑转到对数据的schema变化更友好的NoSQL数据库。
+
+不论你是选择合适的工具，还是去重构系统，都是在选择一种用更短时间去完成工作的方式。重点不是在于你去选择什么特定的方式，而是在加完班之后，你得好好思考一下，今天的工作效率高吗？有没有什么事情让自己觉得没技术含量？你是不是可以避免这些没技术含量的事情？是不是可以让这些没技术含量的事情自动起来？
+
+我们是软件工程师，我们要让每天做的事情，对得起自己的能力。加班不仅仅是在浪费自己的时间，更是在浪费自己的才华和能力。有时间加班，为什么不用这个时间，搞个系统替自己加班呢？
+
+## 紧急的事情
+
+其次就是有紧急的事件。可能是线上出问题了，也可能是忽然有个优先级特别高的项目，需要自己在的组协助，甚至有可能是你直接被抽调去做某个高优先级的项目了。
+
+至于线上问题，这个基本上是不能逃避的。我们能做的，就是防患于未然。比如增强监控，要监控的不仅仅是自己的系统，还有自己依赖的系统和依赖自己的系统。又比如尽量避免在周五上线，因为如果周五上线出了问题，就要加班去搞等等。
+
+至于优先级高的项目，在我看来，更多的是一个机会。这些项目无论是新业务新方向，还是系统升级更新，都是一个让自己刷新技能、扩展眼界的机会。这时候阶段性地付出一些时间，对自己的职业生涯来说，是挺值得的。
+
+拿我自己来说，我是个比较懒的人，有时候对很多系统的了解也是浅尝辄止。但是我被抽调参与过几次紧急项目的开发后，对这些系统和业务的认识提升了很多，反过来再看自己的系统，也更能理解一些之前没注意到的细节了。
+
+## 强制加班
+
+最后就是被大家“深恶痛绝”的强制加班。事情嘛也没啥事情，就是公司的氛围就是这样，大家都在位子上好像都没啥事情做，下班回家吧，又显得突兀——毕竟大家都没走。甚至公司可能会强制规定延长工作时间。即使公司不硬性规定，也可能用各种政策和福利影响你，让你半推半就地加班。比如比法定下班时间推迟几个小时才有“免费”晚餐，或者推迟几个小时下班才有班车等等。
+
+我们站在工作的角度，先看看公司为什么原因让员工没事做，也得留在公司里。
+
+我总结下来，大概有这么三个原因。首先，员工留公司里肯定会做更多的工作。即使你不想做和工作相关的事情，只要在公司里呆着，也难免会不自觉地做一些工作。
+
+其次，是方便彼此协作。即使你自己本身不加班，如果别人加班需要你协助的话，可以直接找到你人，你也不好意思面对面地拒绝别人。
+
+最后，就是公司文化等原因，公司愿意营造出这么一个大家都在努力奋斗的氛围。
+
+那么我们应该如何应对这种类型的加班呢？在我看来，既然选择了这家公司，还是尽量遵守公司的默认上下班时间。那么在你没事做还得加班的时候，在公司能干什么呢？
+
+### 做些对自己有附加值的事情
+
+公司是一个可以专注的环境。如果不得不呆在公司，那对自己最有利的选择，就是做一些对自己有附加值的事情。这里我列举两个例子。
+
+### 学习和探索新技术
+
+首先自然是学习新技术。一个选择是把自己白天没时间弄清楚的技术整明白。不要放过程序中任何一个错误日志，不要放过工作中任何一个没想通的事情。然后就是看看哪些技术可以用在我们自己的系统上，放心大胆地试试看。毕竟这不是被安排的任务，不需要背负产出的压力。
+
+### 不要止步于抱怨
+
+每个组、每个系统，肯定都有大家一直在抱怨的小事情。这些事情不做也可以，但是做了会让自己组的效率更高。这时候，可以选择自己有兴趣且力所能及的点，把痛点修正掉。一个系统既然有人抱怨，还在一直用它，那就说明这个系统解决了实际的业务问题，是有价值的，是值得做好的。
+
+一个被抱怨的大户，就是大名鼎鼎的遗留系统。也许它的技术很落后，也许它的系统设计千奇百怪，也许它的代码很丑陋，也许它各种不好用各种容易崩溃，也许它在技术的角度说，怎么都让人看不上眼。
+
+但是遗留系统，尤其是那些大家都在骂，甚至深恶痛绝，但是却每天都在用的系统，可以说是一块璞玉。因为这些遗留系统帮你积攒了最有价值的东西：货真价实的用户需求，而且是怎么恶心用户都恶心不走的需求，简称刚需。抛开里面的技术不谈，这些业务需求，是值得我们一点点理解和掌握的。
+
+理解了这些需求，就可以找机会改造或者设计新的系统，来替代老系统。需要特别强调的一点是，这个前提和基础在于一定要深入理解这里面的需求。如果你仅仅是从技术和代码层面觉得系统烂，就想重新做一个，大概率做出来的系统还是会烂。因为你如果没有对业务需求的完整理解，新系统的架构设计大概率也会无法很好地容纳这些业务。
+
+老的系统也是因为架构设计没跟上业务的发展，才会被一会儿一个补丁、一会儿一个临时解决方案、一会儿一个hotfix，慢慢给弄得乱七八糟的。那么如果你在设计新系统的时候，不去全盘理解业务问题，设计更优化的业务模型，那么很可能会重复老系统的坑，疲于应对自己无法处理的业务需求，然后变成第二个大家眼中的烂摊子。
+
+举个简单的例子，业务需求是要在遍布泥滩和小水沟的地面行驶，而老系统则是造了一辆普通的车。时间久了，普通的车自然无法很好地应对这种路面环境，这里进水，那里生锈，还时不时抛锚，慢慢成了大家眼中的烂系统。
+
+如果你再重新造一辆车，用更好的引擎、轮胎、底盘。对应到软件上，就是用了最新的技术，比如升级SDK、升级各种软件包和技术栈、上云、用Docker等等。这些技术层面的东西，当然对车有帮助。而且新系统刚开始因为没有历史包袱，看上去好像还不错。但是慢慢地，这辆车也会和原来的车一样变成一辆烂车，因为传统的车就根本不适合在遍布泥滩和小水沟的地面行驶。
+
+技术升级无法解决架构的问题。对于遗留系统，很多时候需要考虑的不是升级技术，而是升级架构。比如面对遍布泥滩和小水沟的地面环境，就应该用履带车，而不是用传统的四轮汽车。
+
+## 总结
+
+程序员加班的现状，是由不同的原因造成的。我们能做的就是不断反思、好好利用加班，让加班的时间尽量短，让加班的时间尽量对自己的发展更有好处。
+
+如果是效率低，那就尝试提高效率。如果是有紧急任务，那就好好做、好好学。紧急的事情，是公司层面优先级更高的事情，更值得我们花时间做好。而对于现在被大家诟病的强制加班，也不能浪费了自己的时间。毕竟时间是自己的，一旦浪费了，损失的其实还是你自己。
+
+不浪费时间的好方法，就是做一些没有业务压力，但是可以提升自己的事情。比如去把白天不懂的事情弄懂，优化现有的系统，或者去遗留系统里淘金。这些都是在为自己的发展积蓄能量。即使这些事情都没得搞，还可以多和同事闲聊一下，沟通沟通。大家都在公司，又不忙，是多么好的一个沟通的机会呀。
+
+<img src="https://static001.geekbang.org/resource/image/ac/9d/ac981098d5d6d6ea224acc9ca1c3c99d.png" alt="">
+
+## 思考题
+
+你现在的工作需要经常加班吗？你是如何应对的呢？你加班的时候，效率高吗？
+
+欢迎在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/加餐/30 | 焦虑：程序员怎样才能越干越给力？.md

@@ -0,0 +1,105 @@
+<audio id="audio" title="30 | 焦虑：程序员怎样才能越干越给力？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fe/5d/fe70d09c53716df6accf903a3fb6aa5d.mp3"></audio>
+
+你好，我是臧萌。这两天看了半佛老师的一篇文章，有感而发。文章叫做[《为何有的职业后期不给力》](https://mp.weixin.qq.com/s/QaUoAC0wzpQ42Qj48HTL3Q)。
+
+你没看过的话可以去看看，当然，你要是懒得看半佛的原文的话，也不影响我这节课。简单来说，半佛老师从职业什么时候开始给力这个角度，把职业划分为了前期职业和后期职业。
+
+前期职业刚开始很给力，后面越来越不给力，比如工作多年后，竞争不过新人，薪资待遇无法持续提升等。后期职业则正好相反。半佛老师的观点我还是比较赞同的，但是也让程序员这个职业看上去前途堪忧。所以我有感而发，想来和你一块谈谈程序员这个职业的前途。
+
+## 焦虑着，也就习惯了
+
+如果我在二十出头的时候看到这篇文章，肯定会焦虑得不行。那时候的我，非常像是半佛老师文中那种，可以被公司用完就扔掉的零件。所以我那时候就一个理念：提高自己的性价比。简单来说就是努力工作，好好学习。
+
+“程序员是吃青春饭”的这个观点，其实当时已经有了。所以焦虑感肯定还是有的。而且当时看不清自己如何才能站住脚，稳扎稳打地向前发展。
+
+最近几年，反倒是没有那么焦虑了。
+
+一部分原因是焦虑惯了，这份焦虑感，让自己持续要学东西，跟上技术的发展。一段时间没学习没成长的话，就会感觉心里不安。
+
+就像我经常提的那句话一样：软件行业在快速发展，一个技术如果适应行业的发展，那么势必一直保持升级换代；而保持不动的技术，基本都是不适应行业发展了，慢慢地都会被淘汰。因为程序员见过太多潮起潮落，一直这样焦虑着，渐渐就养成了持续学习新技术、持续扩建自己技术领地的职业习惯。
+
+另一部分原因是，自己在误打误撞中，也算是走出了一条适合自己的成长之路。我觉得我在这条路上的有些感悟，对大部分愿意走技术路线的人还是有帮助的，在这里我想借半佛老师的文章为契机，在这篇文章里和你分享一下。
+
+其实我在专栏里，原本有一节叫《对不起，程序员这个职业可能无法混到退休》。但是考虑到内容连贯性等原因，这一节中的很多观点和内容被拆散到别的章节去了。那这节课，我们再多聊聊程序员这个职业。
+
+## 前期职业 V.S. 后期职业 ？
+
+半佛老师在文中，用前期职业和后期职业来给职业分类。前期职业的典型可以说就是程序员，后期职业的典型就是教师和医生。
+
+### 职业类型是后期发展更好的决定性因素吗？
+
+这里其实是有一点幸存者偏差的。其实仔细看看教师和医生，有多大的比例是在职业后期，成为了名师或者名医呢？
+
+教师和医生可以一直做下去，这点对比程序员确实是优势，但是如果没有混出点名气来，待遇也不会提升太多，这么一直混下去有啥意思呢？
+
+所以说，无论是程序员，还是教师和医生，想提升自己的待遇，肯定要提升自己的能力。这个过程必然是艰辛的，绝不是说选对了行业，就可以闭着眼睛随便怎么混都可以混出名堂来了。我们都在说，选择比努力更重要，但无论选择是什么，努力都是让一个人脱颖而出，提升自己职业发展上限的必要因素。
+
+### 软件行业的特殊之处
+
+借半佛老师的一个观点，软件行业是新行业，在爆发式发展中，缺人不缺钱。其实真就能力和产出而言，很多人是不值这个钱的，但是缺人，没办法。尤其是对于职业初期的人来说，多出几千块，其实就感觉挺多了。
+
+程序员很多时候也确实要加班，工作强度确实很大。所以对于能力略逊一筹的人，只要肯吃苦耐劳，很多公司也愿意给到行业标准水平的薪资。比如说我自己，我就觉得我刚毕业那会儿不值什么钱，因为什么都不会。
+
+种种因素，造成了程序员的起薪比较高。但是这也可能给程序员一种错觉，感觉自己就是值这么多钱。所以想当然地觉得，随着自己工作经验的增加，收入应该相应增长。但其实人才只会越来越多，程序员的精力会慢慢下降。所谓的工作经验，如果得不到市场的认可，自然无法获得更高的薪资。
+
+更残酷的一点是，正如半佛老师所说（我附议），程序员用到的技术一直在更新换代，老师和医生在立住脚之后，可以不用持续在自己的专业技能上投入太多，也能混得下去，但是程序员却不行。
+
+### 程序员这个职业更深层次的不同
+
+那如果程序员可以保持自己的技术，并且跟得上发展呢？比如说，一个程序员现在可以用主流技术，熟练的写着CRUD的业务代码，n年后依然跟得上主流技术，依然可以熟练地写CRUD的业务代码。不得不说，即使在这样的情况下，程序员可能依旧很难跟得上行业主流的薪资水平。
+
+为什么呢？很多人会说能力没涨，但是年龄涨了，精力慢慢不行了，自然不值那么多钱。当然这是一个原因，但是我觉得这不是主要原因。更主要的原因在于，软件行业需要程序员有创新的精神、有斗志、不安于现状。
+
+比尔·盖茨是微软公司的创始人，可以说他用Windows+Office软件改变了世界一点不为过。这里我借用比尔·盖茨的一句话：微软离倒闭永远只有18个月。
+
+你仔细思考一下这句话。很多人会觉得这句话是危言耸听，但是你纵观微软的发展历程，看看它经历过的那些低谷，这句话绝对是真实的写照。当然，微软最终没有倒闭，而且还发展得很好。有一点我想你肯定认同，那就是微软里绝对不是一群喜欢岁月静好，安于现状的人。
+
+所以，公司也绝对不想攒一堆发展后劲不足、安于现状的员工。这是在给公司的发展埋雷。从这个角度，你是不是对为啥年龄大的程序员容易被淘汰这件事，有了新的认识呢？
+
+当然，我并没有做过调研，去分析这些人被公司“优化”是什么原因。但是任何一个明智的软件公司管理者，都会淘汰后劲不足的人。简单来说，我相信很多公司都有或明或暗的规定，一线软件研发岗位，如果在某个年纪前无法升职到某个岗位，那么就必须淘汰。这是为了让公司保持活力的措施。
+
+## 程序员的路怎么走？
+
+在专栏中，我也尝试谈过我对职业分类的理解。当然这里只是谈论职业本身，并没有论高下的意思。也欢迎你在留言里说说你的想法。
+
+### 不同类型的职业
+
+首先是有些后缀为“员”的职业，比如售货员、收银员、操作员等等。这些工作的特点是技能要求少，而且技能本身不怎么需要更新。这些职业的工作成果，可以有非常明确的评判标准，工作内容也可以详细地用规定来约束。员工不需要去想怎么把工作做好，因为都已经规定好了。当然，这不是什么严格的分类，比如宇航员需要的专业知识、技能和素质，绝对比大部分职业要求都高。
+
+然后是后缀为“师”的职业，比如教师、医师、律师、厨师以及我们软件工程师等等。这些职业的一大不同就是，产出成果的过程很复杂，影响工作的因素很多，无法规定标准的工作流程，产出的成果没有统一的衡量标准，所以这类人才是无法批量培养的。从业者需要积累大量实践经验，才能形成一套自己的工作方式。
+
+就拿教师来说，如何培养学生，没有固定的套路；怎样才叫好学生，也没有统一的标准。这种类型的工作，就需要从业者发挥主观能动性，根据自己工作的经验，思考如何才能将工作做得更好。
+
+最后是后缀为“家”的职业，比如科学家、教育家等。这些职业更偏向研究方向。做开创性的工作，工作成果的不确定性更大，对从业者的专业技能要求是无上限的。如果对别的职业来说，创新是加分项，在各种“家”这里，创新是起点。
+
+### 程序员要怎么办？
+
+回到我们的主题，程序员的路应该怎么走呢？我有两个建议：第一，技术要不停地学。第二，脑子要不停地思考。
+
+技术这点我不再赘述了，技术一直在发展，不学的话，老的技术就被淘汰了。脑子思考什么呢？回到我反复强调的一点，那就是思考业务。思考自己所在的行业是在解决什么问题，问题是如何得到解决的。这是一个软件架构师必须锻炼的能力。无论我们有没有软件架构师的头衔，这都是我们不断进步所需要的养分。
+
+回过头来再echo一下半佛老师的一个观点，吃下的资源越多，要替代你的成本就越大。对于程序员来说，什么是资源呢？就是日常工作、做的项目，解决的问题等等。工作中亟待解决的问题是最宝贵的资源。能够理解这些问题，解决这些问题，那么收获的经验就是自己成长的后劲儿。
+
+有人吃了很多资源，确实是成长到了更高的水平，但有人却成长不够快。那么公司肯定更愿意把资源供给这些成长的更快的员工，期待他们可以助力公司发展的更好。
+
+软件行业确实残酷，可能没有哪个行业里公司的危机感如此强烈。如果微软距离倒闭永远只有18个月，那么别的公司呢？如果公司本身都需要保持奋进才能生存，又如何养着一群期待岁月静好的程序员呢？
+
+程序员不是一个能混的行业，混只能坑了自己。无论待遇如何，无论职位如何，问问自己：我今天学了点啥新东西吗？我今天悟到了点啥新道理了吗？
+
+## 总结
+
+根据我的实际体验，在软件行业中，一线程序员的高级人才还远没到饱和的程度。至少就现在的情况看，对标阿里P8左右的高级软件开发工程师，在市场上还是一人难求。在面对人才这个事情上，绝大部分公司都不差钱。所以我们需要担心的不是自己以后有没有地方呆，而是更应该注意如何才能让自己成长为人才。
+
+其实只要有合适的候选人，很多时候公司更愿意雇用高级人才，一方面是出于人力成本的考虑，对公司来说，能力强的人投入产出比更高。另一方面，这些人才已经用自己的实力证明了自己的能力和成长的动力，公司可以更放心地向他们投放资源。
+
+软件行业，真的不能混到退休。很多职业，即使是对于医生和老师这些职业，保持水准也是标配。一直保持水准做下去，并且提高自己则是高配，可以成为名师或者名医。但是对于程序员来说，提高自己才只是标配，超速地提高自己才是高配。长期来看，程序员的职业生涯，没有保持水准这个选项。
+
+时间不等人，技术在更新。你要学会锻炼自己的工作能力，做好技术与业务问题之间的桥梁，用好公司给你的资源，成就自己的成长。
+
+<img src="https://static001.geekbang.org/resource/image/0b/4d/0be907ff6b1ec0efcf1089c2ebd2704d.png" alt="">
+
+## 思考题
+
+在程序员的从业之路上，你有焦虑过吗？你是如何应对焦虑的呢？你是如何定义软件工程师这个职业的呢？你对职业分类的理解是什么？
+
+欢迎在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/加餐/31 | 数据观：在你眼里，数据到底是什么？.md

@@ -0,0 +1,103 @@
+<audio id="audio" title="31 | 数据观：在你眼里，数据到底是什么？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ff/46/ff0cec40d81a8e680a32dc9511a6bc46.mp3"></audio>
+
+你好，我是臧萌。这一节我来和你漫谈一下数据。工作这么多年来，我看待数据的态度，经历了从轻视、差不多就行，到重视和严谨对待的转变，甚至对数据有些敬畏。
+
+我相信很多同学在刚开始工作的时候，也是只重视程序不重视数据。程序员嘛，就是写程序的。数据结构、算法、设计模式，这才是我们程序员的战场高地。数据什么的，随便搞搞，别耽误我写程序就行。数据大不了删了重来。什么？不能删？那就迁移一下嘛。
+
+还有的同学在抛出自己的观点时，经常是七分靠直觉，两分靠猜测，一分靠经验。就是没数据什么事儿。当别人就某个细节问下去的时候，就开始拍胸脯拍脑袋，但就是给不出什么具体的数据。这时候，沟通基本就进行不下去了。因为当每个人的观点有冲突时，光凭直觉、猜测、经验都无法让对方信服。
+
+今天，我们就从软件系统和与人沟通两个方面，来谈谈数据的重要性。
+
+## 程序重要？数据更重要
+
+我们来思考一下这个问题，是我们设计的系统和写的程序代码更重要，还是数据更重要呢？相信很多同学都会下意识地觉得系统和代码更重要。但我觉得不然，数据其实更重要。下面我们来聊聊这个话题。
+
+### 数据是软件系统的根本
+
+我们来打个比方，数据就好像经济活动中的钱和账。数据在各个系统里的流动，就好像钱在不同的组织之间流动。无论是什么经济活动，做账都能把钱的流动一笔笔记清楚，通过账本，你就能够把经济活动给理解清楚。钱和账，是经济活动中最重要的。
+
+公司可以今天卖口罩，明天卖水果，但是账的重要性是不变的。就好像软件系统可以重构、重写，甚至可以换技术、换语言、换平台，这都不重要。重要的是软件系统要能把数据落地入库。只要数据能够按照之前的规则入库，软件系统怎么改都无所谓。
+
+在软件构造的虚拟世界中，数据是唯一的真实存在。尤其是那些以数据处理为目的的软件系统，更是这样。软件系统的目的就是把数据写入库。所以很多程序员戏称自己是专业的CRUD，从这个层面来说，CRUD才是根本。如果一个程序不CRUD，不读取数据，也没有数据落盘，那它跑起来有啥用呢？
+
+下面我们再从实际情况来看看，为什么应该重视数据。
+
+### 软件系统可以升级，数据很难升级
+
+对于很多偏数据的系统，数据架构设计比软件的架构更重要。数据的架构包括系统中有哪些实体、实体有哪些属性、属性分别是什么类型、实体与实体之间有什么关系、数据如何联动等等。当然也包括采用哪种数据库、数据库怎么分库分表等等。如果采用的是NoSQL数据库，则要考虑数据的访问模式、数据的可靠性、数据的可用性等等。当然两种数据库都要考虑如何应对数据的增长问题。
+
+为什么说数据的架构比软件更重要呢？升级软件系统，很多时候是可以测试的。只要最后输出的结果对，就没啥问题。给软件系统升级，还有很多方式可以让系统升级的影响更小，比如灰度发布、A/B测试等等。只要底层数据结构不变，底气就还有。只要程序没破坏数据，出了问题回滚就可以了。
+
+但是数据升级，难度就远远不止这样了。如果说给业务系统升级是给飞驰的汽车换轮子，那么给数据升级则是相当于是给飞驰的汽车换发动机。有时候还是得从内燃发动机换成新能源发动机，同时车还不能停。
+
+为什么这么说呢？因为给数据升级，有很多沉甸甸的问题需要解决。这里我随便列出几个：
+
+1. 数据如果不兼容怎么办？如果补的话，缺的属性值怎么补？
+1. 数据的结构变化升级，如何保证业务不受影响？要知道历史数据的大小，绝不是一个alter可以简单搞定的。alter一下数据库可能很久很久没反应，甚至直接挂了都有可能。
+1. 如何保证数据不丢失？
+1. 这种数据升级往往是没有回退可能的，或者回退的代价极高。如何能做到万无一失？
+
+删库的代价和删程序的代价是不能比的。删库给公司带来重大损失，甚至倒闭的例子有很多。但是把程序删了，恢复的挑战和风险要小得多。比如当年携程不小心把线上的程序给删了，但是真的恢复起来，也很快。对后续的业务，也没有任何影响。
+
+这里我们再强调一点。程序写得烂，比如跑得慢一点，设计得不好等等，这些问题很多时候并不麻烦，大都是稍微花点时间就能够修复，也不会造成什么损失。我们写程序的时候，尤其需要注意的是生成入库数据和写入数据的代码。在对这些程序代码进行更改的时候，更是要谨慎谨慎再谨慎。如果破坏了数据或者写入了脏数据就麻烦了。这点一定要注意，敬畏数据。
+
+### 数据是新时代的土地
+
+对于很多行业来说，比如AI、自动驾驶等，数据就是根基。再牛的算法和模型，也顶不过真实的海量数据有价值。算法可以招人来做，实在不行可以买。而数据呢，得自己积累，需要时间和渠道。想购买数据呢，也很难买得到，因为数据就是核心竞争力，谁会去卖自己的核心竞争力呢？
+
+我们可以把数据理解为新时代的土地，是一切的根基。有了数据，干什么都可以。没有数据，再好的种子，也没有发芽的空间。种子和土地，当然都重要，但是两者的分量不在一个级别上。数据够多，随便什么算法模型都能得出不错的结果。但如果没数据，能做到的事情就会很受限。可以说，数据起的是决定性的作用，是基础，是土地，算法和模型是地上开花。
+
+即使是算法和模型工程师，日常工作中很大一部分时间，也是在整理数据。俗话说：数据从来不是干净的。所以能把数据整理好，基本上就胜利一大半了。
+
+## 没数据，莫开口
+
+我们之前反复聊了沟通。今天我们从沟通的角度来看看数据。我们可以思考一下，我们在和同事沟通的时候，信息是否足够地准确和清晰呢？我们在沟通中，有没有提供或者接收到足够多的数据呢？
+
+### 先说数据
+
+我刚工作那几年，交流的时候经常无法传递准确的信息。比如被问起数据量增长了多少，我就说增加了一点；被问起数据丢失了多少，就说丢失了不多；被问起一行数据有多大，就说不太大；被问起有几个单元测试没过，就说没几个。有时候对方不再追问，我可能还感觉自己回答得挺好。
+
+有时候对方一个反问：增加了一点具体是增加多少？我就傻眼了，可能支支吾吾也说不出个所以然来。当然，数据我确实是看过，在我看来，也确实就是增加了一点，但是具体的数字没上心，被问起来，就很尴尬。
+
+可能有时候我心里还有点不平：一点就是一点，你管他多少，反正不多嘛。但是实际情况是，每个人对于一点、不多、不大、没几个这些词语的理解都是不一样的，很多时候这些都会掺杂进个人的判断。而交流首先应该提供事实，而不是个人的主观判断。当大家对事实都有了一致的认识之后，再各抒己见。
+
+再比如说单元测试，很多人看来，一个不过就是有问题的，也有的人心大觉得10%以内的就没问题。当然这个也和具体的项目有关系，可能某些项目的单元测试已经对环境有依赖了，有几个不过确实难免。所以，交流应该从具体有几个单元测试不过，具体是哪几个单元测试不过这些方面开始。而不是上来就给出自己的结论。可能有些测试特别重要，而且一定要求过呢？
+
+所以我渐渐地养成了给出准确数据的习惯。任何问题，先找出数据，罗列清楚，再去做自己的分析。准确、经过整理的数据是自带力量的。我们经常说：一图胜千言。这里除了具象的图画之外，我觉得图表也应该算在这个图里面。一份整理好的数据传递的信息，有时候胜过反反复复地讨论得出的结论。
+
+### 注明出处，交叉验证
+
+很多时候，仅仅是列出直接的数据还不够。为了更全面地理解问题，还需要注明数据的出处，甚至需要从多个数据源来交叉验证数据。数据是我们用来做判断的依据，对数据的态度要仔细认真，否则后面基于数据的讨论、结论和方案，可能都会是错的。
+
+注明出处是对数据负责。很多时候，罗列的数据可能并不全面。注明出处，方便你可以根据出处去对数据进行更详细的检查。而且不同的数据源，数据的可靠性也不一样。可以说数据源本身，就是数据的一种。
+
+关于交叉验证，我举个简单的例子。A服务调用B服务，那么要验证服务调用的增加量，自然需要对A服务对比过去一天的服务调用数据，为了更加全面，还可以增加上周同一天，上个月同一天调用量。同时呢，从B服务这一端，也可以做同样维度的考量，这就是从另一个数据源做交叉验证了。如果发现两边的数据有差异，那么就要先找出差异的原因，再来看调用的增加量。
+
+这里我再举一个生活中的例子。市面上有很多种牛奶：巴氏杀菌牛奶，高温杀菌牛奶，常温酸奶等等。如果要选一种牛奶喝，你会选择哪种呢？在做判断之前，你可能会觉得酸奶风味好，但是有糖热量高，在我去超市逛了一趟之后，我收集到了下面这些数据：
+
+<img src="https://static001.geekbang.org/resource/image/e3/30/e385d4b45c1f05d22ec3eb209f008b30.jpg" alt="">
+
+数据来源是商品外包装标注，这个来源还是可靠的。同时经过了多方对比，我看了三个主流的牌子的牛奶。这些数据是事实。酸奶是用乳酸菌消耗掉牛奶中的乳糖，所以无添加的酸奶肯定是酸的，因为乳酸菌会生成乳酸，这是常识。在这个基础上，我们可以去推断自己的结论。比如下面两个结论就是比较初级的结论：
+
+1. 纯牛奶的热量是差不多的，上下不会超过10%。无论是巴氏杀菌牛奶还是高温杀菌的常温奶。
+1. 酸奶的热量比纯奶更高，说明添加了很多糖以及其它增强其风味的物质。一般来说，会比纯奶高出20%~30%。
+
+有这样一张表格，是不是说出来的话就更有力量了？什么叫差不多？相差不到10%，就叫差不多。什么叫酸奶比纯奶热量高？高出20%~30%就叫热量高。
+
+## 总结
+
+数据是有分量的，对数据的辗转腾挪，都要费很大的劲。数据是有力量的，当你把数据整理好罗列出来的时候，甚至都不用说明自己的观点，就可以不言自明，让人无法反驳。数据是最难获取的，真正有价值的数据，钱是买不来的，只能靠自己积累。数据是软件系统的目的，和现实中业务相关的软件系统，无论业务逻辑玩的多花，最后都是要生成相应的数据，落盘为安。
+
+数据不会说谎，数据很难伪造，数据中最重要的一个属性就是时间，这让数据可以日积月累的积聚力量。小小的一张地铁卡，只有两个操作，滴，刷卡进站，滴，刷卡出站。如果一个人用地铁卡刷卡上下班，一次两次，数据确实没啥意思。
+
+但是如果这张卡积攒一年的数据，那么数据的力量就会爆发出来。它可以证明这个人有稳定的出行时间和路线，从而可以证明这个人有固定的工作地点和居住地点。这就是一个人信用的证明。这个数据，能伪造吗？一次两次，可以。长期下来，很难。
+
+数据是什么？让我们在工作中来重新思考这个问题，重新认识它吧。
+
+<img src="https://static001.geekbang.org/resource/image/93/c7/932f8803901f18b0e5c7f9ee003c8ec7.png" alt="">
+
+## 思考题
+
+我们每天都在跟数据打交道。你是如何看待数据的呢？你在设计程序的时候，有重视数据存储的设计吗？你在与人沟通的时候，有注意把支撑自己判断的数据都罗列出来吗？
+
+好，今天的加餐到这里就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，并把文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/开篇词/开篇词 | 学会如何工作，和学习技术同等重要.md

@@ -0,0 +1,59 @@
+<audio id="audio" title="开篇词 | 学会如何工作，和学习技术同等重要" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/96/9b/96892d4f3cff6c742000d02963909c9b.mp3"></audio>
+
+你好，我是臧萌，一名已经工作了14年的一线程序员。这些年来，我曾先后在Sybase、eBay、盛大、亚马逊、携程工作，目前是PayPal数据处理组的技术负责人。
+
+回顾我这14年来的工作，其实并不是一帆风顺的。我犯过一些常识性的错误，也对工作中遇到的事情有过迷惑和不解，自然而然的，也就吃过一些亏。后来我遇到了许许多多的程序员，发现无论是初级的，还是中高级的，都会遇到和我一样的问题。
+
+有次一群朋友一起吃饭，有个人说自己最近特别苦恼：
+
+“我现在在一家还不错的公司做后端开发，虽然公司是个很大的跨国企业，在业界也很知名。但是我们公司其实没有自己的产品，说白了，就是专门给人做外包的。我一开始想着公司不错，虽说是外包，但是能做不同的项目，我也能多接触一些东西。但是时间长了我就发现有点不对……”
+
+“我的同学都有自己的专攻方向，我却没有，我还要不要留在这里？有个同事跟我一起入职，但现在职级比我高，为啥升他没升我啊？”
+
+我认真想了一下，他的情况，他的问题都似曾相识。
+
+其实很多人这么迷茫，是因为陷入了“技术之外，别的不重要”的误区。事实上，除了赖以生存的技术本领之外，有很多看似很小的工作细节，也是造成不同人在职场上处于不同地位的重要因素。它会在你不知不觉的情况下，影响你的工作成果、个人成长以及方方面面。
+
+学生时期的我们都想知道如何学习，同样的，到了职场上，我们也要知道如何工作。这不仅仅包括技术方面的事情，也包括如何与同事协作、如何与上司沟通、如何正确地使用邮件等等一系列需要与同事打交道并付诸实施的事情。
+
+经过我这么多年的工作经验，我发现这些事情虽然琐碎，但其实可以大致分为4类，它们分别是职业素养、职业选择、职场情商和技术成长。这也是专栏的模块划分。
+
+在**职业素养篇**中，我们将会讨论如何培养良好的工作习惯。这些习惯很容易影响我们的工作效率和与同事之间的关系。比如，你以为邮件仅仅只是发送信息的吗？邮件的背后有什么样的工作逻辑？再比如，来自领导和部门的任务那么多，我们要如何根据任务的性质划分出它们的重要性？
+
+在**职业选择篇**中，我们将会探讨工作选择，以及与领导之间的关系。在就业形势如此严峻的情况下，我们选择公司要比之前更加谨慎。如何选择和自己“聊得来”的领导？他们都有怎样的特质？在此基础上，如何选择心仪的公司？你是更适合创业公司还是更适合成熟的大公司呢？
+
+在**职场情商篇**中，我们会探讨一个比较敏感的话题，那就是职场政治。我们都说，有人的地方就有江湖，相信不少人都会对同事关系感到头疼。比如最常见的，为啥领导更喜欢他？工作能力也许是一个原因，但绝不是唯一的原因，在这背后，个人的输出、看问题的方式和立场、工作的方式也同样重要。
+
+最后一个篇幅是我们最熟悉的内容，那就是跟**技术相关**的一系列话题。在提升技术能力的道路上，我们需要注意哪些坑？技术是一种手段，也是一种观念，技术观为何如此重要？它能指导我们什么？
+
+## 我是如何在文章中讲述这些内容的？
+
+问题已经摆出来了，那么如何带着你将每个问题都想透彻呢？
+
+我的做法是，以利益为视角，以换位思考为手段，以现实例子为场景来给你讲。而事实上，我平时其实也是这样思考问题的。每个人在职场中遇到的问题都是不同的，都会有具体的背景，因此，即便我已经尽可能考虑到了你可能会遇到的问题，但是也可能有漏网之鱼。怎么办呢？放心，这套思考问题的方式，换在任何问题上，都是完全适用的。
+
+<img src="https://static001.geekbang.org/resource/image/7e/fe/7e8aa25296a35f4bf85087e6ca149efe.jpg" alt="">
+
+### 以利益为视角
+
+当我们想要理解工作中的各种问题和各种事情的时候，不妨坦诚地从“利益”这个视角思考，弄清事情背后的“原动力”。别觉得“利益”是什么不好的词儿。公司存在的最主要目的就是创造利润，而我们工作最主要的目的就是赚钱。但是，除了看得见摸得着的金钱，我们可以从工作中获取的“钱”还有很多，比如升职、学习、实战的积累、好的成长机会、可以复用的资源、公司内外的声誉等等。
+
+可以说，利益贯穿了工作中的每个关键环节，是推动工作中几乎所有事情的原动力。这样想的话，很多时候事情的走向就会简单、明晰很多。
+
+### 换位思考为手段
+
+换位思考是一种很重要的能力，很多事情之所以不能理解，甚至看上去匪夷所思，其实就是因为我们没有把自己的屁股坐在在对方的板凳上，站在对方的利益考虑问题。
+
+你可能要说了，换位思考到底对我有啥好处呢？
+
+我觉得最直接的一点就是，换位思考可以帮助我们自己更高效地工作，因为它能有效地帮我们避免一些麻烦，在做事情之前预知随之而来的后果。
+
+### 现实的场景为例子
+
+我们都讨厌干巴巴的理论讲述和推断过程，那太枯燥了。因此，我在讲课的时候，充分考虑到了这一点。刚好，咱们课程中的问题，其实原本就是现实工作中的。所以我在讲述的时候，基本都是把这些真实的场景直接给你给放进来。
+
+在我开始讲之前，你可以去想想，如果你遇到了这个问题，你是怎么想的，你会怎么解决。然后，再看看我的做法，是不是和你的一样。这样对比的过程，你慢慢就能明白，我们的思考问题的方式，有啥不一样。我也欢迎，你对这些话题提出更多自己的想法，我们能够教学相长，共同进步！
+
+我一直坚信，学会如何工作，和学习具体的技术是同等重要的。我一直觉得，在职场中，我们每一步的经历都是有用的，我们在职场中遇到的每一个问题都不小。正是这一点一滴，才构成了我们的职场生活。
+
+你想想，我们人生的多少时间是在职场中度过的呢？你不想更有意义地度过职场人生吗？

极客时间专栏/geek/职场求生攻略/技术成长篇/22 | 学习观：程序员如何定义自己的技术舒适区？.md

@@ -0,0 +1,98 @@
+<audio id="audio" title="22 | 学习观：程序员如何定义自己的技术舒适区？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1b/62/1b329ba43ce0bcc7001f2067f92a5562.mp3"></audio>
+
+你好，我是臧萌。从这一节开始，我们就进入到了技术成长篇。不过在这篇里，我们不去深入聊任何具体的技术细节，而是围绕技术这个核心，和你聊聊如何看待技术，聊聊围绕技术的那些事儿。这是技术成长篇的第一篇文章，我来带你一起看看，我们应该如何定义自己的技术舒适区。
+
+## 程序员的舒适区
+
+平时我们谈论所处的工作状态的时候，都喜欢用舒适区、学习区、恐慌区这三个词来形容。我觉得这几个词形容得非常贴切。一个人处在舒适区，就是可以轻松愉快地应对自己工作，闭着眼睛都能把工作完成。学习区呢，就是工作有一点挑战，需要学点东西，但是也不需要费什么劲儿。恐慌区，就是看啥啥不懂，干啥啥不会，满满的压力，完全无法进行工作。
+
+### 不要相信舒适区
+
+其实很多职业都可以轻松打造出自己的舒适区。比如出租车司机、售货员、手机贴膜员这些职业，从技术技能角度来讲，花个几个月，就可以打造出自己的舒适区，然后就可以轻轻松松完成自己的工作了。
+
+但是程序员这个职业不同。程序员所在的软件行业是一个高速发展的行业，如果要把技术当做安身立命的本事，那么程序员就必须要一直学习知识，才能保证自己不被淘汰。下面我来说说为什么。
+
+假设现在你可以不太费劲地完成自己的工作，紧接着的一段时间，你也不需要学什么东西，也可以完成自己的工作，看似岁月静好，十分惬意。但是设想一下，在IT这么一个飞速发展的行业中，为什么没有给你所做的工作带来新的挑战？为什么不需要你们的技术进行升级换代？
+
+答案很可能就是你所在的公司，或者现在所从事的职业，已经处于淘汰、停滞不前的状态了。公司业务非但没有增长，可能还缩水了。这时候一切舒适、惬意、轻松所营造的岁月静好的氛围，其实都是表象。而表象下面，则是你很可能被淘汰。
+
+### 技术要么发展，要么被淘汰
+
+急速发展的软件行业，尤其是互联网行业，是一个不进则退的行业。业务量和业务的复杂度都在增长，留给开发的时间则是越来越短。为了满足这一切，技术的更新换代，甚至技术方向的完全改变，都是不可避免的。
+
+比如微服务架构，一个重要的目标是能解耦依赖，进而加快迭代。本着配置简单、从轻从快的思想的SpringBoot，很好地满足了微服务的要求，让原本部署在J2EE容器里的war包，变成了返璞归真的jar包，可以直接运行，吃过的都说香。
+
+最近几年风行的Docker，就颠覆了之前打包部署的方式，让打包部署上线这个过程简单又标准。同时与之一起的虚拟化技术，也颠覆了计算资源分配和管理。当然还有很多很多别的技术，比如熔断降级，监控等等，这些技术串在一起，犹如一条龙服务一样，解放了我们程序员的生产力，让我们可以更快地对业务需求作出响应。
+
+如果一个程序员现在还在使用Tomcat、web.xml、打包、物理机、拷贝部署war包，一方面说明公司对程序员的效率要求不高，业务压力不大，也就是业务发展的不好。另一方面，如果这个程序员想出来找工作，和面试官一聊，好么，考古级的技术栈，请问谁愿意要这样的程序员？
+
+我们不能拿公司用不到做借口，程序员就是要有学习的本能冲动，推动公司的技术进步，至少要让公司的技术能跟得上行业标准水平。所以，就好像北上广不相信眼泪一样，我们程序员也不要相信有舒适圈的存在。如果一个工作让一个程序员享受到了舒适圈待遇，那么就说明这个工作可能要凉，可以考虑换个工作了。
+
+### 学到手的技术会贬值
+
+其实从利益的角度来讲，我们程序员也不应该呆在所谓的舒适区。一个客观事实是，软件行业的技术在飞速地发展，也就是说，程序员现有的技术知识存量，会一直贬值缩水。
+
+长期来看，你觉得公司会为贬值的技术付出不变的，甚至还要增加的薪水吗？如果人才市场上，有性价比更高的人才，要的薪资更少，能做的事情更多，你觉得公司会不会考虑换人呢？
+
+所以说，也许老的技术应对公司的业务足够了，但是这并不代表一个程序员就可以守着老的技术，在一个公司一直混下去。只要技术还在进步，那么就会有人可以用更少的工作经验，更低的薪水，更好地完成一份工作。别等到自己的看家本领被淘汰了，才想起来学习。
+
+做一个合格程序员，就要拒绝技术舒适圈。但是拒绝舒适圈，不代表不能有一个舒适的状态。下面我们就来聊聊程序员的舒适状态。
+
+## 程序员的舒适状态
+
+程序员的生涯中，只有一直学习才是最舒适的状态。这里说的舒适当然不是指轻松随意，而是通过不断的学习，让自己可以轻松地应对工作，知道自己能够一直学得会、跟得上最新的技术。而自己的这种状态，可以带来发自内心的自信。这种技术自信，就是让自己舒适的根本。那要如何建立这种技术自信呢？我们接着往下讲。
+
+### 找到提供正反馈的学习目标
+
+其实关于学什么这个问题，我也走过弯路。立过很多flag，最后大都啪啪打脸。捂着“打肿”的脸，我就开始反思，为什么没坚持学下去呢？最后我得出了一个结论：学习没有形成正反馈。
+
+没有正反馈，就是指学了之后找不到用的地方，没有看到学习带来的好处，没有感觉到自己在成长，热情就开始大大下降。最后，心里随便找个什么借口，比如工作很忙啦、这个东西用不到啦之类的，也就弃坑了。
+
+最后，我发现我是一个比较懒的人，也发现工作确实让人“急功近利”，很难像学生时代那样心平气和地为学而学。后来，我总结出来一个寻找学习目标的法则：没事儿不找事儿，遇事儿不怕事儿。
+
+没事儿不找事儿，就是当遇到对你没太大帮助的技术，不去投入大把精力学它。只去简单了解这个技术的大概，细枝末节不去深究，只要知道它解决的问题是什么就可以了。
+
+这样做有两个原因，一方面，当一个技术名词频繁出现在你眼前的时候，不能完全无视它。我们得先知道它是干嘛的，通过什么方法和技巧，解决了什么问题。不到这一步，你就是固步自封了。接下来，你就得想想在自己的兴趣和工作的范围之内，这个技术能否用得上，用上了是否能带来好处。如果不能给你带来好处，那就先不去管它。
+
+遇事儿不怕事儿，就是说每当你遇到任何需要解决的技术问题，不要绕着走，要记下来，挤时间吃透它。因为根据我的经验，你遇到过一次的问题，就会遇到第二次第三次。与其让问题一遍遍地欺负自己，不如自己主动点，第一次遇到问题的时候就别认怂，直接学起来。这样的好处就是正反馈来得很直接，成果立竿见影。
+
+对比上一条说的“没事儿不找事儿”，如果你工作中遇到问题或者某个细节不清楚的情况，正愁不知道学啥呢，忽然一个问题“千里送人头”。这时候还等啥，送上门的不收割，难道还放走了不成？
+
+在这里我举个自己的例子。大概在10年左右吧，Hadoop在国内已经开始火了。我的心也躁动得不行，大数据、分布式、Google论文这些词儿都在撩着我。于是我就立了一个flag：“今年学Hadoop”。结果毛都没学，只是知道了一个HDFS和Mapreduce的基本概念，一丁点实操都没有。
+
+忙吗？那一年其实不算忙。就是自己懒，而且内心就知道这玩意学了用不上。后来过了几年，我换了工作，有一个工作要用到Hadoop和HBase，从把集群折腾起来了，到用客户端API跑通POC，总共也没用俩星期，期间还做了别的很多工作。
+
+无数的经验告诉我，有需求的情况下，知识的供给才是有效的供给。知识解决了问题，就有了正反馈，学习的飞轮才能持续地转下去。还有就是人的潜力是很大的，deadline才是第一生产力，哈哈。
+
+### 有效的学习姿势
+
+前面说的方式也有一个问题，就是可能无法系统地学习知识。如果只是东一榔头西一棒槌的学，知识会很不成系统。这样不是一个好的学习姿势。我总结出一个学习的方法，就是主动花功夫构建骨架，被动增加知识点。
+
+主动花功夫构建骨架，就是指有大的方向不会，就选个趁手的资料，有计划成系统的学习。任何一门新技术，都要先经历这个过程。比如Spring，核心就是管理对象的创建和依赖关系。你得深入了解Spring内部机制，了解Spring是如何做到这一点的。
+
+如果再往细了说，可以从以下五个点来构建骨架。
+
+- 核心架构设计：这个技术有哪些核心的架构设计。架构设计决定了技术的特征，也决定了这个技术的优劣势和适用的场景。比如Java是基于字节码和虚拟机的，HBase的本质就是一张排序的大表，Aerospike本质就是一张大的散列表等等。
+- 功能模型：这个技术有哪些功能，功能的接口是什么。
+- 状态模型：系统在运行时有哪些状态，状态之间的变化原因是什么。
+- 数据模型：这个技术是怎么组织数据的，是怎么处理数据的。
+- 线程模型：这个技术有哪些线程，分别是做什么的。
+
+构建这个技术骨架，我大部分都是靠自己的业余时间来完成的。在我日常工作中，如果统计下来算的话，应该有30%到50%的时间在学习。其中很大一部分都是在学习一些细碎的小东西，比如某个API或者某个library怎么用之类的。这些东西，都是技术骨架上的点缀。有了自己的技术骨架，接下来就可以等着问题上门了。问题送上门一个，收割一个，so happy。
+
+技术骨架的重要之处还在于，它一方面可以让我们学习相关的新东西时能抓住精要、触类旁通、学得更快更准。另一方面，技术骨架可以让我们学的知识成系统成生态，这样我们才能记得更牢固，用得更顺手。
+
+## 总结
+
+程序员的舒适区，其实就是自己的技术领地。技术领地越大，舒适区越大。当你精通Java了，Java就是你的舒适区。当你听到一个Java的问题，心里就很舒适，因为你知道这对你来说根本不是问题。
+
+技术只有被淘汰和正在进步两种状态。即使是网络，操作系统这些基础，也在不断地进步。随着IPv6的普及，原来IPv4的知识就被淘汰了。随着计算机硬件的发展，操作系统里的CGroup也应运而生，可以让我们更好地管理资源的分配。即使你原来精通网络，精通操作系统，如果几年不学习，回过头来也会发现自己的知识已经过时了。
+
+所以说，程序员就是要在自己的旧领地被慢慢淘汰的同时，积极地去开拓自己的新领地，让自己的舒适区不断扩大。<br>
+<img src="https://static001.geekbang.org/resource/image/96/de/96d69ee22bce1293c3b9b724864dd7de.jpg" alt="">
+
+## 思考题
+
+这篇文章，可以说是我这个懒人关于“如何打造技术舒适区”的一套方法。你是如何学习新技术的呢？哪些技术是你领地呢？哪些技术让你觉得自己可以舒舒服服地解决相关问题呢？
+
+欢迎你在评论区写下自己的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/技术成长篇/23丨技术观：做程序员，技术观为何如此重要？.md

@@ -0,0 +1,101 @@
+<audio id="audio" title="23丨技术观：做程序员，技术观为何如此重要？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c9/dc/c921f4a79d5e34ac023e95f082749fdc.mp3"></audio>
+
+你好，我是臧萌。在这节课里，我想跟你谈谈我的技术观。
+
+首先从技术的角度介绍一下我自己。我从业十四余年，除了担任过几个月的管理职位之外，其他时间我都是做一线的编程工作，并且以此为乐。这十四年来，我做的东西主要是偏产品、平台和框架，支撑上层业务，因此在工作中对代码和技术都是略有要求的。这些年来我也一直在学习技术，有的是出于工作需要，有的是单纯出于兴趣。
+
+技术的重要性当然不需要强调，但是有时候物极必反，会让人迷失在技术中。这么多年来，我总结出这么两点技术观。第一，**吃透技术**。你在工作中，用到的技术必须吃透。第二，**需求至上**。技术对你来说只是满足业务和用户需求的手段。
+
+这两个观点可谓我的肺腑之言。我喜欢做开发，学技术，但是我并不认可技术至上论，从来不认为技术可以凌驾于需求之上。我和很多人交流过，包括和我一样多年来一直从事一线编程工作的人，以及一线程序员的管理者，他们都很认同我的观点。
+
+谈技术观，首先要和你聊聊软件工程师和技术的关系，这样你可以对这个问题有一个更深入的理解。毕竟，我们就是要和技术打交道的。
+
+## 用技术把事情做成
+
+程序员的大名是软件工程师，也就是说，我们是做工程的。工程就是要落地，要把一件事情做成，这是最根本的，也是软件工程师价值的体现。不管技术有多牛，只要对事情落地没帮助，那都是空气。公司为什么雇佣我们？这不在于技术本身，而在于我们可以用手中的技术，把问题搞定，让项目落地。
+
+软件开发工程师，其实和厨师一样，一个是用技术写代码做软件，一个是用厨艺做菜品。软件开发的技术也是一样，菜刀就是Java，炉灶就是数据库，炒锅就是网络，要做到融会贯通地使用，还要不忘初心，把事搞定。
+
+简单说了一下程序员和技术的关系，下面我们再来详细说一说我技术观中的两个方面。
+
+## 吃透技术
+
+技术是一个程序员安身立命之本。既然是看家的本领，那就必须吃透。那么问题来了，如何吃透呢？
+
+我自己的习惯是，把用到的主要技术，再接着深挖一层。只有深挖一层，才能让我感到安心。我自己定义的“吃透的原则”大致有三条：
+
+1. 熟练使用：熟练使用技术解决问题，深谙技术的各种坑；
+1. 精准掌控：明晰技术的能力边界，准确判断技术能否以及如何满足某个具体的业务场景；
+1. 知根知底：知道技术的底层实现和关键细节，如果让自己做，可以大致做出一个来。
+
+怎么理解这三点呢？
+
+举个我自己的例子吧。我大学学的是Java语言，大一会写Java之后，我确定了两条进阶路径：一手抓“写”，一手抓“学”。
+
+我当时做了一个自己的小网站，做了计算器、拼图游戏、聊天程序、联机对战的俄罗斯方块等等各种杂七杂八的东西。我还熟悉了各种Java的类库和工具，比如JDBC，Tomcat 4，网络，文件，Java Swing/AWT，Applet，Graphics等等…我开始和各种乱码作斗争，和各种环境与配置做斗争，练就了一双高度近视但是能从万千个O中找到0的火眼金睛，并乐此不疲。
+
+在那个互联网和电脑刚刚开始普及，Java在中国还是小众的时候，学习资料的获取还是存在一定限制的，主要靠学校图书馆。就在我学得顺风顺水的时候，我遇到了这本书《深入Java虚拟机（原书第二版）》：
+
+<img src="https://static001.geekbang.org/resource/image/2e/24/2e88fb07ee047e4c774b8c4d08894924.png" alt="">
+
+说实话，我从图书馆借来的书，看不懂的有很多。什么EJB之类的，我感觉跨度太大，就弃坑了。但是这本书，我觉得我应该要看懂，这就是我要深挖的那一层——我要知道Java是怎么跑的。
+
+那个年代学习并没有这么便捷，一切只能靠自己硬啃。于是整个大二，我借了还，还了借，一年下来，反反复复地看，只能算是勉勉强强看了3章。这本书有461页，不包含附录有21章。这本书是我大二的痛苦回忆。
+
+好在啃过前几章之后，也可能是后面的内容简单了，也可能是自己写得多了悟到了。大学毕业前，我把这本书基本啃完了，这才算是对Java有了一个系统的理解。
+
+工作以后，才算是踏上了吃透Java的漫漫旅程。工作之初，可以说是看啥啥不懂，用啥啥不会。这时候算是开荒，疯狂学习各种框架、类库、工具。紧接着，我工作中遇到了各种千奇百怪的问题。我的态度是，能绕过就绕过，先解决问题。这样的目的是能够在不背着业务压力，不受时间约束的情况下，有充裕的时间去找出问题原因。
+
+程序出问题，肯定有原因。我坚信这一点，需要挖多深就挖多深，是为了避免以后再糊糊涂涂地趟进同一个坑。不放过log里任何一个无法解释的异常，不放过任何一个看不透的细节。当然，这里学的有些东西，并不是为了使用，而是为了知其不可为而不为之，或者是为了不被不知其不可为而为之的人坑，是不是有点绕，哈哈。
+
+最后，我再结合这段经历做个总结，让你更直观地感受一下各个阶段的时间线以及需要做的工作。
+
+1. 熟练使用：需要做到只要面对Java 的问题，你都不觉得难。
+1. 精准掌控：知道 Java 和 Java 生态的长处与短处。看到一个需求，直觉判断出可行性，难点以及可能出问题的地方。
+1. 知根知底：以JVM为分割线，熟悉其上的类加载器、字节码、内存分配和内存模型这些 Java 生态的基石。这样做一方面是为了你能够进一步精准掌握Java。另一方面，Java 作为一个设计优秀的语言，在设计自己的 DSL 的时候很多地方是值得参考的。
+
+我面试时，如果看到有同学的简历上写着“精通某项技术”，我就会问一个标准问题：“使用这个技术的时候你有遇到过什么问题，踩过什么坑吗？”如果这个同学的回答非常干瘪，那么就说明面试者只做到了第一点，也就是熟练使用。因为如果深入地长期使用一个技术，肯定会有业务需求和技术能力边界的各种摩擦和冲突，踩过大大小小的各种坑。当然没有遇到问题自然是好的，那只能说明这个面试者很幸运。但是少了挫折，也让人距离精通这门技术，差了点火候。
+
+## 需求至上
+
+需求至上，是我的第二个技术观。需求一般来自于用户和业务。
+
+我这里说的用户，不是最终用户，而是我们做的软件系统的用户。用户可能是同一个公司的不同部门，也可能是对口的业务公司。绝大多数情况下，用户非常明确地知道自己想要什么，非常明确地知道自己想要解决的问题。
+
+那么技术到底如何支撑业务呢？
+
+我的看法是，多和用户以及业务方交流，理解他们的需求，才能更好地施展技术。而不能本末倒置，自己想做成什么样，就做成什么样。业务方不理解，那是他们low；用户不会用，那是他们笨。如果抱着这种态度，那么用再好的技术也做不成事情。
+
+但沟通自然没那么简单。
+
+刚开始你和业务方以及用户交流的时候，会有鸡同鸭讲的感觉，但是请相信，随着交流的深入，观点的碰撞，作为程序员的我们，会更能够理解自己所做事情的价值，也更能够选择正确的技术和解决方案。
+
+这也是为什么很多理论派、技术流的产品，很难获得市场。但是很多实干派的产品，却可以赢得市场。技术流的产品，做出来一般都很酷，但是却把用户的需求和实际的业务问题放在了一边。而实干派，就是立足于解决用户的问题，满足业务需求，所以更容易赢得市场的认可。
+
+举个例子，为什么Google在云计算市场战不过亚马逊？在我看来，Google由于太过于技术流而脱离了需求。
+
+亚马逊在2006年推出了AWS，最开始的产品是IaaS、S3。当时IaaS尚属于新事物，但是和传统的虚拟主机差不多，IaaS的易用性和扩展性，大大地方便了很多公司，满足了他们对于计算和存储的需求。
+
+Google在2008年推出了Google App Engine（简称GAE）。而Google这一步，迈得有点大。在GAE上写程序，必须用Google自己的SDK，存储要用Google自己的KV数据库，看起来很炫酷，但是这些炫酷，甚至可以称为是“划时代”的东西，能赢得技术拥趸的叫好，却很难赢得公司的叫座。为什么？因为不实用嘛。
+
+亚马逊胜就胜在“实用”二字。各种方便实用的功能，都做到用户心坎里去了。监控，报表，工具怎么用怎么顺手，怎么玩怎么顺心。而GAE，用“华而不实”形容并不为过。回过味之后，Google现在也回来好好做IaaS了，但是基因难改，各种边边角角的地方，都能闻出华而不实的技术派味道。
+
+还有很多小例子。比如一个公司，按照自己理解的业务方向，去解决自己认为有价值的问题。公司产品做了三年，拿出来给用户一看，用户说压根就不是他们想要的样子。比如更小的事情，各种监控功能做得花里胡哨，但是对于用户最关心的销量指标week by week对比，却要用户开两个浏览器去人肉比。
+
+这不是逗呢嘛？
+
+做技术一定要懂业务，也就是要理解我们要解决的问题。你一定要懂得，怎么用技术为业务创造价值，而不是给业务添乱。
+
+## 总结
+
+我们除了要死磕技术之外，还要理解技术所服务的业务领域，理解用户的需求。这样，才不至于在死磕中，碰晕了头，犯想当然的错误。双管齐下，才能进一步理解自己工作的价值，朝着有价值的方向前进。
+
+对待技术，我们不妨换个角度，不要认为自己是在学习技术，而应该这样认为：日常的工作都是在锻炼解决问题，而非技术。技术只是顺带学的。工程师的核心能力，是理解问题和解决问题的能力。
+
+<img src="https://static001.geekbang.org/resource/image/02/70/02ce3d9ff26df0abf60a9961cd320870.jpg" alt="">
+
+## 思考题
+
+不知道你看完这篇文章有什么感想呢？你觉得你吃透技术了吗？对于你现在常用的技术，如果让你自己去实现，你有思路吗？你理解自己所做的系统的需求吗？
+
+好，今天的课程就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，并把文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/技术成长篇/24丨技术观：程序员在技术的成长之路上，有哪些陷阱？.md

@@ -0,0 +1,126 @@
+<audio id="audio" title="24丨技术观：程序员在技术的成长之路上，有哪些陷阱？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/85/66/857a8200914ba0f9585f08ebc58e0166.mp3"></audio>
+
+你好，我是臧萌。今天，我们对上一节课做一下延伸，基于上一节课中抛出来的技术观，今天我们来看一下在我们实际工作中，关于技术的事儿都有哪些陷阱。
+
+为了给你增加一些代入感，我们首先来看一个厨师的例子。假设你是一个餐厅的老板，要招一位厨师。
+
+厨师小白来面试了，土豆丝切得要么像吸管一样粗，要么像绣花针一样细。炒出来的土豆丝一盘偏咸，一盘偏淡，仔细一看土豆皮还没削干净。
+
+厨师小稳来面试了，只见他麻利地抓起土豆，开始削皮切丝，青椒去瓤切条，大火爆炒。10分钟后，热气腾腾香气扑鼻的土豆丝就出锅装盘了，一尝，嗯，标准的饭馆儿味。小稳憨厚一笑，道：“如果有干红辣椒，用油一爆，那就更棒了。”
+
+厨师小洁来面试了，对着后厨一堆菜打量了半天，眉头拧成个疙瘩，嘴上啧啧叹道：“这个土豆不行呀，大的大小的小；这辣椒也不行，得是刚刚摘下来的；油也不合适，得是古法压榨的菜籽油。”吐槽了半天，像是受了天大的委屈一样，磨磨唧唧半个小时才“勉为其难”地炒了一盘土豆丝，上口一尝，味道只能算一般。小洁皱着眉头地说道：“这些材料不大行。”
+
+厨师小高来面试了，把土豆削一削切一切，一斤土豆就用半斤。土豆丝呢，切得倍儿棒，每根都是1mm粗，6cm长，误差不超过0.1mm，堪称艺术品。土豆丝炒好之后，小高把土豆丝一根根地码到盘子里，一“根”不乱。3小时后，凉透的土豆丝上桌了。
+
+厨师老遗来面试了，进后厨第一句话就是问你：“咱这儿有土灶吗？烧柴火、拉风箱的那种，我用得惯。”你遗憾地表示，这个真没有，以后也不大可能会有。老遗叹了口气扭头走了，边走边念叨：“燃气灶烧出来的菜不香。”
+
+现在你是老板，你会选择雇用哪个厨师呢？厨师嘛，自然要有刀工、配菜、烹饪、装盘等技术。但是最终的目的，就是要利用一切合理的资源，做出色香味均衡的菜肴给食客。
+
+所以小稳自然是没得说。
+
+剩下四位的毛病，相信你也已经心里有数。其实他们身上体现的问题，就是我总结的技术人常犯的四种错误：
+
+1. 技术不扎实，不思进取；
+1. 技术洁癖；
+1. 一味追求新潮流，新技术；
+1. 固步自封。
+
+下面我就谈谈这四种错误该如何纠正。当然，我要强调一点，不管是哪种问题，都得充分发挥自己的主观能动性。需要你由内而外地纠正，自己认识到错误，发自内心地想改正。
+
+## 技术不扎实，不思进取
+
+软件行业的“小白厨师”，技术能力已经差到无法产生有效生产力的程度。
+
+事实上，“小白”是一个相对概念，不是绝对概念。也就是说，在人生的不同阶段，我们都有可能是一个“小白”。
+
+大学刚刚毕业的天之骄子，到公司变成一个普通员工，是小白；从之前的业务骨干，转到新的工作方向，也是小白。小白并不可怕，怕的是一直“白”下去。如果没有危机意识，惯性地以为自己可以凭借之前的地位和高度，就能够完全掌握新的工作内容，这是很危险的。
+
+当我们换一个工作或者方向的时候，都是从小白开始，这时候的我们生产力很低，甚至为负。我们一定要意识到并且承认这一点，积极主动学习、补齐短板，至少做到合格。那么成为小稳，指日可待。
+
+## 技术洁癖，满眼问题
+
+软件工程师中的“小洁”，满眼都是问题，看到的都是各种先天不足。没错，每个公司，每个项目都有现实的问题。也许这个项目不能用Oracle只能使用MySQL；也许这个项目不得不临时调走几个人，导致团队人变少了；也许这个项目不能使用Spark只能用老掉牙的Hive；也许这个项目没有预算买Zing JDK……
+
+如果只能依赖先天优势，看到不足就无从下手，那我们的工作还有什么意义？我们的价值又从何处体现？
+
+身为软件工程师，我们拿这份工资，就是要解决这些问题的，而不是去一味地抱怨。软件工程师就是要在现有的条件下，结合自己的技术，解决问题，把事情办成，让项目落地。当然，并不是所有问题都能靠软件工程师解决，但是能解决到什么程度，就很考验一个软件工程师的功力了。
+
+项目在落地的过程中，外部条件不如意者，十之八九。软件工程师的职责就是要找出关键点，给出合理的期待。
+
+如果没有Oracle，就找方案，让数据在MySQL上也能有足够的安全性和可靠性；如果临时有人被抽调走，就把项目排出个轻重缓急，不重要的事情先放一放；如果不能用Spark，就看看是否可以把数据刷新的速度从小时级变为天级；如果没有Zing JDK的加持，就试试把P99增加到500ms，如果这个数值不理想，可以后期调优。把这些数据和相关人等沟通好、协调好，并得出一个可行的方案，才是软件工程师的价值所在。
+
+小稳厨师就没追求吗？他也想炒出更完美的炒土豆丝。但是他知道，有没有干辣椒，并不是炒土豆丝的必要条件。你作为老板，面对小稳圆满完成工作之后提出的请求，和小洁什么都没做就提出的一大堆请求，你会考虑满足哪个的要求呢？答案不言自明。小稳已经证明了自己，老板当然会选择给他更多信任。
+
+张口闭口就是“这也不行，那也不行”的人，其实根子上，就是自己解决问题的能力不行。
+
+## 避免使用不必要的技术手段
+
+这个观点的意思其实很明确，就是当你在工作中使用一项技术，要用保守的态度，要以投入产出比做衡量，而不是根据自己对技术的偏好和冲动乱来。小高和老遗就是正反两个极端。
+
+我们来看看这两种态度。
+
+### 学了新技术，内心很骚动，不用不爽
+
+首先是小高厨师，看得出来小高厨师是有点骄傲的，程序员也都是有点骄傲的。感觉我们技术人就像魔法师，看不起不会技术的“麻瓜”。而学会新技术的人，又按耐不住显摆一下的冲动。
+
+“学了本领，不显摆显摆别人怎么知道我会呢？”于是在这种心境下，就很容易小题大做，杀鸡拿起宰牛刀。有些技术不错的年轻人，就是因为做事情的态度有问题，才导致自己发展受限。
+
+比如说，Scala这个语法糖好甜，我要把项目都转成Scala的。Guava新版里这个API看着不错，我用用看。
+
+结果呢？语法糖是糖衣“坑”弹，各种想当然的接口和Java并不兼容；Guava是Google的，Google是业内典型的视兼容性为无物的公司，新版Guava和老版API不兼容，只能回退。当然还有更骚的，比如使用库中internal的API；使用实验性质的JVM功能；将系统架构在一个连文档都没有的新功能上等等等等。
+
+各种骚操作，不一而足。炫技一时爽，全组陪你加班到天亮。
+
+其实很多时候，觉得自己一身本领无处施展，主要还是因为自己学艺不精，没学到位，不知道怎么正确地施展。下面我们就看看，怎么拯救炫技的厨师小高。
+
+小高无疑是对技术有追求的，刀工不错。但是他浪费了一半的土豆，而且一道本可以10分钟就搞定的菜，生生用了3个小时。小高的问题是，本末倒置，而且功夫没到家。
+
+用户要的是一道炒土豆丝。速度快，味道好，这是红线，不可逾越。小高要做的，就是精进自己的技术，在保证十分钟可以搞定的前提下，再保证土豆丝一丝不乱的造型，不浪费那么多土豆。这时候，小高的这道炒土豆丝将会是饭店的一大特色。否则，就是一道摆设了。
+
+回到我们在上文中举的例子，面对这些情况，又该怎么办呢？
+
+Scala可以用，前提是吃透，能提高大家效率，不增加集成工作量。Guava可以升级，但是要先好好阅读文档，检查兼容性问题和整个项目的依赖关系，确保升级没有问题。而内部API这些，真的不要主动用，只有在救火的时候，才可以作为临时的解决方案。
+
+再举一个例子。我在12年的时候买了一个谷歌 Neuxs 3，那时候它就支持前置摄像头面部识别解锁。但是体验是怎么样的呢？嗯，10次里面大概有3次是失败的，更不要提光线和角度不完美的情况。直到5年后，也就是2017年，苹果才推出了成熟的面部解锁方案。
+
+所以说，一个技术的出现和一个技术可以用在生产上，完全是两个概念。一个技术在成熟之前，在确定能给用户带来价值之前，不要盲目使用。不要沉浸在自己的技术世界里不可自拔。谷歌不差钱，可以搞酷炫的东西，培养自己技术急先锋的人设，但是，普通公司并不愿意付出这个成本。
+
+其实很多时候，老板宁愿雇佣小白，也不愿意雇佣小高。只要愿意干，技术不行可以练，不能炒菜可以先练习切菜、配菜，但如果做事情的态度出了问题，很难由外而内地改。但这一点也只能由小高自己去领悟（想让老板容忍一盘土豆丝炒了三个小时，除非厨师是老板的小舅子）。
+
+在用宰牛刀杀鸡之前，不妨先问问自己，宰牛刀法练好了吗？
+
+新技术要好好学，吃透了，才能用得对，用得好。用之前问问自己，使用这个技术的代价是什么？价值是什么？事情值得做吗？我是为了解决实际的需求，还是为了满足自己那颗躁动的心？
+
+### 固步自封的遗老遗少
+
+和小高相反，老遗厨师代表的另一个极端——固步自封。用自己N年前的观点，衡量现在的事物，拒绝接受事物的发展，对技术存有刻板偏见，倚老卖老。
+
+举个例子，我有个朋友跟我吐槽，说他的经理眼里只有C++，看不起Java，张口闭口就是Java慢，Java垃圾，他当初写C++怎么怎么地。听说Impala是用C++写的，就找人研究，要替换公司里的Hive，又听说百度用C++重写了一遍Hadoop，就又来了精神。可能他觉得自己有金手指吧，一个手指就能搞定数据迁移，客户端升级和测试。
+
+我听到后，笑得都合不拢嘴了。必须承认C++是一门优秀的技术，我认识很多Java的大牛，本身就是C++的大牛。技术本身没有好坏，只有合适不合适。既成事实是，当今整个基于JVM的大数据生态既完整，又成熟稳定。而且公司在有一套Hadoop平台的前提下，只有一个语言的遗老才可能因为语言原因，想要去替换平台。
+
+据说等他离职了，也没完成他的夙愿。
+
+技术是会发展的，以前有的缺点，不代表未来一直都有。对技术不要有无谓的偏见，技术就是工具，就是用来解决问题的。一项技术能够在行业中流行，必定是有原因的。若是固步自封，早晚会被淘汰。现在还在念叨“燃气灶烧出来的菜不香”的厨师，已经不适合在饭店做厨师了，可能农家乐里还有他们的一丝生存空间。
+
+## 总结
+
+中国有句话，叫学好数理化，走遍天下都不怕。其实我觉得应该说成“用好数理化，走遍天下都不怕”。
+
+软件工程师靠技术吃饭，但是世界并不是绕着技术转的。我们要对技术要有追求，但是要分清什么是自己的追求，什么是公司的追求。除了极少数脱离了低级趣味的公司之外，绝大多数公司雇佣软件工程师的目的，是为了创造价值。
+
+技术是手段而非目的，炫技很没必要，固步自封必被淘汰。技术的目的是解决问题，而非带来更多的问题。
+
+当然很多公司会鼓励大家学习新技术，还会举办类似“编程马拉松”的活动。这是因为技术公司基本都看到了，如果新技术用得好，很多时候可以带来生产力的提升。这么做也是变相地做人才和技术储备。公司鼓励你抬头看天，但是并不鼓励你拿着公司的钱，坐热气球去看天。
+
+态度只能由内而外地改变。如果不是自己认识到问题，是不可能积极主动地改正的。不要让自己对技术错误的态度，成为职业生涯的绊脚石和阻力。
+
+当然，你可能会有疑问：说得这么冠冕堂皇，自己真的能做到吗？确实人都有不自觉的时候，但是做得不对，和不认为自己做得不对，是两回事儿。我们要做的就是时常审视自己。吾日三省吾身。不怕自己犯错，只怕犯错不改。
+
+<img src="https://static001.geekbang.org/resource/image/d8/d1/d83e88166d9945e506521a210c2d69d1.jpg" alt="">
+
+## 思考题
+
+最后问你几个小问题。在自己成长的路上，你有没有经历哪个阶段，是文中的小白、小稳、小洁、小高或者老遗呢？你现在对技术的态度，和这篇文章有没有冲突呢？你还见过哪些技术路上的陷阱呢？欢迎你在评论区讨论。
+
+好，今天的课程就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，并把文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/技术成长篇/25 | 系统架构：如何从写代码的程序员，成长为软件系统架构师？.md

@@ -0,0 +1,102 @@
+<audio id="audio" title="25 | 系统架构：如何从写代码的程序员，成长为软件系统架构师？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/66/6b/66fe53769dcee9d612c6f10a7c9a7d6b.mp3"></audio>
+
+你好，我是臧萌。这一节，我们来聊聊软件系统架构师。软件系统架构师简称架构师，它可以说是每个做技术的程序员心向往之的职位。这个职位对于很多人，还有些许神秘的味道。在这节课里，我就来和你谈谈我眼中的软件系统架构师，它其实并没有那么神秘。
+
+## 软件系统架构师是干什么的
+
+### 架构师的输入
+
+软件系统架构师的工作，有两个输入。一个输入是要解决的问题，这里说的问题，可能是一个系统，可能是某一类相似的业务等，我们也可以把它认为是一个产品。另一个输入是为了解决这个问题，所能使用的资源。这里说的资源，包括系统的工期、团队和公司的技术储备。以及人才储备、业界可以使用的技术、公司的基础设施等等。
+
+也就是说，在架构师的输入里，一手是问题，一手是资源。当然，这两个东西不是一步到位的，不会有人准备好送给架构师，而是架构师要自己去深入了解和摸索。
+
+### 架构师解决问题的理念
+
+随着对问题理解的深入，架构师会在脑子里慢慢形成自己对问题的理解。这时候，架构师作用中最重要的一点就会慢慢形成，那就是架构师解决问题的理念。换句话说，就是架构师如何定义这个要被解决的问题。
+
+问题本身要尽量客观地去认识，但是如何看待和定义一个问题，就不是一个客观的事情了。这会受到每个人的理念影响。其实对一个问题的定义，很大程度上就决定了如何解决一个问题。架构师看问题的理念不同，也直接影响了应对问题的不同方案。
+
+比如我举个例子，楼房单元大门的门锁坏了，一直叫，这是一个具体的客观的问题。但是对这个问题的认识不同，可能就应对着不同的解决方案。
+
+如果你认为这个问题是噪音问题，那么把报警的蜂鸣器切断就解决问题了。如果你认为问题就是锁坏了，那么就去找人修好锁，就解决问题了。如果你认为问题是有人蓄意破坏，那么报警找到破坏锁的人，让他赔偿，修好门锁，并保证不再犯，就是解决问题了。
+
+如果你认为锁经常坏，是因为住户觉得开单元门的锁很麻烦，并非纯粹恶意破坏，那么就去给单元门升级智能锁，让它支持面部识别开锁、NFC门卡开锁、密码开锁、手机App遥控一次性开锁等方便实用的功能，就非常好地解决问题了。
+
+同时，你也可以在单元门口增加监控，提示“锁具昂贵，单元门在监控范围内，破坏锁具涉嫌犯罪！”。并附带一个物业电话，提示物业可以帮快递人员等临时进门的人员开门，帮业主新增解锁的面部ID、办理NFC门卡等事情，那就更加完美地解决问题了。
+
+架构师需要从实际问题出发，给出自己对问题的根本理解。所以，架构师和程序员相比，是一个更具有个性化的职业，也是一个更考验自己经验和技术功底的职业。而架构师最重要的能力之一呢，就是对问题的理解的深度。理解问题的这种能力，除了每个人的天赋之外，更多的是依靠你反复沟通、反复思考，以及在某个行业和领域的经验积累。
+
+随着自己的技术积累、反复的思考演练以及过往的实际经验，架构师会慢慢形成自己的架构理念。这个理念，就会进一步形成架构师自己认识问题和理解问题的风格。当然，这些都是发生在架构师心里的事情，在外人看来，这时候架构师还没有任何实际的产出。那么，架构师的工作成果是什么呢？
+
+### 架构师的输出
+
+架构师工作的输出，其实有两部分。一部分是自己对问题的理解和定义，另一部分就是给出解决问题的框架模型，也就是软件架构。
+
+#### 问题的定义
+
+对问题的定义，不是简单的文字性的描述。换句话说，定义可以是从系统架构角度给出的需求分析，或者说是对系统的建模。说起建模，你可能会觉得比较高深，不好理解。我们也可以称之为高层设计（high-level design）。
+
+很多中间件和产品的建模会抽象一些，里面的模块也会有着架构师自己深深的特色烙印。比如Kafka，将系统抽象为borker、partition、message、offset、consumer group等关键模块，通过这些模块的互动，组合成一个独具特色的消息系统。Kafka里面的各个模块，已经非常抽象，和具体的业务没有了直接的关系。
+
+在Kafka的架构师看来，消息队列和log系统是相通的。正是这种独到的、富有洞察力的见解，才造就了Kafka这种独特的架构。也正是这种对问题本质的理解，让Kafka很好地解决了大数据浪潮下传统消息队列无法应对的问题，让Kafka在消息队列市场上独树一帜，赢得了很大的市场份额。
+
+所以说，对问题的定义很重要。能够给出直指问题要害的定义，是非常考验一个架构师，尤其是偏产品类架构师的功力的。对于很多产品来说，架构师能够给出一个准确的定义，就已经成功了一小半，哪怕这时候一行代码都没有。
+
+#### 解决问题的模型
+
+如果说给出问题的定义，更多的是依靠架构师对行业理解，那么给出解决问题的模型，就更多的是考验架构师的技术实力了。这时候架构师要给出的，是每个模块的详细设计。包括每个模块的接口定义、技术选型、关键实现的设计等等。
+
+对于Kafka来说，如何处理这个消息队列系统的各种技术问题，就是架构师接下来要解决的问题。Kafka的理念虽然非常简约，但是作为一个可靠的消息中间件，Kafka本身是一个非常复杂的系统。
+
+这就好像E=MC2一样。质能转换方程很简单，但是造出一个原子弹来，却是一个非常复杂的工程，也和理论研究是两个维度的东西。这里我们不去展开说Kafka的架构，从架构师的责任上来说，构建的这个模型，要能够落地到具体的模块、接口、功能。这就是系统架构师要给出的详细设计。
+
+对于比较庞大的系统，做高层设计的架构师，可能并不是每个模块的架构师。所以架构师们也不是都在做同一层面上的事情。
+
+如果要形容一个架构师的核心能力，那会是两个词：积累和眼界。积累来自于架构师实操过的各种产品、搜集到问题后的思考、对行业各种技术的掌控、结合实际情况在心中进行的反复演练等等。眼界是一个架构师对行业和技术的产生的自己的理解。这两者决定了一个架构师的能量。
+
+## 如何一步步成为架构师
+
+那么我们软件工程师，如何才能一步步地成长为软件系统架构师呢？其实在我看来，任何一个软件工程师，从写第一行代码的时候开始，就已经既是软件工程师，又是软件系统架构师了。因为我们在写代码之前，肯定要经历这么一个理解问题、分析和定义问题、构建系统的过程。知道自己要干什么，要怎么干，最后一步才是写代码。
+
+架构师的成长之路，就是在这个路径上一步步有侧重点地走。但侧重点则正好是反过来的。
+
+### 夯实技术实力
+
+首先你得重视自己写代码的能力，打好学习技术的基础。在这个阶段，程序员要能写得一手好代码，把基础的知识都学牢固，比如数据结构、网络、操作系统等等，建立起自己的技术领地。在写代码中，慢慢开始理解程序设计的技巧，比如设计模式、模块化、高内聚低耦合等等。
+
+别看前面说架构师的输入和输出部分有些虚，感觉不会技术的人也能搞。但实际情况是，一个合格的架构师，肯定是要有深厚的技术做支撑的。之所以架构师可以搞这些看上去“虚头巴脑”的东西，还能让这些东西落地，就是因为技术够硬，心里有底。
+
+随着我们程序员经验的积累，我们会慢慢发现，写代码是整个过程中最容易的一步。这也是为什么我会在外包和外派相关的章节中说，做普通的外包和外派，如果只是给甲方写代码，那么成长是很快会看到天花板的。因为工作性质没有给这些程序员向下一个阶段发挥的机会。
+
+### 注重架构师能力培养
+
+紧接着，就要更进一步，开始注重自己看问题、理解问题、分析问题的能力。简单来说，就是把重心向前挪，理解代码背后解决的问题，理解代码背后的设计理念，主动思考这些“虚头巴脑”的问题。
+
+这个阶段，可以从熟悉自己做的系统的架构设计开始。也可以找一些优秀的开源框架，学习它们的架构设计。比如 Java 中最常见的slf4j，就是一套设计得非常优秀的日志系统。几乎每个 Java 程序员都在用，但是，我们去深入理解过它的架构吗？在slf4j的世界里，它是如何定义“记日志”这个事情的？它又是使用了哪些技巧，让这个日志框架可以灵活高效呢？
+
+同时，这个阶段程序员也要开始主动承担起，一些小模块的设计工作。系统架构师是一个需要非常多的实践积累的工作。每个人都有自己的成长方式，但是多做设计多思考，是普通人进阶软件系统架构师的不二法门。
+
+### 保持开放的心态
+
+软件系统架构师要有一个开放的心态，不能固守己见。优秀的系统架构，需要跟上发展，打破常规。比如前面提到的Kafka的设计，我当时第一次看到的时候，不由得心里说：我靠，这玩意有意思，对味儿。
+
+再举个简单的例子。Chrome在飞速抢占市场份额的那几年，曾经有一个大的变化，那就是让每个页面都是一个进程。要知道，之前多标签的浏览器，都是共享一个进程的。我当时得知这个变化，看着我的破电脑，心里想，Chrome这是脑子进水了么？
+
+现在回过头来想，我这种用着破电脑的小程序员，和Chrome的架构师的境界果然就是不一样啊。每个页面一个进程，一方面解放了JS engine，让不同的标签之间不再受制于同一个JS engine。另一方面这种变化也代表了浏览器发展的未来方向：因为一个标签，它就是一个单独的应用程序啊。这是Chrome对标签的崭新定义，只是我等俗人要过很多年才能体会到的。
+
+我们在实践系统架构的时候，也不要怕推翻自己之前的设计。你应该这么想：如果对于一件事情，我今天的认识和昨天是一样的，那就代表我这一天没有成长，如果我今天的认识和去年是一样的，那就代表我这一年没有成长。你想想，是不是这个道理？
+
+## 总结
+
+软件架构师，是要从无到有去设计出一个“新的世界”，制定这个世界的各种规则，让业务在自己设计的这个世界里运转起来。而这一切都需要实际经验的积累，这种积累需要的条件，远比单纯的技术积累复杂，所以架构师是一个需要岁月沉淀的工作。
+
+对于程序员来说，不是年纪大了没人要，而是能力没跟上年纪的增长，才会没人要。程序员做架构，不需要有架构师这么一个名头。因为如果我们自己做一些业余项目，肯定就是先开始思考架构设计。如果是工作中安排的编码工作，其实只要自己平时写代码的时候多思考，多想想代码背后的业务，代码背后的系统设计，慢慢也会积累一些系统架构相关的经验。
+
+当然，更重要的是去实践。工作中没机会，可以自己搞一些业余项目实践。自己想的可能很好，真的实际去做做看，可能会发现自己想的东西有很多纰漏。而系统架构的经验，就是这样一点点积累起来的。<br>
+<img src="https://static001.geekbang.org/resource/image/b7/fb/b7be1ec0fa8e031c0d01eaeeab05ecfb.png" alt="">
+
+## 思考题
+
+关于软件架构师这个职位你有哪些疑问呢？你在工作中有承担过软件架构师的职责吗？你遇到过哪些优秀的软件架构师呢？
+
+好，今天的课程就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，并把文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/技术成长篇/26 | 系统集成：为什么最容易出问题的是系统集成？.md

@@ -0,0 +1,85 @@
+<audio id="audio" title="26 | 系统集成：为什么最容易出问题的是系统集成？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f2/3f/f22c82ef5a8da0880695259bda2e913f.mp3"></audio>
+
+你好，我是臧萌。在上一节中我们聊了软件系统架构师。软件架构师完成了最核心的系统，但是这还远远没完。如果你想让这个系统真的运转起来，那还需要系统集成。而且在我看来，系统集成很多时候所占的时间和精力，远比系统核心要多。
+
+那到底什么是系统集成呢？系统集成，简单来说，就是要对接、落地，验证，看到真正的成果。
+
+## 吃上一道新菜，过程远比你想的复杂
+
+我们拿饭店来打个比方。假设我们现在运营着一个连锁饭店，中心厨房会为每个连锁饭店配送半成品的菜品。现在我们要推出一款叫“三菌笋片烩鸡丁”的新菜品。对于新菜品来说，一开始我们要先构思，然后去小范围地验证这个菜品。如果在这个小范围内得到一致好评，那第一步就算完事了。
+
+这时候，如果用软件系统研发的进度做对比的话，菜品研发部分，就是完成了系统架构和关键模块的编写，也就是完成了核心系统的开发。请大家试吃就是搞出一个演示给大家看，结果就是大家看着核心系统的演示，都觉得功能很棒，翘首期待能早日用上。
+
+这是决定这个系统特色的一步，也是最有创造性的一步。但得到了大家的认可，这能算成功了吗？远远没有。这只能算是迈出了通向成功的第一步，距离成功，还差着系统集成这关键的一步呢。
+
+回到我们的例子。我们的目的是为连锁饭店推出一道新的菜品。我们需要给连锁饭店的食客们安全快速地呈上这道新菜，才能算成功。而一个菜能在厨房做出来，和一个菜能一年能在所有饭店长期保持稳定水准，是完全两个概念，难度也是两个级别。
+
+三菌笋片烩鸡丁这道菜，用到了三种菌菇以及笋片和鸡丁。三种菌菇可能无法保证每一个连锁店所在地都有货，可能某些菌菇即使有货，价格也波动很大，可能有的菌菇对保鲜和运输的要求比较高，弄不好就容易变质，造成食品安全问题。
+
+饭店一旦要连锁，类似的问题就会不断地暴露出来，并且不断放大。如果类似问题处理不好，那么这个菜品就是失败的。而这个让新菜品落地的过程，类比到软件系统里，就是系统集成。
+
+## 如何不掉进软件系统集成那些坑
+
+那我们继续回到软件系统。软件系统在特定的场景，无其他干扰因素的理想情况下正常工作，并不代表它就可以用了。外界的很多因素，都有可能影响系统发挥出本身的功能。系统集成的过程，才是对系统的大考。
+
+每个系统面对的情况都不一样，这里我还是用一个电商网站来举例子，给大家聊聊软件系统集成中常见的那些坑、如何尽量避免掉进坑里、以及要是你不小心掉进去的话，如何快速而优雅地爬出来。
+
+电商网站有库存、商品展示、订单管理、退换货等等子系统。退换货子系统需要对接供货商的ERP系统。
+
+### 系统内部集成：架构统一
+
+所谓系统内部的集成，就是一个系统各个模块之间的集成。比如将库存记录、进出库存、库存盘点等模块等，集成为一个完整的库存系统。如果一个系统设计得过关，那么对于这种集成来说，出问题的几率还是比较小的，而且即使有问题，也容易解决。原因在于这个系统本身就是新的，是遵循着一个统一的架构设计做出来的。各个模块之间在设计之初，就已经做好了集成的准备。
+
+这时候出现的问题，大多是因为一些实现的细节，或者是设计时没有描述清楚造成的。比如代码接口定义不统一，数据交互的格式不统一等等。我之所以说这时候还比较容易解决，就是因为新系统没有历史负担，不需要考虑兼容性等问题，所以只要大家将之前的误解消除，解决问题的工作量还是可以估算的。
+
+这时候如果出现比较大的问题，很可能是因为模块由不同的架构师来负责，而不同的架构师之间没有充分的沟通。好的方式，应该是让一个架构师负责一个完整的模块，根据开闭原则，提供统一且简单清晰的接口，对外提供功能。
+
+正所谓，令出多门，兵家大忌。如果很多人都可以拍板做决定，那么事情到头来很可能会乱套。即使需要不同的架构师负责，也要有一个总的架构师，提供统一的总体架构，解决架构师之间的争论。
+
+好的，这时候我们有了一个库存模块，功能都测试过了，而且它接口简单精炼，一张A4纸就能打印出来。别的模块也纷纷告捷，大家满心欢喜地开始向前推进。
+
+### 外部系统集成：不做假设
+
+这时候，退换货模块需要就退货功能，跟外部ERP系统集成了。当你自信满满地问：你们的退货接口是什么，发给我看看。对方发给你一个文档，描述了退货需要提供的数据。你看完，发现需要的数据没啥特殊的，一切尽在掌握。
+
+于是你按照要求，对接的代码就写了起来，没两天就弄好了，和对方说：你们的RESTful接口给我测试一下，我这边的数据弄好了。对方一脸问号地说，我们没有什么RESTful接口，你把数据保存成那个格式，上传到我们这个FTP就行，我们三天内处理完，然后你再去那个FTP上，下载一个叫yyyy-mm-dd-result.json的文件就可以了，很简单的。
+
+这时候，你终于知道了什么叫做两个世界的人，在你眼里，对方重新定义了简单。同时，你也体会到了什么叫做失控。按照之前的设计，退换货是需要即时给出结果的。这种通过FTP传递数据，需要三天处理的模式，完全打破了之前的设计。且不说很多内部的功能都要重新设计重新做，对外的接口也要大改，而且还会影响所有已经和退换货模块集成好的模块。
+
+和外部系统集成，越早确定细节越好，不要假设任何东西。任何在你看来很自然的东西，可能对方就是没有。你的系统如果对这些想当然的东西有强依赖，那么代价可能是惨重的。
+
+这里我可以再举一个例子。如果你的系统的核心功能依赖于某个外部系统的功能，比如某个数据库功能，那你就先把这个通路确定好。比如公司购买的数据库是否有这个功能、公司的DBA是否允许我们使用这个功能、这个功能的吞吐量有多大等等。
+
+如果在集成的时候发现，你的系统核心功能与外部系统依赖之间存在问题，这会变得非常麻烦。因为外部系统已经存在，外部系统能不能因为你的需要来做出改变，是非常不确定的。而不同的系统之间，本来就没有统一的架构，系统之间的集成点，需要在设计之初反反复复确认并验证。
+
+### 漫漫集成路之问
+
+下面我们来谈谈系统集成中其它常见问题。
+
+首先就是配置。有些模块的配置非常繁琐，甚至配置比代码都麻烦。有些系统的配置需要经验的积累和专业的学习，比如Kafka，HBase，Hystrix等中间件系统。和这些模块或系统集成，代码之外的配置将是一个非常容易出问题的点，比如说，配置不合理、配置被覆盖、配置非法导致没有生效等等。
+
+如何应对这类集成呢？我的建议是眼见为实。在你用到配置的地方，将配置用log的形式输出出来，方便用二分法确定问题。
+
+接着是数据。其实系统集成的时候，很大一部分问题是和数据相关的。这里我给出两类常见的数据问题，一个是用户输入的数据，一个是数据交换。
+
+对于用户输入的数据，简单来说，一个字节都不要相信。用户可以给用户名填写100k个字符、用户填写的日期可能是未来或者几百年前、用户可能输入任何数据。所以在使用用户的数据之前，要把数据全部检查一遍。还是那句话，不要做任何假设，哪怕前端已经做了数据验证，自己的系统也要保护性地验证一下数据。
+
+至于数据交换，也是一个非常容易出问题的点。系统集成少不了数据交换，因为大家对数据schema定义的不同，数据交换往往伴随着数据格式的转换等操作。这时候，不同系统对于数据缺失、默认值、数据约束等规定的不同，可能会造成各种问题，甚至出错。数据在不同系统之间，交换还可能伴随着数据丢失等问题。
+
+所以，外部系统给的数据，一个字节也不要相信。当和外部系统进行数据交换的时候，一定要在系统交互的边界，好好记log。要能够将数据的输入、转换、出错等各种情况都记录详细的log，方便排查问题。
+
+## 总结
+
+系统集成为什么这么麻烦，这么漫长，原因在于一方面，它需要给出最终的被大家认可的成果。另一方面，在现实条件中可能有各种各样，之前没有想到的问题。这些问题，都会在系统集成的时候，一一暴露出来，成为系统集成路上的拦路虎，造成无法交付成果的情况。
+
+每当我听到有同学说：我代码写完了，这个事情可以结束了。我都会露出尴尬而不失礼貌的微笑。我不能否定这个结论，因为如果你问我还有什么事情没弄完，我也可能说不出个123来。但是我敢肯定，这位同学可能还要付出一倍甚至数倍写代码的时间，才能让这个代码真的跑起来，才能说这个事情结束了。
+
+这个过程，就是系统集成，是我们在为自己的想当然、对需求的理解偏差、经验的欠缺、能力的不足、视野的限制、不充足的前期调研、未预料到的意外来付出的代价。功力深厚的架构师，也是一个系统集成的大师。他可以在设计阶段，根据自己的经验，尽量减少问题，降低难度。所以，能够越少地付出这个代价，越能代表自身综合能力的提升，也是代表自身价值的提升。
+
+<img src="https://static001.geekbang.org/resource/image/b9/12/b92f2c8698d34448bf31171194fd4f12.jpg" alt="">
+
+## 思考题
+
+系统集成，是任何一个系统都逃不过的大考。你有过哪些关于系统集成刻骨铭心的经历呢？关于系统集成，你遇到过哪些问题，又有哪些实践经验可以分享呢？
+
+好，今天的课程就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，并把文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/技术成长篇/27 | 答疑篇：什么样的技术观能够更快成长？.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="27 | 答疑篇：什么样的技术观能够更快成长？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/74/46/741e26c1c8bb9cf0b9fcbcd665f09546.mp3"></audio>
+
+你好，我是臧萌。转眼之间，咱第四个模块也结束了。在这个模块里，我们围绕着技术，聊了聊程序员的技术领地、我们程序员应该如何看待技术、如何从主要做开发的程序员成长为软件架构师、以及如何不掉进软件系统集成的那些坑。
+
+在一开始，我们只要关心技术就可以了，打好技术基础，养成学习技术的习惯。紧接着，我们要开始审视自己看待技术的观点，也就是技术观。因为随着我们程序员的成长，工作的重心将开始从单纯的技术，转向如何用技术服务业务。
+
+在这个过程中，如果你打算继续走技术路线，很大的一种可能就是工作重心继续上移，在自己思考技术服务业务的过程中，逐渐培养自己做软件架构的能力，进而成为一名软件系统架构师。
+
+## 软件架构师需要哪些能力？
+
+软件系统架构师，要有自己的经验积累和独到的眼光，要能够很好地认识问题、对问题建模、解决问题。除此之外，还要考虑的一点就是软件系统的集成。因为软件系统的集成，才是对一个软件系统的终极大考，也是对架构师综合能力的大考。一个软件架构看上去很美的系统，如果不能很好地落地集成，最后的结果只会是叫好不叫座，被束之高阁。
+
+你如果能够走通这些关键节点，在我看来就已经是一个软件研发的全能人才了。软件研发全能人才更多地是从个人综合能力上来讲，而我们平时说的全栈工程师，更多地是从技术层面来谈。技术是武器，使用哪种武器解决问题，肯定会影响最终的架构。不过在架构之上，理解问题、分析问题、解决问题的能力，这个和具体的技术是没有太大关系的。
+
+所以，我更愿意建议程序员，不要把自己的视野局限在技术层面，而是要把视野扩展到从看到问题，到最终解决问题这么一个全过程。这也是整个技术成长篇里，我想表达的一个非常重要的观点。
+
+必须补充一点的是，并不是说做了软件系统架构师，就不需要持续学习技术了。软件系统架构师也必须持续不断地更新自己的技术库，维持甚至扩张自己的技术领地。这样才能够让自己做出适合当下甚至未来发展的架构，可以进一步可以减少系统集成的风险。技术是武器，熟悉武器的发展，指挥起打仗来心里才能有底气，才能灵活应对。
+
+这部分里，很多同学提出了非常多有价值的问题，也有同学分享了自己的心得体会，这里我们一起来看一下。
+
+## 修炼内功，厚积薄发
+
+关于技术舒适区，**@牛牛** 同学分享了自己的感受。开始的时候，学习很痛苦，等熬过这段时间，就会有各种小惊喜，持续不断地形成正反馈、就越来越有学习的动力了。小惊喜来自于随着知识的融会贯通，之前不懂的事情，一下就懂了。
+
+的确是这样的，尤其是数据结构、 算法、操作系统、网络、计算机系统结构这些内功，虽然没有立竿见影的效果，但是会对你还没学的东西都有加成。你会发现内功一旦深厚了，学习其他东西会很快。
+
+举个简单的例子，HBase里用一个叫做Bloom Filter的数据结构去做过滤，Bloom Filter的特点是如果这个值存在，Bloom Filter绝对会返回true，但是如果某个值不存在，Bloom Filter可能会返回true，也可以返回false。它里面用了一种非常精妙的设计，可以在可控的内存占用下，达到预期的判定准确率。如果不事先学习，肯定会让自己学起来阻力重重。但是如果之前就学会了，那看到的时候就只需会心一笑。
+
+学好基础，以后学习就一帆风顺。基础不行，学习就是步步维艰。
+
+## 搭建骨架，稳步前进
+
+**@pyhhou**  同学对如何构建自己的技术骨架比较感兴趣。我觉得这是一个很好的问题。确实技术骨架不是一开始就能搞起来的，尤其是在自己的知识存量还没有形成规模效应，可以让我们触类旁通的时候。
+
+我从开荒的状态说起吧，以Spring为例子。我们首先肯定是要学好Java，明白对象、类、方法、多态、继承等核心概念。对于Spring来说，慢慢还要知道注解、反射、代理这些Spring会重点用到的知识。
+
+然后就是学Spring，和学一般的技术一样，你需要找个趁手的书或者资料，一以贯之地啃完。可以是我们的课程，也可以是官方文档。这个过程，开始更多的是比着葫芦画瓢，先看效果。
+
+接着，你就可以发挥自己的想象力来探索了。这时候的最好的方式就是多写程序，想到什么就拿出来写写、练练，验证自己的想法。这一步，就是在慢慢构建你自己的技术骨架了。
+
+所谓骨架，就是藏在表面之下的东西，虽然看不到，但是如果没有它们支撑的话，表面的东西就不牢固。就拿Spring来说，你要能知道这些bean是如何被描述、被创建、被组装的。做到这些之后，当出了某种异常，你就很容易能找出是哪个步骤的问题，马上去修正。
+
+如果能做到这些，让你自己写一个IoC的框架，也不是难事。当然，并不是说一定要做的像Spring这么全面，可能只是一个微小的内核，但是相信我，如果你自己做一遍、思考一遍，你会对Spring的认识更近一层。当你把自己的设计和实现与Spring做对比时，会记得更牢固，印象更深刻。这个步骤，可以帮助你完整地构建关于这个技术的骨架。
+
+当然，也不是说每个东西都要自己照着写一遍。即使不去自己做一遍，也要有意识地在脑子里思考一下，如果是你自己做，你会如何设计、如何架构、遇到想不通的地方去仔细看看现有的设计，能够有很多收获。
+
+**@Sdylan** 同学也分享了自己构架技术骨架的方式。虽然方式不同，但和我的划分也有异曲同工之妙。
+
+其实每种技术都有侧重性，有些技术可能也需要这几种模型之外的模型。比如偏向数据存储和处理的技术，重点考虑它的架构，然后是数据模型和线程模型。把这几个搞清楚了，就知道这个玩意是怎么转的，出了问题可能是哪里的问题，也能知道它是否适合一个场景。
+
+其实每个人都有自己的习惯，重要的是要有个技术骨架，这样才能把知识整合在一起，才能系统地学会新领域的知识。否则就容易什么东西都只会个表面，容易浮躁。
+
+## 服务业务，不忘初心
+
+在技术观部分，Sdylan 同学提到，空谈技术，不顾业务，只会误了技术误了业务。技术本来就是为了解决问题而生的，若脱离了问题。就会变得毫无价值，生命周期也是短的。只有落地，随着业务发展才能长久。对个人而言，用到必须里外吃透，做的需求至少要理解到为啥做需求，解决什么业务痛点。
+
+关于生命周期，可以分享一个我的看法。其实做技术久了会发现，技术过几年大概率会扔掉，而业务反而不容易扔掉，积累起来越来越值钱。
+
+其实我们程序员容易忽视业务，或者说容易钻到技术里出不来，也是有客观原因的。就是做技术需要全心全意的投入，就是需要你钻进去。这时候，就容易忽略我们的初心：服务业务。所以我们程序员可以时不时地，从技术的世界里钻出来，重新想想业务是什么，我们钻的深度和方向，是否还是为了业务服务。
+
+## 从业务来，到业务去
+
+在系统架构部分，有同学表示好的架构都是从业务问题来的，然后再抽象出来。一个很好的例子就是Kafka。看完此文章后，也开始慢慢理解公司设计出来的内部架构，以前觉得这玩意不就是Spring系列，值得这么整么。其实发现是自己对业务的理解过于狭窄，随着接触的业务多了，开始慢慢明白为啥这么做。总之，架构师首先是业务架构师，本质上是业务与架构的tradeoff，关键是对问题思考和抽象程度。
+
+这个总结很到位。所以你也理解为什么软件工程师有饭吃吧。同样是造轮子，在我看来，软件工程师不是为了重复造轮子，因为对于每辆飞速行驶的车来说，轮子上各种细节的雕琢，都可能会对业务带来巨大的提升。
+
+这辆业务的车是在沙漠里开，还是在湿路上开，还是在山路上开，都会对轮子提出非常具体的要求。甚至沙子是细沙还是粗沙，都不一样。所以只要全世界的业务还都没挪到软件系统上，只要业务还在发展，软件工程师就一直有饭吃。
+
+当然，重新造轮子，得到最大锻炼的就是架构师。架构师要珍惜珍惜再珍惜每一个重新造轮子的过程，深入理解公司业务的需求，构建业务模型，打造能帮助公司飞驰的轮子。解决实际的问题，是锻炼的绝佳机会。这种公司花钱出人让人得到实践锻炼的机会，遇到了做梦都能笑醒。
+
+## 保持数据警醒度
+
+关于系统集成，很多同学都提到了 / 打印外部系统传来的参数。这个确实是一个很重要的点。确实系统集成的很大一部分就是数据。比如接入别人的数据，读取别人写的数据库，把数据传给别人等等。
+
+为什么数据这么容易出问题呢？因为数据交互就涉及到数据的序列化和反序列化，数据的封装和传输。其中任何一个环节都可能造成数据的错误或丢失。
+
+比如说最常见的http协议。http header虽然可以放一些数据，但是它是有长度限制的。而且不同的服务器对这个长度限制的默认设置也不一样。所以在系统集成时，任何外部的数据都不要信，同时，发给外部的数据，自己也记录一下。
+
+## 总结
+
+在这一篇里，我们聊了技术和架构，核心是程序员的成长。虽然没有涉及到具体的技术知识，但跳出纯技术的角度来看程序员这份工作，知道我们为何学技术、知道如何用技术、思考如何用技术给自己的职业生涯助力，也是非常重要的事情。
+
+这一篇的内容，是按照由浅入深来安排的。侧重点分别是为何要持续学习技术，如何看待技术和工作，如何培养自己架构师的能力，以及如何培养自己将系统落地的能力。你可以参考自己当前的状态，思考之前是否有不足，也希望能对你日后的职业发展有所帮助。
+
+以上就是答疑篇的内容，不知道有没有解决你的困惑呢？
+
+欢迎你在评论区与我交流一下你的想法，也欢迎把这篇文章分享给你的朋友或者你的同事，一起来交流一下。

极客时间专栏/geek/职场求生攻略/测试题/结课测试 | 这些职场相关问题，你能答对多少？.md

@@ -0,0 +1,10 @@
+
+你好，我是臧萌。
+
+《职场求生攻略》这门课程已经完结一段时间了，在完结的这段时间里，我依然收到了很多留言，十分感谢你一直以来的认真学习和支持！
+
+为了帮助你检验自己的学习效果，我特别给你准备了一套结课测试题。这套测试题共有20道题目，包括 8道单选题和12多选题，满分 100 分，系统自动评分。
+
+还等什么，点击下面按钮开始测试吧！
+
+[<img src="https://static001.geekbang.org/resource/image/28/a4/28d1be62669b4f3cc01c36466bf811a4.png" alt="">](http://time.geekbang.org/quiz/intro?act_id=200&amp;exam_id=535)

极客时间专栏/geek/职场求生攻略/结束语/结束语 | 职场的攀岩之路.md

@@ -0,0 +1,81 @@
+<audio id="audio" title="结束语 | 职场的攀岩之路" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/2c/57/2cafc8c88d856538e44067ba5c9a8857.mp3"></audio>
+
+你好，我是臧萌。
+
+真的是转眼之间呀，这个课程就到结束语了，感谢你的一路陪伴。在这3个月的更新期里，很多同学分享了自己的故事和经验，也有不少同学提出了非常赞的问题，我特别喜欢这样的互动。
+
+现在课程要完结了，在这最后一课里，我该跟你聊点什么呢？老实说，我有很多话想讲，但是一下子不知道该怎么表达出来了。正好最近看了一部电影，中文名字是《徒手攀岩》（Free Solo），给了我这一讲的思路。
+
+<img src="https://static001.geekbang.org/resource/image/17/f8/17ce8aee23c03f06ebdbb181920cd8f8.jpg" alt="">
+
+这是一部纪实电影，主要讲的是主角徒手攀岩酋长岩的经过。什么是徒手攀岩？就是不用任何安全措施的攀岩。关于酋长岩，你可以去搜一下图片。它就像是一块吐司面包一样，有一个几乎垂直且光滑的面，那个面正是主角要一步步攀登上去的。
+
+我不会攀岩，如果你见过我，会觉得我这种人也谈攀岩会很可笑。我可能连引体向上都做不了几个。但是这部电影中很多细节和意境，引起了我的共鸣。
+
+看完后我还真是感觉心潮澎拜的，我们就从“攀岩”这两个字来切入吧，因为我觉得攀岩二字就是我们工作生活的真实写照，我们每个人都是在职场中徒手攀岩，就连这门课程的制作过程，其实也是一个攀岩的过程。希望通过攀岩这个视角，把这些年让我受益匪浅的2条心得分享给你。
+
+## 要做，就认真把事情做好
+
+那我就先跟你聊聊这个课程诞生的背后故事吧。我们的课程只有30来讲，但是这个课程中的内容和素材，我其实酝酿、积累了很久。
+
+我在软件工程师这个职位上工作了14年，经历了很多事、认识了很多人、换了很多工作。一路走来，回头看看，有些想不通看不懂的事情，我慢慢有了一套方法可以去理解它们；有些不知如何处理的事情，我也慢慢有了应对的方法；有些错误认知，我也慢慢纠正过来了；有些迷茫的时期，也慢慢走了出来。这些我踩过的坑、总结出的经验、工作里的技巧，我在平时都会做做总结。但很多年来，这些总结都是写给自己看的。
+
+直到最近几年我才注意到，其实不少同学的成长都有差不多的过程。我想通的事情，光给自己看远远不够。我无法通过时间隧道告诉N年前的自己，该在职场里怎么做，但是我可以总结出来，给更年轻的同学参考参考。这就是这门课的初心。这时候，就如同攀岩者看到想征服的山，心里会情不自禁咯噔一下的情景，我也发现了那个激起我心中征服欲的山。
+
+在2019年年末的时候，我真正开始和极客时间编辑一起，系统地去归纳这些内容。这样一个准备的过程，就好比攀岩过程前的初期规划，比如准备攀岩装备、研究攀岩路线等等。
+
+准备好了，那就出发，向着目标前进。说实话，攀登之前，有心潮澎湃的酝酿，也有对自己能力的怀疑，有想过放弃算了，也有对成功的期待。而每当抬头看的时候，山它还在那里。这时候，总会有这么个声音，让我别管这一路上假想的困难。在一遍又一遍地过了提纲之后，我决定试试看。
+
+从目录大纲、文字稿到音频稿、再到录音，大家都是一块努力，往做出一门好课程的顶点上爬。仅仅大纲的打磨，我们就互相磨了很多遍。上线后每篇文章的内容、架构、组织衔接等各个方面，我们也在一块互相沟通互相交流。我就是喜欢和认真的人一起合作，我脸皮薄嘛，别人如果认真，我就不好意思不认真，只能努力更认真一些，才觉得能对得起认真合作的同学们。
+
+在迈出第一步之后，要做的就是坚持。我每攀登一寸，山就矮了一寸。更不用说还有编辑同学们的神助攻，我不是一个人在攀登，我们是组团冲着一个目标去的。
+
+在攀登的过程中，之前想到的困难反而显得没那么难以克服了，但是总有很多我之前想不到的困难冒出来。我觉得这个过程中，无需抱怨任何困难，无需抱怨任何突发状况。**在登顶之前，没有资格抱怨**。抱怨，就是心里想放弃，是在为放弃找理由而已。登顶之后，过程中经历的一切，都是自己的收获。
+
+这里和你分享一件事儿，我觉得是这次课程攀岩之旅最难的一件了，那就是录音。一开始，我以为写稿子会是大头，没想到录音这个环节的难度，竟然远超我的想象。
+
+首先是讲稿子。光打磨自己讲稿子的感觉，就反反复复和编辑、音频导演折腾了很久。把稿子写得好和把稿子讲得好，是完全不同的两件事。录音得有急有缓，既得有讲述感，还不能像老大爷聊闲天似的。看似很简单的事情，其实真的做起来，才知道深浅。
+
+另外，在家里录音，环境问题也是一言难尽。白天各种生活的噪音，梅雨季节的雨点哒哒哒，狗子嗷嗷叫，汽车呜呜呜，喇叭滴滴滴，人群叽叽喳喳，哦对了，还有早起的鸟儿欢快的歌声。
+
+怎么办呢？为了让自己的录音没有太多的环境噪声，在大部分时间里，我得等这个世界清静了，凌晨十二点之后再去录音。上海的雨特别多嘛，有时候好不容易等到了半夜，淅淅沥沥的雨又开始了。不过好在天公也算作美，不会让我为了等雨停，硬熬到三四点。
+
+**每次在心态即将崩溃的时候，我都靠最一句话来平复心情：要做，就认真把事情做好。**
+
+前国家队主教练米卢说过一句话：态度决定一切。最开始听到这个话，我觉得很扯、很虚、很装、很没劲。没错，这就是我之前的一个错误认知。但现在，我越发觉得这话说得很有意思。态度，就是心态。态度对了，心里就有那股子劲儿，就有了坚持的动力，有了受挫后再战一次的斗志。
+
+关于认真，我想再说一个我自己的故事。在刚开始工作的时候，我有将近半年的时间，都是在写文档。没错，就是纯写文档。如果你是Eclipse的深度用户的话，可能知道它有个叫做CheatSheet的功能。CheatSheet可以让用户一边在Eclipse里看文档，一边通过鼠标点击文档中的链接，弹出相应的对话框，让用户走完某个功能的使用过程。
+
+我们管这个过程叫Happy Path，就是让用户开开心心顺顺利利地，把一个简单的用例走通，把我们的功能都串起来。当时我很认真地完成了这件事情。几年后，当我写书的时候，其实很多功底是在那个阶段练就的。
+
+认真做事，不仅仅要在自己能力范围内把事情做到最好，更是要让自己得到更好的锻炼，提升自己的能力。
+
+这就是我想和你分享的第一句话：**要做，就认真把事情做好。**
+
+## 耐得孤独，稳扎稳打，默默坚持
+
+但认真不是全部，攀岩的过程还有一个关键挑战需要我们去面对。
+
+再回到我开头说的这部电影。整部电影，没太多台词，情节也很简单，场景也就是大山和森林。主角站在山下，或者在看着山，或者在规划着自己的攀岩路线，又或者为攀岩做身体上的准备。虽然主角的几位朋友都在尝试帮助他，但是感觉孤独就像是整部电影的基调。尤其是电影最后，只有主角在一步一步地攀登酋长岩，那份孤独感真的太真实了。
+
+想想我们作为程序员，为了写一段完美的程序代码，创造一个完美的软件系统，要去一遍遍地思考、推翻，再思考、再推翻，若有所思地踱来踱去，嘴里絮絮叨叨一些只有自己能听见的声音，也是经常只有孤独的夜相伴。
+
+再想想我们职场上的每一天，做的每件事、每个决定。小到如何回复邮件、如何与人讨论、如何和人沟通、如何与人撕，大到是否做某个系统、如何在技术上投资自己、是否内部转岗、是否换个行业领域、 是否换个工作，所有事儿都需要自己独自承担。
+
+这些，都是充满了孤独、挣扎、坚持、努力和探索的过程。攀岩如此，写专栏如此，做软件如此，混职场亦如此。
+
+整个过程中，我们需要的就是安安静静地自己思考，然后默默坚持，努力付出。就好像徒手攀岩一样，你站在一个大山的脚下，在脑子里规划着攀登的路线，然后稳扎稳打地攀登、攀登、再攀登，直到登顶。
+
+在这个孤独的攀岩过程里，只有目标和汗水。很多事情，我们只能自己琢磨。很多付出，也只有我们自己知道。但也正是这份孤独，造就了只属于我们自己的成绩。
+
+这是我送你的第二句话：**耐得孤独，稳扎稳打，默默坚持。**
+
+好了，啰嗦了很多了，希望这两句话能走进你心里。最后，祝职场上的你能够努力认真攀登好每一座属于自己的山峰。也希望这个课程，能在这个过程中对你有些许的帮助，帮助你抵抗这份孤独。
+
+对于你在留言区的精彩问题和分享，我会在InfoQ写作平台上以FAQ的形式不定期更新，并同步到部落。欢迎你关注我的[部落号](https://horde.geekbang.org/usercenter/5505C1516EDFD5)和[InfoQ写作平台账号](https://www.infoq.cn/profile/1008692/publish)。
+
+最后的最后，我还为你准备了一个毕业问卷，希望你用2分钟填写一下。大胆表达自己吧，期待听到你的声音！
+
+[<img src="https://static001.geekbang.org/resource/image/a7/33/a7f4fae4f2d63b8178082b9e7c766133.jpg" alt="">](https://jinshuju.net/f/ONyZp0)
+
+再次感谢你一路的陪伴，欢迎分享自己的故事和问题，期待你分享自己登顶时的喜悦。不说再见，我在评论区等着你！

极客时间专栏/geek/职场求生攻略/职业素养篇/01丨优先级：工作中那么多事情，我要如何安排优先级？.md

@@ -0,0 +1,103 @@
+<audio id="audio" title="01丨优先级：工作中那么多事情，我要如何安排优先级？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ca/08/caafad7ff6a256725877210d716a9408.mp3"></audio>
+
+你好，我是臧萌，这篇文章是专栏的第一篇，我们以工作中的优先级这个话题开始。我们在日常工作中，总会这样感慨：事情，是干不完的。
+
+既然干不完，那我们就要分清轻重缓急，哪个重要，哪个不重要，给它们划分一个优先级，这样不至于让自己手忙脚乱。
+
+能给手头的事情排上正确的优先级，是一项很重要的工作能力。
+
+当然，我们在生活和学习中，事情也可能不少。但是和工作中的优先级相比，生活和学习里的事情是我们自己的事情，只要安排得让我们自己满意就可以了。在工作中，事情的优先级的标准，是要让公司受益，让老板满意，让同事认可。
+
+首先呢，我们先谈谈优先级为什么重要。
+
+## 优先级的重要性
+
+我工作中有一段时间，就经常被工作的优先级所困扰，经理也时不时地批评我：“这个事情这么重要，你怎么到现在还没开始弄？”我心里也有点憋屈：“我又没闲着，我做的事情还不都是经理安排的么？”
+
+这里有一个很重要的字眼——重要。
+
+优先级有很多的考量，并不是简单的先来后到的线性时间顺序，我们需要根据事情的要紧程度安排优先级。
+
+还有一个需要考虑的因素就是程序员的工作性质。对于软件工程师来说，一个事情可以用一天的时间做完，也可以用一个星期的时间精心打磨。如何在时间有限的情况下安排自己的时间，让时间用在最值得做的事情上，就是排优先级需要考虑的内容。
+
+给不同的工作安排优先级，不仅会让我们的工作效率更好，也可以让我们和同事之间达成良好的合作关系，为什么这么说呢？且往下看。
+
+## 如何给工作排优先级
+
+首先，我们可以从两个维度去给工作划分类型，一个维度是工作本身的性质，另一个维度从合作角度出发，然后根据这些工作的重要与否安排优先级。
+
+### 基于工作性质安排优先级
+
+基于工作本身的性质，我把工作划分为公司发展计划、安全相关的事情和生产上的事情。
+
+每个公司都有自己的发展计划，并给这些计划划定不同的权重，以指导协调公司内有限的资源。
+
+拿我所在的公司来说，每年公司高层都会制定当年的发展目标，然后以此为依据，制定不同的发展项目，再根据项目，一层层地将项目分解为各个部门的子项目等等。每个部门，以顶级项目的优先级为参考，安排自己的资源，以达到公司的发展目标。
+
+我们程序员作为公司人员组织的基层员工（我习惯称为叶子结点），自然不需要操这么大的心。但是我们需要了解公司的发展方向和重点项目。一般来说，公司的发展目标和与之相关的各个项目的优先级都会对内公开，公司也鼓励所有员工都熟悉这些内容。当和这个项目相关的工作安排到自己手里的时候，一定要给予这种工作足够的优先级。
+
+同时，这种重要的事情，最好多花点时间在上面，力争做到最好。因为这种重要的事情是拖不起的，如果因为没做好拖累整个项目的进度，可能会影响自己甚至整个组的表现（performance）。
+
+我们再来看看安全相关的事情。
+
+“安全无小事”这个口号在所有工程类的工作中都适用。软件开发里的安全问题虽然不会直接影响生命安全，但是它会带来很大的经济损失和商誉损失，现实中各种数据泄漏的例子不胜枚举。
+
+我随便举个Java的例子。在JDK 的早期版本中，有一个执行任意代码漏洞。Java可以启动新的进程，执行任何命令，方式是使用Runtime的exec方法，传递一个命令的String数组。这个漏洞在于，它先检查了String数组里的命令是否允许被执行，然后再遍历数组，依次执行每条命令。而在多线程环境下，完全可能在检查完毕后，数组里的内容又被别的线程恶意更改了，改为不应该通过检查的命令。这样的话，一条本不应该通过检查的命令，就这样被执行了。
+
+作为承担着软件开发和运维工作的现代程序员，我们首先要遵守安全部门的安全规范和检查，这就好像进入工地要戴安全帽，是没得商量的。
+
+安全部门有时候还会发布紧急安全升级等要求。比如升级有安全隐患的jar包/组件等，这时候，我们一定要把这个当作优先级最高的任务，不要有任何的犹豫或轻视。
+
+站在我们程序员的角度想一下，一旦出了安全问题，如果是因为自己执行不到位，这个责任肯定是要自己承担的，即使后期再怎么弥补，也无济于事。
+
+试想一下，如果你没有配合安全部门的任务，导致一个有漏洞的 jar 包被利用，造成了数据泄漏。即使接到任务的时候你没有闲着，甚至为了完成业务开发挑灯夜战，但你觉得业务的人会为你说话，替你挡箭背锅吗？
+
+如果你不确定，那么就换位思考一下吧。如果你是业务方，给开发提好了需求，进度也排好了，结果忽然开发组跟你说，因为做你的项目，导致我们没时间做安全升级，造成了公司损失，你要背锅。你是不是觉得这锅来得匪夷所思？
+
+安全部门的要求就是最高的要求，是一切需求的“挡箭牌”。当一个安全部门给的任务到了你手上，告诉经理你要放下手中的工作，立刻开始执行安全任务吧。这既是为了公司，也是为了自己。
+
+除了安全问题需要注意外，我们还要注意生产上的问题。
+
+如果生产出了问题，那么作为 DevOps 的程序员，要第一时间放下手头的事情，冲上去搞。理清问题之后，马上开始行动。生产上的问题都是火烧眉毛。火烧眉毛的时候，你会等着别人给你送水，还是自己想尽一切办法找水呢？当然是自己找水了。如果需要别人配合，马上联系相关的人或者其经理。
+
+### 基于合作安排优先级
+
+讲完工作本身的性质，我们再来看看那些需要跟别人合作的事情，毕竟有人的地方就有沟通，如果优先级没有排好，那就很容易导致沟通不到位，出了纰漏，就很麻烦了。
+
+在日常工作中，我们有很多任务都是经理下达的。经理往往掌握着更多的信息，也更能判断一件事情的优先级。现在一般都是敏捷开发，经理会给每个story排优先级。在给任务排优先级的事情上，程序员可以提建议，也可以和经理讨论，但是一定要以经理的决定为准。
+
+还有一些经理临时安排的事情，这种事情有时候更急一些，可能也不用耗费很长时间。所以这种事情也要先做。
+
+如果一个事情需要别的部门配合，那么优先做。比如申请资源，和自己的上游讨论需求等等。这样一方面可以让别人尽早开始工作，另一方面也可以尽早交换信息，避免日后翻车。
+
+举个简单的例子，如果有一个需求依赖上游服务。那么在自己这边需求明确的情况下，你要尽早和上游的组通气，看自己的需求能不能做，排期是怎样的。如果自己觉得没问题，先开展自己的工作，结果上游那边无法做或者无法排期，那工作就彻底翻车了。
+
+如果事情没有太明显的轻重缓急，那么换位思考，与人为善，优先做那些阻塞了别人工作的事情。有些事情是来自组内的，有些来自组间合作。良好的合作关系就是这样一点点打磨出来的。
+
+## 做事情本身的优先级
+
+给工作排好优先级之后，我们还要注意工作内部各项事情的优先级。工作需要拆成不同的步骤来实施，这些步骤也有优先级，其实基本道理和我们上面讲的都一样。
+
+我举一个开发新功能的例子。开发新功能可能要申请机器，要找上游谈依赖，要开发代码，要找下游谈需求，要和上下游联调接口等等。
+
+你看，这里有“申请机器”“找上游谈依赖”“找下游谈需求”，那么这个时候，申请机器和找上游就是应该尽早开始的。同时，接口和联调也应该尽早开始，接口具体实现的代码不需要写得那么完善，甚至mock一些过程也是可以的。这样一方面可以和上下游尽早落实集成的细节，另一方面也可以尽早将阶段性的成果展示给需求方，随时review，避免最后来个大“惊喜”。
+
+我们做事情的时候，如果能把其中的每一步都想清楚，理清依赖关系，安排得井井有条，这就已经事半功倍了。
+
+## 总结
+
+我们的工作繁杂而琐碎，今天我也仅仅是给出了一些通用的建议。在不同的工作内容，工作岗位上，可能有不同的维度。但是需要牢记的是，当你觉得自己工作手忙脚乱的时候，不妨停下来，先理理自己手头工作的优先级。怎么整理优先级呢？这里我给出一个简单的方法。首先把所有的事情列出来，然后对每件事情问自己两个问题：不做这个会怎么样？做了这个能怎么样？剩下的事情，就是顺着这个思路走下去了。
+
+其实，给工作排优先级，不仅仅是一个提升工作效率的方法，也是提升自我和磨合团队的重要方式。
+
+程序员的工作不只是低着头写代码，也不只是别人让干什么就干什么。给事情排优先级，是一种能够帮助把事情做对，做成，做好的重要能力。它不仅需要你对事情本身有准确的认识和判断，还需要你有清醒的思维，能够将事情分解，按照最优的顺序执行。给工作安排优先级的过程，也是锻炼自己能力的过程。
+
+进一步说，这种能力更是一名经理的必备能力。经理的很大一部分任务就是理清事情，排列优先级，让自己的手下去做事情。程序员能控制的就是如何安排和使用自己的时间，而经理要对手下所有人的时间负责。所以经理眼前的事情更多，关系更复杂，需要做的判断也更重要，对这个能力的要求也更高出好几个层次。所以如果你有转做管理的计划，不妨在这件事情上多花点心思吧！
+
+<img src="https://static001.geekbang.org/resource/image/2b/ac/2be0c0b0ebcd3b8a9fc0a2051f65ccac.jpg" alt="">
+
+## 思考题
+
+我在开头中提到了我刚参加工作时的窘迫，你有过我当初那种“我明明没闲着，却被经理说做事情不得力”的委屈和困惑吗？你现在走出这种困惑了吗？
+
+欢迎你在评论区和我讨论，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职业素养篇/02丨沟通：邮件那么重要，你还在轻视邮件吗？.md

@@ -0,0 +1,113 @@
+<audio id="audio" title="02丨沟通：邮件那么重要，你还在轻视邮件吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0e/83/0e5f16a5e6504ba16ca195c838a73083.mp3"></audio>
+
+我刚毕业开始工作的时候，是比较讨厌邮件的。面对面聊不好吗，异地的话打电话不好吗？但是现在，我和组外的工作伙伴说得最多的一句话就是：“好的，你发封邮件给我吧。”有时候会再加一句，“抄送我老板”。
+
+嗯，成功变成了自己当初讨厌的样子。为什么呢？
+
+其实工作多年的人都隐隐理解邮件背后的含义，但是不会明说。我有一位前辈在某次组内会议的时候，直接捅破了窗户纸：“邮件不是用来沟通的，它是用来撕扯和甩锅的。”
+
+为什么这么说呢？让我们先从邮件的功能开始说起。
+
+## 邮件的特性
+
+在我看来，邮件有三个重要的特性。
+
+1. 异步交流：邮件是一种异步交流的方式，双方有足够的时间准备邮件内容。
+1. 无法修改：邮件内容无法修改，这是邮件可靠的基石。
+1. 方便扩散：邮件有邮件组，可以很方便地把相关人员加进来，并且保留邮件历史记录。
+
+## 邮件是公司内部的合同
+
+下面我们开始聊有意思的。邮件，其实就是一种简易版的合同。在这里呢，我们来模仿电商公司两个组之间的一次合作，以此来看看邮件在整个过程中的作用。
+
+### 情景介绍
+
+业务组负责开发业务，对接和集成上层产品线，配合运营做营销活动等。基础服务组负责提供基础框架和服务，蹭个流行一点的词，就是中台。这次的功能是购物车，需求一层层传递下来，基础服务组需要提供一个“购物车功能”给业务组使用。
+
+#### 场景1：设计确认（邮件的“确认”功能）
+
+购物车的需求设计等等需要一个接一个的会议讨论。当然，需求最后也要用文档的方式确定，并且通过**邮件**的方式通知所有相关人员。邮件这种异步沟通的方式，其实就是给双方足够的时间去细细地看，不催着你立刻给一个确定的回复。邮件可以随意加人，如果有任何疑问，可以随时把相关人员加进邮件线程（email thread）。
+
+我们工程师作为实际干活的人，有问题一定要提出来，或者和组内讨论，或者在邮件讨论。关键的点可以在邮件里确认，比如购物车的数据是保存在服务器端，而非session中。
+
+如果你收到邮件又不说话，那就是默认。
+
+如果没有问题，相关人员（比如经理、技术经理、功能主程、双方对口人之一）应该礼节性地回复一个赞扬的邮件，内容不重要，重要的是这封邮件代表你已经同意邮件内容了。注意，这点很重要：同意。这时候，双方相当于签订了合同，合同内容就是大家对购物车功能的共识。
+
+购物车功能的需求清楚了，开发周期有个差不多的数字了。经过双方估计，基础服务组大概需要10个人做两个月，一台标准服务器可以服务10w活跃用户。
+
+#### 场景2：优先级（邮件的“证据链”功能）
+
+这时候第一个扯点来了：优先级。按照这个预估的工作量，基础服务组之前排好的工作计划就要重新排。但是基础服务组之前已经排好的需求，也大多为了业务组服务的。这个球就踢到了业务组：是把已经排好期的某些功能往后推，还是把购物车功能往后推？亦或者暂且简化购物车的功能，压缩工期到5人一周（比如把购物车保存在session里）？钱多优先级都高的话，可以借人或者招人。双方的经理可以开会，拉上各种相关人员做出决定。业务组内部肯定也会有不同的声音，如果之前的功能排期被挤掉了，肯定会影响业务组一些人的工作。
+
+所以，这时候得出的结论，一定要通过邮件的方式让业务组老大发出来确认。
+
+无论是推迟已经做好的计划，还是简化购物车功能，都可能带来潜在的业务风险。邮件的作用就是允许人在深思熟虑之后，通过邮件的方式宣布决定。这时候，这封邮件就是合同。同样的，基础服务组也要履行自己的承诺，10个人，2个月，做出之前设计的购物车功能。
+
+如果业务组老大的决定是推迟已经安排的功能开发，若是因此被竞争对手抢走了很多用户，那么业务组老大要承担大部分责任。开撕的时候，这封邮件就是依据。同样的，如果2个月没做出购物车功能，这个锅就要算在基础服务组头上。当然，有些时候项目延期，并不会导致明显的损失（软件行业开发延期再正常不过了）。所以这份合同，会不会被用来当做开撕的证据，不好说。但是我们在公司做事，还是要严谨稳妥一点，别在邮件里承诺自己没有把握的事情，力争做到“没事儿Be Nice，有事儿必耐撕”。
+
+#### 场景3：大促（邮件的“沟通协调”功能）
+
+接下来公司搞大促了。沟通从运营一路到业务，到基础服务，到运维，到预算批准，到服务器上线，服务部署等等，每个操作都需要相关的组给出明确的操作细节和时间节点，比如大促的时间、峰值人流、持续频率、活动地区（全国还是某些省市）等方面的数据，都需要相关的组在内部充分沟通之后，以邮件的方式确定。各个组之间通过邮件的方式签合同，用邮件组等方式确定各个组和人员都得到了相同的信息。
+
+每个组各自背负好各自的责任。
+
+#### 场景4：新业务接入（邮件的“防遗忘”功能）
+
+紧接着，公司别的业务也要接入购物车了。对基础部门的你来说，改动可能就是增加一个配置。但如果业务组的人过来找到你，说：“哥们，购物车功能棒棒哒，我们安卓的应用也要用啦，给加个配置呗。”你脑子一热说：“好好好，立刻就加。”
+
+那么这种沟通，就是双输。
+
+为什么呢？
+
+对业务组来说，他们并没有得到一个上线的保证，只是你的一句口头承诺。而你可能一忙，转头就忘了。如果业务组立刻着手进行安卓的购物车集成，结果上线之后发现你这边还没改配置，这就是车祸现场。
+
+对你来说，如果你真的立刻做了这个事情，组里没有人知道，非但无功，而且有过。配置的修改，至少要对流量有个预估吧。而这些数据，包括上线时间，还是需要用邮件的形式做出正式的沟通和确认。还有很重要的一点，一个组要做的事情，需要在组内告知，因为组员都可能会修改这个服务，万一有对安卓不兼容的改动而你不知道，上线之后依旧是车祸现场。当然组内的沟通，可以不通过邮件这种方式。
+
+#### 场景5：技术升级和Bug修复（邮件的“广而告之”功能）
+
+接下来是基础服务组要对服务做改动，可能是一个Bug的修复，也可能是技术升级，比如增加一层Redis缓存。发布的时候，服务的可用性可能会受到影响。作为基础服务组的你，如果只是走到业务组那边，找个相熟的人问：“哥们，今天晚上我们做个升级，购物车大概停服一个小时。”你哥们也很“够意思”，说：“木有问题。”那么你们俩就都掉坑里去了。
+
+你这个哥们可能不知道全组的情况，可能组里有些项目今天晚上正好要用到购物车服务。万一出了事情，俩人就都得歇菜。所以和上面的情况一样，还是要用邮件加邮件组，充分告知足够的人，而且提前足够多的时间（比如三天），让大家都能得知变动的计划详情。
+
+## 邮件的魅力
+
+到这里可能你会觉得心好累，为什么有这么多算计，为什么不能干就完了。其实，**这不是算计，这是负责**。邮件是正式的沟通渠道，一封邮件如同一份合同。我现在为什么张口闭口让别人发邮件给我，因为别人张口就来的需求，可能并没有经过深思熟虑，也可能没有经过他们组内部的讨论。我让对方发邮件的初衷，就是让对方好好思索和沟通好之后，给出一个正式的需求，而不是草草地开始做事。
+
+同时，邮件确认了，做不好就要负责，也就是“背锅”。**我们都是普通人，普通人没有“背锅”的压力，就没有持久的把事情做好的动力**。你品，你细细品，我们是不是这样的人。
+
+## 邮件的小技巧
+
+我在上面说了很多，模拟了一个场景，既想让你了解合同的重要作用，也想让你知道合同的正确使用方式。那么在这里，我再给一些使用合同的小技巧，或者注意事项，希望对你有帮助。
+
+#### 定期查看邮件
+
+既然是要使用邮件，那我们就要定期看邮件。不要觉得这个建议很不起眼，事实上，我刚开始工作那几年，经理经常跟我说这句话。因为那时候的我还时不时地会漏掉公司的一些公告信息，以及别的组请我们帮忙的邮件。这就很尴尬了。所以一定要养成定期查看邮件的习惯。
+
+#### 发送邮件的小技巧
+
+回复或发送一封邮件的时候，看清收件人有哪些，再决定自己该说什么。
+
+首先要学会抄送老板。如果想催促进度，就抄上对方的老板。如果觉得自己搞不定，记得抄上自己的老板。
+
+其次要用好邮件组，该加人的时候加人，比如某个组的邮件列表，某个部门的邮件列表等。做到应通知，尽通知。避免只通知某个组的某个人，以免这个人对邮件中的事情有误解或者漏掉了信息。
+
+如果你的邮件收件人比较多，那就记得**多检查一下邮件内容和标题**。版本公告就是个例子，每次都是复制上一次的模版然后修改一下。我曾经不止一次忘记改标题或者时间，虽然没直接影响，但是会让人觉得你不仔细（本来就不仔细囧）。
+
+#### 写会议纪要
+
+如果是和自己相关的会，开完会之后一定要记得发一封会议纪要，给所有参会人员。会议纪要可以总结这个会上得出的共识，列出下一步可以采取的行动，保证这个会上得出的成果不会被遗忘或者被误解。
+
+## 总结
+
+我今天讲有关邮件的一些内容，比如邮件的功能、使用技巧等。其实你也能看出来，邮件不只是一个沟通的渠道，而是一个正式的，签合同的渠道。现在很多公司也在积极的使用更高效的工具代替邮件的功能，但是本质是一样的。
+
+因此，在正式的工作使用场所中，我们要牢记使用邮件的注意事项，这样一来可以避免工作沟通带来的问题，二来也可以帮助自己梳理工作任务。
+
+发邮件要有仪式感。邮件只是一种形式，如果公司不使用邮件，也会有一种正式的沟通渠道。好好利用它，祝大家工作愉快。
+
+<img src="https://static001.geekbang.org/resource/image/fa/fc/fafa86315896fe947c68eaf1872bdcfc.jpg" alt="">
+
+## 思考题
+
+你在使用邮件的问题上，有过哪些疑问或者故事吗？欢迎在评论区讨论，我会和你一起交流，也欢迎你把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职业素养篇/03丨沟通：程序员为什么应该爱上交流？.md

@@ -0,0 +1,130 @@
+<audio id="audio" title="03丨沟通：程序员为什么应该爱上交流？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/28/e1/282fa7402e381c036901223825ee0be1.mp3"></audio>
+
+程序员这个群体最开始被社会认知的时候，标签之一就是不善交流。慢慢地，“喜欢玩电脑，不喜欢和人交流”成了大家对程序员的一个刻板印象。作为程序员，我发现工作的时间越久，承担的责任越大，那么交流是一个越来越重要的能力。
+
+在这一讲里，我们就来聊聊程序员如何进行高质量的交流。当然了，你可能会想，我不喜欢交流照样工作得很顺利，可是，交流带来的好处也就体会不到了。
+
+当然了，在开始前，让我们先想想，为什么我们会不爱交流呢？
+
+## 为什么程序员普遍不喜欢交流？
+
+其实，是不是喜欢和人交流绝大部分是由性格决定的，和职业无关。可能程序员这个行业，相比其他行业，吸引了更多的不喜欢交流的人吧。但是除了性格之外，确实有些客观因素影响了交流的积极性。
+
+### 工作被打断严重影响效率
+
+我觉得这个绝对应该是排在第一条的。和人交流一般需要约好时间，到了时间不得不放下手头的工作。有时候也会有人主动过来，随便聊点东西。无论是哪种形式，其实都会打断程序员当前的工作。
+
+而所有的程序员，都非常讨厌自己的工作被打断。
+
+### 交流不能直接帮程序员完成工作
+
+网上有个段子，说程序员和产品经理在开会，讨论到下班才结束。产品经理一看正好到点了，就欢欢喜喜地闪了，留下程序员拿着需求挑灯加班。
+
+会议结束之后，程序员的工作才算真正开始，从利益的角度来说，也难免我们会抵触这种不能帮自己直接完成工作的交流了。
+
+程序员其实只是交流中的“利益受损者”，我们排斥的不是交流本身，而是厌烦交流中时间的“浪费”。
+
+当然，面对面的交流只是一个例子，其实写文档、回邮件、做演示等等都一样，都让程序员感觉是“浪费时间”。
+
+简单来说，没有无缘无故的讨厌。别管程序员嘴里怎么说，心里其实明白，归根结底，还是因为我们觉得这些事情影响了自己的“利益”。
+
+## 爱上的第一步：正视和人的交流
+
+如果交流有损程序员的利益，那为什么我们还要交流呢？我就写我的代码，写完下班不是挺好的吗？其实这就涉及到一个长期利益和短期利益的问题了。短期来看，少参加一个会，少和人聊两句业务，少被人打断几次，从一个星期的维度看，可能工作确实完成得更快了，加班更少了。
+
+但是从长期发展来看，缺少交流的程序员，很难发展为公司的骨干，升职加薪可能都会被排在后面。我们的工作，真的不止眼前的程序。
+
+在做事情的时候，优秀的交流能力是必须的。如果你能够展示自己在交流能力上的优势，组内外的同事也更愿意和你合作，经理也会优先考虑让你承担更多的责任，对自己的发展有很大的好处。
+
+我认为，交流的好处可以从两个方面来说，一个是输入，一个是输出。
+
+### 输入
+
+我们都说要创新，要整合资源。其实要想做到这一点，在一个公司里实现成长，就要时刻保持自己获取信息。如果能够重视平时的交流，交流的时候多主动思考，慢慢地，自己收获的关于公司和行业的信息也就越来越多，没准还就能够找到新的突破点，抓住新的机会。
+
+机会都是自己争取的，这句话看似鸡汤，但是背后的道理一定要明白。没有哪个创新是空中楼阁，在现代社会闭门造车也很难成功。只有足够的信息可以在脑子里碰撞，创新的火花才更有可能出现。在外人看来的灵光一闪，背后可能有很深的积累。
+
+### 输出
+
+现在已经不是一个酒香不怕巷子深的时代了。自己的想法，自己的工作成果，都应该积极主动地向外界输出。输出不一定是什么长篇大论，可以是简单的交流、发邮件、写文档、做工作成果演示等等。通过输出，我们才能慢慢赢得自己的声誉，树立自己的影响力。
+
+### 养成主动交流的好习惯
+
+当我们意识到交流的重要性之后，就应该慢慢养成主动交流的好习惯。
+
+交流不一定要是非常正视的形式。我们可以闲聊，趁着吃饭或者散步的时间，主动和组内同事，和自己的经理，和自己上下游的关键联系人交流自己的想法以及正在自己做的事情，然后也从对方那里获取相应的信息。
+
+不要让自己做一个小透明，做的事情要让别人知道。同时，也知道别人在做什么，别人遇到了什么问题。别人的问题，就是你潜在的机会。
+
+当然了，我们也可以通过分享会的形式，进行正式演示。这种演示一方面可以展示自己的工作成果，另一方面也可以听取别人的意见，看看自己的工作如何能给更多的人带来价值。
+
+前面说到的交流多偏向于信息交换。其实日常工作中还有很多交流都是为了解决具体的问题。从技巧上而言，这两种类型的交流并没有什么区别。
+
+## 程序员交流的技巧
+
+### 换位思考，注意受众
+
+其实人和人之间交流最重要的一点就是换位思考。站在对方的角度理解自己表述的内容，看看能否被正确地接纳和吸收。程序员是一种专业性很强的工种。很多专业技能相关的内容，可能会让非专业人士摸不着头脑。大到一个公司，一个部门，小到一个组，一个项目，都可能有很多专有名词，专用词汇，需要很强的背景知识。
+
+所以我们在交流的时候，首先要进行快速的角色转换，找到对方和自己认知的“最大公约数”，英文叫做“on the same page”。然后对于交流中需要补充的知识做简单的介绍，比如系统特点，专有名词的介绍等等，避免受众一路带着问号听你说，最后对话变成了“鸡同鸭讲”。
+
+举个例子。如果我们发现上游的订单数据有问题，那么我们可能需要找同组的人帮忙看。这时候，我们可以找组内相关的同事说，帮忙看看订单的数据是不是有问题。组内的同事对系统都是很熟悉的，不需要交代太多上下文。
+
+如果我们发现确实是上游的数据有问题，有些字段缺失了，需要上游系统配合帮忙查找问题。这时候可以发邮件给上游系统。我给出两个邮件标题，你觉得哪个更好呢？
+
+1. 订单数据在OrderProcessor引起异常
+1. 从3月15日起，来自Kafka的订单数据，缺失了OrderingTime，OrderName字段
+
+第一个标题，明显没有分清交流对象。OrderProcessor是自己组内项目的代码，这明显不是两个组的责任交界。数据在进入OrderProcessor之前，还有很多步骤，不能确定是上游发的数据的问题。难道你想让上游的组去看你的代码，帮你找自己代码的问题吗？
+
+第二个标题，很清晰明确。上游数据发到Kafka，这是大家责任的交界处。时间，问题也都交代得很清楚。上游的组完全可以以此为起点，向后查找自己的问题。
+
+简单来说，既要让对方听明白，也要让对方听到自己应该听的。交流不是应付差事，说完拉倒，也不要只顾自己说。
+
+### 交流要带有足够的信息
+
+我们来看一个教科书般的交流失败的例子：
+
+A问：“订单信息数据在HDFS上有吗？”
+
+B说：“有。”
+
+B的回答没错，但是也没啥用。A的问题明显是想知道订单信息在HDFS的具体位置，而非只是有或者没有。B如果知道具体在那里，就应该一并告诉A；B如果不知道，也应该回答“有，但是我不知道在那里。”如果B知道谁可能会知道，那么应该一并告诉A。这样，一次交流，基本就可以结束了。
+
+再以上面订单数据的问题举例。使用了正确的邮件标题，内容也要足够翔实。邮件内容应该包含如下信息：
+
+1. 证明订单信息并非一直缺失这部分数据，并拿出数据，附带数据的详细来源。
+1. 证明现在的订单数据并非所有的消息都缺失这部分数据，并找出缺失数据的消息ID和没有缺失数据的消息ID、时间等追踪信息，以便对方定位问题。
+
+用数据说话，数据出处要清晰；推理条理要清晰，事情的来龙去脉要清晰。有时候写重要的邮件和文档，就像写论文一样。
+
+### 先说重点和结论
+
+这一条规则适用于所有场合。日常中普通的交流也是，如果带着明确的目的，那么就要先说出自己的结论和想法；如果是写邮件和文档，内容翔实的一个副作用是难免冗长。这时候应该注意，先把结论抛出来，再写细节。如果是PPT类的演讲，也是先抛出结论和成果，再去涉及详细的内容。
+
+这样不仅可以让对方马上抓到重点，而且还可以让对方在有疑问的时候，可以带着疑问去阅读后续的细节。
+
+## 总结
+
+程序员的工作就像是产品。好的交流就像是包装，广告，公关和营销。有了好的产品，还要有好的包装，突出产品特点的广告，及时的公关和合适的的营销，才能赢得市场。没有这些，别人可能根本就不知道你有这么个产品，不知道这个产品能干什么，有什么特点等等。
+
+这里再总结一下，从输入这个角度来说，交流的好处可以分为以下几点：
+
+1. 获取更多的信息；
+1. 理解公司的业务；
+1. 加深对行业的理解；
+1. 发现新的机会。
+
+如果在交流中能够输出自己的内容，长期来看，给自己带来如下好处：
+
+1. 赢得自己的声誉；
+1. 树立自己的影响力；
+1. 赢得同事和经理的信任，承担更大的责任。
+
+充分的交流，并不是“就知道动嘴”，而是一个获取信息，加工信息，给出信息的过程。只有交流了，我们才能知道对方的想法，自己认为的好，可能并不是大家认为的好，自己没有想到的好处，别人可能想到了。我们在日常工作中应该多注意自己交流技巧的培养，养成喜欢和人交流的习惯。工作越久，交流在工作中的地位也就越重要。
+
+<img src="https://static001.geekbang.org/resource/image/34/27/34d9e3cbbc2920518d0f37b62d42af27.jpg" alt="">
+
+## 思考题
+
+你是一个喜欢交流的程序员吗？你有因为擅长交流而获得什么惊喜吗？欢迎你在留言区留言，我会和你一起交流，也欢迎把这篇文章分享给你的朋友或者同事，一起讨论一下吧！

极客时间专栏/geek/职场求生攻略/职业素养篇/04丨主观能动性：为什么程序员，需要发挥主观能动性？.md

@@ -0,0 +1,95 @@
+<audio id="audio" title="04丨主观能动性：为什么程序员，需要发挥主观能动性？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/66/36/6637a3d8edbe9bc85ea8473f8903bb36.mp3"></audio>
+
+其实关于这个主题，我也仔细想过，是放在生存发展篇合适，还是放在职业素养篇合适。最终还是觉得，作为程序员，发挥主观能动性应该算是一个基本的职业素养。
+
+很多时候，只要我们勤勤恳恳，认真负责地做好老大交代的任务，就算是一个合格甚至优秀的员工了。但是程序员这份工作，如果只是做到这一点，最多算是合格。由于软件开发的特殊性，一个任务完成的界限是非常模糊的，而且会根据具体的情况而变化。那么这时候，就要求程序员发挥自己的主观能动性，才能把事情做成，能够交付，而不仅仅字面意义上的“完成工作”。
+
+你可能会想，说得这么玄乎，是真的么？我们来看两个例子。
+
+## 数据清理和数据标准化背后的要求
+
+在一个数据处理和分析的项目中，有两个功能是对订单数据进行数据清理（data cleaning）和数据标准化（data normalization）。
+
+我首先简单介绍一下数据清理和数据标准化。我们要知道，来自不同的订单数据源的数据质量是不一样的。有的会缺失重要的信息，比如说购买者的ID、商品详情、订单时间等等。过滤掉这种缺失信息的不合格的数据，这就是数据清理。
+
+数据标准化则是对数据中的数据格式进行标准化转换。比如有的时间用毫秒表示，有的用秒数表示，有的用不同的格式“2020年5月15日 15点30分15秒”“2020-3-15 15:34:45”，有的甚至用不同时区的时间。再比如对于苹果这个品牌，有的数据用“Apple”表示，有的用“苹果”表示，有的用“苹果（Apple）”表示等等。那么数据标准化的任务就是要将这些数据转换成统一的格式。
+
+### 怎样才叫“任务完成了”？
+
+如果按照需求文档里的描述，我们完成了数据清理和数据标准化处理，这样是不是就叫完成了呢？如果你是负责开发的程序员，你还会做些什么呢？
+
+你可能会想到单元测试，代码覆盖率等。不错，这说明你已经是一个“摸着良心”干活的程序员了。那么除此之外呢？还有什么可以做的呢？如果就这么交付出去可以吗？
+
+一个有经验的程序员会想到，这种功能可能会用到不同的计算框架上，比如 Spark、Flink 甚至 是Hive。而之前蹚过的坑会告诉他，不同的计算框架内置的Jar 包的版本都是不一样的，自己的程序要能够尽可能少用兼容性差的 Jar 包。那么也许他就会在开发期间，跑去问相关的用户，这个功能可能会跑在什么框架的什么版本上，然后按照计算框架的版本，确定自己使用的 Jar 包的版本。当然，系统架构设计等也是一个需要用心的地方，我们在后面再细聊。在这里先不涉及。
+
+做了这一步，用户集成的过程就会顺畅很多，虽然你自己确实付出了一些额外的时间，但可以帮助整个项目的进度不被 Jar 包兼容性的问题所阻塞。
+
+当然，从责任上来说，功能是否要适配到不同的计算框架，应该是在需求上写清楚的。但是道理归道理，实际归实际。没有人能把所有的细枝末节都考虑全面，互联网时代，软件开发和迭代速度并没有给我们这么宽裕的时间。
+
+如果因为各种需求没有说清楚，导致最终做出来的功能无法使用，我们程序员虽然可以把锅甩出去，但程序员作为一线工作人员，很多细节可能只有走到那一步的时候，才能想得全面。如果一个程序员做事情永远只知道按照需求中写的做，不多考虑一分，实际上就是自己的失职。从结果上看，就是程序员没能交付自己的工作。长期如此，是很难成长为一名合格的、让人觉得可靠的程序员的。
+
+站在用户的角度试想一下，如果用户的这个项目要在 Spark 上用到两个功能。一个功能出现了各种 Jar 包版本兼容性问题，各种跑不起来，各种修改 Jar 包版本，甚至还需要修改代码，整个集成过程从原计划的三天拖延到了三周。另一个功能一下就用上了，一点毛病没有，原计划三天的集成时间，一天就搞定了。你会给这两个功能打多少分呢？又会倾向和谁合作呢？
+
+当然，这里的例子其实是一个比较明显的例子，确实应该在需求中写清楚平台和版本。但是在程序员的工作中，确实有很多我们需要考虑的细节，有很多考验我们“良心”的地方。发挥自己的主观能动性，多为用户考虑一点，是评判一个程序员是否合格的重要标准。
+
+### 一个合格的Dashboard是怎样的？
+
+聊完了数据清洗和数据标准化，我们接着聊下一个需求。这个需求是设计一个Dashboard，把每天的销量和销售额用一个Dashboard展示出来。
+
+这个需求看似很简单，就是把数据按天展示出来嘛。按照需求，我们先原封不动地作出一张如下图所示的Dashboard。
+
+<img src="https://static001.geekbang.org/resource/image/e7/61/e768fcec1e1f9bfa5e0cb5f6c0c25361.png" alt="">
+
+我相信，大部分用户看到这个图，第一个问题都会是：怎么就一根线？你可能会说，我确实把销量和销售额都展现在图上了啊，按照需求做的没毛病啊。用户有问题那是他们需求有问题，用户只看到一条线那是用户不会看。
+
+这种看似忠于需求的工作态度，其实并不能真正地让用户对工作成果感到满意。当然，程序员将需求做出来了，确实只是如此，没有人能挑出毛病，但也不会有人喜欢跟这种程序员合作。
+
+为什么呢？正如上面的例子所说，在互联网快速迭代的今天，需求可能不会那么细致。我们依然要站在用户的角度看问题。
+
+那么这张图到底有什么毛病？
+
+在上图中，因为销售额比销量大很多，销量被销售额的数字“压”得几乎成了一条底部的直线。那么这样一来，有一个很明显的事实就是，销量这根线，已经不能传递任何信息了。除非用户是列文·虎克，有耐心还喜欢拿着显微镜看报表。
+
+所以用上面两个例子我想说明什么呢？
+
+完成明面上的用户需求，仅仅只是我们工作的合格线而已。一个程序员应该基于需求，把自己的触角延伸到需求之外，交付用户真正想要的东西。比如给报表增加按照对数设置Y轴坐标的功能，让数据相差特别大的两根线，也能在同一个Dashboard里展现自己的“曲线”，如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/e5/5d/e5b6b055996aa9032ac1633cf65a775d.png" alt="">
+
+我相信，任何一个用户都会更喜欢第二种方案。虽然需求没有明确说要支持这种功能。但是从交付的角度，第二种方案才能对用户产生实际的价值。
+
+那么前面通过两个例子，我描述了一下程序员这个工种对发挥主观能动性的要求。下面我们来谈谈如何发挥主观能动性。
+
+## 如何发挥主观能动性
+
+其实发挥主观能动性的方式会随着程序员具体工作内容的变化而变化，比如说前端工程师、后端软件开发师、架构师等等。但总有一些东西是共性的，那么在这里，我就说说我的几点建议以及需要注意的东西。
+
+我在上面反复强调交付思维，所以我觉得这一条应该列在第一位。
+
+### 交付思维
+
+发挥主观能动性，究其核心，我觉得就是一点：站在用户的角度，交付用户想要的东西。也就是说，不能止步于用户的需求。程序员作为冲在第一线的人，对细节的掌握是最多的。我们需要依靠这些细节，结合用户的需求，理解用户需求背后真正想要的东西，然后努力向这个目标发展。
+
+正如前面的两个例子，其实做得好的标准，就是理解用户没说出来的需求，能够为用户着想，交付用户想要的东西。
+
+### 注意时间
+
+发挥主观能动性的一个代价，就是会用掉更多的时间。这方面一定要注意。比起功能的完美，在规定的时间内实现基本功能，才是优先级更高的事情。
+
+假如你突然对一件事情有了想法，但是时间来不及，或者不确定是不是对用户有价值，那么可以及时和用户交流。如果用户觉得这个细节确实很重要，即使延期也值得做，那么大家可以商量新的时间线。如果用户觉得可有可无，或者可以放在后续迭代来做，那么就专心做好需求里描述好的功能。
+
+程序员在发挥主观能动性的时候，也难免会“夹带私货”。比如说，自己想用个什么新技术，试试不同的做法。这时候也要注意时间。用户可能一时无法理解新东西给自己带来的好处，但是用户肯定知道项目无法按时完工的坏处。所以在“夹带私货”的时候，一定要保证自己对项目的进度有所把控，不要因为自己的私欲让整个项目无法完成。
+
+## 总结
+
+程序员这个职业，已经远远延伸到了写代码之外。对内我们要DevOps，对外我们要交付对用户有价值的东西。而发挥主观能动性，就是帮助我们做对用户有价值的事情。程序员接到需求之后，要进一步理解需求背后的用户意图，理解用户的问题。
+
+正所谓，将在外，军令有所不受。又有言：让听得见炮声的人决策。程序员就是那个拿着作战目标，冲在一线，能够听得到炮声的人。面对系统实现时各种复杂的情况，我们有责任，也有义务发挥自己的主观能动性，达成最终的作战目标。
+
+<img src="https://static001.geekbang.org/resource/image/5b/f6/5b6aaf94e387a5f4767519d6df7c60f6.jpg" alt="">
+
+## 思考题
+
+你在工作中，有发挥自己主观能动性的习惯吗？有发挥自己主观能动性的场景吗？
+
+欢迎你在评论区和我分享你的留言，也欢迎你把这篇文章分享给你的朋友或者同事，一起交流进步一下。

极客时间专栏/geek/职场求生攻略/职业素养篇/05丨责任的边界：程序员的职责范围仅仅只是被安排的任务吗？.md

@@ -0,0 +1,95 @@
+<audio id="audio" title="05丨责任的边界：程序员的职责范围仅仅只是被安排的任务吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/20/91/209c3e6afde31fd2951cfee332ee5291.mp3"></audio>
+
+我们要知道，在现代社会，责任一般是和钱挂钩的。
+
+我举一个例子。现在很多ERP软件都提供SaaS的服务。一个公司如果要使用这个SaaS服务，即便免费的额度已经够用，大多也会选择付费。为什么呢？其实花钱就是为了买个对方的责任。不付钱，看似节省，但如果真的出了问题，比如数据丢失、数据泄露等，那么对方是没有责任或者义务帮你修复的，但花钱就不一样了，一旦出现数据安全、数据稳定相关的问题，服务提供商都是要担责的。
+
+那么同理，我们参加工作，和公司签了合同，有了工资。工资的背后，就是“责任”二字。
+
+任何拿了钱的事情，都要负责——这是一个最基本的社会规则。
+
+## 程序员需要对哪些事情负责
+
+看到这里，你可能会有疑问，这还用说吗，我对自己的工作负责不就好了？可是我们的工作边界在哪里？“工作”仅仅指的是在公司内的工作职责吗？
+
+首先，我认为，身为程序员，我们的工作边界及其范围包括3个部分，分别是个人的基本能力、工作内容以及工作时间。
+
+### 对自己的基本能力负责
+
+首先，程序员要对自己的基本能力负责，基本能力主要是技术能力和熟悉公司系统的能力。
+
+**持续精进技术能力**
+
+技术能力就是工作中用到的技术，是我们看家的本事。公司毕竟不是学校，没有教学的义务。既然拿了工资，就要学会相应的技术，完成安排的工作。
+
+我在工作中也遇到过一些人，很多基本技能都不会，自己还没有任何补短板的意识和动作。安排工作的时候，直接甩出一句：我不会。理直气壮，令人惊叹。久而久之，大家对这个人的印象就是——没有工作能力。
+
+当然，很多时候，并不是所有的技术需求都来得那么强烈，也不是所有的技术每个人都熟。我们在实际工作中，也难免会遇到自己不会的问题。这个时候可以向别人请教，但是千万不要觉得请教完就算完了，我们还要意识到自己为什么不会，想办法补齐这块的知识和技能。
+
+如果一个事情不会做，那么基本上就相当于“违约”了。
+
+但如果公司安排确实不合理，工作岗位不能发挥自己的能力优势，这种情况下又该怎么办呢？我的建议是，首先还是考虑发挥自己的优势，再抽时间补短板。态度要积极，不能摆出一副“我不会我有理”的态度。但如果新的工作全是短板，技术不熟悉，业务不熟悉等等，那么不妨和经理和HR聊聊转岗的可能性。
+
+除了补短板之外，我们更可能遇到跟随公司做技术转型，学习新技术。如果是一些重要的公司层面的技术转型，有些公司可能会安排培训，或者给出一定的激励措施。当然，如果公司没有相应的政策，那么自己也是有责任把技术学起来，胜任新的工作的。
+
+其实公司技术升级，也是给自己的技能升级的好机会。我一直强调的一点是，学的东西一定要在实际工作中使用，因为这样最能够激发学习的积极性，也最能验证自己学的成果。公司决定转型采用的技术，也大都会比现在使用的技术更优秀。很多工作久了的同学会抱怨说工作中用不到新技术，如果遇到公司技术转型升级，赶紧抓住机会努力一把，给自己的技术也升级一下。
+
+就我个人的例子来说，我学会Hadoop、HBase、Hive、Spark、Scala和JS等等很多技术，都是抓住公司新的项目要用到新技术的机会，“强迫”自己学下来的。有些项目公司会留一部分学习的时间，大部分情况下全靠自己挤时间学。一边学，一边通过公司项目的实际操作来考验学习成果，过程非常的充实，学得也牢固。
+
+所以公司技术升级，对我们个人来说，其实是一个非常难得的机会，如果你有遇到过，那么请一定要抓牢它。
+
+**熟悉公司的内部系统**
+
+很多公司都有自己的内部系统，熟练掌握和使用这些系统，也是我们程序员的责任。
+
+在有些程序员看来，公司内部的系统不能算技术，因为这些东西不是通用的，就算学了对以后找工作也没什么用处，所以一般对内部系统的学习积极性并不高，甚至有些排斥。
+
+但能够熟练使用内部系统，也是拿工资后要承担的一部分责任。公司内部系统的价值在于，它们一般都是和公司的整个框架集成好的，比如公司内部的SOA框架或者微服务框架，都是和公司内部的监控系统等等集成好的，即使这个框架再“不好”，公司内部的项目还是要使用，这样我们才能够在宏观上建立对公司内部所有服务进行的理解，从而更好地利用自己的技术，不至于“盲人摸象”。
+
+撇开硬性工作要求不谈，事实上，有些公司的内部系统，做得还是很优秀的，甚至于让人离职之后还很怀念。积极学习公司内部相关的系统，也是自己在这个公司的收获之一。以后如果有机会在别的公司从事相关系统的开发设计工作，也可以借鉴学习。
+
+你看，这同样也可以提高我们工作的基本能力。
+
+### 对安排的工作负责
+
+说完我们个人的基本能力之后，接下来，就是我们非常熟悉的内容了，工作责任。无论什么职业，都要对安排的工作负责。
+
+程序员这门职业的特殊性在于，工作本身的具体内容和难度，会随着被安排的工作内容的改变而改变。从对工作负责的角度来说，我们大部分人会付出比当时预想的更多的时间，才让自己能够按时完成工作。
+
+当然，这里并不是鼓励加班，只不过是一个小建议，如果你有额外的付出，那么到时候可以将自己做的计划外的事情说出来，这样一方面让大家认可你做的工作，另一方面，也是能够让大家对这类事情的工作量估计更合理。
+
+当然还有另一种情况是，事情超出了自己的能力范围，比如一件事情的复杂度远超过之前的估计，在规定的时间内，自己确实无法完成。那么这个时候，正确的态度不是硬着头皮上，而是将情况理清楚，早点找经理或者负责人，让他们知道事情的进度和之前没有预想到的难度，把事情重新安排一下。毕竟，谁也不能承担“到了deadline事情还没有做完”的风险。
+
+从管理者的角度来看，一个事情安排得不合理，就应该早发现，早计划，重新安排资源。毕竟大家的目的是把事情做完，而不是冒着事情可能做不完的风险去压榨一个人。
+
+当然，还有一种情况就是，给自己安排的事情实在太多了，自己没有时间完成。这时候，一方面要自己思考事情的优先级，这点我们之前也讲过，另一方面要及时和经理沟通，建议将优先级低的向后推，或者找别人来帮忙。总而言之，不要在最后给经理“惊喜”。
+
+很多新人可能很难把握这样一个度，什么叫“偷懒耍滑”，什么叫努力负责呢？在工作经验不丰富，技术能力也相对薄弱的情况下，怎么才能知道事情有没有“失控”呢？
+
+我的建议是，当遇到自己吃不准的事情，可以多问问组内资格老的同事，如果老同事说问题不大，那么自己也更有底气。如果老同事说这个问题自己也没有遇到过，那就得找经理聊聊下一步的安排了。
+
+### 对工作时间负责
+
+很多软件公司，其实都是弹性工作制。毕竟程序员这个工种要求一直在线，有时候出了问题，随时随地掏出笔记本就得开干。既然没有一个明确的“下班”时间，那么很多公司也就不规定硬性的上下班时间了。
+
+这里说的“对时间负责”，也是因公司而异的。我的建议是，一定要在“实际上班”时间之前到，避免有人找你却找不到的情况。比如说，大部分人都是在九点半之前到公司，那么你也尽量在这个时间左右到公司，不要延迟太久。
+
+还有就是如果有会议，一定要准时参加。如果临时有事无法参加，要及时和大家同步。
+
+对时间负责的背后，其实不止是为了保证工作时间。毕竟我们程序员都知道，坐在座位上并不代表就在工作，没在座位上也不代表没有在工作。这里想强调的一点是，程序员的工作不只是写代码，还有很大一部分是交流沟通，保证基本的工作时间，才能更多的和大家交流。
+
+## 总结
+
+随着级别的升高，程序员的工作也更丰富，从不同的角度来看，也会有不同的责任。比如我现在担任组里的技术主管，除了要做好安排的工作之外，还要协助组里的同事完成工作，同时要思考如何推进系统的技术升级，以更好地满足用户的需求。对于级别更高的同事来说，还有更具有挑战性的责任。付得起责任，才对得起自己那份工资。
+
+俗话说：受人之禄，忠人之事。责任是一点点增加的，负责任的态度和习惯，也是从平时工作中的一件件事情中养成的。当你养成这样一种习惯之后，你会收获一个别人对你的金字评价：这个人，负责，靠谱。
+
+如果你承担的责任更重了，那么距离你加薪升职还会远吗？
+
+<img src="https://static001.geekbang.org/resource/image/63/6e/63d3bcf51ac687a1853a5eb73f01d56e.jpg" alt="">
+
+## 思考题
+
+这里给你留一个思考题吧。你觉得程序员还有那些基本的责任？就文中的内容而言，你觉得你是一个负责任的程序员吗？
+
+欢迎你在评论区与我分享你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职业素养篇/06 | 职业素养篇热点问题答疑.md

@@ -0,0 +1,99 @@
+<audio id="audio" title="06 | 职业素养篇热点问题答疑" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0e/11/0e8a94726e85adb06e4a9ff3c47fe011.mp3"></audio>
+
+你好，我是臧萌。转眼之间第一个模块就结束了，这个模块讲了我们在日常工作上遇到的问题，也引起了很多同学的共鸣，在评论区纷纷说出了自己的苦恼。我觉得有些话题非常值得展开讨论，
+
+## 有关优先级的那些事儿
+
+优先级这个话题牵涉到很多人，不止有自己的，还有合作方，乃至领导的。有些同学在评论区中说到，会因为优先级的事情和经理有争论。
+
+我的建议是，不要跟经理就事情的优先级有太多争论。
+
+什么意思呢？并非说不能交流，交流是很好的一个过程，也是帮助我们理解经理决定的过程。交流 = 沟通事实，同步信息，表达自己的意见和想法。但是交流之后，就听经理的判断，不需要再跟经理争论。因为决定事情的优先级是经理的一项重要的权利。这个权利就好像将军有军队的指挥权一样顺理成章。
+
+### 交流技巧之逼出对方心里的优先级
+
+@峰 同学说，需求方每次都说事情很急，但是他做完之后，对方就没动作了，这样很打击积极性。
+
+我的建议是，如果你的客户只有这一个需求方，我建议你给出任务的工作量估算，然后让对方给出优先级，这样就能“逼”出对方心里真正的想法，哪个活儿重要，哪个活可以适当延后，你自己干活也更有目标性。当然，有时候对方可能也没有仔细思索优先级，只是惯性地把事情压给你而已。这时候你这么倒逼对方一下，也可以让对方更好地思索一下事情的重要程度。
+
+比如说，可以这样：“taskA，3周；taskB，5周；taskC，2周。现在还有一个月，这边有俩人，也就是8个周的工作量。你自己选吧，哪个可以延期。”
+
+当然，对方可能说“不行你就得加班撒……”你就说：“这个已经算上加班了。”
+
+## 做好自己的事情，负好自己的责任
+
+@jhren 同学问，自己的工作被阻塞了，自己催没用，经理不帮忙催，怎么办？
+
+我站在利益和换位思考的角度说说我的观点。
+
+老板的一大职责就是搞定人，搞定关系，搞定非技术的事儿。如果你老板知道这个情况，还想躲在后面，站在经理的角度，从利益最大化为出发点，他这么做有3种可能性：
+
+1. 他觉得这个事情并不值得他出面，或者说他觉得这件事做成的好处远远小于他“得罪”阻塞你工作的人。
+1. 他本身就不想这个事儿能办成，但是也不能什么都不做，明知不行还把下面的人推上去，让你去催。
+1. 他本身知道这个事儿成不了，他出面也摆不平，他也不想趟这趟浑水。
+
+你作为最下面的执行者，可以发个邮件给到协同的同事：大家好，请大家把事情定下来之后通知我一下，我可以继续下面的工作。非常感激大家的通力合作。
+
+你自己呢，就是做好自己的事情，负好自己的责任。守住一个职业人的底线就可以了。
+
+## 邮件在现在到底还适不适用？
+
+@再来二两杜康酒同学 问，发了邮件没人理怎么办。
+
+也就是说，邮件没效果怎么办呢？我给出一个标准组合拳：
+
+1. 抄经理，抄对方经理，目的就一个字——催；
+1. 开个会，仔细聊，聊不清楚继续聊；
+1. 列出事情的优先级，列出事情不做的影响，给对方施压。
+
+除了这个问题外，还有相当一部分人在说，现在已经不用邮件了。比如@Kǎfκã²⁰²⁰就提到了这个问题。
+
+这里要为这位同学的公司点个赞，就好像文章里说的，邮件并不是一个高效的沟通工具。相信你工作中用的工具更高效。
+
+我写这篇文章的时候专门找字节跳动的同学聊了聊，飞书确实很不错。大家也表示，在字节不扯别的，就是干！不过，确实也是累。交流的效率上去了嘛，自然有更多的时间干活了，可以更快出成果。但是呢，慢也不是一无是处，慢可以让给我们留出更多的时间去全面地思考问题。
+
+总之，“邮件”的逻辑也还是在那里的。同步的沟通更高效，异步的沟通更需要深思熟虑，要为自己给出的话负责任。
+
+## 内向的程序员如何沟通？
+
+@chewbee 同学问，内向的同学如何养成主动交流的习惯呢？
+
+我觉得我和这位同学挺像的。我给出一些我自己的建议吧。
+
+首先还是态度上的转变，我们要把交流沟通当作做事情的第一步，而不是把做具体的事情作为做事的第一步。现在我把“和人交流”放在比“做具体的事情”更高的优先级上。也就是说，不把事情弄清楚，就不开始做具体的事。这样一方面是为了把事情做对，另一方面来说，对于写了那么多年程序的人来说，在知道怎么做的前提下，做事本身没有什么挑战了。而弄清事情的前因后果，弄清要解决的核心问题，才是更有挑战的工作内容。
+
+其次，我在直播里也提到过，对于内向的人来说，可能很难忽然转变，跟谁都能聊得无拘无束。其实这样也没关系，我们可以在经常合作的部门里，找一两个固定的人交流，作为起点。比如自己组里的经理，架构师，或者是比较熟悉组里情况的同事。别的组里，也可以是一些资深的员工或者架构师等职位的人。不要觉得对方和自己交流是耽误对方的时间。我的感觉是，大部分的架构师，经理以及资深的员工，都非常愿意和人交流。当然，如果有那种不愿意和人交流的，那你下次换个人就是了。
+
+最后，别和人张口就是工作，没事儿可以和别人打个照面，打声招呼，随便聊聊别的事情，游戏，生活，电视剧，八卦，军事，音乐，运动什么都可以，只要是双方都感兴趣的。这样非常有利于拉近彼此的距离，减少陌生感。
+
+## 让别人看到自己的工作
+
+@牛牛 同学有个问题，说自己做的事情都是小事情，又很繁杂，那么如何优雅地让自己做的事情让别人看到。
+
+这里，我可以给你出个主意。小事也是跟大事相关的，这些琐碎的、浪费时间的事情，为什么不得不处理呢？就是因为跟这些事情相关的更高层级的事情更重要。把自己做的事情跟这些重要的事情关联起来，就显出自己做的事情的分量了。
+
+我随便举个例子。比如说是给业务增加新的API和数据表。你如果只是单纯地说“增加了一个表，添加了几个API操作表里的数据。”这样谁看着都枯燥，也突出不了自己的贡献。从技术角度看，也就是CURD，没啥好说的。
+
+如果你在做API和数据库表的时候，多跟业务方聊两句，问问这个API是给哪个项目的，是干什么用的等等，那你报备的时候就可以这样说：“为公司重点项目购物车二期新增三个API，一个购物车数据表，提供了购物车二期项目中对Android和iOS应用中购物车操作的支持。”
+
+所以，觉得做的事情没意思的时候，就问问业务方的目的，因为我们做的东西都是业务提供的。正如你说的那样，注意沟通，沟通让你获取更多的信息，see the big picture。
+
+@咸鱼翻身记 同学也提到类似的问题，他解决了很多系统遗留的技术债，做了优化，而且写了文档。
+
+这里必须点一个大大的赞，同时也建议你，记得总结并跟大家分享自己的工作成果，这样一方面可以让大家了解相关的改进，另一方面也让大家了解自己的贡献。
+
+这还牵涉到了另一个问题，@LDxy 问，要不要把自己想做的额外的东西说出来。
+
+说，必须说，而且要先说再做。想做的东西，先跟需求方交流，看自己理解的对不对，对他们来说有没有价值。
+
+这个也和之前说的交流有关系。自己对问题的理解和解决方式有了新的想法时，应该先跟需求方确认自己的想法是否正确，做出来是否有价值。这样，对自己发挥主观能动性，是一个巨大的正反馈。如果只是自己的理解，做出来用户不买账，反而很打击发挥主观能动性。
+
+所以我们不能玩霸道总裁向，不能说“我不要你觉得，我要我觉得”。而是要玩霸道码农向，要说“我不要我觉得，我要你觉得”。快给我觉，我说的这个怎么样，有没有感觉，这个feel对不对。不对我们继续聊。
+
+作为结尾呢，我分享一位同学的评价，他说我“可以把挺多讲出来很容易负能量满满的道理，用一种充满正能量的视角合乎情理地表达出来。”
+
+我觉得说的还挺贴切。这也是我这门课的一个目标。说说职场上的这些事，进而理解这些事背后的道理和职场的逻辑，让大家在职场的路上走的更顺畅一些。俗话说，世界上只有一种真正的英雄主义，那就是在认清生活的真相后依然热爱生活。
+
+把这句话的“世界”换成“职场”，把“生活”换成“工作”，也挺对味儿。大家品品：职场上只有一种真正的英雄主义，那就是在认清工作的真相后依然热爱工作。
+
+以上就是答疑篇的内容，不知道有没有解决你的困惑呢？欢迎你在评论区与我交流你的想法，也欢迎把这篇文章分享给你的朋友或者你的同事，一起来交流一下。

极客时间专栏/geek/职场求生攻略/职业选择篇/07 | 职业规划：如何选择一个公司？.md

@@ -0,0 +1,99 @@
+<audio id="audio" title="07 | 职业规划：如何选择一个公司？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/51/8f/5119992070e8913cd02612b3e36bdd8f.mp3"></audio>
+
+“哪个公司好”，一直是职场圈内人们津津乐道的话题。每个人自然是想进入一家好的公司，既有前途，也有钱途。
+
+但其实一家公司的好坏，除去客观情况之外，更多的是个人的主观感受。甲之蜜糖，乙之砒霜，别人口中的“好公司”未必适合你。
+
+那么在今天这篇文章里，我就来谈谈选公司这件事儿。这里说的公司是指有一定规模，发展稳定的公司，创业公司我们会有一篇文章专门谈。两篇文章看完之后，相信你会对自己的选择有更清晰的方向。
+
+在我看来，要想选择一个适合自己的好公司，需要考量如下几个角度。
+
+## 企业文化和价值观
+
+你可能会想，为什么首先是文化啦，价值观啦这么虚的东西呢？我们就是打工干活拿工资，为什么要关心这虚头巴脑的东西呢？其实这个东西一点都不虚，文化和价值观，上至公司管理层，下到员工在作出各种大大小小的决策的时候，起着重要的作用。一个具有一定规模的公司，一定会有一套企业文化和价值观，指导公司上下行事。
+
+无法适应企业文化和价值观的员工，注定会被边缘化，获取不到资源，直到被淘汰。而适应企业文化和价值观的员工，在公司做事情则更能够得心应手。
+
+我拿亚马逊举一个例子吧。
+
+亚马逊的文化非常有名，大名鼎鼎的“14条领导力准则”相信你一定听说过。读完这“14条领导力准则”，基本上你就能感受到亚马逊工作的风格了。我随便列出几条：Deliver Results（完成业绩），Customer Obsession（顾客至上），Bias for Action（崇尚行动）。如果不能够认同并适应亚马逊的这些准则，那么在亚马逊工作将是非常别扭的。
+
+拿“顾客至上”来说，在亚马逊工作，on call是每个人都必须的，on call就是服务顾客以及用户的。亚马逊有一套专门的 Ticket 系统配合on call，任何亚马逊的员工，在使用相应的内部系统的时候，比如库存管理系统，都可以开 ticket 上报问题寻求支持，并且由用户自己指定 ticket 的优先级。如果优先级高，那么库存管理系统的 on call人员就会收到短信，并需要在30分钟内登陆到 ticket 系统，作出响应。否则on call人员的直接经理就会收到系统电话，如果经理没有及时反应并及时找人处理 ticket，那么再过30分钟，总监也会接到电话。问题升级的次数（Escalation） 和 Ticket 的数量，都会纳入到绩效。
+
+所以亚马逊的“顾客至上”，不是说着玩的，“customer”是不分内外的，是落实到每一个Ticket的处理和响应的，是落实到整个管理层级，是要反映到业绩的。
+
+### 如何选择适合自己的企业文化和价值观
+
+要想评价一个人，并不能只看这个人平时的行为举止，更是看这个人遇到关键事情的时候，会作出什么样的决策。公司就好像一个人，公司的文化和价值观其实就代表了这个“人”的品质和性格。公司里的每个人，都是公司里的细胞，被这股力量裹挟着，需要做出符合企业文化和价值观的决策。我相信亚马逊的这一套 ticket 系统，绝不是一蹴而就的，而是在企业文化和价值观的影响下，逐渐形成的。我们国内公司的价值观也各有特色，比如鹅厂的内部竞争和华为的狼性文化。
+
+企业文化和价值观要的就是一个贯彻执行。比较普遍的几点是，大部分的公司都会强调服从上级，强调奉献。但是根据我的经验，大公司内部不同的部门，具体的风格上也会略有不同。对程序员来说，会相对宽松一些。
+
+如果你打算在一个公司长期发展，不妨先找找里面的熟人，聊聊公司内部做事的风格，比如晋升，奖金，淘汰，组内合作，跨部门合作以及如何处理各种意外情况的“八卦”，这样就能实际地感受到企业的文化和价值观了，然后再根据自己的标准，判断是否适合自己。
+
+## 行业势头
+
+除了公司价值观之外，“行业”也是选择公司时要考量的重要因素。一个行业一般都有风口期，黄金发展期和下降期三个阶段，我们分别来聊聊。
+
+### 下降期的行业
+
+首先，已经处于下降势头的行业要慎重考虑。举个例子，早在七八年前，通讯行业的发展已经显露出疲态了，当时我在的公司来了一位从头部的通讯公司跳槽来的经理。第一次开会大家闲聊，就问，他为什么愿意从这么有名的公司跳出来，甚至还换了行业。他回答得很直白，因为自己感觉通讯行业的黄金时代已经过去了，而互联网行业现在的势头，就像是通讯行业处于黄金时代时的样子，所以他要主动求变，投入还处在上升期的行业。
+
+如果你只是短期的谋生，那么行业的势头可以不用考虑太多，但如果选择一个长期发展的公司，行业势头是必须要考虑的因素。
+
+### 风口期的行业
+
+互联网行业的风口每隔一两年就会来一个，甚至有时一个来好几个，应接不暇。我就随便说几个：云计算、移动互联网、社交、在线支付、电商、搜索、游戏、出行、短视频、机器学习、区块链、共享经济等等。
+
+如果你之前从事的行业就跟新的风口有关系，知道深浅，那么不妨试试新的风口。比如说，原本就是做支付的，那么当在线支付、移动支付、刷脸支付等等风头起来的时候，不妨带着自己的行业经验去看看，没准就能抓住一个好的风口。
+
+但如果你对这些风口背后的行业不是很熟悉，不妨等风口的势头明朗了，再做打算。前面列出来的那么多风口，每一个出现的时候都是风光无两，带着“颠覆性的使命”出现的。但是并不是每一个都能从风口发展为一个行业，比如说“团购”，当时这个风口可以说是席卷全球，在中国甚至有“千团大战”。但是现在这个概念基本上消失了，团购也不再是一级入口。再有就是区块链，现在还是很热，但是迄今为止还没有除了炒币之外成熟的盈利模式和业务场景。
+
+### 黄金发展期的行业
+
+那么最后再聊聊还处于黄金发展期的行业吧。相比之下，很多行业的发展已经稳定，有了盈利模式，而且行业还在持续发展。如果正好对这些行业有兴趣，不妨选择这些行业的公司。在一个行业积累的经验，会在行业发展上升期变得越来越值钱，相反，如果一个行业已经式微，那么积累的经验也就会随着时间变得越来越不值钱。
+
+## 工资待遇
+
+当然了， 前面说了那么多，我想你最关心工资待遇。工资待遇当然也很重要，但是工资待遇里面也有很多道道，我们来聊聊这些门道。
+
+我们都知道，工资待遇不仅仅包括固定工资，还有一次性收入、奖金、股票以及各种福利等。在这里面，固定工资是最重要的，这个才是受法律保护的收入。因此在面试公司时，一定要问清固定工资是多少，免得被忽悠。
+
+除了固定工资外，很多公司会给新入职的人一些一次性的奖金，显得待遇好一些，比如搬家费，签字费等等。这些基本上都只是一次性的，有时候还会附加“规定时间内不能离职”等各种约束。所以这部分钱的性价比比较低，但是一般钱还是不少的。如果是刚刚来到一个城市，这笔钱能解决不少问题。
+
+至于奖金，大概是除了固定工资之外我们最关心的东西了。事实上，奖金这个事情要看公司的良心，因为奖金是有很大操作空间的，谈offer时约定的数字未必能给你，这个受到工作表现、公司营收等等各方面的影响。即使发，也可能会推迟。
+
+至于人人都关心的福利，那就千差万别了，福利一般是商业医疗保险、年假、体检、补贴等等。福利的内容会随着公司的行业而灵活变化，非常具有公司特色，比如蚂蚁会有无息房贷，出版社一般会有免费图书等。这个就看你个人的兴趣了，选择空间也会比较大。
+
+那么股票呢？我们这里主要谈股票，不谈期权。期权的水太深，说不清。不同公司给股票的风格也是不一样的。
+
+大多数时候，我们国内的大公司给股票的风格都是入职给一大波，显得offer好看。这一大波股票分四年给，但是后续可能不会再给股票，或者就算给也不会给那么多。所以这个股票就相当于一个有效期为四年的奖金。当然，在这种情况下，公司一般都会给得比较多，如果四年之后公司发展很好，甚至上市了，这也是一笔不少的钱，但是如果四年之后不再给股票，收入相当于会掉下一节。
+
+总之，工资待遇项目繁多，选择一个公司之前，要弄清这个公司给的待遇的组成部分。
+
+## 公司规模
+
+很多人的梦想就是去“大厂”，公司规模也是影响选择的重要因素之一。如果待遇和岗位差别不大，建议优先选择头部大公司。这些公司的成功自然有自己的独到之处。在头部公司里，你可以学到更多的经验，接触更有挑战的业务场景，也会让自己得到更快的成长。
+
+如果你看好一个行业，那么就要努力进入这个行业的头部公司。
+
+## 人才水平
+
+不可否认的是，每个公司对招聘的人才的水平要求是不一样的。一个公司的人才水平，决定了公司对人才的态度和公司内部合作与管理的风格。
+
+举个例子，如果一个公司里程序员的水平都很一般，那么这个公司就更倾向于不相信员工的技术能力，并制定非常细致和严格的管理规范和流程，避免员工犯错。如果你的水平高，就会被各种管理规范和流程束缚住。同时，如果你发现与你合作的人的水平都很“感人”，你也需要调整自己的风格，让自己的工作成果能够适应公司普遍的水平。
+
+当然，反过来也是一样的。如果勉强去一个技术能力很强的公司，难免会发现自己水平差距太多，工作很吃力。当然，正所谓见贤思齐，如果自己能奋起直追，自然是好的。
+
+## 总结
+
+说到如何选择一个公司，大部分人的答案应该就是两条：名气大，给钱多。通过这篇文章，我希望你能够在换工作之前思考得更加长远。
+
+我见过很多在之前公司表现极为优异的人，换到另一家公司就表现平平，甚至有些人的表现竟然差到要被末位淘汰。也见过很多能力很强的同事，只想要更多的钱，不注重自己的积累，以至于发展受到限制。
+
+所以选公司是个非常个性化的事情。当自己在一个城市站稳脚跟之后，不妨做个长久的打算，找个适合自己的，能够在里面长期发展的公司。
+
+<img src="https://static001.geekbang.org/resource/image/fa/f1/fa8e648c1d0a2a90ab1e26597f7b53f1.jpg" alt="">
+
+## 思考题
+
+看完今天的文章之后，我想问问你，你在换工作选公司的时候，都会考虑哪些方面的因素呢？欢迎在评论区和我交流，也欢迎你把这篇文章分享给你的朋友或者同事，一起交流进步一下。

极客时间专栏/geek/职场求生攻略/职业选择篇/08丨管理者关系：怎么才叫“跟对人”？.md

@@ -0,0 +1,106 @@
+<audio id="audio" title="08丨管理者关系：怎么才叫“跟对人”？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c8/32/c8a0dd1fcf91a65315c545e1af757d32.mp3"></audio>
+
+职场两大幸事就是跟对人，做对事，也就是在一个值得跟的经理下面，做有价值的事情。这就好像是千里马遇伯乐，而好巧的是伯乐管着一个赛马场，带着千里马用来赛马而不是用来驮货。
+
+其实一般来说，只要跟的人非常好，那么做的事情一般也是可以接受的。但反过来，如果跟的人实在是不行，那么如果有更好的机会，可以考虑求变。
+
+但每个经理都有自己的风格，对于身为程序员的我们来说，怎样才叫跟对人呢？今天，我们就从一线程序员的角度，谈谈这个话题，希望对你选择工作和公司有所启发。
+
+下属和领导，某种程度上来说是互相成就的，你们认可彼此的价值观和人格，也可以就一个问题互相讨论，甚至争论，他还会和你定期沟通，合理地安排资源和利益。
+
+那么，我们分别从这四点详细说明一下。
+
+## 认同彼此的价值观和人格
+
+你可能觉得这太虚头巴脑了，咋还放在第一位呢？其实不然，我们中的大多数人会被直接经理所影响。
+
+比方说，一个经理每天都要求别人按时上班，但自己吃完午饭才来。作为他的下属，你会心甘情愿地每天早晨按时上班吗？反过来，如果一个经理什么都不说，但每天都是第一个来，每天下班的时候都往外“撵”自己的员工，让他们早点回家。那么，作为他的下属，你会好意思不按时上班吗？
+
+人以类聚，物以群分。你的价值观和性格，也会被你的经理所影响。如果你无法认同一个人的价值观和人格，那么你是很难融入到这个人的队伍中来的。
+
+在我看来，值得跟的人还有一个很重要的特性，就是有担当，勇于承担责任。经理作为管理者，有权利支配所有人去做事情，甚至开除办事不力的人，但是同样的，他也要对手下的人做的事情负责。组里的成员如果工作没做好，出了问题，那么经理应该承担起责任，做“背锅侠”，同时制定相应的策略，避免问题再次发生。如果一个经理出了事情就拿手下的人开整，那么这不算一个值得跟的经理。
+
+同样，一个负责任的经理还或多或少有这几个品质：优秀、真诚、公平。在你眼里，一个比你优秀，对你真诚，处事也公平的经理，毫无疑问会潜移默化地影响你，让你也更上一层楼，正所谓见贤思齐。
+
+简单来说，不要跟着自己讨厌的人干，要跟着自己欣赏的人，佩服的人，认可的人干。
+
+## 定期和你交流
+
+这里说的交流，指的不是经理居高临下地在上面讲话，你在下面拿着小本本一边记录一边点头；也不是安排工作时的交谈，而是和你交流你工作中遇到的问题，对组里做的事情的看法，未来想要发展的方向，自己的兴趣，甚至平时生活工作中的琐碎事情等等。同时，他也会和你聊他眼中的组里的发展方向，事情的优先级，可能的机会等等。更重要的是，他会根据你这段时间的工作，指出好和不好的地方。好的地方给予肯定，不好的地方也要指出根本原因，并给你进一步发展的建议。
+
+这种沟通有个名字叫做一对一会议（one-on-one meeting），是由经理发起的，和手下人定期一对一交流的会议。这种会议的作用，就是让经理和手下坐在一起，把平时不方便说的话都说了，能够放开沟通，增进彼此理解，是上下级关系的润滑剂。
+
+在这种沟通中，你能了解自己工作的意义，看清“诗和远方”；也能把自己对问题的认识和看法跟经理讲一讲，让彼此的认知能够同步；还能够对自己进行一个非正式的“绩效考核”，对自己的工作成果有一个阶段性的认识。
+
+那么，如何高效地利用一对一会议呢？我来举几个我自己的例子。
+
+我曾经有一个阶段，工作进度并不顺。虽然工作时间很长，但是工作成绩并不怎么样。然而我自己却忙得顾头顾不了脚，完全没跳出来反思自己的问题。结果有一次一对一会议上，经理很直接地指出了我最近工作的问题——优先级。这一点我们之前也说过。
+
+所谓当局者迷，旁观者清。当时我的责任在增加，事情也多了起来，之前会努力把每件事情做到最好，现在必须要学会给事情排优先级。所以如果你有什么困惑，不妨利用这种机会跟上司领导直接沟通，也许会柳暗花明。
+
+同时，这种沟通还可以给你带来职场发展上的启发。
+
+我其实算是一个比较典型的80后内向程序员。喜欢闷头做事情，以把事情做出来为乐。但是在我能够出色地完成自己的工作之后，我的经理不止一次地指出我发展的局限：和别人交流得太少，不能塑造自己的影响力。慢慢的，我会试着花更多的时间来帮助找我问问题的同事，甚至主动帮助解决问题。经过一段时间我发现，这样不但让自己的能力得到更多人的认可，也扩展了自己的知识，自然的让自己向更高的级别发展。
+
+这些都是管理者站在更高的角度，看出来的问题，对个人成长来说，有很大帮助。
+
+## 没有一对一会议该怎么办？
+
+根据我的经验，一对一会议这种舶来品在中国有点水土不服。很多公司也有规定要经理定期和手下员工做一对一沟通，但是贯彻的质量却参差不齐。我有个朋友离职的时候，HR做离职调研，问他上次和经理进行一对一沟通是什么时候？朋友说从来没有过，我从来不知道我们公司还有个一对一沟通。HR表示很惊讶，并且表示要调查清楚。
+
+但其实，撇开这种会议不谈，你可以抓住一切机会，和经理进行类似内容的沟通，甚至可以主动和经理定这样一个会议。如果一个经理从来不跟你进行一对一的会议，也不以任何形式和你进行类似的沟通，那么只能说明经理并不看重你，认为不值得为你花时间，也不打算培养你。
+
+## 可以互相讨论甚至争论
+
+前面我提过，程序员需要发挥自己的主观能动性。与之相对应的，程序员应该也要获得和经理讨论问题的权利。如果不明白问题的来龙去脉，怎么发挥自己的主观能动性呢？
+
+所以可以和经理讨论问题，在我看来也是很重要的。经理要有足够的心胸，愿意和自己的手下讨论问题，听取大家的意见。能够在和下属讨论问题的时候，平等的交流甚至争论。
+
+讨论的目的是能够得出比最初更好更完整的结论，能够提升大家对问题的认知，而不是争得面红耳赤，为吵而吵，甚至发展到对人不对事。尤其是在一组人一起讨论问题的时候，经理要有能力引导讨论，指出讨论的方向。
+
+## 资源和利益的分配
+
+前面讲的都是偏向价值观的内容，如果不落实到行动，那么就都是“大忽悠”。那么下面我们就来聊聊，好的经理会如何落实上面的价值观，如何说到做到。
+
+如果一个上司足够重视你，那么肯定会为你合理安排资源，下面我列举两个比较常见的资源。
+
+### 新技术新方向等机会
+
+首先是新技术、新方向的学习机会。作为程序员，我们的工作领域就是不断变化的，一直都有新的方向，新的技术。
+
+如果你曾经跟经理表示，自己对云计算感兴趣，并愿意付出时间学习，那么如果组里有一个将服务迁移到云计算平台上的机会，经理应该要让你参与。
+
+如果你原来是一个测试，表示自己想转开发，那么经理应该愿意给你这个机会，让你日常的工作慢慢减少测试的内容，逐渐增加开发的内容。
+
+当然，组里可能还有各种大大小小各种各样的机会，比如新的项目、新的客户、新的平台、技术培训等。这都是经理可以掌握的资源。如何合理公平地分配这些资源，就很考验经理的素质了。
+
+从经理的角度来讲，肯定愿意组内有更高的产出。如果你和经理交流的时候明确表达过自己的兴趣和下一步希望发展的方向，但是真有了这种尝试的时候却没有考虑你，那么不妨开诚布公地和经理聊聊。经理可能觉得你现在的工作更重要，也可能觉得你现在火候不够，也可能觉得你平时工作不够踏实，新的机会给你对别人不公平。
+
+### 时间
+
+第二点就是时间了。每个人的工作时间可以说是经理掌握的最有价值的资源了。培养人才和为公司创造价值这俩目标，都需要用到组员的工作时间。当两者冲突的时候，如果经理愿意出于培养人才的目的，安排一部分时间让你成长，那么可以说是一种非常明显的培养你的信号了。而且经理愿意这么做，更重要的原因是他愿意相信付出的这些培养人才的时间，后续可以获得更多的回报，能够为公司创造更多的价值。
+
+还是拿我举个例子。之前我提到，我有一段时间因为事情多，自己又没有养成按照优先级做事情的职业习惯，导致工作效果不好。经理在帮我分析问题之后，后续安排工作时，都会花时间跟我多聊聊，讲清楚事情的优先级，以及为什么会是这种优先级，慢慢地我自己也能够准确地给事情排优先级，合理安排时间做事情了。
+
+再后来，经理指出我应该拿出更多的时间帮助同事，培养自己的影响力，他也会注意在平时的工作计划中，减少我工作的内容，尽量只安排必要的事情给我做，为我腾出更多的时间发展自己。
+
+### 能够争取到利益并公平分配
+
+能不能为下面的人争取到合理的利益，就是对一个好经理的终极考验。最常见的就是升职和加薪。
+
+如果经理不能将优秀的工作成果转化为大家的升职和加薪，那么就是经理的失职了。
+
+当然，对于个人来说，也可能是有失公平公正。所以这里你能够理解为什么我把“公平”列为好经理必须考虑的品质之一了吧。如果你认为一个经理做事情不公平，那么大概率也会认为他对利益的分配是不公平的。在你眼里，这个经理就不能算是个好经理。
+
+## 总结
+
+最后我们来总结一下。跟对人很重要，可以说是一段职业生涯的好开端。经理可以站在更高的角度，分配合适的资源来培养自己的手下，让他们少走弯路，及时修正自己的错误，更快更顺利地成长。
+
+其实经理的好与不好，有很大的主观因素在。这里列出的诸多因素，可能在每个人心中的重要性也不一样。所以遇到一个和自己非常合拍的经理是非常难得的，这也是为什么有些人愿意跟着一个经理一起换工作的原因之一。
+
+在这里要补充一句，经理愿意培养一个人，肯定是看到这个人的潜力。也就是说，我们在讨论经理好不好的时候，要先做好自己，证明自己的能力。如果自己做事情的能力不行，单纯地埋怨得不到发展的机会是没用的。在一个公司里，好经理绝对不是一个滥好人，而是一个善于挖掘、培养与使用人才的伯乐。<br>
+<img src="https://static001.geekbang.org/resource/image/91/a8/9145b9b54aba9e76b9033ada2a14b9a8.jpg" alt="">
+
+## 思考题
+
+不知道你有没有遇到过这样的经理或者领导呢？在你眼中，一个好的经理最重要的因素是什么？欢迎你在评论区写下你的看法，也欢迎和我一起交流，我们一起分享下彼此的经验。

极客时间专栏/geek/职场求生攻略/职业选择篇/09丨管理者关系：跟对人和做对事哪个更重要？.md

@@ -0,0 +1,97 @@
+<audio id="audio" title="09丨管理者关系：跟对人和做对事哪个更重要？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/32/9d/327bf4989e23fb62931f5a519164349d.mp3"></audio>
+
+你好，我是臧萌。上一讲中，我们讲到了“跟对人”是怎样的，那么今天我们就来看看，如果跟不对，又会怎样呢？
+
+其实一般来说，我们程序员和经理的关系都是“正常”的，很少能好到千里马和伯乐的地步，也很少能坏到水火不容的地步。但是常在河边走，哪有不湿鞋。工作换得多了，公司重组多了，难免会遇到和自己不对付的经理。
+
+## 勇敢地问自己一句：是我的问题吗？
+
+作为经理的下属，我们程序员自然会很努力地完成经理交给的任务。在无法完成任务的时候，就会难免陷入自我怀疑和否定。其实不必有心理压力，我觉得这是非常自然的职场现象。每个下属都是有迎合自己经理的惯性的，都想要得到经理的认可。毕竟下属创造的价值必须要得到经理的认可，才能保住自己的饭碗，进而升职和加薪。
+
+但是，当你的工作进展很慢，陷入瓶颈的时候，不妨先把手头乱七八糟的工作先放在一边。仔细问问自己，确实是自己的问题吗？是自己的能力不行，还是经理给的资源和决定有问题？为什么偏偏就最近这段时间的工作不太顺利？有没有可能是经理的问题？
+
+这里我希望你能在工作不顺利的时候，在纠结自己能力的同时，也好好思考一下自己的处境。
+
+毕竟哪里都有奇葩，经理这个人群也会混入奇葩。这里我罗列几种奇葩经理的类型。
+
+### 贬低控制型
+
+这种类型的经理有的习惯使用各种言语手段，对自己的手下进行贬低，已达到让下属觉得工作摇摇欲坠的感觉。还有一些会抬高自己，变相地让手下觉得自己的水平和经理差很多。当然更多的是两招混用，这时候心理脆弱或者经不住忽悠的人，就很容易上套，战战兢兢，这就达到了经理的目的，让手下乖乖听经理的话，唯经理是尊。
+
+我举一个我朋友的例子。当时朋友的公司进行了一次大的重组，他所在的组换了一个经理。新经理上任第一天，就把组里所有的人挨个叫过去一对一对话。朋友本以为这会是一次交流，没想到等来的是一场批判。
+
+新经理将他做过的事情，正在做的事情以及打算做的事情全盘推翻并否定。并在得知他并没有读过TAOUP（原话，即The Art Of Unix Programming，中文译名《Unix编程艺术》）之后，表达出“你根本不配写代码”的意思。还好我朋友并不是很吃这一套，虽然当时晕头转向的，也对自己的价值有所怀疑，但是回头和自己的同事一聊，发现他对谁都是说的那一套，朋友马上做出换组或者换工作的决定。当然还没等他来得及换，这个人就被公司赶走了。据说后来还是在做经理。
+
+这种经理常用的手段还有这些：
+
+1. 攀附名人和上级：就算是点头之交的人也张口闭口说跟谁谁谁很熟；
+1. 夸大成绩：听说过的项目就是自己做过，参与过的项目就是自己主导过，获得一点成绩在他嘴里就成了令人瞩目的成就；
+1. 炫耀历史：张口就是我原来如何如何，曾经怎样怎样。但是对身边人的“成就”，则一概闭口不谈。
+
+究其目的，这类经理的目的无外乎就是树立自己“金身不败”的形象，压制自己的下属，同时让自己对下属的工作成绩有充分的贬低空间，造成“你有这份工作是你的运气”或者“能跟着我干是你的运气”的氛围。
+
+### 技术压制型
+
+这种类型的经理一般是刚刚从技术岗位转为管理岗位，对手下人的技术不放心，必须要有技术上的压制，才能让他有足够的安全感。一般来说，很多人会慢慢调整过来，专心做管理，或者在技术和管理上找到一个平衡，抓大放小。
+
+但也有人转不过这个弯来，会一直行使技术和管理的双重角色。这个其实是很尴尬的。手下一般不会愿意和经理抬杠，尤其是技术问题。而程序员作为真正做事情的人，如果在解决问题的技术层面被压制或被控制，那么肯定无法更好地发展自己的主观能动性——我想那么多干嘛，反正最后还是听经理的，经理怎么说我就怎么做算了。长期来说这是一种双输的局面。
+
+### 极致压榨型
+
+这种类型很直接，就是高压管理，恨不得让手下一直工作，但是在培养人才上，却十分吝啬。对下属的工作成绩，也不予以客观的评定，反而是极力贬低。如果这种类型的经理再叠加上“贬低控制型”的属性，那会活脱脱地打造出一个程序员的血汗工厂。
+
+在这种经理的手下，程序员的成长空间有限，时间都用来干活了，没时间成长。加薪升职基本也是没指望的。这种经理更愿意耗到下属主动离职，重新招人。
+
+### 性格缺陷型
+
+每个人的性格都不能说是完美的，而很多人在转向管理角色之后，性格缺陷被放大，多疑、自私、爱耍官威、自我感觉良好、喜欢自吹自擂等等。对于登上管理岗位的人来说，手里忽然有了更多的资源，性格缺陷也有了更大的发挥舞台。各种奇葩的事情也就随之而来了。
+
+## 别对公司抱有太多的幻想
+
+我们前面说了那么多，也许有人会问，公司不讲理的吗？经理做的事情不对难道我不能申诉吗？
+
+基本上，除非经理做了严重违反公司文化和价值观的事情，或者违反了法律和公序良俗，公司才会选择惩罚经理，因为这样传达的信息是公司为了维护文化和价值观，愿意牺牲经理。
+
+而下属和经理之间的矛盾基本上都集中在做事是否公平，资源分配是否合理等等。在这些事情上公司很大概率不会站在下属一边。为什么呢？我给你分析一下原因：
+
+### 程序员被替代的代价并没有那么高
+
+很多程序员觉得自己在组里独当一面，以至于有种“我的重要性比经理还高，缺了我组里的事情就玩不转了，组里没有了经理也不能没有我”的错觉。
+
+事实是，一个程序员可以独挡一面，但找个替换者继续独当一面，也并非难事。一个稍有规模的公司，随便哪个人被替代都没啥问题，甚至CEO、VP或者总监被开了，也没见多少公司会因此停摆。所以作为程序员，更不能自视太高，甚至想着以此作为闹的“资本”。
+
+### 如何做事是经理权限之内的事情
+
+我们上面说到那些矛盾该如何处理，基本都在经理自己的权限范围之内，而且是非常主观的，很难辩出个黑白分明。
+
+从立场上来说，公司更倾向于在下属和经理起争执的时候，站在经理的一边。因为经理其实就是代表公司管理下属，也就是说，经理就是公司的一部分，如果站住员工一边，可以说是“胳膊肘朝外拐”。
+
+### 公司不能传达按闹分配的信息
+
+如果员工一申诉，公司就倾向惩罚经理，那么公司对经理传达的信息则是：不要“惹”自己的员工，否则你会被惩罚。对员工传达的信息则是：有事情就闹，闹一闹就能从经理那里获得好处，甚至把经理闹走。这么一来，员工敢闹，经理不敢管，公司就没法正常运转了。
+
+### 惩罚经理对公司的损失大
+
+从利益上来说，惩罚经理会对公司带来的潜在损失更大。经理掌握着全组的资源，同时他也背负着完成这个组的KPI的任务。如果惩罚经理，对整个组的工作和完成KPI的影响，都会大过惩罚经理的一个下属。
+
+事实上，经理无法完成自己的KPI是经理被“干掉”的最大原因，而不是对自己的手下不好。对自己手下不好，造成离职率高，只是考核经理的一个并没有那么重要的指标而已。
+
+## 跟对人，还是做对事？
+
+我们用两篇文章讲了这个话题，回到结论，没有什么比跟对人更重要。事实上，跟对人，还是做对事，本身就是个伪命题。只有跟对人，才有可能做对事。如果你跟着一个不对的人，是很难做出成绩的，即使做出成绩，利益也没你的份，最后你还申诉无门。
+
+我有个朋友，经理是个刚刚转管理的奇葩，但是当时组里做的事情是比较热门的，他觉得机会难得，想积攒点经验，本着“我就好好做事，少跟经理打交道”的原则忍着。但是事实是，一个再好的发动机，配上一个不对付的变速箱，也不可能在奔向目标的路上发挥自己的能力。最终也就导致想做的事情还是没有能做成。
+
+如果真的愿意全心投入一个热门行业，不妨找个值得投靠的经理，哪怕换个公司。
+
+## 总结
+
+这节聊了一些腌臜的事情，毕竟生活不止诗和远方的田野，还有眼前的苟且。但是我们的生活还是要有正能量。顺境的时候别人的赞赏不要当真，逆境的时候，别人的贬低和冷眼也不要放在心上。遇到问题时，先反思一下是自己的问题，还是别人的问题，然后再解决问题。身为程序员，我们要靠能力吃饭，只要本事过硬，换个工作并不难。从这个角度来说，程序员没必要忍着一个奇葩经理。如果是对公司有感情，也可以考虑内部转岗。
+
+当然，无论遇到多么糟心的事情，我都不建议你裸辞，或者作出任何冲动的选择。有奇葩的经理，也有奇葩的公司，我们要的不是改变环境，而是找到合适自己的环境。说句鸡汤一点的话，不要用别人的错误惩罚自己，遇到不顺心的事情，也要在规则和自己的道德底线的约束下，做出最符合自己利益的选择。<img src="https://static001.geekbang.org/resource/image/8c/cc/8cc32032afaf34f90b21964e30b8e0cc.jpg" alt="">
+
+## 思考题
+
+这一篇可能会引出你的共鸣，在你的职业生涯，都遇到过或听朋友说起过哪种类型的奇葩经理？你或者你的朋友都是如何应对的呢？
+
+欢迎你在评论区和我讨论，也欢迎把这篇文章分享给你的朋友或者同事，一起分享一下彼此的看法。

极客时间专栏/geek/职场求生攻略/职业选择篇/10丨职业规划： 跳槽之前你想清楚这些事情了吗？.md

@@ -0,0 +1,107 @@
+<audio id="audio" title="10丨职业规划： 跳槽之前你想清楚这些事情了吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/15/26/1518fec534d116d92cb76a4c53299e26.mp3"></audio>
+
+关于换工作，江湖上流传着很多说法：在一个地方工作满三年就应该换工作了；自己要主动出去看看，涨涨见识；工作一年不要换工作……等等等等。
+
+我参加工作13余年了，换工作的次数一只手数不过来。短的不到一年，长的刚满五年。自己和周围的朋友换工作，有经验也有教训，这篇文章我想跟大家分享一下跳槽之前要考虑清楚的事情。
+
+## 是什么，撩动了你跳槽的心弦
+
+### 心态
+
+马云说：“员工的离职原因很多，只有两点最真实：钱，没给到位；心，委屈了。”委屈了，就是自己心态不好了，心里有疙瘩了。
+
+言论是死的，每个人所处的环境是活的。你需要结合别人的建议和自己的实际情况，好好思考一下，换个工作是很简单，但是换个工作就能奇迹般地让自己在以后的工作中都不会再受委屈了吗？难。
+
+如果因为没有升职，就一口咬定是公司或经理瞎了眼，识不出自己这匹千里马。心中叫一声：“此处不留爷，自有留爷处。”然后跑去面个试，涨个薪，辞职走人。开始肯定是爽的，但如果确实是自己有不足而没有意识到，那么干了两年，可能发现自己还是没有升职。
+
+其实，每个公司都有问题，包括你跳槽想去的公司。我工作这么多年，接触过来自不同类型的公司的程序员。关于前公司和现公司，大家都有吐不完的槽。没有完美的公司等着你加入，不要抱有不切实际的幻想：换个工作就好了。先想清楚看自己是不是有改进的地方，否则单单靠一份新工作，是不可能帮到你的。
+
+你想想，为什么公司会对求职者进行背景调查，想要弄清楚求职者在前司的表现是怎样的？一个人在前司的表现情况，很大程度决定了这个人在新公司的表现情况。如果一个人之前做事就不认真不负责，那么新公司还凭什么相信这个人呢？
+
+同样，对于我们自己的问题，无论是技术的硬实力，还是做事情的软实力，都可能随着公司的发展或者自己承担的责任变化，需要进一步提升。工作一时不顺心，就想要冲动换工作，其实只是逃避自己身上的问题而已。换个公司，自己却不做改变，工作一样也不顺心。
+
+无论是因为什么原因，如果感觉自己心里受了委屈，不妨先放下之前的自己，找相关的同事和经理谈谈，听听大家对自己的看法。也许大家认为你做的事情还有改善的空间呢？也许这家公司就是不适合你，公司的价值观和文化与你的风格有冲突；也许换工作的决心已经定了，但是这并不妨碍你先把心情理顺了。
+
+人都是一边经历一边成长的。既然都已经经历过了，何不弄清楚原因呢？这样才能帮助自己成长。所以要尽量弄清楚心里有疙瘩的原因，再审自己是否应该跳槽。
+
+### 主动求变
+
+除了工作不顺想跳槽之外，当然还有主动求变的因素。如果是自己主动求变，求突破，那么在想清楚之后，不妨直接行动。
+
+我推荐先看看这篇文章：[《选公司 ： 如何选择一个适合自己的公司？》](https://time.geekbang.org/column/article/242615)。除此之外，我们接下来还会进一步主动求变这个要素，比如创业、比如职业选择等等。
+
+我刚刚毕业的时候，在一家传统软件公司工作了几年，工作的方向是单机的工具开发和UI，也就是类似Eclipse这种基于SWT开发的工具和IntelliJ这种基于Swing开发的工具。几年后，虽然自己也有成长，但当时互联网又热了起来（我2006年毕业，没有经历过2000年的互联网泡沫破灭），行业新闻里说的全是互联网，新技术。当时就隐隐觉得，这种传统软件公司的“风头”已经要被互联网盖过去了，于是跳槽的种子就种下了。
+
+后面换的公司是一家大型互联网公司，但工作还是工具开发。但无论是工作节奏，内容还是技术氛围，都和之前的传统软件公司有很大区别。
+
+然后出于一个偶然的原因，我换了一份Java后台开发的工作，自此以后，我基本都在做Java后台开发，工具开发的技术就撂下了。不过即使我当时没有换工作，工具开发的风头也马上要过去了。当时开源和标准越来越成熟，傲娇的大型互联网公司也纷纷拥抱开源，公司自己开发工具的价值越来越小。
+
+没几年后，Android和iOS开发火了起来。这次我玩了玩Android开发，有点UI开发的底子，学起来还是挺快的。但是当时并没有考虑换工作，主要原因还是，我自认没有什么艺术细胞，对画UI，做交互实在是没有什么心得。虽然有兴趣，但是无奈没天赋。
+
+主动求变需要考虑的因素有很多，既要看客观环境的机遇，也要结合自身的兴趣与长处。尤其是个人兴趣。因为变就代表着新的开始，代表未来可能很长一段时间内，付出要大于收获。要想坚持到开花结果的时候，需要兴趣和热情提供动力。
+
+### 薪资待遇
+
+公司的待遇跟不上行业水准，基本上是跳槽最直接的原因。毕竟大家一聊天，发现技术差不多，做的事情差不多，工资却差一截，谁心里都难免不爽。而且如果一个公司工资长期跟不上行业水准，有可能是公司发展不行，那么这种要跳槽，就不仅仅是为了涨薪了，也是为了长远做打算。
+
+如果遇到远高于行业标准的薪资待遇，谁又能不心动一下呢？工资就像是颜值，颜值能用最简单直接的方式吸引一个人的注意力。“想挖人，开高薪”。但是跳槽涨薪有个基本的逻辑：公司能从你身上获取远高于你工资的收益，否则这种涨薪就是不健康的。公司很可能无法长久维系。毕竟我们期待的是长久稳定的高薪，而不是窜天猴式的“一飞冲天，瞬间跌落”式高薪。
+
+另一个是2012年左右的万达电商。当时猎头给出的话是，阿里等电商公司来的，double没问题（猎头的话，不可不信，当然也不能全信）。那自然也是能招到很多人才。但是经历了很多年，万达电商也没做起来。后面的裁员也是一波又一波。
+
+我们是程序员，并不能判断一个公司能否通过高薪招聘健康长期地运转下去。现在也有很多发展很好的公司，能给的offer也是业界知名的高，同样的，工作压力也是业界知名的大。我给出这俩例子的目的是让你思考一下，如果一个公司高薪招聘，但是又不是特别忙，没什么业务，那么你就应该小心一点。
+
+没人会跟钱过不去，但我的建议是，不要让薪资待遇成为你跳槽的唯一原因。公司文化，工作压力，发展方向，是否可持续发展，公司稳定性等等因素也是要重点考虑的。
+
+## 是什么，稳定住了你的心弦
+
+### 频繁跳槽的坏处
+
+虽然现在软件行业已经没有那么疯狂了，但是想换一个工资更高的工作，还是不难的。那么为什么明知道跳个槽可以加工资，大部分人却不在每年加薪完毕就跳槽呢？因为大家都知道，频繁跳槽带来的那点工资涨幅，远抵不过它带来的副作用。
+
+我有几年近乎是一年一跳，基本上是觉得工作没意思了就跳。这样做带来最直接的坏处就是，简历非常难看——不光HR嫌弃，领导更嫌弃。
+
+公司是一个有机的整体，大家一起工作一起磨合，新人也要熟悉公司的方方面面。公司还会安排系统的培训，帮助新员工熟悉公司。一个新员工刚来的前几个月，产出可能都是0。一年下来，好不容易熟悉了，又拍拍屁股走了，公司损失的不仅仅是钱，更多的是培训新人所耗费的一年时光。人走了，又要招聘新人，继续培训、磨合……我相信每个有经验的管理者，都会有类似的经历。
+
+为了避免培养人才的成本付诸东流，经理和HR在聘用招聘频繁跳槽者时会非常谨慎。在条件差不多的候选人中，他们会更青睐稳定性好的候选人。
+
+当然，工作一年一换的简历，也不愁找不到工作。但是喜欢这种简历的公司，更多的是期待你能马上上手工作，输出价值。不会给你熟悉公司和业务的时间，这样的公司很可能也不打算培养你成长。将心比心，公司为什么要冒险培养一个习惯性跳槽的人呢？就好像如果你知道公司一年后大概率会开除你，你还会矜矜业业地工作吗？这样的公司，对员工的成长其实是不利的。
+
+所以说，跳槽，要控制频率。
+
+### 长期来看，在一个公司的积累和成长最值钱
+
+无论想跳去的公司看上去有多美丽，无论猎头多么巧舌如簧，让你感觉错过这个机会就是错过了几个亿。你需要冷静一下，看看这句话是不是有道理：能够在一个行业或者一个公司有所成就的人，肯定是在这个行业和公司长期积累，长期耕耘的人。
+
+不信你想想那些在业内作出实际成就的软件工程师，哪个不是在一个公司的一个领域耕耘积累多年，方能开花结果，一战成名天下知？
+
+张小龙是程序员起家，开发的Foxmail是当时最好用的国产邮件客户端，没有之一。后被腾讯收购，他也加入QQ邮箱团队。QQ邮箱在他加入的那几年，可谓改头换面，做得很不错。后来我们也知道了，张小龙最成名的作品是微信。邮箱和微信，都是沟通的工具。微信的成功，我相信少不了他在邮箱这个产品上的积累和思索。
+
+如此这般在一个领域耕耘多年的人，还有很多很多。
+
+真正有金手指的天才可望不可求，而且对于软件工程师这种需要项目落地的职位来说，和每个公司每个行业具体的环境都是息息相关的。对于我们普通人来说，要想做好软件工程师只有长期耕耘，才能有所成就，这就是事实。
+
+当然，换工作可以不换方向。这个要提前和新公司商量好，最好能有认识的人，做熟不做生。如果你孤身一人加入一个公司，即使之前谈得再好，也难保没有变数。在之前的公司你也许是个人物，换个新公司却不一定有人认识你。事实是，你刚到一个公司，毫无产出，孤立无援。你没有影响力，没有声誉，没有根据地。别人怎么安排你，你都没有太多反抗的资本。
+
+如果你觉得现在做的事情有价值，公司和行业也发展得不错，自己有成长，公司也愿意支持你的方向，给你资源发展，不妨坚持做下去，不要轻易被外界的offer诱惑。因为长期来看，只要公司在发展和成长，一个人在一个公司的积累和成长，大概率会给你带来稳定的长期收益。当你精通某个领域，甚至已经成为这个领域的专家时，offer还会是问题吗？
+
+### 内部转岗
+
+在一个公司的同一个软件开发岗位做得时间久了，如果工作内容没什么变化，难免遇到成长的瓶颈。这时候，内部转岗也不失为一个好选择。
+
+很多公司鼓励内部转岗，鼓励员工熟悉一下公司的各个组在做的事情，让你知道公司是怎么运转的，而不是坐井观天，只看和自己相关的一部分。
+
+如果是既想换公司，又想换工作方向，双重不确定因素，开始的一段日子可能会比较苦。这时候不妨试试看内部转岗。比如你想从Android开发转后台开发，想从开发转分析师，不妨先在公司内部找找机会。这样的话，一方面你对公司的环境和系统都熟悉，工作上手更快，另一方面，如果你之前表现不错，这种好声誉也会伴随着你去新的组。
+
+## 总结
+
+说了这么多，其实道理也很简单。委屈了，要知道为什么，以后才能不受委屈，赌气换工作不能解决问题。升职加薪是好事，但是自己的成长和长期稳定增长的收入才是金不换。换工作之前，更要平衡好自己的生活和发展，要想清楚哪个选择是短期利益下的诱惑，哪个才能带来长期利益下的发展。
+
+有个前辈总结了一个理想工作的关键要素：钱多，活少，离家近。我觉得前辈说的非常符合我自己对理想工作的期待。希望你能找到自己理想的工作。
+
+<img src="https://static001.geekbang.org/resource/image/10/d9/1090df5b015ecc730b85e805e96e8ad9.jpg" alt="">
+
+## 思考题
+
+除了薪资和心情，你还因为什么换过工作？
+
+欢迎在评论区分享你的经历，也欢迎你把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职业选择篇/11丨面试：如何准备简历和面试？.md

@@ -0,0 +1,165 @@
+<audio id="audio" title="11丨面试：如何准备简历和面试？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b8/54/b81b49958a72abd8df5262ec7ec8b654.mp3"></audio>
+
+在上篇文章中，我们聊了聊换工作之前要思考的问题。接下来我们趁热打铁，聊聊身为程序员的我们，应该如何面试？
+
+面试的时候，不知道你会不会有这几个感觉？
+
+1. 为什么我感觉面试官就是在故意刁难我？
+1. 为什么很多面试中被问到的问题都比实际工作中用到的要难？
+1. 学历重要吗？
+
+## 面试是什么
+
+面试面试，到底面的是什么呢？根据我这么多年面试和被面试的经历，我的观点是： **面试是和面试官合作，展示自己的优势和优秀之处**。这样经过对比之后，面试官才能择优录用。
+
+我们需要摆正自己的心态，其实在面试过程中，面试官和面试者的关系不是对立的，而是合作的。两者的目的是一样的：通过几个小时的面试，弄清楚面试者，到底是有多优秀，是否适合当前的职位。
+
+当然，经理和HR的面试还会侧重不同的角度，他们要考虑成员的稳定性、成长空间、薪资、背景、组内人员构成、性格品格、交流以及技术储备等等。但是基本的逻辑是不变的，面试者需要和面试官一起合作，将自己优秀的一面展现出来。让你这个求职者闪着金光的素质点照到面试官的眼里。
+
+当然了，要想面试，首先要获得面试的资格。简历就是帮助我们通向面试的钥匙。
+
+在你的简历到达每个面试官的邮箱的时候，面试其实就已经开始了。
+
+## 如何书写一份合格的简历？
+
+我面试时遇到过很多让人皱眉头的简历，比如篇幅太长，重点不突出，组织混乱等。
+
+那么简历到底该怎么写呢？
+
+### 精简工作经历
+
+简历中最重要的部分莫过于每份工作经历的职责和内容了，因为这将是面试官挖掘你闪光点的重点区域。
+
+这个部分里，注意不要写流水账，要学会梳理每份工作的重点，尤其是最近的工作——每段经历都解决了哪些问题，带来了什么价值，你从中学到并使用了哪些技术。
+
+同时，面试官还会特别关注你在每一份工作经历中那些不平常的经历，比如，安排你去做了别的领域的工作，你能否快速学习新技术，比如如何维护和迁移遗留系统等等。
+
+这些实打实的工作经验，是最具有含金量的，尤其是和面试的职位有重叠的工作经历。
+
+但我们要注意的是，对工作经历的描写要有的放矢，也可以更好地控制简历的长度。
+
+如果有三份简历扔给面试官，一个5页，一个3页，一个1页，相信我，面试官不会分别用5分钟，3分钟和1分钟看这三份简历的，而是基本都用2分钟。
+
+因此简历不要太长，要精简有力地说出自己在每一份工作中的亮点。如果在一段工作经历中，自己没有发挥什么作用，那就一笔带过。啰嗦的简历只会让金子淹没在一堆没有价值的沙子里。
+
+我的建议是，如果是你刚毕业，简历不要超过一页（单面A4纸，下同）。工作十年以下，不要超过两页，最多最多，不要超过两页半。
+
+### 经历倒叙
+
+简历一定要倒叙，倒叙，倒叙！重要的事情说三遍。面试官关注的永远是你最新的工作经历，而不是你刚参加工作的那段经历。如果面试官看到你的简历，第一段内容是你刚毕业时候的工作，印象分就先减去大半了。
+
+### 突出重点
+
+前面说了要倒叙，但是对于一些自己想重点突出的内容，还是可以考虑放在简历的最开头的。这里的开头指的是在**姓名联系方式等固定开头**的下面。
+
+比如，获得过有知名度的奖，得过有分量的奖学金，是某个知名开源项目的贡献者，深入研究过某个开源项目，自己有个不错的技术博客等等，只要你觉得是你的闪光点，都可以放在简历的开头。
+
+比如说我，虽然已经过去七八年了，我还是会把我写过《Java 入门 1·2·3》这本书的经历放在简历的开头。只是想给面试官一个印象：我Java基础不错，文字描述能力也凑合，而且是倾向于踏踏实实搞技术搞开发的。
+
+以上说的是简历的硬性要求，还有一点我们不能忘记，那就是简历的工整性。
+
+### 排版工整
+
+排版要清晰工整。不要从网页上复制一个到 word 里就当简历了。这是一个态度问题，虽然不用过度迎合（大部分程序员不吃这一套），但最基本的互相尊重还是要有。
+
+最后，以上所有的原则都建立在“简历不要造假”的前提下。
+
+## 准备面试
+
+当我们凭借简历顺利进入面试阶段的时候，我们就可以根据这家公司的招聘风格做针对性的准备了。
+
+每家公司都有不同的面试偏好，比如Google对算法的要求就比较高，如果你想去Google，就得好好刷算法，要保证脑子先进入状态。其实每个知名公司的面试风格，网上多的是，你在面试之前不妨去搜一搜。
+
+除此之外，还可以先自己模拟一遍面试，进入状态。这里我分三种面试者分别谈谈面试前应该准备什么。
+
+### 应届生
+
+很多大公司的校园招聘和社会招聘是不一样的，有些职位是一定要招收应届生的。但是应届生招聘其实没太多需要说的内容，刷题就对了，刷算法和数据结构就对了，展示自己优秀的一面就对了。
+
+如果能找到学长内推是最好的，只要还有职位，基本上可以保证有一次面试的机会。
+
+### 工作经历不丰富者
+
+如果工作经历在一两年之内，那么首先我劝你不要跳槽，哈哈。当然你看到这里肯定是想换工作的，那么我劝你想一个足够有说服力的理由去回答“你为什么要换工作”这个问题，因为面试官一定会问到。
+
+当然，这个时候的你，除了要梳理工作经历，可能也要像应届生一样刷算法和数据结构。
+
+### 工作经历丰富的面试者
+
+工作三年以上，就可以认为工作经历比较丰富了，毕竟一个大学才上四年，去掉寒暑假和实习，也就三年嘛。这时候准备面试，应该把自己想突出的和自己的优势好好总结一下。
+
+再强调一下，要突出重点，不要泛泛而谈，可以突出自己的工作成果等实际的内容。
+
+然后梳理一下自己用到的技术。如果面试官问到工作中的一些技术细节，要能回答上来。最后还有一些基础的算法，数据结构还是要礼节性地准备一下的。
+
+当然了，还有内推这样的方式，不过内推一般都可以获得面试机会，只要好好准备即可。
+
+那么最重要的来了，面试的时候，我们到底需要注意什么？
+
+## 面试中需要注意什么
+
+这里我列出一些面试中需要注意的点。
+
+### 不要勉强
+
+面试时间有限，要抓紧短短的面试时间，展示自己的优势。不会就说不会，不要勉强，更不要瞎扯，有时候，瞎扯会被直接拒掉。
+
+### 注意反馈，交流通畅，表达清晰
+
+注意和面试官的互动，注意面试官的反馈。如果面试官明显对你的回答不感兴趣了，或者没有听懂，那么要主动停下来，不要自顾自地喋喋不休。
+
+要注意表达的清晰准确，毕竟面试官有考察你的责任，对于你的“口误”，面试官可能会点一下，确认你是不是会，也可能直接在心里认为你不会。
+
+有时候面试官可能问不出问题，冷场了。这时候你可以将你自己认为的亮点之处主动说出来，和面试官主动交流。
+
+### 不推荐靠面经面试
+
+如果你面试前的心态是怎么“对付”面试官，那么很可能会把事情做偏。比如去找各种面经，各种所谓经典的面试题来背诵。
+
+当然，如果你本身是会这个技术的，面经还是可以看看的。这也是对面试的尊重。如果你本身没有这方面的经验，想指望靠面经“伪装”成会这门技术，其实不大可能。这种套路很容易被识破的。实际工作中用过学过，和突击看面试题的区别很大。如果只是背过，稍微换个角度问一下，不会的就直接卡住了。
+
+### 其它注意事项
+
+首先，要准时到场。这一点不用多说。
+
+其次，不会的时候不要较劲，不要反问面试官问你的问题。面试官是挖掘你的闪光点，不是证明自己比你更优秀，懂得更多。出于考察的目的，面试官是有可能问一些“自己认为你应该会但是自己不会的问题”的。
+
+## 关于面试的世纪疑问
+
+### 为什么我感觉面试官就是在刁难我？
+
+一个合格的面试官，是在面试中挖掘面试者的优势，而不只是劣势。但是不可否认的是，确实有些面试官会逮住面试者不会的，或者是没有做过的东西使劲儿问，再比如有的面试官把面试者当编译器、技术规范、文档手册这么来面，过于死板。
+
+这种行为实在欠妥。
+
+遇到这种面试官，我们首先还是要尽量回答面试官的问题。然后可以围绕面试官考察的点，试着“主动出击”，突出自己解决问题的能力。比如，自己使用过和某个技术相近的技术，而且解决了实际问题；比如自己确实阅读过技术规范，理解其中的概要，并在实际工作中，通过查技术规范解决了某个问题等等。
+
+### 为什么面试中问到的问题比实际工作中用到的要难？
+
+面试也是一种淘汰和选拔的机制，所以使用比实际工作更难的技术来选拔出更优秀的人才，也无可厚非。
+
+但你可能还有疑问，为什么面试难度堪比造火箭，实际工作确是拧螺丝？比如面试时一水儿高大上的算法，实际工作不还是用不到？
+
+换个角度，面试算法，其实是考察你的学习能力，你是否能通过学习，掌握这些算法。如果你可以，那么就说明你的能力挺好。接下来就是重点，那么你这种能力，也可以用在解决工作中其它问题上。
+
+所以背后的逻辑明白了吗？问的内容会不会用到不重要，重要的是你有没有学习的能力。这能力就好像黄金一样，黄金不能吃不能穿，但是它代表价值，可以换来吃的穿的。
+
+其实我对这个，也是有点无奈的。这相当于变相承认了技术等于能力，不过不得不承认，用技术难题来考验面试者，始终是一个有效的手段。
+
+### 学历重要吗？
+
+在没有工作经验的时候，确实只能看学历，这和考察算法是一个思路。好的学历，说明这个人学习能力强。至于学会的那些东西在工作中有没有用，其实不是那么重要。一个学习能力强的人，更能让公司相信TA在工作中也可以学得更快，工作得更好。
+
+当然，随着工作年限的增加，学历的重要性就会慢慢减小。学历就像是一块奖牌，但是工作经历和工作取得的成就也是奖牌。奖牌多了，单块奖牌的重要性就下降了。
+
+## 总结
+
+面试是公司择优录用的一个过程，因此从一开始，我们就要精心准备，从简历，面试准备，到面试发挥，每个步骤都需要用心思。在这个过程中，最重要的，就是自己的积累和成长，毕竟面试靠的就是厚积薄发。
+
+最后需要强调的是，面试最重要的一点是，要真诚，绝大部分的公司对面试中的作假行为都是零容忍的。对于自己的经历，要坦诚地和公司描述清楚。即便之前工作的经历不好，但坦诚的态度也会让人相信你有改进的决心。
+
+<img src="https://static001.geekbang.org/resource/image/28/18/28d3152d298e389b1ddaade7101a8218.jpg" alt="">
+
+## 思考题
+
+你有什么样的面试经历想吐槽吗？你有经过自己的努力，拿到自己心仪的offer的经历吗？欢迎你在留言区和我交流，也欢迎把这篇文章分享给你的朋友或者同事，一起分享一下彼此的交流经验吧。

极客时间专栏/geek/职场求生攻略/职业选择篇/12丨外包：外包不也是写程序吗？有什么不一样的？.md

@@ -0,0 +1,88 @@
+<audio id="audio" title="12丨外包：外包不也是写程序吗？有什么不一样的？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5e/1f/5e6ef8a50062292988ddf313ec89871f.mp3"></audio>
+
+有一种软件公司，叫做软件外包公司。软件外包公司做的是拿甲方的钱，按甲方的要求，帮甲方完成项目的工作。这里的工作一般就是写代码，也可能会包括一些上线、运维、维护等内容。
+
+外包的工作一般是以项目为单位的。一般来说，如果项目需求设计都很清楚，外包公司都会在自己的办公地点工作。也有项目需要频繁和甲方交流的，根据实际情况，外包公司也会让项目相关的员工去甲方的办公地点工作。
+
+除了这个形式上的特殊之外，软件外包具体是做什么的呢？和软件研发有什么区别呢？外包值不值得做呢？
+
+我可以在这里先甩出结论：一个程序员，如果想长期从事这个行业，那么外包不值得做太多年。下面我们就来说说为什么。
+
+## 从修路的例子看，外包有什么限制？
+
+首先，我们来看个修路的例子，通过这个例子我们来看看外包的主要矛盾到底是什么。
+
+假设A公司要给一个开发区规划公路，那么A公司要考虑的事情其实有很多，比如哪里是居民区，哪里是办公区，哪里是主干道，各条道路分别需要几个车道，路的承重多少，路基怎么设计才能扛得住承重……除了设计，可能还要铺设简单的实验道路，验证设计的可行性。
+
+当A公司做好所有这些设计之后，就会交给市面上专业的修路公司，将修路工程外包给这些公司去做。修路公司人多，长期从事铺路工作，签了合同之后就可以带着几百上千号人拿着图纸开干。
+
+这时候，我们可以认为，A公司就是甲方，修路公司就是外包公司。外包公司在具体做项目的时候，对路的各种技术细节以及其背后的奥妙，其实并不是特别清楚。比如为什么这条路是双向8车道，而不是双向6车道？为什么路基要分这么多层，每层要这么厚？为什么路面的坡度是这样的，而不是大一度或者小一度？
+
+看到这里，我想你应该明白了，我们的软件开发上也是同样的道理。
+
+软件外包中，甲方公司一般也都有些软件背景，会自己分析需求，自己做出详细的系统设计，但是写代码的人手不够。这时候甲方公司就找到外包公司，让外包公司按照自己的设计，帮自己写代码做系统。
+
+做软件外包，其实就要面对着一堆需求文档、API文档和详细设计说明书，照着要求写代码。但是代码背后的业务逻辑，外包人员可能是无法理解的。比如说，原始的需求是什么样的？基于这些需求，又经过了怎样的讨论和权衡，才得出这样的API设计？API文档中为什么要强调某个地方？缓存为什么是Redis？为什么设计里使用的数据库是MySQL而不是MongoDB？
+
+看到这里，是不是已经隐约感觉外包和非外包的区别了？外包工作并不能让我们详细地了解工程的本质，除此以外，它对我们的限制还体现在方方面面。
+
+## 外包的限制具体有哪些？
+
+### 难以获得完整地解决问题的能力
+
+**如果用一句话来概括，我觉得外包真正的问题在于，它的工作内容只包括最后的写代码，不包括写代码之前的思考和筹备过程**。然而就是这个思考的过程，对程序员来说，是非常重要的锻炼。通过这种锻炼，程序员可以逐渐培养出思考问题的能力，再学着将这些问题分解为一个个小的、复杂度可控的模块，进而通过编程完成一个能解决问题的系统。这就是使用技术解决问题的能力。另外，还能够积累在相关领域的专业经验。而这些积累，是程序员拥有更好待遇的有力支撑。
+
+纯粹写代码，并不是解决问题的完整过程。如果不经过前期的思考和锻炼，解决问题的能力是无法得到很好的锻炼的。就好像只修路的工人很难理解路背后各个参数的含义，自己也就没办法设计出一条合格的公路。
+
+### 外包公司不注重人才的技术成长，涨薪受限
+
+外包的工作内容，事实上也决定了外包公司对人才的态度。从外包公司的利益来看，只要员工能够“按照需求，写出代码，完成功能”就可以了。只要能够到达这个水准，那么外包公司就没有理由，也没有动力去培养人才了。
+
+同样的道理，一般外包公司也不会鼓励员工深入学习一门技术。毕竟外包公司的任务就是把事情做出来，至于怎么做更好就不在外包公司操心的范围内了，甚至可以说，外包公司也操不上心。所以，我们在前面提到的很多主观能动性等内容，在外包公司看来，并没有太多的适用场景。
+
+在我看来，外包公司不鼓励程序员深入学习还有两层利益的考虑，一方面，学习需要耗费时间。技术够用就行，没必要探索用不到的新技术，公司更希望你用这个时间来干活。另一方面，如果程序员技术精进了，跳槽的几率就会变大。因为外包公司不需要程序员有强大的技术，而程序员有了技术傍身，工资又不涨，自然会考虑跳槽。
+
+### 外包公司没有探索的环境
+
+因为需求和详细设计都是甲方定的，作为实施的乙方，也没有权利和自由去实践可能更好的方案。需求里写的用MySQL，那么就是MySQL，即使乙方的开发人员再怎么觉得用MongoDB好，也没有权利和渠道更改。
+
+我们还是用修路的例子来举例。如果A公司的一个设计人员通过计算，认为改一下混凝土的成分比例和路基的厚度，可以降低成本，达到更好的承重效果。那么A公司大概率会鼓励创新，让设计人员铺个实验路面试试看。
+
+但如果是铺路公司的施工工人有这个想法，负责人大概率只会让工人老老实实按照图纸施工。一方面是因为就算乙方有了更好的实施方案，也不会拿到更多的钱，另一方面是铺路的材料可能都已经按照之前的规划定好了，已经过了方案修改的窗口期，修改的代价太高了。
+
+### 可替代性强，可能无法完整参与一个项目
+
+因为外包公司的工作比较单一，所以可替代性也更强，同样外包公司程序员的可替代性也强。这也造成了外包公司的人员流动比较大。
+
+外包公司可能会被甲方换掉，即使不换掉，一个项目的程序员也可能无法参与项目的下一期的工作，甚至有可能在做一个项目的过程中就被抽调走了。
+
+从成长和积累的角度来说，程序员最好能参与项目的整个过程，甚至一个项目多期的开发，这样就能够沉淀完整的经验。如果是东一榔头，西一棒槌，技术和业务都很难沉淀下来。如果能参与一个项目多期的开发，也可以从这个项目的技术演进中，学到不少东西，但是如果无法连续参与，也无法收获这部分经验。
+
+## 什么情况下可以考虑外包？
+
+看完了上面的内容，我不知道你有没有发现，我不赞同长期从事外包工作的出发点只有一个，那就是不利于程序员的个人成长。那么反过来说，只要你觉得自己有成长，有收获，那么从事外包也不要紧，毕竟凡事没有绝对。外包没有好与不好，只有合适与不合适。
+
+这里我一下可以考虑外包的几种情况。
+
+### 通过外包快速积累经验
+
+对于刚毕业的同学来说，好的外包公司也不失为一个不错的开始。成熟的外包公司一般会有规范的项目管理、文档管理和代码规范管理等，这些可以培养程序员优秀的编码习惯。同时，在还没有熟练掌握一个技术之前，在外包公司可以通过项目将自己的熟练度提升上去。
+
+### 希望进入一个新的行业
+
+有的外包公司有自己的工作风格，比如主要接某个行业的外包项目。那么如果你想进入某个行业，但没有相关经验，无法通过面试直接进入这些公司。那么不妨考虑相关行业的龙头外包公司，积累相关的行业经验。
+
+当然，并不是每个人都喜欢一直从事一线程序员的。相比来说，外包公司更容易转管理。当然，我并不认为管理是程序员必须走上的道路。后面我会专门写一篇文章来聊这个话题。
+
+## 总结
+
+外包公司并不是一个很好的让程序员可以长期发展成才的环境。在外包公司呆久了，这种氛围可能会让人有两个错误的认知：程序员的工作就只是写程序；程序员只有转管理才有前途。
+
+如果想要成长，就不要被外包公司的氛围影响，做个有心人，肯下功夫，也会有自己的收获。当然，如果你觉得在外包公司已经没有太多的成长空间了，感觉自己不想只是写程序了，那么不妨换个环境。一般来说，在一项技术上如果有三年的积淀就差不多成熟了，五年就可以说很成熟了。这时候如果还想继续做程序员，就要考虑向更高的层面发展了，去锻炼自己除了写代码之外的能力。
+
+当然，实际的外包形式有很多，今天的内容里只是讨论了一种最主流的形式。也有一些外包公司反其道而行之，专门做一些甲方无法搞定的非常专业的工作，甚至连方案都是外包公司参与一起制定的。想当初，MS-DOS就是IBM外包给微软开发的。如果你正在从事外包工作，千万不要否定自己的工作。总之一句话：只要感到自己有成长，有收获，那么就是值得的。<br>
+<img src="https://static001.geekbang.org/resource/image/f1/f2/f190315878631678eae30a1f7d4144f2.jpg" alt="">
+
+## 思考题
+
+外包可以说是一个很常见的现象了。不知道你有没有在外包公司工作过呢？根据你的成长历程，你有哪些感触呢，欢迎在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职业选择篇/13 | 外派：大家都在一个办公室工作，有什么不一样？.md

@@ -0,0 +1,141 @@
+<audio id="audio" title="13 | 外派：大家都在一个办公室工作，有什么不一样？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/81/2e/819647da051131dfb72c966173cfff2e.mp3"></audio>
+
+你好，我是臧萌。前面我们聊了外包，今天我们来聊聊外包的兄弟：外派。
+
+外包和外派有类似之处。都是甲方因为某些原因，需要一些人帮助甲方工作，但是甲方不和实际工作的人直接签订劳动合同。那外包和外派到底有哪些不同呢？如果我已经在做外派了，有哪些点是我可以注意的呢？到底要不要一直做外派呢？今天我就和你来探讨一下这些问题。
+
+## 外派和外包有哪些不同？
+
+### 1.同事和环境不同
+
+从同事和工作环境层面上来看，如果你是外包公司的程序员，那么你的同事就是自己公司的同样做外包的程序员，基本也就在本公司工作。
+
+而外派之所以带个“派”字，意思就是要派到甲方那边工作。所以外派程序员的同事通常是甲方的员工，工作地点也一般是在甲方办公室。一般来说，外派的程序员会加入到甲方公司的某个组里，和甲方的员工一起从事一个项目。
+
+### 2.和甲方的关系不同
+
+从与甲方的关系上来看，外包一般是以项目为单位，所以甲方和外包公司是项目合作关系。甲方公司和外包公司的员工没有任何关系或约定。
+
+对于外派来说，外派员工除了要和外派公司签订劳动合同之外，还需要和甲方签订派遣协议。虽然外派一般也都是因为甲方的某个项目，带来的用人需求，但是涉及人要来甲方公司工作，还是需要一个名分和一定的稳定性。所以派遣协议一般是以时长为单位，比如一个外派的员工派遣协议上一般是签一年的时间。
+
+### 3.做的事情不同
+
+从做事的层面来看，外包公司的介入是在甲方完成了前期需求分析和设计之后。因为有合同的约束，留给外包公司的发挥空间其实很有限。而外派一般会参与项目开发的大部分甚至整个过程。
+
+## 外派到底在做什么？
+
+下面我们还是通过上一讲中外包修路的例子，来看看什么是外派。
+
+还是熟悉的A公司，这次A公司要负责给开发区设计公路。项目伊始，有很多论证、规划和设计的事情要做，这些都是项目施工前期工作，更具有技术难度和不确定性。
+
+A公司为了给出可靠的设计，可能要去勘探开发区的地质环境；可能要铺设实验道路；可能要在总体设计确定之后，赶工画设计图纸。这些都是项目早期的工作，但是技术含量并不是那么高，而且根据道路规模的不同，需要的人也不确定。
+
+在道路设计期间，A公司可能需要临时雇佣一些人来协助完成相关工作。这些临时雇佣的人一般就是外派的员工。外派员工需要和A公司员工频繁交流、紧密合作。
+
+相比于外包的单向交流，这部分工作的双向交流会多一些。比如，地质条件测量的很多指标和细节，如何结合地质条件，设计和铺设实验道路等等。这部分的工作，都对外派人员的技术、经验和仔细用心等提出了更高的要求。
+
+好，外派的工作内容我们大致了解了，接下来我们聊聊软件公司里的外派都有哪些不足。
+
+## 外派有哪些不足？
+
+从钱的角度来说，外派的逻辑是甲方公司用预算购买人力。所以从甲方公司的角度来看，外派员工就是拿钱过来办事的。一方面，甲方公司需要外派员工能够保质保量地做好工作。另一方面，甲方公司不会为外派员工的工作支付额外的钱。
+
+这种金钱和人力关系看似直接且确定，但作为外派员工来说，却会产生很多问题。
+
+### 1.工作于此，却不属于此
+
+从归属上说，外派员工是和外派公司签订的劳动合同。派遣协议则规定了甲方公司接受外派员工来公司工作，但这并非劳动合同。
+
+甲方公司和外派公司会签订项目合同，甲方公司按照合同付款给外派公司，外派公司再拿这个钱，给自己外派出去的员工支付工资，剩下的就是外派公司的利润。简单点说，就是外派公司会拿着甲方公司的钱，给自己的外派员工发工资，缴纳五险一金等。
+
+所以，外派员工是外派公司的员工，甲方公司不会再有额外预算给外派的员工。没有预算，外派员工就无法享受甲方公司的福利待遇。这里的福利待遇很多种，比如，和健康相关的有医疗保险和体检，和工作相关的比如加班报销政策、餐饮补贴、交通补贴、内部外部技术培训等，生活相关的比如年假、零食、团建费用、年会等等。
+
+除此之外，在待遇和机会方面，外派员工和正式员工也是不一样的。正式员工会有奖金和股票等奖励，但是外派员工并没有。很多公司还有些大大小小的机会，比如出差交流、内部转岗甚至直接转到本公司在外国的研发中心，这些都是外派员工无法参与的。
+
+很多时候，甲方的预算是确定的，所以无论外派员工干得多么出色，付出多少额外的心血，都既无法获得更多的金钱，也无法获得更好的机会。
+
+当然，对应的外包公司也无法享受甲方公司的福利待遇。正所谓不患寡而患不均，外包公司大家都是一个公司的，在福利待遇机会面前都是平等的。但外派员工在甲方公司工作，多多少少都能接触到甲方公司正式员工的福利待遇的信息。有句话是这样说的：一碗水端平。可惜正式员工和外派员工本来就不是“一碗水”，所以根本没法儿端平。
+
+看大家做着“相同”的工作，但收获却不一样，外派员工心中难免会有疙瘩。更有甚者，可能会以此小题大做，网上传的“外包员工深夜加班吃了公司一桶泡面，被内部员工批评”（新闻标题说的是外包，其实他们的工作性质是外派）的新闻，更是凸显了这种不平等。
+
+即使没有这么过分的做法，很多人还是会区别对待正式员工和外派员工。
+
+我有个朋友之前做外派，他跟我提起过一个自己的经历：当时他们和正式员工做同一个项目，自己在项目设计上有个小小的建议，比起现在的方式，他认为有更好的做法。而当他跟一位正式员工说这个事情的时候，对方听都没听两句，直接“礼貌”回绝：“对不起，技术的问题你不要问我。”他的一个建议，被对方当成了问技术问题，而且对方直接制止了他问问题的行为。
+
+这件事情可以看出，首先，这个人可能是觉得外派过来的人技术水平一般，张口一说技术，就下意识的认为是要向他请教问题。这种不礼貌的行为可能和个人的素质有关，但也从侧面反映了，正式员工与外派员工在这个公司的不平等地位。
+
+简单来说，外派员工在甲方公司工作，却不属于这个公司。各种“看得见，摸不着”和区别对待，都是客观存在在外派这份工作中的。所以从我的感觉来说，我觉得外派的工作性质，大多数人都会受不了。
+
+### 2.没有机会独立承担任务
+
+一般公司都会有成文或者不成文的规定，不允许外派员工独立承担一个任务。换言之，外派员工必须跟着正式员工干活，接受正式员工的工作安排。
+
+公司当然有他们的考虑，比如，外派员工和正式员工相比，存在较大的不稳定性，如果外派员工忽然有更好的机会，离职了，事情换人接手比较麻烦；独立承担任务是对人才的培养和锻炼，公司更愿意把这种机会留给正式员工，让正式员工在公司里有更多的积淀。
+
+### 3.不稳定
+
+派遣协议一般都包含甲方可以更换派遣人员的条款。条款内容类似这样：如果甲方觉得外派的人员不能满足甲方的要求，可以让外派公司换人甚至直接终止合同。
+
+对于正式员工，如果发生这样的情况，公司都会给你机会改善自己的表现，或者给你换一个组，很少会直接辞退。毕竟劳动合同不是说解除就能解除的，还涉及赔偿。而辞退外派员工，甲方公司一般是不需要赔偿的。
+
+所以相比之下，外派员工的稳定性，肯定要比正式员工低一些。
+
+### 4.发展受限
+
+甲方并没有培养外派人员的动力，对于甲方来说，外派员工过来就是要能直接工作的，合同到期，也不会自然而然的成为正式员工。因此，外派人员实际从事的工作，大都是非核心的，得到的锻炼有限，自己的发展也受限。
+
+## 外派有哪些优点？
+
+说了这么多外派的不足，下面我们再来说说外派的优点。如果是外派到优秀、成熟的大公司，其实还是有不少优点。
+
+### 1.增长见识
+
+成熟的大公司有很多优秀的内部系统。对于外派员工来说，在这些公司实地工作，会频繁使用这些系统。正所谓，百闻不如一见。这时候如果能做个有心人，多琢磨琢磨这些系统面对的问题，以及这些系统如何去解决这些问题，对于以后自己的发展是非常珍贵的经验。
+
+这些大公司今天已经解决的问题，很有可能就是别的公司明天将要遇到的问题。如果能有相关的积累，之后在去别的公司的时候，说不定就能抓住机会。
+
+再者，大公司内部的资料文档一般都是对外派人员开放的，这也是一个免费学习的好机会。同时，在大公司解决的问题也更具挑战性，也有更多机会接触到解决这些有挑战性问题的新技术。
+
+### 2.较早参与新项目
+
+前面我们提到，和外包相比，外派员工可能会在甲方更早的参与项目。这时候，自己的主动性是可以发挥的。为了能更形象说明这个问题，我们继续回到之前修路的那个例子。
+
+现在路已经修好了，但是路口拥堵严重，通行效率不高。这时候，A公司想到的是统计路口各个方向在不同时间段的实际车流量，通过动态调整不同时间段红绿灯的时常，来提高通行效率。
+
+这么来看，我们这个方案需要开发一个算法，同时也需要搜集各个路口，不同时间段实际车流量数据。在论证期，可能需要外派员工去路口，人肉统计不同方向的车流量，然后将这些数据输入给算法，得出一个更优的红绿灯时长。
+
+这时候，作为外派员工，就能够接触到A公司解决问题的思路和细节。如果你是个有心人，有了什么想法也可以在提交数据的时候和A公司的相关员工交流。
+
+真正到了执行阶段，如果你的这个方法可行，假如施工公司负责的就是在各个路口安装可以搜集车流量的摄像头，你其实就已经在很早的时候参与新项目了。但是外包公司的员工并不知道这个摄像头的作用，更不知道通过优化交通信号灯缓解交通拥堵的整个过程。
+
+这就像在软件开发中解决问题，最终的方案背后，隐藏的是一步步思考和摸索的过程。可能最后的结果是在某个数据库前加设一个Redis缓存。但是这个过程可能要包括预见问题、用原型证明问题、思考问题的各种解决方案，再通过原型证明方案的可行性，最终敲定解方案。这一堆步骤，如果能够全程参与其中，肯定能收获实实在在的能力。
+
+### 3.证明自己的能力，赢得更多的机会
+
+大公司招聘外派员工的理由有很多，有时候是因为项目紧，事情多，但是没有招聘名额。所以公司会申请一些预算来招聘外派人员来参与项目。不过，在有些公司，如果在工作期间，大家都非常认可外派员工的能力，在有合适的职位开出来的时候，还是有很大可能可以转正式员工的。
+
+当然，如果有这个打算，记得一定要在面试的时候，就跟甲方公司以及外派公司问问清楚，毕竟外派员工是给外派公司赚钱的，转正之后外派公司其实就损失了一笔收入，所以有些外派公司的合同里不允许在派遣期内转为甲方正式员工。
+
+但是，即便不能转正，优秀的人也总能赢得更多人的认可。在人才密集度高的公司工作，对建立高质量的人脉关系也是非常有帮助的。
+
+### 4.现金收入较高
+
+甲方公司也是知道外派员工处境的，对于不差钱的甲方公司，给外派员工的实际到手的钱超过相应的本公司的正式员工，也不是什么罕见的事情。据我所知，基本上规模比较大的公司，都会舍得给外派更高的薪资。
+
+## 总结
+
+好了，今天的内容讲完了，我们来总结一下。
+
+总的来说，外派到不同公司，工作体验的差距还是很大的。有些公司会尽量“压榨”外派员工，有些公司则会尽量公平对待外派员工。正所谓，人心都是肉长的，尤其是我们程序员这个行业，大家都是凭能力吃饭的，大家其实很自然会认可有能力的人。无论是正式员工还是外派员工，只要你的工作能力够强，都可以赢得大家的认可，获得相应的回报。
+
+但是，从职业发展的角度来看，除非是类似咨询这种高端的外派，我个人觉得，普通的外派工作基本和外包一样，并不是一个程序员值得长时间做下去的工作。
+
+但是如果能有机会去一个心仪的公司做外派，工作中好好展示自己的能力，抓住转正的机会，也不失为一条曲线救国之路。
+
+<img src="https://static001.geekbang.org/resource/image/7d/60/7daaba2cae17c49b72bf0c4d0a9fda60.jpg" alt="">
+
+## 思考题
+
+外派和外包一样，也是非常常见的现象了。不知道你有没有在外派公司工作过呢？你在外派过程中有遇到过什么问题，又有哪些收获呢？
+
+欢迎在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职业选择篇/14 | 职业规划 ：转管理是程序员的终极选择吗？.md

@@ -0,0 +1,155 @@
+<audio id="audio" title="14 | 职业规划 ：转管理是程序员的终极选择吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d1/31/d183005f9b4448be73b4fd2efa3dc631.mp3"></audio>
+
+你好，我是臧萌。今天我们来聊聊程序员转管理这个话题。
+
+这个话题在中国程序员界很热，很大一个原因就是中国官本位的想法依旧根深蒂固。很多人会觉得，转管理才算是“混出头”了，转管理之后就可以悠哉悠哉地“混日子”了。
+
+这种想法肯定是错的。公司不会养闲人，做管理确实拿的钱更多，但那是因为个人能力更强，付出了更多。传统官本位那一套，很大程度上，在现代的软件公司是行不通的。说通俗一点，在软件公司里，管理和开发，都只是为公司打工而已。所以呢，**不要给管理套上太多虚无缥缈的光环，也不要对管理这份工作抱有太多不切实际的幻想。**
+
+那么，程序员是否成长到一定阶段就一定要转管理呢？我觉得，这个问题背后的核心问题其实有两个：
+
+1. 如果不转管理，是否就到了成长瓶颈了，以后升职加薪基本没戏了？
+1. 如果不转管理，会不会到一定年纪就写不动代码了，导致对公司的价值越来越低，最后被淘汰？
+
+那在讨论这两个问题之前，我们先来理解一下经理这个职位。
+
+## 管理岗和个人岗有什么不同？
+
+首先，从职责上说，公司都有个人岗和管理岗（Manager）。
+
+首先来说说个人岗。个人岗英文简称叫做IC，全名叫做Individual Contributor，也就是个人贡献者。顾名思义，IC的意思就是只能通过自己实际的工作，来为公司做出贡献，创造价值。软件公司里的程序员，都是IC，也就是通过自己的专业技能为公司创造价值。
+
+那么与之相对应的，就是管理岗。管理岗一般是不做具体工作的。换句话说，管理岗除了具体的事情，所有的别的事情都要管。管理岗不是通过做具体的工作，来为公司做贡献，而是通过各种管理技能和指导，让手下的IC能够发挥更好的合力，为公司创造更多的价值。简单来说，就是通过他人来达成目标。
+
+其实说到管理岗和个人岗，这俩概念并不是什么舶来词，个人岗和管理岗就好似我们古代的官吏之别。做官，就是要和人打交道，要有治理理念，能管理人和人之间的关系，平衡各方利益。而专注做某项事的，则叫做吏。比如税吏、狱吏、刀笔吏，这些岗位的名称都明确了这个职位需要的相关技能，也代表了这个职位对应的具体工作。
+
+那么管理岗到底和个人岗有什么不同呢？简单来说，管理岗位是公司执行系统的一部分。我来打个比方吧，**如果将公司看做一个人，管理岗就好像是人的神经系统，个人岗就像是各个职能器官。神经系统控制各个职能器官来做事情。**所以如果是从IC转管理的话，很多公司都会提供配套的培训，帮助员工完成职责的转换。
+
+## 软件研发公司里一线经理要做什么？
+
+搞清管理岗和个人岗有何不同之后，我们再来看看，软件研发公司的一线经理都要做什么。一线经理，简单来说就是直接管理一组程序员的经理。一个组的规模看具体的工作性质，可能是七八个人，也可能是十几个人，甚至更多一些。那么这样一个经理，平时都要做什么事情呢？我将从对内、对外以及对未来三个大方向和你聊聊。
+
+### 一、对内
+
+#### 从IC视角转向管理视角
+
+正如前面说的，IC转管理带来的是视角的转换。IC看管理，很自然的是一个从下向上的视角，觉得管理好呀，可以管人，自己不用做事情。但是真正屁股坐在管理岗上之后，就会发现自己手头的事情忽然多了，担子重了。这时候再看管理，内容就完全不一样了。“可以管人”就变成了要对手下的人负责，要让手下的人有事做，发挥价值。而“自己不用做事”这种想法，则变成了，“怎样才能发挥好管理岗作为神经系统的指挥、协调和管理作用”。
+
+#### 管理绩效
+
+管理绩效问题是每一个经理都绕不过去的一关。手下的兄弟姐妹们跟着经理干了一年了，谁该升职加薪，谁要黯然退场，都是经理需要搞定的事情。有时候甚至要开除员工。如果没有让大家心服口服，带队伍会越来越难。毕竟没好处的话，谁愿意拼呢？
+
+### 二、对外
+
+#### 组织协调各种资源
+
+经理每天的工作都可以说是在救火。人永远不够用，事情永远都很急，技术债务也在一天天成为发展的掣肘，线上生产问题还会时不时的凑个热闹。经理要组织协调各种资源，在有限的人和有限的预算内，把事情安排到内外各方都能接受甚至满意。
+
+#### 计划和安排，争取资源
+
+经理要给出未来的人员计划和安排，计划未来一年可能需要的预算（包括人、机器、软件等），这些资源分别用来做什么。
+
+这就要求经理必须深入理解自己队伍的家底和强项，并能够在自己的队伍发展和公司发展之间找到契合点，除了要证明自己的队伍现在存在的价值外，还要能规划未来发展的价值，进而争取到更多的资源。
+
+#### 进行各种交流，做出承诺和决策
+
+经理是一个组说了算的那个人，什么事情要在什么之前做完、做完的标准是什么、什么事情要做、什么事情拒绝做等等，这些交流和承诺都要经理给出。经理做出各种决策的同时，自己心里的算盘也要算清楚，手头有多少人，有多少事情，未来还能接多少活儿等等。
+
+### 三、对未来
+
+#### 理解公司发展方向
+
+作为公司的“神经系统”，当然要和“大脑”有通常的信息通道。经理需要洞悉公司和所在部门的发展方向，并理解发展方向背后的逻辑，在此基础上，才能够在繁杂的日常工作中找到工作的重点，让自己的手下能够把时间用在该用的地方。
+
+#### 培养人才，发展团队
+
+人才和团队是经理这根“神经”控制的“器官”和“肌肉”。一线经理很大一部分的工作就是要培养人才，发展团队，让队伍更具凝聚力和战斗力。前面我们讲到的一对一会议，就属于这部分内容。
+
+#### 获取客户，赢得认可
+
+经理还必须是个嗅觉敏锐的销售，队伍里的人负责做事情，经理要向外宣传，也就是所谓的“吹”。
+
+对于一个稍有规模的公司来说，一个需求有时不止一套解决方案。如何能够让自己的队伍做的系统，去争取到更多的高价值客户，创造更多的价值，就是经理要做的事情。同时，更多的需求也是打造产品的原材料，通过让队伍理解和消化这些需求，可以打造更好的系统。
+
+同时，一个公司的事情，往往是多个组协同合作完成的。你不出去“吹”，别人就看不到你在这件事情里的贡献，队伍的付出也就“打了水漂”。所以，如何把队伍付出的汗水包装成大家认可的成果，进而换回队伍的实际利益，也是经理要操心的事情。
+
+在一个队伍中，还难免会有各种摩擦，各种磕磕碰碰，各类杂事，这些经理当然也得去协调。
+
+## 什么样的人适合转管理？
+
+说了那么多经理需要做的事情，经理这个角色不知道在你眼里有没有发生一点改变呢？说实话，就我自己的经验来说，经理可真不是那么好当的。在我眼里，一个合格的经理需要具备如下的素质。
+
+### 喜欢和人打交道
+
+经理的大部分工作内容是要跟人打交道，搞定人和人的关系，搞定关系背后的各种利益，这非常考验经理自身的沟通和协调能力。
+
+同时，跟人打交道的事情不确定性更多，需要操心的事情也更多，工作也更累。所以软件研发公司的经理，绝对不是一个闲职，图清闲的就不用考虑了。
+
+### 会经营、有眼光、有干劲
+
+经理管着一票人，负责一堆事儿。心里要个本账，做什么划算，什么不划算。
+
+还有呢，经理也要有眼光，能够紧紧盯住公司和部门的发展方向，同时为自己的队伍制定适合公司和部门的发展方向。
+
+经理一定是有干劲儿，打心底里要做事情的人。正所谓，兵熊熊一个，将熊熊一窝。如果经理本身气场不足，那么队伍就不可能有太大战斗力。甚至自己队伍的地盘，有可能被人抢走。
+
+### 能够承受压力
+
+转管理之后，各种千头万绪的事情都会涌来，各种信息都要消化吸收，各种决策都等着你做，对外有交付，对内要有交代。所以坐在经理的位子上，抗压能力也是必须的。
+
+### 有远大抱负
+
+如果说前面提到的“要做事”，是管理的基本素质。那么有远大抱负，则是优秀管理者的必备条件。如果你看到技术的前进，感到的不是一般的激动和兴奋，而是心底里不断地涌出要用技术做出一番事情来的冲动，转管理可能是不得不做的选择。因为做技术你只能使用自己的时间，你会深深感觉单凭自己的精力，无法完成自己的抱负。
+
+看着满腔的激情和一天仅有的24小时，恨不得自己一个人可以变成十个人。当然这是不可能的，但你可以带领十个人甚至更多人和你一起做事情。所以如果想成大事，手里就一定要有一个团队，用利益，更用自己的激情，来带领团队实现心中的抱负。
+
+有一个很经典的例子。我们都知道，马云看到互联网之后，感觉这个东西能改变世界。那么他是怎么做的呢？他是不是去学计算机了呢？并没有。他肯定也知道这个事情大到单凭自己是无法做出成绩的，所以他选择组建团队，大家一起来实现心中的抱负。最后他也打造出了自己的帝国。
+
+## 谈谈“临界级别”
+
+无论是IC还是管理，越高端的地带，职位就越少。一般来说，公司都有这样一个临界级别，只要靠单纯的把经理交代的工作完成好，混“资历”就可以升职到临界级别。
+
+临界级别之上，每升一级，几乎都要淘汰十几个甚至几十个候选人。也就是说，就算单纯靠“混资历”，基本是没可能升到临界级别之上的。其实大家平时说的瓶颈，很多时候指的就是这个临界级别。
+
+事实上，管理职位的临界级别，确实是比IC的临界级别高了一级，甚至两级。所以普通人如果有做管理的素质，确实可以通过转管理，达到一个比做IC更高的级别。
+
+在我看来，我并不想从“管理更容易升职”这个角度来看待这个现象。我更倾向于理解为，这是对经理更多付出的一种肯定。也就是说，经理这个职位本身就更辛苦，升到更高的级别是一种合理的现象。
+
+## 我不转管理怎么办？
+
+不管程序员是否转管理，临界级别都在那里。很多软件研发公司的IC职位，也有着非常高的级别，程序员成长的瓶颈不是自己的角色是否是管理，而是在于自己的能力，是否能够达到职业生涯下一个级别的要求。
+
+很多人的迷茫其实是从“临界级别”开始的，不明白自己好好的把事情做完了，为什么不能升职。其实从临界级别开始，要想继续升职，就要实现自我突破，要能够承担起更重的担子，更大的责任。
+
+IC如果想要继续升职，方向有很多，可以吃透公司的业务，主攻业务；可以吃透公司各个系统，主攻架构；也可以主攻技术，成为某个方向的技术专家等等。当然，这些都需要根据自己的特长来决定，也都需要IC能够继续在技术上深入，有敏锐的技术嗅觉。但是有一个共同之处是，这时候，IC的工作就不单纯的是写代码了，花在与人沟通，塑造自己影响力上的时间会越来越多。也就是说，无论是否转管理，想要向更高级别迈进，都必须注重和人的交流沟通。
+
+但是IC和管理的角色还是很不一样的。它俩最大的不同之处就在于，管理要搞定人与人之间最复杂的一件事：利益。而IC则专注于做事情就可以了。
+
+## 解答开篇
+
+那么我们再回过头来看看开头的两个问题：
+
+1. 如果不转管理，是否就到了成长瓶颈，以后升职加薪基本没戏了？
+1. 如果不转管理，会不会到一定年纪就写不动代码了，对公司的价值会越来越低，慢慢就会被淘汰？
+
+第一个问题。成长瓶颈无论对IC还是管理，都是存在的。能够一直做一直升职的人，毕竟是少数中的少数。大部分人会卡在临界级别这里。这时候不妨积蓄力量以求突破，或者跳槽去别的公司寻找机会。
+
+第二个问题。确实，很多人在到了一定年纪之后，就没有写代码的动力，也没有学习新技术的激情了。这时候，一直混下去很难再有升职加薪的可能，甚至还可能被公司淘汰。如果觉得自己随着年纪和阅历的增长，能够应对管理的职责，那么转管理不失为一个不错的选择。毕竟软件公司的一线管理，还是需要有技术底子的人来做比较好。
+
+## 总结
+
+现实中，也很多人确实是因为对技术没兴趣了，才转管理。毕竟想在技术的路上走下去，学习各种新技术是躲不过的。转管理则可以在很大程度上不用关心各种技术细节。
+
+但是也不是每个人都适合转管理。就拿我来说吧，我在某个特殊阶段，短时间担任过一线开发经理。我感觉从担任经理的那一刻起，自己身上的担子立刻就不一样了。各种事情都要开始自己打理，可以说脑子里就没有一刻是闲着的。想静下心来搞点技术，基本上是不可能的。
+
+当然，这也跟每个人的能力有关。对于擅长这种事情的人，会觉得管理岗位激发了自己的潜力，让自己越干越带劲。但对于我来说，除了累，就是累。所以我还是选择了技术方向。潜心做技术，可以让我感受到发自内心的快乐和满足。
+
+所以是否转管理，答案就在你自己心里。你对什么饱含激情，就应该朝着那个方向努力。
+
+<img src="https://static001.geekbang.org/resource/image/a1/38/a115ec84d69c17790fc3933cfd9bca38.jpg" alt="">
+
+## 思考题
+
+你有考虑过转管理吗，或者你有过转管理的机会吗？你的选择是什么？回顾你的成长历程，你有哪些感触呢？
+
+欢迎在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职业选择篇/15 | 职业规划 ：程序员加入创业公司，这些事情你想清楚了吗？.md

@@ -0,0 +1,105 @@
+<audio id="audio" title="15 | 职业规划 ：程序员加入创业公司，这些事情你想清楚了吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c0/95/c0bbb1844f36d4de8f7e790cf9866e95.mp3"></audio>
+
+你好，我是臧萌。今天我们来聊聊程序员加入创业公司那些事儿。
+
+前面我们聊了一些关于选公司的想法。这些公司呢，属于有成熟稳定的业务模式的公司。也就是说，工资水平属于行业合理范围内，基本不会没日没夜的加班，不用担心整天换方向，不用担心下个月会不会按时发工资等等这些问题。
+
+但创业公司就不一样了。加入创业公司，靠的就是要有一股子冲劲儿。创业公司作为一种特别的类型，我在这里再单独拿出来给你讲讲。不过呢，这里说的“加入”，不是自己去搞个公司创业，而是作为创业公司的早期员工加入进去。这么说可能还是比较含糊，那我们就先来框定一下我们要讲的创业公司的范围。
+
+## 创业公司到底是指什么公司？
+
+在我看来，对于程序员来说，创业公司指的是，能够通过自己的超常付出，在以后事业有成之时，获得超额回报的公司。注意这里有个很重要的前提，是“对于我们程序员来说”。很多公司可能会由小到大，慢慢走向成熟和稳定，但是这些公司对于程序员来说，不一定是创业公司。那具体哪些公司对于我们程序员而言，不能算创业公司呢？
+
+### 1.做项目变现的公司“不是”
+
+做项目的公司类似软件作坊，包括但是不限于一些小的外包和外派公司。对于这些公司来说，公司的核心竞争力主要是利用自己的人脉和关系拉项目。而这些项目本身，大都是以业务为主，比如一些ERP系统、换皮小游戏等等。只要公司有一两个技术大拿，一般都能顺利做出来。所以说，这种公司基本能够“做一票、赚一票”。只要一直能有项目做，就可以稳稳地赚钱。加上这些公司一般规模都不会太大，所以可以很好地控制自己的收支，不需要承担太多的风险。
+
+因此，这类公司其实更像是人脉关系变现公司。做软件只是一种途径而已。如果愿意的话，单靠转包项目一样可以赚钱。这类公司的核心成员不是程序员，而是可以拉来项目的成员。所以，对于拉项目的核心成员来说，这个公司才可以称得上是创业公司。
+
+但是对于程序员来说，我们可要小心这类公司了。如果这些公司忽悠你，说，我们是创业公司，现在正在发展期，薪资你吃点亏，以后事成了你就跟着一起发达了云云。千万切记不要当真！这些公司的核心竞争力在于拉项目的能力，和程序员、技术一毛钱关系也没有。对这种公司来说，换个程序员的成本是很低的。既然如此，那么为什么公司要做“慈善”，把自己赚的钱多分给你一些呢？所以啊，加入这些公司之后，即使你努力拼搏，这些公司也不太可能在未来给你带来额外的收入。
+
+### 2.小公司“不一定是”
+
+很多人觉得，创业公司都是从小公司做起的，但是，有一点我想着重强调一下：小公司不等于创业公司。
+
+这个和刚刚说的内容有一些重叠，因为很多做项目的公司的确都是小公司。创业公司可能是小公司，但是并不是只要是小公司，就是创业公司。而且，很多创业公司也是具有相当规模的公司。
+
+**我一直觉得，想要获得超额回报，最根本的逻辑呢，是要成为公司核心竞争力的一部分，要能够在公司创造价值的链条上成为重要的、不可替代的一环。仅仅是重要还不行，如果很容易被替代的话，能分到手的利益很可能也只是象征性的。**
+
+所以说，一个公司是不是创业公司，对于不同的人来说是不一样的。对于小公司的创立者来说，他们确实是在创业。因为他们可以在摸索出一条道路后，提高自己的利润率，让公司成为给自己下金蛋的鹅。但是和刚才的情况一样，在这整个链条上，如果程序员并不是核心要素的话，这个金蛋就和程序员没有关系。
+
+当然，很多人也是加入小公司之后成长起来的，也获得了丰厚的回报。但前提是，他们能够挤进价值创造链条里，成为一个重要的不可替代的一环，比如精通业务，比如赢得了很多大客户的认可等等。不过，这种情况并不能够涵盖广大的一线程序员，所以我们在这里也不去讨论这种情况。需要补充一句的是，这种人才，即使不加入创业公司，而是进入成熟的大公司，很多情况下也可以通过自己的努力和才干获得丰厚的回报。
+
+### 3.创造新事物的公司才“是”
+
+属于程序员的创业公司，一般是那些做产品、做平台，或者有核心技术、做新模式的公司，是创造出某种事物的公司。这种公司有一个共同的特点，那就是可以借助软件系统零成本复制的特点，让自己的产品或系统成型之后，用很低的成本让它去服务更多的人，让程序员的工作成果可以用很低的成本被放大。这些公司大部分会涉及做游戏（换皮游戏不算）、数据库、语音识别软件、图形图像识别、电商平台、支付平台、云计算平台等内容。
+
+这样，一个程序员创造的价值也会随之被放大很多倍。这种情况下，程序员才可能会是整个价值链条上重要且不可替代的一环，在成事之后的财富分配上，才会有程序员的一杯羹。
+
+## 加入创业公司，需要权衡哪些事情？
+
+刚才我们讲了创业公司的定义，相信已经可以让很多冒充创业公司来忽悠程序员的“李鬼”公司显形了。那么，在加入创业公司之前，程序员有哪些事情需要权衡呢？
+
+### 1.提前算好收支这笔帐
+
+据我所知，创业公司一般给的待遇都偏低，然后用期权来“画饼”。创业时期真的是一天天撑下去的，非常有可能是面临失败。具体会面临哪些事情呢？我们不妨把自己带入下面几个场景，想想看自己经受这些事情的时候。
+
+- 公司未来几年都不会给自己涨薪，因此未来几年的生活都要靠现在的薪水水平来支撑，你觉得自己的情况可以承受吗？
+- 公司倒闭了或偶尔不按时发工资时，自己的积蓄要能支撑自己的生活，这样的事情你能承受吗？
+- 创业失败，期权变废纸，多年的努力奋斗换来的金钱收获为0，这样的事情你能承受吗？
+
+可以说，这三个场景发生的几率都比创业成功的机率还要大。我们前面讲到，创业公司要创造出新的东西，这样才可能在新市场里获得巨大的回报。创造和做项目不一样，做项目时，只要按部就班的工作，就可以稳稳地拿工资，而创造要面临很大的失败的可能。创业失败的可能性太多了，方向不对不行，太早不行，不然可能是为后人培育市场，太晚也不行，不然可能只能喝汤甚至都无法入局，执行力不够强不行，没钱了撑不下去不行等等。
+
+### 2.选择公司就是选择团队
+
+正所谓小船好掉头。我们加入创业公司，最重要的不是看创业公司现在的方向，而是看创始团队。创业公司调整方向是非常常见的操作，真正有价值的是创业公司团队。一支磨合好的团队，远比一个对的方向有价值。方向可以随时调整，但是一个好的创业团队真没那么容易攒出来。
+
+那怎么才算一个好的创业团队呢？我觉得，一个好的团队，就是能让大家在困顿时依旧有斗志，要让大家在一次次摔碎心之后能再次拼起来、继续拼命，要能拧成一股绳，要有强大的执行力……
+
+那怎么了解要加入的团队呢？现在网上消息很多，你完全可以通过网络去搜寻信息。这个我想不用我多说。我想说的是，如果可能，尽量找到在这个公司工作过或者正在工作的人，去了解一些一手信息，或者多找一些人来帮助自己，从多角度进行判断。千万不要自己一拍脑袋，贸然就下决定。
+
+通过自己熟识的人，是我比较推崇的一种了解团队的可靠方式。我有个朋友从北京跑到杭州加入了一个创业的公司，我问他为什么，他说师兄在那边，做着顺。这就是通过自己认同的人，选择团队的方式。我觉得是一种选择创业公司的正确姿势。
+
+### 3.认可创始人
+
+前面我们聊过跟对人，也聊过公司的文化和价值观。这两点对于加入创业公司的程序员来说，尤为重要。
+
+你可能要说了，我只是个小程序员，就算公司再小，也不大可能归创始人直接管，创始人是谁，和自己关系并不大吧？
+
+实际上，创始人对一个公司的影响是巨大的。很大程度上，创业公司就是创始人的延伸。可以说，在公司孕育出自己的公司文化和价值观之前，创始人就是公司的文化和价值观的代表。所以说，如果无法认可创始人，也就代表着你可能无法认可这个公司的文化和价值观。
+
+同样，各级经理也是创始人的延伸，如果你不认可公司的创始人，那么大概率也无法适应你的经理，就算你的能力再强，很可能你在这个公司也无法发挥出真正的能力。
+
+### 4.亲兄弟，明算帐
+
+一旦加入创业公司，程序员肯定期待获得一定的回报。
+
+对程序员来说，很多创业公司会承诺给期权和股票的回报。所谓亲兄弟，明算帐，就是说千万不要相信口头的承诺，所有承诺一定要落实在纸面上那才是生效的。只给口头承诺，就是耍心眼、纯忽悠。如果在画大饼的时期，这家公司就开始不实在，你觉得这种行事风格，在公司真的赚钱之后，在画的大饼变成真金白银的时候，会老老实实分给你吗？
+
+### 5.准备好强大的精神和肉体
+
+创业真的很累，真的真的很累。从头到尾创造一个新的事物，各种东西都要自己搞，能不累么？连续通宵、车轮战时不时来一波、每天只能睡三五个小时，这些可能都是在创业公司工作的常态。长期待在这种状态中，单单靠画饼肯定是无法支撑下去的，一定要有足够的精神力量支撑才行。当然，这里也呼应了前面创业团队和创始人的重要性。
+
+精神的力量有了，肉体也要允许才行。所以，你还要考虑一下自己是不是适合奋斗的体质。
+
+怎么判断自己是不是够强大呢？我给你一个简单的问题，你可以来验证一下：你虐过自己吗？你有为了一个目标，坚持数周数月甚至数年，努力奋斗，通宵达旦，咬碎牙根，受尽挫折，一次次看着自己的付出化为乌有却依然热血沸腾过吗？如果没有，请慎重考虑加入创业团队。
+
+### 6.能持续跟得上公司的发展
+
+创业公司如果真的飞速成长了，我们自己也要能跟得上公司的成长。所以，千万不要抱着“我加入的早我就是元老”的心态，进入创业公司。只有那些能够一直跟着公司成长的人，才能成为创业公司的“元老”。只能拼一阵的，大概率会被创业团队淘汰。
+
+## 总结
+
+在创业公司拼搏，超常的精力付出是绝对的，但超额的金钱收获却是低概率的。绝大部分的创业公司，都没有掀起一点波澜，就消失在人海中了。作为程序员的我们，要能分辨出哪些是真正的创业公司，了解清楚这个创业团队是否适合自己加入，还要能平衡好自己的拼搏和生活。
+
+其实，我一直觉得，创业是一种心态，而不是一种姿态。在富有活力的成熟公司，我们其实依然可以用创业的心态进行工作。有了创业的心态，一个组就可以是一个小的“创业公司”，别的组就是自己的客户。虽然成功了之后，收益没有创业公司高，但就算是失败了，最多也就是没有额外的收获而已，不会有额外的损失。
+
+创业的拼搏，堪称游戏的Hell难度，而平时的日常工作，可以说就是游戏的Normal难度。但是，不得不说，创业带来的经历和成长可以说是一生受用的。我自己年轻的时候也曾经拼搏过。现在回想起当时自己那股子劲儿，就觉得现在的工作就和玩儿一样。**创业，也许大概率不会有金钱上的收获，但是可以让你看清自己的潜力**。创业的岁月，是一份值得让自己一直珍藏的回忆。
+
+<img src="https://static001.geekbang.org/resource/image/48/df/488239698e5cf9f7fc69d562f9476cdf.jpg" alt="">
+
+## 思考题
+
+你或者身边的朋友，有去过创业公司工作吗？有遇到过什么问题吗？
+
+欢迎在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职业选择篇/16 | 答疑篇：为啥你工作八年，只抵别人一年？.md

@@ -0,0 +1,104 @@
+<audio id="audio" title="16 | 答疑篇：为啥你工作八年，只抵别人一年？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/24/49/24ec8ae5da00035b8b297eb06162ed49.mp3"></audio>
+
+你好，我是臧萌。转眼之间第二个模块也结束了。我在这个模块里，讲了我们职业生涯中可能遇到的各种职业选择的问题。
+
+职业选择可以说是个大话题了，这个模块也是整个专栏中篇幅最大的一个。围绕着公司、行业、经理、外包外派、面试、跳槽、转管理、创业等等话题，我们聊了很多，举了很多例子，很多同学也分享了自己的亲身经历，也有很多同学提出了很多很好的问题，总结了很多经验。我觉得有些内容非常值得一起分享一下，让我们一起来看看吧。
+
+## 员工为啥会“水土不服”？
+
+**@大土豆**  同学问道：“我见过很多在之前公司表现极为优异的人，换到另一家公司就表现平平，甚至有些人的表现竟然差到要被末位淘汰，这个点感觉很有深入的意义，老师认为是什么原因呢？是否可以举个例子？”
+
+作者答：这个对比比较强烈，说出来确实会对很多同学有参考价值，更证明了选择合适公司的重要性。
+
+真正的原因可能很复杂。我根据自己的见闻，来说说我的理解。我觉得主要原因是，在不同的公司文化和价值观影响下，对工程师行事风格的要求不一样。
+
+每个公司的风格不同，对每个员工的期待值也不同。有的公司的风格更倾向于稳稳的、慢慢的、妥妥的。有的公司的风格更倾向于快糙猛。就好像一个米其林三星的厨师，去食堂当厨师，并不能惯性地靠自己之前的行事方式，来赢得当时在米其林三星餐厅的地位和荣誉。虽然都是做饭，但是米其林三星和食堂对做饭的要求是不一样的。
+
+你可以想象一下，一个厨师在食堂里，跟大家分享了一个“在包子馅儿里加入橄榄油并充分搅拌，放进冰箱冷藏三个小时后使用，可以让包子馅的口感更润滑”的经验。这个厨师肯定会收获同事们的一顿奚落：“得嘞您呐，照您这么来，咱们一天光做包子就忙不轻。”但是，他在米其林三星餐厅里，就是一天只负责做几笼完美到无可挑剔的包子啊，可为啥到了食堂就不被认可了呢？当初他的包子馅的各种创新，可都是得到厨师长的点名表扬了呢。为什么呢？还是那句话，米其林餐厅和食堂对做饭这件事有着不同的评价标准。
+
+公司也是一样的，比如说，有的公司倾向于让员工专心做一件事情，做到极致，有的公司倾向于让员工成为多面手，什么都要能搞定。而每个人自己适合哪种风格，是否能改变自己的风格，适应公司的风格，这都是影响人才继续发光发热的因素。
+
+老牛适合拉车，快马适合跑快递。都是运输，风格不同。
+
+## 沟通不高效，试试一对一？
+
+很多同学也都提到了和经理一对一会议对自己的帮助。也有同学提到之前公司没有一对一会议，现在公司有了，对比之下才觉得现在公司更人性化。
+
+这里我再提一提，一对一会议真的不只是表面形式。一对一会议运用得当，可以解决很多问题。会议会提供一个私密的环境，让人敞开心扉地交流，拉近人和人之间的关系。在一对一会议时，生硬的上下级关系会变得温和，因为彼此之间，不再是纯粹的工作关系，更像是朋友在一块探讨事业与人生。
+
+如果同学们现在的公司没有一对一会议，而你正好是个经理，我建议你可以试一试，没准效果超乎你的想象。
+
+## 大厂的经历对于职场生涯有何意义？
+
+**@天凉好个秋**同学问：“老师觉得有必要为了镀金而想方设法跳槽去大厂吗？有人说去大厂好几年，用惯了大厂的各种工具，出来会很不适应，也有人说大厂的边缘部门也很惨，老师如何看待好多人‘迷信’大厂的现象呢？”
+
+作者答：我觉得这些看法都有道理。你去大厂可以镀金，搞得好的话还能成金。就好像你说的“迷信”大厂。大厂之所以能大，而且能撑得住这个大的规模，肯定是有其过人之处的。只要姿势对，去大厂，尤其是头部的大厂，肯定可以学习到更多的东西。从这个角度说，我觉得这个不能叫迷信，因为人家大厂确实是干得好嘛。当然如果是一些走下坡路，吃老本的大厂，可能实际上已经被淘汰了，这种情况徒有其表，那就是另说了，可以说是“迷信”。
+
+你在大厂能用的工具是很多，出来工具没有了确实不顺手。但是这种不适应不也是一种机会吗？可以在新公司搞新系统呀。去大厂不就是为了长见识，然后用在合适的地方吗？
+
+有的大厂的边缘部门机会比较少。我建议你去之前还是先问清楚。但是机会都是自己创造的，我也见过一个组把非常没前途的系统，愣是给怼成了明星项目。公司存在这个组，就有它的意义。能把这个需求解决得明明白白的，就是价值。
+
+## 定期出去面试真的好吗？
+
+**@Newbie** 同学问到：“老师怎么看待‘跳不跳的另说，每年出去看看外面的行情’这种说法。这种没有强烈跳槽目的的面试有必要吗？”
+
+作者答：我觉得，这个做法没有必要。这样做既耗费双方的精力，还可能会影响自己的名声。我来具体为你分析一下。
+
+1. 行情可以和同学朋友聊，没必要非自己跑一趟。
+1. 面试需要充分的准备，如果不是抱着我要换工作的决心，很难准备得很好。如果状态不好，那么面下来也可能拿不到自己应该达到的水平所对应的offer。
+1. IT圈子其实很小，面试过，早晚会传出来。除非你真的是个小透明。
+1. 你会被拉黑。如果你面试过了，拿到offer又不去。那么很可能会上公司的黑名单。面试其实是一个非常耗费公司资源的过程。从工程师到经理到HR，每个人都要放下手里的工作，把面试者面一轮。再加上前前后后的准备，各种审批，结果公司给你发了offer，你又不来，一方面可能耽误别的想来的人，另一方面也浪费了公司的资源。
+
+关于被拉黑，多说一点。很多公司会考虑将发了offer，但是没有什么理由就是不来的人，拉入黑名单，以后不再面试，或者把发 offer 的优先级向后排。这里一般有几种可能。
+
+1. 一种是你说的，就是出来看看。
+1. 一种是count offer，拿着一个offer去继续面试，要求下一个公司给更高的offer。
+1. 一个是拿着offer和现在的公司谈，要更高的薪资。
+
+无论是哪种情况，只要面试者不入职，那就都是在浪费面试公司的资源。公司也有足够的理由拉黑这些面试者。
+
+所以，如果你想出去谈谈、看看，不妨跟对方公司直说，就说自己来的意愿不大，面试看看情况。如果这样对方可以接受，或者相信可以打动你，那你们再接着往下谈，双方会聊得更深。正所谓打开天窗说亮话嘛。
+
+## 为啥我工作八年，只顶别人一年？
+
+总体来说，大家还是比较认可外包和外派不适合做太久的。在自己的能力提升之后，应该跳出自己的舒适圈，找个更对得起自己能力的工作。
+
+同时，做外包比较容易陷入不需要自我提升的陷阱。因为自己按照公司要求完成工作，公司也对自己没更高的要求，感觉这样就可以了。这里借 **@每天晒白牙同学** 的一句精华： “一年经验用了8年，而不是8年工作经验”。如果你做外包外派的时候，感觉自己的技能树很久没长过了，那就要多多提醒自己，在生活中去有计划地提升自己，跳出舒适圈。
+
+## 技术和管理，哪个才能让你感觉更安全？
+
+**@bigben** 同学说：“做管理没有安全感，还是做技术心安，技术在手说走就走。”
+
+作者答：我觉得，技术够硬，管理够软。其实各有各的优势，也各有各的难处。
+
+技术的优势就是简单，干活靠自己，够硬。到哪儿都能靠技术干活出活。就像上面说的，技术在手，说走就走。反正是干活嘛，靠技术，没毛病。
+
+技术和管理这么一比，就显出了管理的劣势。基层管理靠的是各种软技能。虽有套路，但是对公司、对环境、对团队、对周围人脉的依赖都是有的，靠自己没法出活。很多时候，公司裁员也会优先选择裁中低层的管理人员。
+
+但是反过来说，技术也有劣势。技术的劣势就是随时可能被淘汰，要一直学习新的技术，要时刻关注各种技术的发展方向。
+
+举个简单的例子，在 Web 井喷式发展之前，JQuery 可以说是统治了前端。然后 Web 开始井喷式发展，各种框架层出不穷。现在呢，JQuery 已经在新的项目里寻不着踪迹了，很多老的项目也在迁移。
+
+可以说，发展越迅猛的方向，技术更迭越快，比如前端。而发展迟缓，或者本身就不适合市场的技术方向，整个可能被替代，比如Java中的EJB，现在就被 Spring 替代了。
+
+对比之下，管理的优势就是技能和经验，不会被淘汰。
+
+技术招聘上会有各种专项技术要求，比如“使用 Java 多少年”，“使用C多少年”，“精通性能调优”等等。但是招聘管理的时候，就不会写“有多少年管理Java 程序员”的经验。只是会要求多少年管理研发团队经验。当然，偶尔还会对行业有要求。
+
+硬，容易折了，折了就得换新的。软，不容易折了，但是要有依托。
+
+最后补充一句，计算机的基础知识，就是定海神针，既稳，又硬。比如计算机网络、操作系统、编译原理等等，这些都是看不到被淘汰的可能的。
+
+## 总结
+
+关于这个模块，最后总结两句话送给你。第一，选择比努力更重要。第二，不想被淘汰，必须不断成长。
+
+关于选择比努力更重要，当下的疫情就是一个例子。当然没人能预测到这么一个黑天鹅事件，在这个事件里，没人能独善其身。但是从方向来说，互联网是趋势。无论是在线教育、在线办公、在线购物，还是更底层的在线支付，都是未来的方向，受到的波及也更小。相信经过这一波，不少老年人都学会了在线支付和在线购物，不少小朋友也都经历了在线教育。
+
+同时，从大行业上来说，软件行业受到的波及也更小。至少绝大部分程序员都可以在家办公。程序员的饭碗不至于因为不能出门而受到直接的影响。
+
+关于成长，无论是做技术，还是做管理，都别躺在舒适区一动不动。随着年龄的增长，人的精力是肯定会下降的。如果不能拿时光换能力，支撑起更好的明天，而只是拿时光换舒适，那以后的舒适，就没有支撑了。
+
+以上就是答疑篇的内容，不知道有没有解决你的困惑呢？
+
+欢迎你在评论区与我交流一下你的想法，也欢迎把这篇文章分享给你的朋友或者你的同事，一起来交流一下。

极客时间专栏/geek/职场求生攻略/职场情商篇/17 | 升职：看着周围的人都升职了，我什么时候才能升职？.md

@@ -0,0 +1,135 @@
+<audio id="audio" title="17 | 升职：看着周围的人都升职了，我什么时候才能升职？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ae/ce/aef2d76e201b45yy81499455135e3dce.mp3"></audio>
+
+你好，我是臧萌。今天我们来聊聊升职那些事儿。
+
+升职加薪，人人心向往之。但是升职之路，怎么才能走得顺呢？大家都在同一个公司混，为啥别人升职我没有，我真的比别人差吗？要是差的话，又差在哪里呢？今天这篇文章我们就来聊聊升职这档子事儿。
+
+但我讲的不是咋升到很高的层次，我就讲如何从萌新升到临界级别。临界级别我之前的文章中有提到过，简单来说就是指在公司里只要专心把事情做好，就可以升到的级别。临界级别我们都能达到，但是有人到的快，有人到的慢，还有人到了临界级别后，憋很多年也没升职。
+
+## 升职的逻辑
+
+那你可能要问了，这到底是为啥呢？其实，升职这事大有学问。首先呢，我们来聊聊升职的逻辑。每家公司的风格都有不同，我给出了你升职逻辑的四个共同点。
+
+### 1.先做到，再升职
+
+说到升职，可能很多朋友会有一个问题：我本职工作做得很好啊，可为什么升职没有我呢？
+
+这就要说到升职的第一个逻辑了，那就是先能做到下一级别的事情，才会升职到下一个级别。简单来说，你要先证明自己具备下个级别的能力，才能升职到下个级别。而不是去指望公司先给你升职，再自己努力达到下一个级别的要求。
+
+所以，当前的工作做得好，只能说明自己能力对得上当前的级别。当前的工作越做越好，加薪的几率越大。但是这并不是说当前的工作做好了，就理所当然地可以升职了。
+
+公司给员工升职加薪，不是因为他之前做得多好，而是因为相信他以后能够做得更好。公司是为未来买单。简单来说，公司花钱肯定是有明确的目的。俗话说得好，不见兔子不撒鹰。你之前做的工作，公司给了你工资，给了你奖金，这就是两清了。只有你已经证明自己可以做得更多，做得更好的时候，公司才会相信你未来也可以延续这个势头，然后考虑给你升职加薪。
+
+如果你任性地想着，公司不给我升职，我为啥要做得更多？那你就完全想错了。因为公司和经理不会这么想。因为你的表现还没达到下一个级别，如果给你升了职，结果你还是达不到下一个职级的要求，那怎么办？
+
+毕竟一个职级应该做到什么，做得好不好，都是比较主观的事情。升职升上去了，再降下来的话阻力就会很大。这就好像奖金一样。奖金的规定可以模糊，但如果是罚金，那一定要规定得很严格，否则没人觉得自己应该被罚钱。升职的决定权掌握在公司和经理手里，那么公司和经理自然想让升职这件事情的主动权掌握在自己手里，而不是你手里。
+
+大多数时候，很多公司对于那些无法证明自己能力的老员工，不会给他们升职，而是宁可招聘新的更高级别的员工。因为员工如果表现没有到下一个级别，给他们升职就会是一个错误的示范。会让更多的人觉得混着就应该得到升职。公司可不想让员工有这种念头。
+
+### 2.稳定输出
+
+你可能又要问了，下一个级别的同事能做到的事情，我也能做到呀，为啥我还没升职呢？
+
+这里就要说到稳定输出了。在职场，稳定的输出是黄金一般的品质。
+
+我们来举个视频App的例子。比如说有这样两个视频App，一个App在打开视频的时候，有99.99%的概率会最多缓冲3s，后面就会顺畅播放视频。另一个App有80%的概率视频一秒不卡，还有20%的概率每一帧都卡，卡到忧伤。如果只能选一个App，你会选择哪个App？我想大部分没有自虐倾向的人都会选择第一个App。这就是稳定的魅力。
+
+工作中也是一样。稳定输出，结果可期。不求有惊喜，但求没惊吓。如果做一个事情这次用一天，下次用五天，再下次用一个小时。试想一下，如果你是经理，你敢给这样的员工重要的事情吗？万一下次用一个星期都搞不定呢？所以不如去选择一个，每次都能两天搞定事情的员工。
+
+级别越高，对稳定输出的要求也越高。这里稳定输出的内容，也可能不仅限于具体的某个工作。也包括一些日常琐碎的事情，比如不会漏掉客户发来的邮件和消息、每天都会查看系统dashboard、每次都记得将发布流程按规定走完、每次写完代码都会记得增加UT、每次遇到问题都会记得给系统增加新的报警规则等等。
+
+稳定代表可靠。所有的经理都喜欢稳定发挥的人。而经理喜欢的人，有更大的升职机会。
+
+结合前面说的“先做到，再升职”的逻辑，稳定发挥意味着你能够在连续的几件事情上，都发挥出下一个级别的能力，达到下一个级别的水准。这样才能让经理对你放心，你才会有更大的升职概率。时而行时而不行，就好像一盏灯一会儿明，一会暗，只会伤眼睛，起不到太大的照明作用。你只有稳定地发出光，才能当灯用。
+
+### 3.不仅要绝活，更要靠全面
+
+我们玩技术的，都更喜欢靠技术出位。也就是说，要靠自己技术好，博得大家的认可。这点没问题，但是光技术好是远远不够的，还要足够全面，这样才是全面的好。别人都会的，自己也要会。然后再去说别人不会的我也会。而不是别人都会的，我觉得没意思，我就要整点别人都不会只有我会的。
+
+我再来举个例子帮你理解一下绝活与全面的关系。假设一个人在工作中需要使用ABC三种技术：有两个选择，一个选择是自己的A和C技术都达到平均水平，B技术略突出；一个是自己A和C技术基本无法完成工作，B技术超牛，各种犄角旮旯的东西都会。
+
+在实际工作中，前者会更受经理喜欢。毕竟工作中用到的技术是全面的，只会B技术，基本无法独立地去完成任何一项工作。即使偶尔有机会靠B技术，亮出自己的绝活，也无法让人认可他的综合能力。
+
+所以我建议你不要沉迷于只靠绝活。工作中用到的技术，你一定都要学会，就算是硬着头皮学，也得让自己能达到可以独立完成工作的程度。毕竟公司雇佣一个员工，是为了让员工完成工作，不是来技惊四座的。
+
+### 4.资历老
+
+在能力差不多的情况下，肯定是资历更老的同事更容易升职。这是人之常情。就好像我们前面提到的，程序员的日常工作还包含了交流和沟通，资历老的同事在一个公司里认识的人更多，这也是能力之一。
+
+同时，资历老的同事通常有更多公司相关的经验积累，比如熟悉各种明坑案渠，各种系统怎么用，哪个同事对某个系统最精通等等。升职资历老的同事，一方面是对这种软能力和技能的认可，同时也是对资历的认可。
+
+## 程序员的三个阶段
+
+每个公司的职级划分都不同，对于每个职级的能力要求也都不同。我根据我的经历和理解，将程序员的能力划分为下面三个阶段。
+
+### 1.写代码
+
+这个阶段的工作就是能够按照设计，完成代码的编写和bugfix。这个阶段要锻炼出熟练的编码手感，养成良好的编码习惯。按照我的理解，这个阶段要达成的主要成就有以下五个。
+
+- 能够完成具体功能的代码，保证代码质量。
+- 有阅读代码的能力。
+- 开始理解和掌握基本的设计模式。
+- 不再闷头就开始写代码，而是开始在class和package层级，思考和实践高内聚、低耦合的代码。
+- 建立自己学习技术的体系，培养学习技术的习惯。
+
+这个阶段的成长点集中在写代码。经过这个阶段的成长，一个明显的感觉就是写代码不再是问题了。这个阶段一般会需要3到5年的经验积累。紧接着，就会进入下个阶段。
+
+### 2.能掌握
+
+这个阶段，除了要承担代码编写的任务之外，还能够理解整个系统的设计，针对系统的新功能，能够给出和现有系统连贯的设计，并能够承担新系统的设计，理解这些设计背后的目的。按照我的理解，这个阶段要达成的成就有如下六个。
+
+- 接到需求，能够快读准确的给出可行性，难点，系统集成点，给出设计和工作量估计。
+- 可以将一个系统的设计划分为高内聚，低耦合的模块，并给出工作量估计。
+- 补全自己计算机底层知识的短板。有一个自己是在做系统设计而不是瞎做系统设计的底气。
+- 锻炼自己快速掌握一门技术的能力，包括技术的总体设计，优缺点，使用场景等。
+- 熟练掌握这个系统，能够快速排错。
+- 能主导搞定系统里的一个项目。带领低级别的同事做项目，自己能发挥主导作用。
+
+经过这个阶段的成长，最明显的感觉就是自己清楚系统的方方面面，各种细节，系统能力的边界等，知道自己能稳稳地搞定这个系统。这个阶段一般需要3到8年的经验积累。这时候，就会很自然地想到这个系统的明天会怎样，也就很自然地进入下个阶段。
+
+### 3.能hold住
+
+这个阶段的意思就是能够own一个系统，系统各种大大小小的事情都能搞定。换句话说就是有ownership。说起这个系统，第一个想到的就是你。而且你的稳定发挥也不会让人失望，只要是这个系统的问题，找你马上能够快速直接的解决。按照我的理解，这个阶段要达成的成就有这四个。
+
+- 逐渐掌握系统的全貌，设计新的功能时，可以通篇考虑。
+- 可以对系统进行重构和升级，解决系统的技术债。
+- 开始积淀起自己在相关领域的业务知识，理解领域中的难点，易出错的点和痛点。
+- 可以顺畅地和上下游相关同事沟通交流，并开始培养自己的影响力。
+
+经过这个阶段的成长，最明显的感觉就是对这个系统有了feel，不仅对系统当前清楚，能清楚地知道系统解决的问题，基于此，对系统的未来有自己的想法，可以让系统发展到一个更高的层面。这个阶段一般需要8年以上的经验积累。
+
+能够own一个业务系统，基本上就可以顺利升到临界级别了。这时候，已经站在半山腰了，怎么继续向上爬，需要根据自己的特点来拿捏了。
+
+## 到底我能不能升职？
+
+那到底我能不能升职呢？那我们就得从经理的视角来看看升职这件事了。首先，经理是否愿意本组的人升职？答案是肯定的。经理肯定想争取到更多升职的名额，这样，自己的队伍相当于是壮大了，也就相当于自己有了更多的资源。给自己的手下争取更多的升职机会，是符合经理的利益的。所以，首先弄清这一点，别没事儿就老觉得经理在想着法地不给自己升职。
+
+但是公司肯定是有自己的预算的，每个经理能争取到的升职名额也是有限的。所以如何分配升职名额呢？如果我们是一个经理，我们会尽量避免给哪些人升职呢？
+
+首先，不符合文中开头说的升职的逻辑的人，大概率不会升职。这个是硬性指标。
+
+其次，和经理彼此不对付的人，也基本和升职没太大关系。每个人都有自己的好恶。经理也不是圣人，他为什么要给一个自己不喜欢的人升职呢？让他做更重要的事情，然后继续和自己对着干么？这点我们在经理那节也说过，这里不再细说。
+
+还有就是，经理不会给离职可能性大的人升职。如果好不容易争取来的升职机会，刚给一个员工升职，没多久他就走了，这会让经理很头疼。这样一方面是浪费了升职的机会，另一方面也是对自己的考核不利。因为这代表自己辛苦培养的人才流失了。
+
+同时，对于离职可能性大的人来说，升职之后去找工作更容易，这更加增加了离职的可能性。但是对于员工来说，一直升不上去，就会越来越难在外面找合适自己的工作。所以还是那句话，遇到不对付的经理，如果确实非常不对付，那么可以考虑换个组了。
+
+<img src="https://static001.geekbang.org/resource/image/38/b7/38c3079503a90df6838c2251d83174b7.jpg" alt="">
+
+## 总结
+
+升职是职场永恒的话题。职场永远不缺辛苦工作，却多年无法升职的故事，也从来不缺有人火箭速度升职的传说。有人喜欢富贵险中求，有人喜欢步步为营。本文给出了升职的一些总结和思考，但现实总会更复杂些。
+
+升职不是游戏里的打怪升级，不能像游戏里一样砍怪就加经验，经验到了就能升。升职背后的各种利益考量，各方势力的角力，都会影响最终的升职结果。一时的得失，难免让人心态失衡。而关于升职，最重要的一点就是不要让自己的心态失衡，影响到自己的发挥。升不升职，都要有自己的职业规划。
+
+有次我在一个老同事群里讨论升职之类的事情，有个同事说了一句话，我印象深刻，记忆至今。他说：“从足够长的时间跨度来看，公司对我们是公平的。”
+
+其中滋味，各自体会。
+
+最后，祝你在升职的路上，守得云开见月明；祝你在升职的路上，柳暗花明又一村。
+
+## 思考题
+
+关于升职，你有什么故事吗？有过没想到我竟然没升职，或者我竟然升职了的疑问吗？
+
+欢迎在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职场情商篇/18 | 职场政治：我只想好好干活，职场政治和我有什么关系？.md

@@ -0,0 +1,95 @@
+<audio id="audio" title="18 | 职场政治：我只想好好干活，职场政治和我有什么关系？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/9e/40/9ebeeyyc751f2b27c3500bcd7df75d40.mp3"></audio>
+
+你好，我是臧萌。今天我们来聊聊职场政治那些事儿。
+
+不过我首先得强调一点，这篇文章并不是教你怎么搞职场政治。毕竟在职场政治这个大舞台上，我们程序员不是主角。这篇文章的目的就是为了能让你理解职场政治的必要性，理解职场政治的基本要素——站队。这样你才能在职场政治这个舞台剧上，扮演好自己的绿叶角色。
+
+## 为什么我说一定会有职场政治？
+
+也许你也曾经天真如我，觉得自己靠自己的双手干活在公司谁都不亏欠，觉得自己全凭勤劳和真本事吃饭，觉得公司全靠和自己一样的写代码的人来养活。以至于像我这样想了太久，在公司里感觉腰杆子比铝合金电线杆子都硬气了。如果你是这样的人，那么我建议你仔细品品我下面说的这个故事。
+
+### 人少总是小而美
+
+这是一个电商网站的故事。一开始，有一个“草台班子”，只有创始人单干，卖定制化小商品，比如T恤、杯子等等。所有的事情，包括产品研发、产品代工生产、进货、库存、编写电商商城代码、服务器维护、发货、售后、营销等等都是创始人一个人来包办。
+
+老天有眼，商品的路数对了，卖得很不错，订单量越来越大。这时候创始人一个人就忙不过来了。怎么办呢？招人呀。按照工作职责划分，很自然地，创始人又招了三个人，一个人负责生产，一个人负责营销，一个人负责售后。程序员太贵招不起，所以创始人自己继续负责商城的开发和服务器维护等，同时总管新来的三个人。
+
+这时候，其实问题已经来了。因为人多了起来，赚的钱怎么分就是个问题。之前只有创始人一个人，赚多少都是自己的。现在有了三个手下，虽然他们现在还不管人，只是拿工资。但是年底奖金怎么分？加薪怎么给？谁多谁少？这些问题就开始接二连三地蹦出来了。
+
+当然，这时候人还不多，大家也都很辛苦。所以大家对创始人的奖金和加薪方案，也可能没有什么抱怨。毕竟公司发展得好，对大家都有好处，每个人到手的钱，差的那仨核桃俩枣也没多少。或者创始人如果足够有魅力，还可以让大家忘记心里那一丢丢对利益的纠结，继续拧成一股绳，奔向更美好的明天。
+
+故事讲到到这里，你能够明显看出，当公司只有一个人时，所有赚的钱亏的钱都是创始人自己的，这个毫无争议。公司接着发展下去，会从一个人发展到非常扁平的两层结构。
+
+这个两层结构时期人还非常少，虽然已经要开始为各自的付出来分配利益，为各自的失误承担责任。但是由于公司规模不大，每个人为公司做的贡献和每个人的工作失误造成的损失都非常明显。这时候要做到奖惩分明，并不是特别难。
+
+### 人多就会有“江湖”
+
+但是，公司会继续发展。进一步往下发展的话，之前做产品的部分就会变成产品部和库管部，分别各有十几号人。营销部和售后部也都成立了，也都是好几个人的规模。同时，公司也终于有了商城研发组。创始人终于可以专心地管理公司了。
+
+这时候，公司变成了三层结构，公司的人也越来越多，想做到奖惩分明已经非常难了。
+
+比如说，产品是直接面向用户的，所以产品设计做得不好的话，对销量会有直接的影响。营销可以扩大销路，增加销量。但是产品的销量有多少是要归在产品设计上，又有多少要归在营销上呢？
+
+营销需要经费，那么接下来的营销经费，是应该增加还是减少呢？售后不是利润部门，但是会影响回头客。有多少客人是因为售后不好而流失的，又有多少新客是因为优质的售后才获得的增长呢？因为售后原因增加的客户和营销带来的新客户，又应该如何区分？这些问题的出现，让公司很难做到奖惩分明。
+
+更不用说，公司除了奖惩分明之外，还有更高级更复杂的利益。比如大到某个部门的存留，小到某个项目是继续还是取消。举个例子，库管部负责商品进库、发货、清点等工作。这个工作并不是公司的核心竞争力，而且随着公司规模的扩大，可能交由更专业的公司来负责会更好。这时候，这个部门留是不留？这个部门的老大怎么证明自己部门的价值？是更安全、更快速、还是更省钱？
+
+所有这些大大小小的事情背后，都是赤裸裸的利益。没有这些，你可能都没机会干活，没机会赚辛苦钱，也没机会升职加薪。
+
+你想想看，如果不是商城部门的老大能搞定关系，给出各种让人信服的数据，背上各个方面给的KPI，这个部门可能就被取代，下面的程序员可能就散了。如果不是老大能做出正确的决策，展示出让公司满意信服的成果，整个部门的加薪升职可能都要缩水。
+
+而这整个过程，都是政治的运作。
+
+## 一般公司里的那些职场政治
+
+当然，在一般的公司里，对于我们这些最基层的程序员来说，日常能亲身体会到的，并不是上面例子中说的整个部门不要了这种大动作。我来给你说两个个比较常见的例子。
+
+### 为啥要改组？
+
+在成规模的公司里，大大小小的改组（Reorg）可谓屡见不鲜。比如我们熟悉的腾讯和华为，最近几年都有调整自己的事业群（Business Group）。这种公司层面的改组，肯定会一层层地传递给下面的部门。有时候，一个小的部门，也会随着发展而改组。正所谓，分久必合，合久必分。很多时候改组就是分分合合。
+
+下面我来说说我对改组的拙见。随着公司的发展，内部外部环境的变化，公司改组是难免的。公司通过重新划分地盘，打破老的利益格局，重新规定各自的权利和责任。改组搞得对了，可以激发组织的活力，可以让做事情更顺畅自然。
+
+我之前面对重组，只关心两件事，一是我的工作还有吗？二是我换老板了吗？最多再关心一下我老板换老板了没。现在我更愿意去理解这次改组的目的，想要解决的问题是什么。进而我能去理解，这次重组给自己所在的组带走了哪些老的负担，带来了哪些新的责任，又伴随着哪些新的机会。
+
+### 不改组行不行？
+
+我来给你说个柯达公司的故事。柯达公司原本是做相机胶卷的。后来，随着数码相机的普及，柯达公司的胶卷业务已经没有了存在感。但很多人可能不知道，数码相机其实是柯达最先发明的。但是柯达却将这个未来的潮流束之高阁。
+
+这个也不难理解，一个靠胶卷生存的公司，不待见一个可以淘汰胶卷的发明，这也是很自然的。但是如果当时柯达公司能够改组一下，将数码相机的研发制造从胶卷业务中独立出来，柯达公司或许会走上一条完全不一样的道路。
+
+当然，这也是一个久远的例子，现在数码相机也被手机淘汰了。所以说啊同学们，公司不改组行吗？不打破老的利益格局行吗？当然不行。不变就意味着被淘汰呀。
+
+### 用谁的系统？
+
+在公司里，除了改组，用谁的系统这件事儿也会经常出现。公司大了，系统多了，功能难免会有重叠。更不用说还有鹅厂这种鼓励内部竞争的公司。这时候，用谁的系统这个问题，除了功能等因素之外，还有更多非技术的考量。比如从两者所在组织的角度看，这种合作是否互惠互利？合作是否会动了别人的蛋糕，让别人不爽？合作带来的地盘交叉，以后是否能分得清？在对方系统上做的投资，是否会被好好维护？这些考量都是有政治意味的。
+
+## 面对职场政治，程序员应该做什么？
+
+前面说了这么多，其实目的是阐述职场政治的必然性和必要性。当然，我们是程序员，是基层做实际工作的员工。这篇文章不是鼓励你去搞政治。那么了解这些之后，我们程序员应该做什么呢？
+
+### 尊重职场政治
+
+我觉得首先要做的，就是尊重职场政治。职场政治远不止我这里列出来的这些正能量的事情，也有很多算计，可能看上去并不那么让人舒服。但是，从屁股决定脑袋的角度来说，我们还是要尊重自己组织作出的各种决策，尽自己的力量去支持。
+
+你要知道，每一份工作背后的一系列利益逻辑都是各路老大搞定的。你不要动不动就想着，此处不留爷，自有留爷处。你这样想的话，到哪都没有你的工作。
+
+### 懂得组织的利益所在
+
+一个公司，往大了说，大家是一个整体。往小了说，大家是一个个利益小团体。我们作为程序员，要懂得自己所在的组织的利益所在，不要做违背组织利益的事情。当然，这里也并不是鼓励大家去花太多的时间，思考职场政治。毕竟我们是干活的人，不是搞职场政治的人。大部分情况下，你只要配合经理做好自己的工作就好了。
+
+同时呢，我们还要能理解和自己合作的各个组，以及各个部门的利益所在。这样在大家合作的时候，能够泾渭分明。不要打破大家合作的约定和默契。
+
+## 总结
+
+俗话说，有人的地方就有江湖。那么在职场这个江湖里，它背后的逻辑就是利益。支配利益的方式就是靠政治。游戏的主角就是各路老大们，我们做好配角就是了。别替老大们操心，别想太多没用的，别说太多没用的，更别做太多没用的。
+
+大家在一起玩儿，一定要有游戏规则。这个游戏的规则的制定，不需要我们操心。实际上职场政治也远比我这里举的例子复杂难懂，我们也很难参与进去。就好像你在路上开车一样，你不用参与，也无法参与制定各个路口的红绿灯的规则，我们只要学会看红绿灯，按照红灯停绿灯行的规则走就行了。当然，职场上的政治，没有红绿灯那么简单直接。看不懂的时候，别乱动，问经理该怎么做。毕竟全公司最不希望你犯错的人，除了你，就是你的经理。
+
+<img src="https://static001.geekbang.org/resource/image/fe/c0/fe98b8ea3a7a1f74bacf485a4a0f1fc0.png" alt="">
+
+## 思考题
+
+关于职场政治，你有什么故事吗？有没有因为这个迷茫过，又有没有因为这个吃过亏呢？
+
+欢迎在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职场情商篇/19 | 职场政治：面对公司自上而下的技术更新，我该怎么办？.md

@@ -0,0 +1,117 @@
+<audio id="audio" title="19 | 职场政治：面对公司自上而下的技术更新，我该怎么办？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5d/f0/5db5c134d7588d70353bede2158ab3f0.mp3"></audio>
+
+你好，我是臧萌。今天我们接着继续聊聊职场政治。
+
+在上一节中，我们聊了聊职场政治的必然性。在这一节里，咱们接着这事再讲讲我们程序员会遇到的一种特殊职场政治，那就是公司自上而下的技术更新。
+
+这种技术更新，大都是伴随着技术方向的变化，或者发展策略上的变化。这种变化可能是整个公司层面的，也可能是部门或者小组层面的。变革的目的就是为了更上一个台阶，而打破现有的模式和利益关系。
+
+## 电商软件研发部的困境
+
+光说技术变革几个字还是比较抽象，咱们回到上节课里我提到过的那家电商公司。公司里有个软件研发部，它开始的职责是自己研发电商网站。但是随着公司的发展，软件研发部的老大要做一个非常关键的决定了：是继续自己研发电商网站，还是将自己的销售系统和当时已经发展起来的天猫、京东等电商巨头平台对接呢？
+
+### 自研还是对接平台
+
+两种选择，各有利弊。站在部门内部的角度想，如果走自己研发电商网站之路，自己部门可以把控着公司的网站，能够让自己的部门在公司中有举足轻重的地位。但是就电商发展形势而言，电商巨头已经形成，配套的支付、搜索、移动端多平台支持、购物体验等等，都是自己这个小的电商公司无法做到的。尤其是让自己研发的电商网站获取流量，将是个越来越难的事情。
+
+所以说，自研之路，也许能保证自己部门在公司的地位，但是长期来看，无法保证自己的部门能够为公司的发展发挥应有的作用。
+
+这时候，从有利于公司长远发展的角度出发，也从自己生存的角度出发，软件研发部老大决定壮士断腕。研发部保留了自己研发的电商网站中，最基本的企业展示和主页功能。与此同时，研发部在各个电商巨头平台上建立旗舰店，将购物功能都导流到各个电商巨头网站。
+
+### 程序员如何应对变化，重整旗鼓
+
+随之而来，软件研发部本身也要经历一轮大的变化。原来是做自己的一套电商系统，现在变成了做一套对接各个电商平台的内部ERP系统。一开始研发部老大跟兄弟姐妹们画的饼都不见了。从这种变化本身来看，其实这就是动了程序员的“蛋糕”。之前程序员的那些付出，写的那些代码，做的那些系统，都白费了。瞬间自己为公司创造的价值归了“零”，心里肯定是不好接受的。
+
+面对这种变化，程序员应该怎么办呢？如果你从外部来看，当然很容易就能说：“这有什么的，不就是写代码嘛。公司的变化怕啥，继续拿工资写代码呗。”其实这是一种站着说话不腰疼的说法。如果深入到程序员的内心，公司的变化给程序员内心造成的影响，是无法简单用一句继续拿工资写代码就能带过的。
+
+因为程序员是一种既需要经济利益刺激，又需要荣誉感的工作。看着自己做的系统跑起来，服务千千万万的用户，这种感觉是程序员特别重要的一个追求。
+
+但是说了那么多，还是一句话，技术更新是必然的。我们程序员应该做的，就是收拾心情，理解公司或者部门做出这种变化的原因，然后重新燃起自己的斗志。公司做出这种变化的时候，公司层级或者部门层级肯定有大会。但是大会更多的是单向的交流，很多问题也不适合在这种大会上提。
+
+这就是发挥一对一会议作用的时候了。在一对一会议上，我们可以把自己关心的各个点都和经理聊一聊。比如公司的发展方向、自己以后的发展路径如何与公司的发展路径切合、公司是否有资源安排跟大家做这种方向的转换，比如安排培训等等。对未来的方向清楚了，对变化的原因理解了，自然自己心里的疙瘩也就容易解开了。
+
+## 业界那些技术驱动型更新
+
+刚刚的电商例子是业务直接导致的技术更新。有些更新呢，则是更倾向于技术本身的升级换代。从公司的角度来说，公司更倾向于使用统一的、可以支撑公司未来多年发展的技术架构。这样也有利于公司内部形成技术合力。接下来我们来聊聊业界有名的那些技术更新。
+
+### 亚马逊的SOA
+
+亚马逊全面转向SOA，可能是最有名的一次变化了。简单来说，就是亚马逊提供一套SOA框架，公司内部所有的组与组之间的业务交互，都必须通过service调用来进行。强调一下，这是一个全公司层面的变化。没有任何讨价还价的余地，搞得定就搞，搞不定就换人搞。
+
+后面的事情你应该都耳熟能详了，亚马逊成功地从一个单纯的电商公司，变成了稳坐云计算头把交椅的老大。提供的AWS服务据说有几百个。可以说亚马逊公司全面转向SOA转变是它后来成为霸主的一个基础。
+
+### 阿里巴巴公司的去IOE
+
+很多年前，阿里巴巴在国内掀起了声势浩大的去IOE浪潮。IOE代表的分别是IBM小型机、Oracle数据库和EMC的存储设备。去IOE的大背景是IOE这些传统公司所提供的产品，已经跟不上互联网公司的发展了。
+
+一方面，这些产品很贵，而其主打的特性是可靠。另一方面，随着互联网公司的飞速发展，数据急速膨胀，对这些产品的要求正好是反过来的：产品一定要便宜，才能够在可控的成本下，撑得起急速膨胀的数据。互联网公司可以用自己的技术解决可靠性问题。
+
+这就是去IOE的大背景。通过自研底层这些产品，阿里巴巴靠自己的技术实力支撑起了自己的电商帝国。几年前看到的新闻是阿里系除了核心支付，其他部门都已经淘汰了Oracle数据库。而最近两年更是宣布全面替代了Oracle数据库。
+
+### 编程语言的更换
+
+很多公司也会随着规模的发展，选择更适合公司的语言。比如京东从.Net平台转变到了Java平台就是一个比较成功的例子。相信京东是看中了Java的生态全、工具全、Linux运维更成熟等原因，才做出这么大的变化。
+
+当然，也有很多公司从Java语言转变到别的语言。这都是根据公司的发展作出的选择，不涉及语言本身的优劣。
+
+### 云计算
+
+云计算可以算是最近十年最大最成功的一次技术变革。很多公司的基础设施都已经云化。现在看来，需要机器就上云去申请，已经是很自然的动作了。其实倒退个七八年，很多公司都是自己拥有或租用机房，有一个部门专门做运维，管理一堆物理机。
+
+随着人才的流动和技术的发展，以及各种各样云计算平台的出现，让云计算带来的便利得到了越来越多公司的认可。大家纷纷放弃了自建物理机房，转投各大云计算平台之上。公司摆脱了物理机对业务的束缚，并且享受着云平台带来的各种监控、运维、组网、安全、扩容等便利且高附加值的功能。
+
+## 程序员应该如何应对
+
+那么我们在面临公司技术更新的时候，究竟应该怎么办呢？我有三点经验和你分享。
+
+### 1.改变都是取舍的艺术
+
+首先，我们要意识到，没有完美的改变。我们程序员不能抓住新技术的缺陷，就将新东西一棒子打死，说这玩意就是瞎搞。
+
+如果有一种完美的变化，那这种变化大概率会自然而然地发生，不会遇到太大的阻力。而需要自上而下推动的变化，都是会涉及利益再分配的。改变很少会是完美的，新的方案也很少能完胜老的方案。每一种变化的背后，都伴随着新的问题。
+
+比如前面说的电商平台的话题，放弃了自己开发电商网站，那么随之而来的就是用户体验和页面设计会收到电商平台的限制，商品描述等也会受到电商平台的规范的约束。
+
+SOA也并非适合所有的场景。如果仅仅是交换数据，本来就是拷贝一个文件的事情，现在非要走服务调用，结果肯定会带来非常大的额外开销。
+
+IOE更是一条艰辛的道路。尤其是淘汰Oracle这个数据库的标杆产品。相信这条路阿里走得肯定很艰辛。其中Oracle数据库里各种高级的功能特性，要么就不能使用了，要么就需要在新的产品上支持。
+
+编程语言也一样，每种语言都有人在用，每种语言也都有人在骂。
+
+云计算就更是一言难尽了。物理机提供了天然的资源隔离，而云计算里的资源隔离一直被诟病。
+
+从责任上来说，作出决策的是老大们。我们程序员负责的是执行。我们改变不了我们老大已经做完的决定，但我们可以调整我们的心态，不要去抵触新技术，要看到新技术带来的新可能性。
+
+### 2.看清趋势，做好准备
+
+随着技术的发展，很多专业技能会被淘汰，甚至很多工种都会被淘汰。这时候，我们程序员一定要看清趋势，做好准备。下面我举几个例子。
+
+之前很多软件公司都有专门的人工测试。就是让测试人员来模拟用户的操作，走完整个流程，检验是否有问题。现在测试都是靠测试框架，很少有人工测试的岗位了。原来人工测试的岗位算是被行业淘汰了。所以如果你是一个人工测试工程师，那么肯定越早转测试开发越好。
+
+云计算带来的变化就更多了，可以说淘汰了很多公司的底层运维和机房运维职位。很多新公司里压根就没有这些职位，直接就是上云的，申请机器，线上运维这些工作软件工程师就能搞定。
+
+### 3.或进或退，积极应对
+
+当然，并不是说只要是变化，就一定能取得成功。失败的变化也是不胜枚举的。比如最近很火的“中台化”趋势，就是几家欢喜几家愁。还有很多微服务改造，如果不能结合实际情况实施，可能就会导致服务划分的不合理、熔断降级等落实不到位的问题，最终造成延迟增加，依赖复杂，排查错误不便等问题。
+
+虽然决策是老大做出的，但是作为一个程序员，自然对事情也有自己的看法。如果你觉得老大搞的这个事情不靠谱，那么不妨退一步海阔天空，换个组或者换个部门。这也是一种积极应对。
+
+当然，你可以觉得不靠谱，并且继续在现在的组工作。但是这时候就一定要积极地履行自己的责任，尽全力完成自己的工作。没准你做着做着，就觉得这件事情靠谱了。
+
+最危险的是自己觉得不靠谱，行动上也不积极，在老大看来就是尸位素餐，消极应对。这样即使你的判断是正确的，这件事情最后确实是不靠谱，搞不成。但是真的论起责任来，没准你就会因为工作态度有问题，变成背锅侠。
+
+所以说，程序员面对这种事情的时候，越是觉得不靠谱，越是要积极应对，努力工作，让自己的表现找不到瑕疵。要不然，就明哲保身，退到一边。
+
+## 总结
+
+这节课我们讨论了和程序员关系最紧密的职场政治之一，就是从上而下的技术更新。我之所以称之为职场政治，就是因为它除了跟技术有关，很多时候更是跟利益有关。无论是关于成就感这种虚的利益，还是自己的升职加薪、职业发展这种实实在在的利益，都有可能被技术更新打乱。
+
+从我们程序员的角度来说，有时候这种变化可以推着我们朝着更代表发展趋势的方向前进，有些时候不靠谱的变化又有可能让自己白费劲。所以我们还是回到利益这个点来看问题。老大作出决定，背负这个决定的责任。我们作为程序员，也要果断作出自己的决定，是全力以赴，还是明哲保身。
+
+<img src="https://static001.geekbang.org/resource/image/e4/yy/e423a35dea9bffd634267f37yy1fa1yy.jpg" alt="">
+
+## 思考题
+
+技术变革可以说是程序员职业生涯里逃不过的事情。你在工作中都遇到过哪些自上而下推动的技术变革呢？你是如何应对的，结果又是如何呢？
+
+今天的课程就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，同时欢迎你把这节课分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职场情商篇/20 | 沟通技巧：如何跟自己的同事请教问题？.md

@@ -0,0 +1,121 @@
+<audio id="audio" title="20 | 沟通技巧：如何跟自己的同事请教问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/02/44/02c8217fc0216875fe970f9903e95744.mp3"></audio>
+
+你好，我是臧萌。今天我来和你聊聊沟通技巧这件事。
+
+我们在日常的工作中，和同事的互相交流必不可少。一方面，我们要大胆主动地和同事多多沟通交流。另一方面我们也要意识到，沟通也是有技巧的，如果沟通不得要领，会降低沟通的效率、浪费大家的时间、甚至可能会引起别人的反感。所以在这一节里，我想跟你分享一下我关于交流沟通的一些小技巧。
+
+我把沟通分成三类，分别是输出式沟通、请教式沟通、和向上沟通。这三个方向，面向的受众和沟通目的各有不同，具体的技巧各有不同。
+
+## 输出式沟通
+
+首先我们来谈谈输出式沟通。所谓的输出式沟通，就是把自己知识输出给别的同事。这里说的不是分享会这种集中式的输出，而是通过简单随意的沟通来进行的输出。这种沟通方式，非常考验技巧和方式。毕竟弄不好就会让人觉得你是在臭显摆。不信我们来转换到被输出的一方，看下面这样一个场景。
+
+### 好心也可能办坏事
+
+你工作中遇到一个问题，正在埋头研究着怎么解决，看得正起劲儿，想深入研究一下。忽然一个同事跑过来说，这个啊，你这么弄这么弄之后，再这么弄就好了。你不得不恋恋不舍地把注意力转移到这个同事身上，还不得不装作非常感激地回应这同事的“指导”。然后你说：“哦，知道了，我一会儿试试看。”然后想赶紧抽身，继续自己研究。看你没动作，同事还以为你不会，直接说我帮你弄吧，接过你的键盘鼠标刷刷刷帮你改好了。
+
+这时候，你的学习的劲头也没了大半，想着那就不妨跟这位同事多请教请教好了。当你真的就这个问题深入问下去的时候，发现同事也只会点皮毛，深入的内容并不是很懂。
+
+你想想，在这种情况下，你作为被输入知识的一方，是不是感觉有点不爽？你不仅仅是想解决一个问题，而是想借机学得更深入一点。自己学得好好的，结果被人“一顿操作猛如狗”，学习的劲头被搅和没了。站在那个热心助人的同事的角度看，好像也有点冤。自己花了时间帮你搞定了问题，最后还没落到好。
+
+想输出内容，也是要讲究方式方法的。
+
+### 看准时机，点到为止
+
+其实我曾经有一段时间，就是上面例子里说到的那个“有个同事”。自己一瓶子不满半瓶子咣当，就喜欢到处掺合着给人指点问题。这种行为，别人可能嘴上不说，但是心里还是不欢迎的。每个人都有自己的学习习惯和解决问题的方式，除非一个人的事情已经阻碍到你做事情的进度了。默认情况下，各人做各人的事情就好，一个人是不需要别人来主动指点的。更不要说例子中这种轻率地过去指点江山，甚至抢过鼠标键盘就开始操作的行为。
+
+当然，并不是说热心不对。只不过当我们主动提供帮助时，要讲究时机和力度。下面我们再来看这么一个例子。
+
+你抓耳挠腮地在看一个问题，口中情不自禁地念叨着“这破service的破接口，咋就调用不成功”之类的话。在你打算休息一下，喝口水换个心情的时候，遇到了组里的同事。同事说，那个service是挺烂的，我当时搞了半天也没成，最后一看是少传了TOKEN参数，你回去可以试试看。
+
+这样一来，你是不是感觉上要舒服得多？首先，同事并没有打断你工作的过程，而是在你已经暂停工作的时候，通过闲聊的方式分享了自己的经验。其次，同事把解决问题的主动权交给了你，你可以选择自己去试试看，也可以在自己搞不定的时候，选择去向这个同事请教。因为同事既然主动跟你说了这个话，自然表示他是愿意就这个事情提供帮助的。
+
+正所谓，观棋不语真君子。别人正在思考的时候，别东一榔头西一棒子地打断别人。别人空闲下来的时候，可以找机会说出自己的见解，表示自己愿意提供帮助。
+
+就我自己来说，我现在已经很少主动去掺合别人解决问题了。主动掺合也是多听多想，除非是我非常确定自己在这块儿吃得很透彻，否则我很少会去主动说什么。子曾经曰过：人之患，在好为人师。古人的话是有大道理的。
+
+好了，那如果你确实搞不定，需要主动寻求别人的帮助，那么应该怎么操作呢？我们来接着看。
+
+## 请教式沟通
+
+向同事请教各种问题，可以说是非常常见的一种沟通了。你会问问题吗？
+
+### 摆正态度：没人有责任帮你
+
+首先，大家是同事关系，不是师徒关系或者师生关系。所以从责任上来讲，我们周围的同事，是没有责任帮助我们，回答我们的问题的。
+
+当然，日常同事们会互帮互助。但是上面的道理是不变的。我们不能把别人的帮忙想成理所当然。不能认为这个事情我不会，那么你会你就应该教我，教到我会为止。这里是公司，不是学校。虽然大家一般都会友善地回答同事提出的问题，但是如果问的问题不对，不但很难得到想要的答案，还可能会慢慢地成为同事们拒绝帮助的对象。
+
+那接下来我们就来看看问问题的正确姿势。
+
+### 问问题的正确姿势
+
+既然同事之间都是纯友情帮忙，那么我们就尽量少去麻烦别的同事。在向同事寻求帮助之前，先做好准备工作。比如说，先去看一下组内相关的文档，先去看一下源代码，尝试自己找到问题的答案。如果是一些开源软件的用法，那么就自己去开源网站上看相关的文档，自己学起来。如果在这个过程中，遇到了非常具体的问题，那么就可以考虑拿这些具体的问题去问相关的同事了。
+
+最不受欢迎的问题就是：XXX怎么搞。记住，工作是自己的，问题也是自己的，一个XXX怎么搞的问题，基本就是把自己的工作扔给别人去做了。问别人问题，要尽量具体，而不是非常笼统地问一个问题。
+
+当然，很多时候，如果懂的同事帮忙指点一下，可能几分钟就能搞定了。自己看，可能要几个小时甚至一天。但是这个过程是很难避免的。以一个当前的工作为契机，自己慢慢熟悉起工作中涉及的各个模块，最后收获的是以后可以自己解决问题的能力。如果靠同事指点，解决问题是快，但是收获也小的多。
+
+所以说，问问题的本质，不是让别人帮你解决问题，而是**要学会自己解决问题**。如果问题解决了，自己还是一脸茫然，下次遇到类似或者相关的问题，还是不会，那么你就不是在问问题，你是在让别人帮你来做你自己的工作。
+
+在完成工作的这条路上，路要自己走，在路口不知道怎么走的时候，可以问别人。但是一般情况下，不能让别人领着你一路走到终点。举个简单的例子，你分到的工作任务是用HBase做一个缓存，那么下面三个问题，就非常不适合问同事：
+
+1. HBase是什么；
+1. HBase怎么用；
+1. HBase的客户端有那么多API，我应该用哪个。
+
+因为这三个问题，你靠搜索公开资料就可以自己搞定，完全不需要问别人。但是下面这三个问题，就可以问问周围的同事：
+
+1. 我们公司的HBase集群配置在哪里可以找到；
+1. 我研究了一下HBase，感觉HBase做缓存可能会有些问题，比如内存命中失败的时候，加载数据可能会很慢；
+1. HBase的可用性能满足我们对缓存的要求吗？
+
+在这三个问题里，第一个问题属于常识性的问题。这个问有经验的同事没问题，他们可能会直接给你一个文档链接，然后剩下的事情你自己就可以搞定了。
+
+而下面的两个问题，都是比较有建设性的问题。其实这已经部分脱离了单纯的请教式沟通，而是更多地向探索式的双向沟通发展。从我个人的角度来看，我是比较欢迎这种问题的。因为和大家一起讨论这种问题，大家都能够得到能力和认知的提升。
+
+### 写在后面的三个小技巧
+
+首先要重点说一下的是，千万不要相同的问题问了一遍又一遍。这不叫问问题，这叫把别人当工具人使唤。如果问别人问题，别人也愿意回答，那就一次性问清楚问明白，然后自己好好总结，牢牢记住。一遍遍地问相同或相似的问题，是对别人的不尊重。
+
+然后是积极总结归纳。如果你向别人请教问题，收获了很多，那么不妨总结出一个文档发出来。这样一方面，归纳的过程能加深巩固你自己收获的知识，另一方面你整理出的文档可以帮助更多的人解决问题。这样做也能表达对帮你一把的同事的尊重。
+
+最后一点就是，如果你确实是个超级大萌新，什么都不懂，每天不得不到处请教同事各种问题，那么不妨和经理反映一下自己的实际情况，让经理指派人来帮你完成工作热身。毕竟大家都很忙，对于每天都要完成自己的工作的同事们，很难说能够挤出足够的时间来帮助你。
+
+## 向上沟通
+
+向上沟通，就是指和经理沟通。向上沟通有三个主要目的，分别是汇报工作、申请资源、请求帮忙做决策。总的来说，这三种目的的沟通，都需要提前准备好足够的信息，而且跟经理沟通，要仔细负责，不能信口胡来。下面我来展开说一下。
+
+汇报工作时，先交代两个重点：成果和问题。工作成果是指那些已经落实了的成果，没落实的、没实际验证的不要想当然地乱说。问题是指现在遇到的感觉需要经理帮忙协调的，以及需要经理调动资源解决的事情。至于自己就能解决的问题，不需要说太多。
+
+比如说之前提到的用HBase做缓存的工作。如果要就这个工作向经理汇报，那么下面几个内容是要给出来的：测试环境是否可用、生产环境是否可用、外部依赖是否解决。我们自己是否提供了jar client、还是通过 service API访问、或者说都支持。要是支持的话，性能指标数据又分别是什么。至于细节的技术问题，没必要说，经理不是帮你解决技术问题的。
+
+然后是申请资源。这时候，要整理清楚前因后果，你要想明白申请了资源能做到哪些事情、申请不到又会影响哪些事情、为什么资源不是要得更多或者更少。简言之，就是要证明这个资源用得值。
+
+还是拿HBase做缓存的例子。在测试环境下，你可以整理出数据量、缓存命中率、HBase内存、性能指标的统计数据。然后根据这些数据，以及整体对性能指标的要求，提出生产环境需要的机器资源和配置。
+
+最后是请求帮忙做决策。自己不能做决定的事情，就需要经理帮忙了。这种情况很多，比如遇到了新的情况，或者遇到需要对外部作出承诺的事情等等，所有自己吃不准的，不知道如何处理的，都可以找经理帮忙做决策。
+
+当然，我们找经理做决策，不是去把包袱扔给经理，而是和经理一块协调解决问题。所以在找经理之前，我们也要整理好足够多的信息才行。
+
+比如用HBase做缓存的例子，就像我们前面提到过的，如果在实测的时候，发现HBase不是很适合做缓存，比如因为缓存不命中，会导致P99在1秒以上，比如HBase在生产上有2%的时间会有3%的数据不可用。收集好这些数据，可以让经理做决策，我们是否继续用HBase做缓存，还是另外寻找其它解决方案。当然，如果你已经有别的缓存解决方案的数据，也要一并提供给经理。
+
+总结一下，和经理沟通，不是让经理帮你干活。要带着足够的信息来，不要只带着问题来。
+
+## 总结
+
+好了，讲到这里，这节课也就接近尾声了。这一节中，我们聊了聊沟通的技巧。虽然我们是按照三种不同的角度来说的，但是你发现没有，其实底层的逻辑就是一个词：尊重。
+
+输出式沟通时，对别人要有尊重，不“好为人师”。做到真的是在帮助别人，而不是显摆自己。
+
+请教式沟通时，要自己做出足够多的努力，而不是把手一甩，就直接让别人帮自己干活。同时，也要尊重别人为了帮你而付出的时间，不要拿别人的时间精力不当回事儿。最好是能提出有建设性的问题，这样双方都可以有进步。长期来看，这种请教式的沟通才是一个良性问问题的方式。
+
+和上级沟通时，要准备好足够的数据，说的事情要有理有据，对自己的话负责，不要说一些模棱两可和想当然的东西。这是对上级的尊重。
+
+<img src="https://static001.geekbang.org/resource/image/2e/d5/2e61eb1ce1a3b601590c85f6b978aed5.jpg" alt="">
+
+## 思考题
+
+沟通是必要的，沟通的技巧也是要掌握的。你在工作中，都遇到过哪些让你感觉很膈应的沟通？又遇到过那些让你如沐春风的沟通？
+
+今天的课程就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，同时欢迎你把这节课分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职场情商篇/21 | 答疑篇：想升职，我该准备些什么？.md

@@ -0,0 +1,88 @@
+<audio id="audio" title="21 | 答疑篇：想升职，我该准备些什么？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1e/ab/1edbe865526d2ddfe8086987ff532fab.mp3"></audio>
+
+你好，我是臧萌。转眼之间，咱们第三个模块也结束了。这个模块不大，我们讲了升职、职场政治、和同事沟通这三个点。别看第三个模块不大，但对于满眼都是技术的程序员来说，尤其容易忽视这些问题，导致踩坑。所以我们更要去注意人与人之间的关系，培养好自己的职场情商，做好自己的绿叶角色。下面我就针对这个模块的热点问题做个详细解答。
+
+## “会表现”就容易升职吗？
+
+首先是升职，有同学说，要想升职，还是要会表现。如果是只会默默干活的人，升职机会就少。
+
+很多时候事实就是这样的。
+
+与其默默干活，看别人升职加薪，不如我来给你分享两个容易上手的表现技巧。
+
+会表现，一方面就是多说、多露面、多交流。就好像之前说过的那样，交流沟通可以让人与人之间，组织与组织之间的合作更顺畅，及时消除彼此之间对事情理解的不同。多露面多交流，既能够在经理面前混个脸熟，还能在不怎么交流的大群体里，显得你是个稀缺交流人才，那么你升职更快也就是合理的。
+
+另一方面，会表现还包含和经理沟通顺畅，想经理所想，急经理所急，尽自己最大的努力来帮助经理。这种情况下，经理自然也会更照顾这个人，优先给这个人升职。
+
+那我们反过来再想想，经理安排一件事情给手下，接下来为什么这么做、这么做好不好、怎么做才能更好，这些都是经理希望自己的手下来多花心思来思考的。如果一个人只是自顾自地干活，在经理看来，那也只是手下生硬地干好了交代的活儿而已，没有融入到这个团队，这个公司。对比“会表现”的同事，自然是差了一节。
+
+从利益的角度来说，会表现的人是经理想留下的，因为这种人才的替换成本更高。而只会让干啥就干啥的人，他们可能得不到升职后会选择离职，但这种人随时可以通过招聘找到，从管理者的角度来看，替换成本没那么高。
+
+咱们这个专栏怎么说的来着？“会工作也是个技术活儿”。
+
+## 想升职，该准备些什么？
+
+还有同学提供了很多有助于自己升职的小技巧，比如来自 **@🛠️🛠️🛠️人和尚** 的分享。
+
+- 在公司多做分享，不管有没有人听。
+- 多画图。
+- 体系化思考，总结的能力，形成自己的方法论。
+- 要有自己落地的action，有case支撑。
+
+我解读一下他的话，就是要养成分享的习惯，锻炼自己做分享的能力。没有人听不重要，自己的能力得到锻炼了，随着自己的成长和做的事情越来越有料，以后不会缺少听众的。
+
+而且关于这一点，还有一个很重要的隐含因素，就是要增加自己的曝光率，让更多的人知道自己的名字，知道自己干了什么。如果想给一个人升职，结果大家看到这个人的名字，都感觉很陌生，完全没有任何印象，那么作为升职评审的人，很可能会保守地倾向于否定。但是如果对这个人有印象，知道他分享过什么知识，参与过什么项目，那么名字背后的内容就丰富形象很多，给他通过或者不通过，也会更有据可循。
+
+多画图，也是一个锻炼自己表达能力的方式。正所谓，一图胜千言，能把事情用图展示清楚，让人能马上明白这个事情的要点，是一个非常高级的能力。
+
+第三点，在我看来，就是要能吃透自己的系统，建立自己对系统的认识。
+
+第四点就是要有料，对于自己做出的成绩，要总结归纳得光鲜亮丽，让别人一目了然，无法否定。
+
+还有来自**@ecanfly** 的分享。
+
+提前收集数据，做出成果前后有对比。晋升材料尽早准备，多演练多演练多演练。关键还是日常积累，体系化思考，体系化呈现结果。
+
+简单来说，就是要能突出自己的成绩，要好好准备自己的晋升。这点也很重要，程序员不要抹不开面子。事情做都做了，好好拿出来说说，展示一下自己的成绩，没什么不可以的。升职是自己的事情，自己肯定要多操心。其实有时候，经理真的不一定能记住你一年到头做了哪些事情，所以，务必记得自己做出的成绩，而且要想办法如实突出自己的成绩。
+
+## 技术业务两手抓
+
+关于技术升级，有些同学表示一般都没问题。 更多的应该关注于业务线的升级。
+
+是的，我在文中将业务线的升级，和技术本身的升级换代，都简称为技术升级了。比如电商决定放弃自研电商网站，转向对接电商平台，其实就是一次业务升级。比如携程之前的模式被称作鼠标+水泥，也就是PC端+呼叫中心。后来为了迎接移动互联网的挑战，推出了大拇指+水泥战略，也就是要靠手机App+呼叫中心。公司类似的这种变化，对所有技术人员都是一次机遇和挑战。
+
+再补充一点，新技术一般都更好更先进。但是好的并不代表就是适合的，还是要结合自己的业务、组织架构、实际技术能力等现实情况来具体分析。就好比你手里一天的生活费有100块钱，如果附近有个高级购物中心开业了，基本跟自己没啥关系；如果自己不能吃辣，就算附近开了个好吃的川菜馆，也跟自己没啥关系。如果你硬要上，就要有问题了。
+
+## 你真的会沟通吗？
+
+沟通技巧，我没有将它放在第一篇中，而是放在了职场情商篇中。原因是沟通是工作要求的基本素质，而沟通的技巧，则更关乎情商。
+
+俗话说，三岁学说话，一生学闭嘴。话不是说越多就越好，如果技巧有大问题，那么沟通的结果可能是负面的。当然，大家都是社会人，不会有人愣头青一样地直接跟你说：你别来找我了，你说的这些都是废话，对事情毫无帮助。（不会吧不会吧不会吧，不会真的有人这么说吧。）这么说是过分了一点，但是对方心里的意思可能就是这个意思。
+
+这里呢，我给一个指标供你参考。这个指标就是你找人沟通，和别人找你沟通的次数比例。如果每次都是你主动找别人沟通，但是别人极少主动过来找你沟通，那可能就说明，别人和你沟通下来，感觉收获不大。
+
+如果每次和你沟通完，都有“与君一席话，胜读十本书”的收获感，别人肯定逮住机会就找你聊聊。当然，这个指标也是受到各种因素影响的，比如因为彼此的职责和级别不同等。但是站在基层一线程序员的角度，这个指标还是有参考意义的。
+
+当然，不是说没人过来找咱，咱就放弃了，而是应该主动解决自己的短板。你可以从认真对待和总结与别人的每次沟通开始。记住沟通的核心：尊重。和你沟通，是否有收获？如果没有收获，自己应该如何改进？只要思想不滑坡，办法总比问题多。
+
+## 毕业生需要什么样的帮助？
+
+有同学问，有些刚毕业的同事，希望得到全方位立体式帮助。对于这些同事，工作中应该如何带呢。
+
+这里，我的建议是，对于刚毕业的同事，还是要多宽容一点。毕竟大家都是从开始什么都不会这样一路过来的。提示他们可以自己尝试着解决。遇到真的问题再大家一起讨论。
+
+很多刚毕业的同事并不是能力不行，导致一个事情搞不定，而是他们自信心不足，怕自己搞会弄出问题。这时候他们需要的不是一个帮他们的人，而是一个给他们信心的人，让他们可以放心大胆去自己搞。你需要做的是告诉他们：“有问题不怕，遇到问题来找我”。
+
+## 总结
+
+和机器打交道，靠技术。和人打交道，靠情商。咱们程序员，如果不想被贴上低情商的标签，首先得重视情商，要能清楚的意识到情商在工作中的重要作用。
+
+打开IDE，程序员就是一个没得感情的代码生成器。但放下键盘鼠标，我们程序员作为芸芸社畜里的一员，也要频繁的和人打交道。人和人的关系，就要靠情商来支撑了。
+
+情商不是阿谀奉承、放彩虹屁，不是阴险狡诈、两面三刀。对于程序员来说，情商可以充当人与人之间关系的debugger。与人交流的时候，可以设置一个断点，好好想想该怎么说话。人与人之间相处时的那些事儿，也可以用调试程序的态度来复盘。在尊重彼此的利益的前提下，我们要用好这个debugger，把人与人之间相处时的那些事儿整明白。
+
+培养自己的情商，可以让自己与同事和上下级更好的相处，更高效的工作，更好的收获自己的利益。
+
+以上就是答疑篇的内容，不知道有没有解决你的困惑呢？
+
+欢迎你在评论区与我交流一下你的想法，也欢迎把这篇文章分享给你的朋友或者你的同事，一起来交流一下。