技术管理课

开篇：

不论是在技术上，还是管理上，我要走的路还很长很长。但是，很多时候，当你充满激情，快步前进的时候，反而有更多新鲜的领悟可以分享，更切身的体会可以鼓舞同行的人。这两三年可能是我积累和成长最快的一个阶段，我获得了很多前辈，同事和朋友的帮助，让我慢慢走上分享和写作的道路，分享与写作让我认识了很多人，也让很多人认识了我。
很感谢我的导师，一点点指引我走上了带项目，带团队的道路，很多谆谆教导，极大地加速了我这两三年来职场上的进步和成熟，工程师 总是平淡和专注来形容，大部分时间，我都在不断地积累和练习，我独立学习，做科研，或者长时间的编写代码，对编程的热爱是发自内心的，写程序可以让我自然而然地沉迷其中，我可以一整天坐在电脑前噼里啪啦的敲击编写代码，饿了随便吃一点，有时候会忘记喝水，也不会觉得困，等到从代码逻辑中抬起头来，发现一天的时间已经不知不觉的溜走了，编程非常容易让我进入“出神”的状态。机器完全是逻辑控制的，没什么情绪，无论运行良好，还是宕机挂掉，都会有原因，肯定不是因为它开心or不开心，我喜欢用代码与计算机沟通，但人总是要成长，总要走出舒适区，我希望后续我可以多多好运，在老板和同事们的培养和提拔下，一步步从技术转成为技术管理者。

那些技术和管理上的领悟以及忠告，还有工作体会和见识，学习和感悟，很好的道理，那些我的上级和我自己的思考，见闻和实践，这些东西我还不能非常熟练地应用，我也还在练习

1 技术领导方面的学习和感悟
2 技术领域内容，技术在领域内的应用和前景
3 互联网 与 文化
4 技术人成长，遇到的困难和克服困难的心路历程，职业规划，如何建立个人影响力

很喜欢和工程师门一起工作，阅读，学习和交流。常常会折服于工程师们的睿智，呆萌，执着，单纯和幽默。他们说着别人听不懂的笑话，做着这个时代最具创新性的工作，他们充满好奇心和创造力，并希望用技术改变生活

与我处在同一条成长道路上的人很多，大家会看到相同的景色，也会遇到相同的困难，会把自己的思考，经验和解决过得困难第一时间分享给你。相互陪伴，并一起成长。

聊聊： 从给答案到做引导

不能每次都给出答案，应该试着用引导的方式，让对方学会自己找答案，比如：如果是我，我会尝试全看看某某文档，这样的建议，或者，我觉得这个线上错误可能是哪些地方引起的呢？你有没有尝试用排除法，先把哪些不可能的因素排除掉？

什么问题适合直接给答案，什么时候适合给线索，让对方自己找答案
答案就是某些知识点，就直接给答案，这些问题他全然没有线索，我们也不可能让他自己去推导出业界多年发展才形成的规律和规则

当对方有一定的积累和经验后，就可以让他自己去探求解决方案了，给他方向和建议，让对方继续寻找，这样更有意义

如何引导
问对方问题，通过问题去引导对方进入深入思考，找到解决方案，好的问题会让人们主动思考，让他们跳出自己之前设定的方案和框架，换一个角度去看待问题

好处
对方会有积极性，和成就感，同时他自己解决问题的能力后续也会得到提升

引发事故，该不该追责

正确的做法
追究责任，但不是惩罚

对事情不对人

反复问“为什么”，从根本上发现问题

员工关系的建立也很关键

聊聊：A/B 测试

1 永远不要过分相信你的直觉
2 实验样本的数量和分配很重要
3 分析的维度尽可能全面（比如高转化率会导致出错率也提高）
4 考虑实验之间的相关性
5 比较值的趋势必须是收敛的，而不是发散的
6 数据埋点（这个是A/B 测试成功的关键）
7 形成一个流程，或者设计一个工具，才会事半功倍
8 试图给每一个结果一个合理的解释
9 必要时候重新设计实验
10 不同客户端分开进行实验

如何快速帮助团队成员成长

一个优秀的技术管理者应该做那些工作呢？
1 帮助团队成员迅速成长
指导，反馈，监督，交流，协调资源等方式帮助下属提升能力，快速成长。
2 明确地分解与布置任务
不仅包括分解和布置任务，还包括需求边界，制定计划，选拔人员和工作授权，其中需求边界，又要求与上级和下属细致沟通，确定下属需要做什么和怎么做
3 建立有效的合作关系
有效指的是与下属，上级和相关部门建立坦诚交流和相互信任的合作关系

错误的领导方式：陷入静态思维

提升一个人到下一个级别时候，通常采用这样的做法：
他们对每个界别都在各个方面设定了一些标准；比如，你在技术上要达到什么水平，执行能力如何，做出的项目是不是有足够的影响力，是不是能够独立的去解决各种困难，有没有对别人做出贡献等等

你是不是已经在过去的半年到一年里，按照下一个级别的标准在工作，你已经达到下一个级别的标准，并在这个水准上稳定的保持了一段时间，才会被提升。

作为管理者，你应该做哪些思考呢？

一个技术管理者的成功并不在于自己代码多好，能力多强，他的成功一定建立在团队的基础之上，只有团队成员不断成长，这个团队才可以做更大的事情，而你在可以在团队的基础上，站的更高，看的更远。

当我们给别人提意见时候，要注意些什么

1 要思考自己是不是合适提这个意见
也就是说，对方会不会产生 “就凭你” 的逆反心理

所以在工作中尽量放低姿态，往往更容易获得尊重，不要总是试图居高临下地提意见，尤其是你在对方还没有建立任何威信的时候，不要贸然给别人提负面意见。

2 提意见要讲究时机
初次犯错误，没必要上纲上线，可以等一等，看他会不会自己改过来，或者稍微提醒一下，让对方注意到这件事情，或者委婉地引导对方去关注和思考。如果你发现某个问题已经出现多次，可能就是直接点出来的时候了

这种讨论不是为了说服or被说服本身，不是为了争高下，讨论是为了增进对讨论主体的认识，引发思考，寻找可能存在的问题的最优解。提意见其实是门聊天的艺术，如何理解，各人高根据具体情况以及和对方的关系来调整。
最后，多夸夸对方做的好的地方，多给予正向反馈

很多时候，正向反馈能更好的帮助对方成长，表扬的力量永远大于批评，他会试图把事情做得更好。正向的沟通还能帮助你与对党构建良好的沟通渠道，让你们未来的合作更加顺畅和有效

每个工程师都应该了解的：聊聊幂等

Idemopotency：
简单来说，一个操作如果多次任意执行所产生的影响，均与一次执行影响相同，我们就成其为幂等。

幂等该如何实现呢？
简言之，你需要一个去重机制。这往往有很多不同的实现方法，但是有两个很关键的因素：
第一个因素是幂等令牌（idempotency key）.

第二个因素是确保唯一性（uniqueness Guarantee）服务器用什么机制去确保同一个请求一定不会被处理两次

一个系统能正确处理和实现上面的两个基本要素，基本就能达到幂等的需求。
那么现实系统中常见的问题都出在哪里呢？

当别人给我们提意见时候，该如何应对

很多时候，情感上的抵触使我们要克服的第一步。知道自己可能的情绪化反应，尽可能在下次听到意见的时候，下意识地要求自己去做一些改变。从某种程度上讲，这就是一种内省机制

我们都不要试图从恶意的一面去揣测对方的动机，而是先假设对方是善意的，并且对主动提意见的人表示感谢
并不意味这我们需要对外界所有的反馈兼容冰雹，而是在假定对方是好意的前提下，我们可以进一步对意见进行归类和筛选。

如果是陈旧性意见，先诚恳接受，在实际处理中忽略就是

如果是崭新意见，这一类意见包含了从来没有听到过的新意见，去想一下，是因为提意见的人观点过于片面，还是时过境迁问题早已不存在，或者是自己做的真的不够

即便你有充足的理由认为对方说的不是实际情况，但如果不止有一个提过意见，或者你比较看重提意见的人，这个人可能是你的上级，或者一个德高望重，谨慎靠谱的队友，那你就要思考了，虽然这件事觉得自己没有做错或没有不合适的地方，为什么会给别人留下“我做的不够好”的感觉呢，然后继续去思考，做什么样的改进可以让事情变得更好，可以改变别人的感知。

总结如下：

聊聊 一对一沟通

谈话内容都有哪些呢？
没有定式，一般会谈到最近的项目进展，没有什么阻力，最近的生活和家庭状况如何，有没有出游计划
一个话题的纯粹讨论，这个话题应该是团队成员感兴趣的，这一点非常重要。因为一对一沟通通常以下级为核心，由他来掌控说话的内容和气氛，话题应该是是他想和你沟通的内容。

相对正式的内容都一般都与工作相关，包括项目进展，工作中的挑战，技术，业务，人事关系，大家甚至可以针对一个技术细节进行缓解，甚至直接解决。

如何让沟通更有效？
管理者应该学会聆听，通常说来，成为管理者，大家会更加注重你的表达能力。
作为领导，你需要时时传达各种信息，比如公司决策，企业文化，项目信息，协作信息，产品信息等，你需要通过自己的表达让去哪组人员对某个决定or某个项目建立一致的认识，然后才能形成合力，让正确的事情持续发生。正因为如此，管理者的主动聆听能力往往会被别人甚至自己忽略

领导者在很多时候在综合层面–比如经验，知识，信息，能力等–都属于佼佼者，大家往往或多或少都有种“自己什么都知道”的心态，至少是什么都知道一点，所以对别人，尤其是自己团队成员的一些意见–不够有耐心。

所以 在领导与员工的交流中，经常会产生一个方向上的信息流大于另一个方向上的信息流这种情况。

还有一点需要注意，就是：对方想从这个谈话中获取什么，是单纯希望上级知道，还是想要我给出意见；为什么这件事和我无关，但是对方会主动跟我说。如果对方期待我的反馈，而我当时有没有好的想法，我可能会坦诚相告，然后和他承诺，后续我有了更多信息时会跟进这个问题。

如果下属提出了很好的工作建议和创意想法，应该马上动笔记下来。一方面这些内容可能真的非常宝贵，另一方面，记下来这个动作其实是一种承诺，就像双方打成了一种契约，让后续可以进行跟踪和持续推进，甚至可以在下一次沟通总继续讨论这个问题。

沟通的杠杆
一对一沟通会花掉很多时间，但是在沟通中可能会提升他接下来一周甚至两周的工作品质。同时，通过信息的分享，你也可以学习和了解到更多东西。长远来看，这些贡献是远远超过自己的那五个小时的。

对于一个技术领导者，团队的成功，才是真正的成功。

做好一个技术领导，最重要的是你真的在乎团队里每一个成员。只有真的在乎，才回去聆听；而一对一沟通，就是你和这个团队连接中最重要的环节之一。

每个工程师都应该了解的：大数据时代的算法

首先，算法是面试的敲门砖
其次，编程时用到的更多是算法思想，而不是写具体算法

好处在于：如果工作需要读一段代码包含一些基本算法思想，你会比不懂算法的人理解代码含义更快。读到一段烂代码，你知道为什么烂，烂在哪里，怎么去优化。

最后，不精通算法的工程师永远不是好工程师

项目延期了，作为负责人该怎么办？

为什么项目这么容易延期呢？
这是因为人们在历史长河中积累的经验失效了

项目一旦延期了，该怎么办呢？
如果是计划本身的问题，或者是因为项目成员没有很好地跟进同一个计划并保持一致，那我们应该尽最大可能避免这些问题的发生,在第一时间做出好的应对措施，做好计划，把计划分享给每一个对项目进度有影响的人，就是项目干系人。

一旦项目延期了，应该有哪些具体措施呢
1 建立一定流程，及时同步进度和问题

2 有优先级

3 制作一个共享的项目状态表，让团队成员一眼就看清楚项目进展，并保持该图标的更新。

4 不要漏掉任何一个人

5 提供一个有效的反馈渠道。让你知道他的担心

做到这些，每个人都会有参与感和使命感，一旦出现项目延期的情况，我们就能非常清晰地知道哪个环节出了问题，能循序地意识并了解这个延迟对整个项目产生的影响和后果，并在第一时间整理需求，计划，人员，重新让项目回到正确的轨道上。

如果做到这些，项目还是延期了，我们需要尽早和上级沟通，让他们了解为什么延迟，自己做了哪些努力，还需要哪些资源或者作出什么样的调整才能赶上期限，是不是一定会延期等等

管理和被管理：期望值差异

期望差异值很多时候都是一种很自然的存在。原因很简单，因为每个人都会或多或少的高估自己
我们在制定计划和展望未来的时候，会强调技能的因果作用，却忽视了运气，环境，协作和他人对自己的响应。
职场中当然也是这样，每个人或多或少都会对自己的某个方面自视过高。这个自我评价和来自他人的评价不符，并且从来没有沟通和校对过，那么在某个特定时候，这种问题就有可能发生，从而伤害彼此的关系。

如何校对管理者和被管理者之间的期望值呢？
最重要的一点是增加彼此的了解：

每半年或者一年进行一次关于期望值的深度对话：

最后有了这样的约定，还需要持续跟进

有能力有空间公司也往上走，自然能留住。光有期望没有能力的，没有必要留，有能力又有期望又有干劲，但公司没空间了，那是公司的问题，怨不得员工。

每个工程师都应该了解的数据库知识

常见问题：
1 选型：根据场景进行，通过不同的技术和架构给予相关的业务场景最优支持。
2 数据库相关架构：代理层，日志文件，管道，分区，备份，连接池，吞吐量，扩展
3 人为错误：很多
4 数据库访问瓶颈

研发过程中，有哪些数据库相关问题呢？
1 索引
2 事务支持
3数据库锁
4 缓存和主从机制

管理者在进行工作分配时候，会考虑哪些问题？

1 建立参考基线

2 问对问题比正确答案更重要

3 工期估算

4 执行力

5 后期维护

还要注意的一些细节问题：

如何看待加班

主动延长工作时间，努力完成更多工作，会不会有助于升级加薪？
会有一定程度的帮助，但并没有直接联系。

系统拆分

为什么需要进行业务拆分？

业务拆分时的注意事项？
1 测试会变得异常复杂
2 与接口相关的改动需要大量协调
3 报错的处理
4 日志的完整性
5 超时设置
6 代码自由（每个服务的实现都可以自主选择自己的语言，自己的存储方式，自己的代码风格）

如何判断系统是不是到了进行拆分和服务化的临界点？
1 业务量级是否足够大，逻辑是否足够复杂以至于必须进行系统拆分。水平扩展是不是已经不起作用了，代码相互影响，部署时间过长是系统的切肤之痛嘛？ 如果是，那就要进行系统拆分了
2 开发人员的经验，能驾驭以上提到的问题嘛，会成为拦路虎嘛
3 系统拆分是一个从一到多容易，从多倒一困难的过程，这个过程几乎是不可逆的，一旦你三分天下，想在同一江山就没那么容易了。

如何建立个人影响力

建立个人影响力并不是凸显你自己有多重要，或者让别人更加认可你，而是通过影响力把事情做成。
在一个技术团队里，影响力很多时候与你的贡献紧密相关。如果你的存在能够让别人的工作更好的推进，让别人更容易取得成就，久而久之，伙伴们就会很自然地认可你，信服你，有问题的时候，也会想要咨询你的意见。帮助别人成功，帮助别人成就梦想，你就会具备积极正向的影响力。

管理者不用亲力亲为：关键是什么

避免误区
1 事情能不能做好和完全按照你自己的方式做好，是两码事情，别人有别人的工作方式，也能把事情做好
2 介入与不介入并不是非黑即白，用什么方式介入，在那些地方介入，才是关键

避免这些误区之后，就会把关注点放在如何帮助别人把事情做好上面，比如，接受任务的人需要那些支持和帮助才能更好的完成任务，我们应该在什么样的时间点去提供这样的帮助。

注意什么
1 让对方明确目标，知道最终想要达到什么样的结果，对这个任务完成的期望值是怎么样的，比如：在什么时间内完成什么样的任务，你对这个任务成功的定义是什么样子，如果有取舍，那些取舍是重要的，哪些是次要的，哪些是可以妥协的。
如果这些标准没有说清楚，很可能会出现认知偏差，比如对方觉得做得很好，但是你认为有些重要的东西并没有被照顾到。

这里面有个前期是：对方同意并承诺完成这个目标。

2 指定一个计划，并保持跟进，而不是知道，不是让你去频繁介入别人的任务，而是在对方对某个环节有疑问的时候，能有随时提供帮助，这种帮助可以是解决方案，也可能是技术方向。给出技术建议或者线索

3 给出反馈，尤其是正面的反馈。

每个工程师都应该了解的：API的设计和实现

1 自由总是相对的，很多大公司会指定一些AQI的最佳实践，强制要求设计和实现中必须按照某种某事来做。从规范代码和一致性的角度而言，还是有很大好处的

2 API 设计的经典原则，概括一下就是：要考虑未来的场景，在设计时候留有余地，但永远只实现当前产品真正要用的功能

3 其他一些不重要的原则， 以后补充吧

项目管理中的三个技巧

1 要对多个项目进行细分重组
1 先评估能力，在分配任务，每个人的能力和任务难度匹配
2 每个人任务完成所需时间要尽量平衡，也就达到了一种负载平衡
3 每个人得到的任务里，挑战有意思的工作和脏活累活比例要大致相等
4 每个人任务里有足够的挑战，能搞帮助其成长，又不至于太难而让其望而身为并产生挫败感
5 不同人的任务如果有依赖性，在分配任务时候要安排合理的顺序，确保不回有人被别人阻塞
6 每个人的任务里都应该有一个主题，就好像故事有一条主线。每个成员会觉得自己参与了一个比较完整的任务，进而产生成就感，而不是感觉做了一堆杂活

2 细分重组，两个阶段
1 要做的事情，细分为一个个小任务，时间大致差不多
2 将任务快，按照上述因素，分装到几个虚构的箱子里，分配给团队成员。每个箱子有一个主题，记住每个箱子的内容，重量等各个方面都比较均衡
3 做到管理者，心中有数，让每个人不至于太闲，也更加有成就感和责任感

3 工期估算
1 注意工程师高估自己的能力和复杂逻辑处理能力，以及单元测试，功能测试，上线时间
2 中途遇到bug 和 难以解决问题

4 实时跟踪，并做好PlanB计划

不要做微观的管理者

1 因人而异
我们共事的人，大部分都是优秀的人，他们和你一样进入这个公司，每个人都经历了差不多的考察和审核，每个人的能力都是毋庸置疑的，每个人都有自己的优点和缺点，擅长的领域，往往各不相同

全局规划，协调资源，注重细节，善于思考，擅长交流，专注执行， 我们所要做的就是最大程度调动并发挥其长处，并帮助他在短板的方面获得更快的成长。 用人用其长处
要给与充分的资源，信息和指导，又同时给他们足够的空间，往往不能一概而论。

2 因事而异
先问自己，这个任务在整个项目中是不是很重要，是不是很紧急，如果是，并且每一步的完成有很强的时间限制，在 “怎么做”的方面会因为各种要求or限制 并没有太多的发挥空间，那么这个时候，更多的介入是你更好的选择，不过在介入之前，你需要让对方理解为什么需要频繁沟通。

如果有试错空间，或者不在关键线的关键路径上，这时，不妨试着放手让组员尝试独立完成。这样，管理者这样才能有鼓励创新，并且增强组员的工作积极性。他们全权负责，即使出了错，他也会更有责任感和足够的经验去改进

如果整个项目时间都特别紧，任何一个点都不容出错，就应该去思考，如何规划整个项目时间和人员的安排，尽可能去创造出一个可以让员工发挥的空间。如果什么都不放手的话，除了对员工有负面影响，没什么其他的

3 跟进的粒度
1 制定目标，确保传达
明确说明最终结果什么样子，并明确地告诉员工，他的责任是达成什么目标，通过结果去衡量他们

2 多给指导，少亲手做

3 设定频率，保持跟进
根据对方的经验和任务紧急程度

4 交流难点，给出建议

4 交流的重要性
最关键的就是让对方完全明白对方的期望值，可以很坦诚的告诉组员。如果觉得他介入的太多或者太少，可以随时告诉他

如何处理工作中的人际关系

在工作中，我们需要尽量摆脱自己的感性判断，尽量平和地对待别人，处理好工作的人际关系。
工作中的很多交流是不可避免的，所以常常需要比生活中的关系更严谨对待。如果在工作中和某人闹僵了，后续的合作就会变得非常困难。

1 对于自己的上下级，保持开发的心态和愿意沟通的态度十分重要
2 在交往过程中，尽可能对别人的分享，工作，交流持有一种积极，友善和鼓励的态度
3加入一些有利于自己成长的社交圈子
4 适当的寻求帮助，但是不要问不值得的问题，注意是不会耽误对方太多的时间，自己的态度也尽可能的开发，谦逊。
5 对于别人的意见要尽可能认真对待

编程语言漫谈

1 初学者 不要纠结 “先学哪种语言”，不如随便挑个语言，跳进去游几圈试试。对于工程师来说，学习一门编程语言支持万里长征的第一步，只要你还在这个领域，就不可能只学一种语言，只会一种语言的工程师根本不能称之为工程师

2 如果不能用一种编程语言的基本特性写出好代码，那换成另一种语言也无济于事，你会写出同样差的代码，掌握一门语言的功能和语法特性之后，要去做实践和练习，能写生产代码了，再回过头去看编程语言的本质，了解这门编程语言的设计原理，能力边界和高级功能，这样有助于你更快的掌握其他编程语言。

3 很多人觉得不用脚本语言入门，不一定，尤其现在就着人工智能搞机器学习的人，用Python入门就很好，脚本语言在面试中，占绝对优势，平时工作中，我对，Ruby，Python，C++， 和Java的熟练程度差不多。

4 后端工程师要熟练掌握一门前端语言，前端工程师也要熟练掌握一门后端语言。因为两者的编程模式思维不一样。知己知彼，在架构设计和解决具体问题时，才会有更精确的判断。 大前端的概念比较流行，也就是大前端工程师 能够同时掌握 Web编程语言，IOS 和Android 编程语言，原生技术（IOS 和Android）和Web的配合会越来越紧密。

5 SQL 是一门非常非常重要，并且应该熟练掌握的语言

6 无论使用什么语言，工程师都应该能够基于这种语言搭建测试框架，写好测试代码和写业务代码一样重要，甚至更重要

7 在任何时候都要用并发的，分布式的思维去看待你的程序。因为竞争条件 或者并发中的不确定因素（比如调用顺序）导致的Bug，仅仅理解语言的基本特性，根本不能解释，学习每一种语言，都应该去了解它的并发模式，在这个多核的时代，不懂并发的程序员不可能是个好工程师。

兼容并包的领导方式

如何做自己的职场规划

做一个职场规划时，你作为当事人，自己要先想清楚很多问题，然后再和你的领导者交流沟通，寻求他的支持和帮助：

1 你的个人价值观是什么，最在意什么？
换句话说，什么样情景or状态 会让你有幸福感或者自信心。比如，在你成长路上那些是你在意的，
是独立解决问题的能力，
还是挑战别人做不到的东西
是受欢迎的程度，和所有人良好的关系，
还是在意自由，健康的家庭生活。

2 你的长期愿景是什么，五年甚至十年后，你希望自己成为什么样的人？

3 为了达到目标，你还需要哪些技能或者经验，你可以在短期内发展什么技能让你走的更远，想达成你的梦想职业，在工作中获取成功，你还需要做些什么？
需要哪些必备技术技能？
哪些技能对你来说不是必须的，但是会有很大好处？

4 你的优势和长处是什么？ 是合作性，独立思考，行动快速，还是有良好的产品思维。
你现在的日常工作能否让你展示你的长处，优势如何展示的，你觉得你比别人在那些方面做得好，能不能举出些例子？

当你想清楚以上问题的时候，大概就知道自己想要什么了。如果你是一个管理者，也可以用这些问题去启发你的团队成员。

思考完自己的问题，接下来的也就是最重要的问题就是，你需要你的领导者提供什么样的支持？

在这些问题或者要求提出之前，你应该考虑到领导者的资源和整体项目进度，也就是说，领导者在提供这些支持之前，很可能会有一些限制或者要求。

比如你想要的一个能证明自己的项目，那么在你承担重任之前，你可能需要完成另外一些不那么重要的项目，甚至是脏活累活来证明自己**。这种情况下，沟通的关键就是契约，你需要如何证明自己，才能去做自己喜欢的项目，阻力是不是有人明显比你胜任很多？**

比如，你需要一个能够带着自己的往前的老员工，那你就要知道，对新员工知道会花费老员工很多时间和精力，当你这样要求的时候，是不是可以提供一些力所能及的回馈呢？比如朱勇帮助老员工做一些他手上的杂活，也可以把老员工传授给你的经验写成文档，这样，你被指导了一次，却留下了以后新人都能使用的文档资源。老员工会更愿意去带这样的新人。

比如，你想接触更多业务和架构相关讨论，那你是否按时完成了自己的本职工作？如果你自己很勤奋，索然参与了各种讨论，但自己的工作完成得又快又好，甚至利用自己的休息或者娱乐时间做了一部分工作，这样领导不会有顾虑。如果你作为新人，该做的工作没做，整天参加各种讨论开眼界，这让领导者怎么管理团队里的其他人呢？

作为员工，不要提过于脱离实际的要求，作为管理者，要明确地让对方了解不让他承担这个项目的理由是什么，风险在哪里，让对方知道自己的不足，并提供机会让他先提升着方面的技能。

你和你的领导者都应该明确，多有的支持和帮助对你的长期目标和短期目标都是有益处的，不要提一些似是而非的需求，也不要人云亦云，如果这些要求不会让你离你的目标更近，那就是无用功。

得到领导者的帮助和支持后，剩下的就是让这一切变得可执行和可追踪。你可以和你的领导者一起为你的成功 or 进步 定义一些可测量的标准，制定可执行的行动计划，然后记录你的发展，按时和你的领导进行一对一沟通，讨论你的进步，反省做的不够好和不好的地方。需要的话，你可以适当调整你的计划，完成自我发展。

总结：
1 了解差距
2 得到领导者支持，得到一些有前提or回馈的支持和帮助
3 设定目标，指定一个你和你的领导者都同意的计划和期限，确保计划会让你和目标更接近
4 让计划变得可执行和可追踪，按部就班的完成和跟进，同时根据执行情况调整不合理或者不完善的地方，持续改进

Java 开发中常见问题

1 不要重复造轮子，也不要搬太多不同型号的轮子来用
2 深入了解依赖注入，选择一个好的框架
3 所有项目使用统一的文件夹结构
4 规范所有项目的API， 保持统一的风格和模式
5 规范开发环境，提供合适的工具

如何激发团队人员的责任心

1. 明确责任制，尽可能通过规则来明确和规范与责任心、责任感相关的事情；
2. 让责任制变得有效，而不是形同虚设。每个人真正对自己的那块业务负起责任来；
3. 尽可能地让团队成员充满归属感，进而激发他们的责任心。

首先说说明确责任制：
怎么把一些没有明确职责范围的事变成职责呢？有一些不同的方法可
以尝试。比如，适当的放权，让团队人员不是负责执行一些事情，而是对某一块业务具备完
全的决定权，也就是说，让他们去主导一些事情。这样员工会认为自己对项目有完整的所有
权，进而具备责任心。

当然，由于人员流动、项目组重组的原因，这种全权负责的项目制度还是会留下灰色地带。
比如，前面一个人项目刚做完甚至做了一半就离职了，或者被抽调到其他组了，那后期的
Bug 和改进要怎么做呢？

如果项目剩下的工作还很多，可以找一个工程师接手并负起全部责任。如果剩下的工作不多
了，而且很零散，可以通过一种守门员的机制，组里的人每周轮流值班，负责这一周与该项
目相关的各种杂活，比如处理用户反馈，修复 Bug 等。

另外，还要有适当的奖励机制，对于主动承担责任的员工表示认可和感激，适当的物质激励
也是可以的。他们自发地做了一些对团队有益处的事情，承担了本不属于自己的责任，理应
得到其他人的尊重。

**其次，让责任制变得有效而不是形同虚设。**关键点是让责任人意识到承诺了就要努力做到，
如果承诺的事没做，需要承担后果，而不是没人在意。

比如 Bug 引发了事故，大家只是去修复 Bug，但没人去跟进 Bug 是怎么产生的，造成了
什么影响，后续怎么预防，那 Bug 就会越来越多。如果项目延期，大家只是继续延后项目
完成的时间线，而不是去分析为什么会延期，如何赶上进度，是否需要外部资源的支持，那
期限就会变得可有可无。

有效的责任制，在开始的时候就要让所有人明确责任与权利，而不是最后追究责任或推卸责
任。

在这个基础上，根据每个人的不同情况，在执行过程中适度跟进。发现问题的时候，及时指
出来，但这时需要注意的是，管理者要用关心的口吻，而不是追究的态度，让对方了解到问
题出在哪里。不要因为做好人而什么都不说，那样只会让小问题扩散成大问题。多花时间，
让对方自己认识到问题所在，而不是把你的主观感觉强加于人，用引导的方式，会更好地激
发团队的责任心。

不要变成一个微观管理者，也不要成为一个纯粹的规则执行者。那样对团队人员的责任感、
上进心和积极性等，都有害无益。

**最后谈谈归属感。**归属感是指一个人对某样事物、组织的从属感觉，是一种主观的个人感
受。
比如一个对公司有归属感的人，会对公司产生一种“家”的感觉，觉得自己是公司的一分
子，会非常在意公司发生的一切，并希望公司发展得更好，自己也会有更多的空间；相反，
如果员工对公司没有归属感，始终会认为自己是这个公司的过客，总有一天会离开的，自然
也谈不上什么责任心，能够做一天和尚撞一天钟就不错了

如何增加员工的归属感呢？首先要在有利公司发展的基础上建立独特的企业文化，创新、公
开透明、积极向上，这些因素可以留住更优秀的员工。

需要强调的是，公司不是温情脉脉的家，公司是一艘大船，有了方向，大家合力划桨，才能
到达理想的彼岸。想要优秀的人产生归属感，仅仅靠丰厚的薪酬待遇和舒适的工作环境是不
够的，他们还需要远大的目标和坚定的信念，只有真正伟大的创见，才能让这些优秀的人与
公司一起往前走。

除此之外，管理者还应该以身作则，让员工看到自己的努力，对公司目标的追求，对企业文
化的践行。真诚对人，能够从员工角度考虑问题，对好的行为认可并加以鼓励，同时做一些
仪式感比较强的团队活动和建设，都是增加员工归属感的好方式。

技术人的犯错成本

1 所有关于公司公关层面的事情都不是小事
很多技术人都喜欢分享，但是分享的过程中，要避开公司公关层面的内容，更多去分享自己的技术和成长体验。很多内容写在平台上是很不负责任的，直接影响了公司，还会有辞退的危险

2 人事变动的宣布一定要谨慎
一定要让老板宣布

3 技术或者业务的问题，如果不确定，就不要随便给答案
涉及业务和技术，都是可丁可某的事情，很对时候对就是对，错就是错，没有中间状态，技术人处理这些问题一定要严谨，千万不要丢失自己技术上的信用分。

4 技术失误导致错误的产品决定
一行代码 就是千万资金。 涉及交易，产品决策，和数据问题，都要慎之又慎，反复考量犯错概率和成本。
错误告诉我们两个重要的事情就是： 第一要去试错；第二要从错误中成长。

很多公司都会鼓励多尝试，但某些时候，工程师们的错误成本很大，这些错误可能会引起比较大的麻烦和损失，也可能会让我们失去信用和机会。

要去认清我们犯错的成本，知道我们可能会犯什么错误，避免去犯致命错误。

如何从错误中成长

1 伸展错误
尝试去做能力之外的挑战的时候，因为自身能力or 其他条件的舒服，做的不够好而犯的错误。这种错误通常是因为我们主动尝试导致的，再小心也难以避免。不过在次过程中，你获得学习的机会成本很高，一旦经历过一次，就可能有长足的进步。
摸索前行，遇到问题，解决问题，犯错，然后纠正错误，所谓逢山开道，遇水搭桥，就是这个道理，当你到达彼岸的时候，你会发现自己已经升级了，进入另一个境界。

2 无知错误
这种错误一般是因为你不知道or 忘记考虑某些特殊情况导致的错误，或者是你做了错误的假设。
初级称需要很容易犯这样的欧五，比如忘记处理异常，没有考虑某些边界值，没有进行安全校验等等。主观意识上没有认识到犯错的风险，还以为自己一直是对的，以至于出错后才会有那样的反应。

3 粗心错误
因为不小心或者 忘记了 导致的错误，如果你是一个粗心大意的人并且没有意识纠正自己，这种错误可能一犯再犯。

4 高风险错误
主动去做事情，但风险粉膏，是否会犯错误不受自己控制。比如你面临一个重要的选择，但在结果出来之前，你之前掌握的所有的信息都无法告诉你哪个选择是绝对正确的，你只能去做自己认为大概率是对的选择。

有哪些措施or 方法可以系统的让我们避免那些无效错误，并从错误中成长呢？

1 为了避免延伸错误，尽可能提供一些培训机制。
2 为了避免无知错误，要做好信息的透明和共享。
3 为了避免粗心错误，设置一定的复盘机制。
4 为了避免高风险错误，所有的决定尽可能都有一个备用方案。

理解并建立自己的工作弹性

真实的情况可能就是：别人也很焦虑，只是表面上看不出来而已。
事实上，不安，轻度的焦虑，几乎会伴随人的一生，那些有抱负，有上进心并取得成功的人，同样会有各种坏情绪，只是他们自身的系统弹性比较好，可以很快消化和处理这些情绪，而轻度的焦虑和失控状态，有时候更容易激发人的创造力，并保持机体活力。

把注意力放到那些自己能控制的地方，不要过多的因为自己无法控制的因素而责怪自己，知道每个人都有弱点，有局限性，不要过高的估计自己的能力。

有些人平时睡眠很少，大部分时间用来学习和工作，但是偶尔也会有完全不想干正事的时候，那么给自己放个假，逛逛街，睡个懒觉，或者在家瞎折腾消磨时间，都是很正常的事

每个人都有乏的时候，偶尔放纵自己，也是弹性的一种表现，没什么可自责的，不要觉得浪费了时间。文武之道，一张一弛，紧张久了，松上一扣，然后再层层递进，学到的东西必然扎实。

哪怕真的做了什么愚蠢的事情，好好总结为什么会这样，下次不犯同样的错误就行了。最多自嘲一下，谁不会偶尔笨一下呢？遇到坑就赶紧翻过去，后悔并没有太多的帮助。

如果担心自己能力不够，不能把一件事做好，那不如把注意力放在改进和提高上，找到自己的差距在哪里，哪些地方是自己要持续提升的。把注意力放在当下一个个可以实现的小目标上。只有宏伟的目标却没有一个可执行的方案，必然引发焦虑。

再次，身边要有一些积极向上的人，与他们做朋友，没有的话就去努力结识这样的人。看一些积极向上的文章，保持良好的心态。

当自己陷入迷茫的时候，有个人可以倾诉或者咨询。有的时候，你觉得自己特别惨，事实上别人都曾经经历过。知道了事实的真相，就好像过一条长长的黑暗隧道，你知道出口在哪里，也知道一定能够走出去，就不会太迷茫。

另外，要确认自己在做一件有意义的事情。这很重要，因为你一直在向自己希望的方向前行。如果你觉得自己正在做的事完全没有意义，不论你多努力都没有帮助。这个时候，不如停下来，仔细想想自己该往哪走。

记住：
不论你多努力，也不是所有的付出都会有回报，或者有等比的回报。
很多努力，并不一定有立竿见影的回报。当我们做出一些超出自己职责范围的事情的时候，应该是自发的，而不是一定要什么回报。否则，做了之后一直纠结回报，反而不利于成长，也不能持久。

我们的努力就像一道线，有的人做的工作还在线下面，却因为运气，时机，项目，公司等因素收到了好得多的结果，而有些人，付出和努力已经超过了那条线，却久久看不到成果。这个时候需要的是耐心，因为你已经攒足了信用分数，一旦机会到了，就能顺理成章拿到你应该得到的东西。

**不只是你，每个人都有自己搞不行的时候。**英文有句话很有意思：Fake it，until you make it。意思是：假装就好了，一直假装最后就成了真的。不要去考虑别人做成了什么，或是有什么技能。把自信放在自己身上，按照自己的步伐和速度，每天进步一点点

别人比你强，也许也是装的呢？想学什么，就去学，想做什么，就去做。工作上也是，公正地看待自己的能力，不断给自己设定比自身能力高一点的目标，然后努力去做，你会发现自己的弹性能力远远超乎你的想象。

解决方法：
就是不断正确思考而不是钻牛角尖，找到需要改进的地方持续改进，偶尔放纵，不担心犯错，从错误中成长，结实乐观的朋友，一直做自己认为有价值的事情。
最后还要具备好的心态，知道付出不一定有回报，每个人都有自己搞不定的事情。日拱一卒，不期速成

编程马拉松

最后总结一下我对编程马拉松的感受：

1. 编程马拉松是一项能够激发创意的活动，很多活动中的产品最终都成了成功产品的原
   型。
2. 根据公司的实际情况举办编程马拉松，掌握好节奏。
3. 编程马拉松不仅可以激发创意，还可以让你和团队的小伙伴建立特殊的感情和纽带，增
   加团队的凝聚力。
4. 参加编程马拉松尽可能选择一些可以扩展你知识边界的项目，开阔视野。
5. 与牛人结对编程，要敢于说出自己的真实想法，无论对错，都会有不同的收获。

CodeReview

后续在学习吧

如何拒绝更多的工作

1 事情分轻重缓急，有些紧急的事情和优先级高的事情很难拒绝。
2 正确评估自己的能力和时间资源。

对于很紧急的事务，我们需要在短时间内放下其他事情，哪怕在忙也要说“Yes”，尽自己最大努力去处理。这样的收获是建立了自己的信用度，公司和同事会觉得这个项目的人就是靠谱。

事从紧急，在攸关大局的事情上，尽可能能避免说“不”

1 正确评估需求后，如果事情没有那么紧急，或者这件事别人也能完成，并且你手头正好有
更重要的事情在做，告诉对方，这个需求现在做不了，需要完成当前任务之后才能考虑。
从对方的角度看，如果这个需求对他很紧急，他会去协调其他的资源完成，而不是非你不
可。这种需求你如果在分身无术的情况下答应了，却没有立即处理，会让别人觉得你言而无
信。

2 如果某件事的处理已经远远超出了你的能力，甚至职责范畴，不要只是为了别人高兴而充
当滥好人，揽下来又做不了，或者达不到对方的预期，不仅会耽误人家的事，还会丢失自己
的信用分。这时候要学会说“不”。

3 如果某件事你可以做，但是因为各种原因，自己觉得有些难处，又不愿意解释就勉强答应
下来，最后的结果可能是事情做了，却做得心不甘情不愿，完成度也不够。这时候也可以考
虑说“不”。

与生活中相比，在工作中说“不”肯定更理性，但是也不要强硬拒绝，让对方觉得你是因为
不愿帮忙才拒绝的。
无论是自己当前正在处理更重要的事，或者是觉得自己不是最佳人员，亦或是因为其他原因
不能承担某个连续的任务，都要开门见山，把自己的想法和事实清晰地表达出来，不要用借
口，承认自己能力有限并不是什么丢人的事，继续努力就好了。

答应一件事情之前，要想清楚是不是同时有更重要的事，能否并行，以确保不会有时间或其
他冲突。答应一件事情之后，尽可能地兑现自己的承诺，如果出现计划外的情况或者难处，
及时沟通，多替对方着想。同时也要记住，在工作上，对自己力不能及的事情，提早
说“不”，无论对人对己，都是负责任的表现。**

在自己能力不能及的事情，提早说“不”，无论对人对己，都是负责任的表现

硅谷 互联网公司的开发流程

后续带团队时候在看

成长不是顿悟，而是练习

每个技术人成长到一个阶段，都会去思考：下一步到底要怎么走？是要在一个自己比较陌生的领域开辟一块新的天地，还是在自己比较擅长的领域继续精进？要不要转管理，转产品，要不要去搞机器学习，搞区块链，哪个领域在风口浪尖，就投身哪个领域么？

有太多不同的声音了，每个声音都似乎那么有道理，比如：要勇于尝试，要勇于走出自己的舒适区；比如，你连自己现在的事情都做不好，换一件事情也很难做好。会有人告诉你做技术很容易就到了自身的天花板，也会有人告诉你转了管理就丢失了你原有的技术优势和核心竞争力

迷茫过嘛？迷茫过，事事顺心的时候，勇气来的容易，但是当生活变得艰难，勇气就弥足珍贵了。
同样的是选择。人生一帆风顺的时候，很容易相信你自己的选择，当人生一次次亮起红灯的时候，甚至告诉你此路不通的时候，你就会慢慢后悔自己的选择，怀疑自己的选择，甚至再有机会到来的时候，你会彷徨纠结，总是对自己做出的选择唏嘘不已，后悔万分，也许山那边的风景更好呢。

没有办法，时间无法倒退，面对迷茫只能不停地成长，在自己选择错误的时候，也知道自己在这条路上是不是比起之前的自己更成熟，更有见识了。只要在不停成长，就不怕犯错误，就知道自己还有机会。反之，哪怕一路坦途，事事顺利，但是自己没有什么成长，就会陷入更大的迷茫。

找到那些适合你的道，尤其是合适你当前的道，这个道，即是道路，也是道理，剩下的就是练习。
我的同学们，同事们，论技术，论能力，论经历，论职位，比我优秀的比比皆是。相反，因为我的普通，少了很多压力，我可以是个流浪汉可我的狗不是流浪狗，我可以是个垃圾但我的爱不是就好了。那些我挣扎过的，奋斗过的，失败过的，迷茫过的，都不在重要，因为这种启发，感悟，分享，随着时间的成长，更具有阶段性。

即使是同一个人，在人生不同阶段时期，获益的感悟也很不相同，有时候伙伴会觉得我讲的很有启发，那是因为我碰巧走在了他的前面，偶尔也有人觉得，我的太浅显了，我也不会介怀，因为可能碰巧走在了我的前面，闻到又先后，术业有专攻。

去年的文章，也许我今年就写不出来了。因为站在当前，突然会觉得那个时候的很多东西似乎有了更多的理所应当。那我现在写的，也许随着我的成长，未来也会觉得不尽然。而且我做的是否很好呢，有些是，有些是走过之后回望的总结，有些是我当前认可的，我坚持的，也是正在练习的。

就像黄蓉练不了降龙十八掌，郭靖练不了逍遥游，有些对的选择，对的理论，最后可能因为性格，资质，甚至生活，境遇，发现却是走不通的路，没有练成，但对自己也还是有成长就好了，我已经不期待自己最后可以成为什么样子，归来是否还是少年，无所谓了，没有了那些期待，更加轻松了，享受当下就很好了。

对于我而言，这些都是我人生阶段的一份记录，我把所有地感想写下来，是一种沉淀，因为时过境迁，以后我可能写不出来此刻这样的文字了，之所以分享，是因为它记录了我的成长，甚至不一定是正确的，但里面有我的故事，是我现阶段认为正确的，是我正在坚持的，它记录的不是我的顿悟，而是我的练习。

我平时几乎很少回合别人说这么多话，写专栏的时候，我也尝试着像跟一位朋友聊天一样去记录和书写。

一路很长，感谢有你~！