@xixun 不少，但前提你家有两个厕所，1 个厕所没必要

不是所有人都适合当领导，能这么想，大概率是没当过小组长的

你觉得有可能么，这代码不麻烦？实际上别优化就行了，比如 Android 的 相对布局 measure 的过程，是指数增加计算时间的，CPU 差一倍，时间可能差四倍。很多开发基于新 CPU 一通测试，老 CPU 跑得慢很正常。

@wuhan027 喜欢是喜欢。。。要添加到资料库

@murmur 都有补偿，不然傻子才会转。这种情况出现，一般属于员工水平还不错，公司有铁定裁员名额的时候，没办法保住人，但又需要才会这么搞

@c2const 这种情况大概率不转外包就是直接裁掉，转外包，还是可以拿裁员补偿的，先转再找工作才是最佳选择

@Kirscheis 一般 commit hook 都是签名或是对抗 gerrit 写的 泛式的 模板。主要楼主这事情，压根不是事，git 至少有 10+种办法处理，还都很简单，只要本地当前 branch 是 track 远端的，直接换成 detach 状态，把改动提交了，再生成一个本地分支就行了。

@pkoukk stash 还是很有用的，当然不是不可替代，stash 相当于可以把一些 CL 特别放在那，list 一下就能立刻找到，比较相似的是生成 patch 放一边。

一般书不可能汇编和 C 一起讲。
谈汇编不谈架构就是耍流氓，gcc 汇编和 intel 汇编又不一样，这们问就只能当兴趣了...
intel x86 汇编，看看 30 天写一个操作系统这种类型的书，基本就够用了，问题在于一半时间在处理 IO 或是 intel 分段机制，而且现在都是 x86-64 架构，完全用不上；
arm v8 汇编，找个新一点的类似树梅派的开发板（甚至 QMUE 也行）足够了，也学一下从 0 开发 os 足够了，不过绕不开 ATF 那一套；
如果不嫌弃，从 risc-v 玩起来倒也是不错的选择。

@pclsm 兄弟，裁员难道不是看你的工资么...如果天天不干活，请假大多数领导根本不在乎...

你是个领导，你还不明白什么影响考评么？再不济，不要在考评前的一段时间请长假也差不多了啊。

@xgfan
@Salticey 我说实话，这些划痕都在焦外，就像镜头的前盖划了一道，基本成像影响非常小...

共享单车的齿比不是很适合锻炼，去北京出差的时候，还用过美团爬戒台寺，速度感人。

@nothingistrue 这是大公司和小公司的区别，大公司允许使用一堆庸人，如果你只是优秀一点点，那么另宁用制度把你变成庸人（平均水平），这样便于管理，简单来说，5 个人你搞这套制度就是傻逼，20 个人的团队，你不这么干也能凑合，100 人的团队，不这么干就可能出事情。
另外大公司的流程是配套进行的，根本不可能只有一套判定逻辑，拿遥遥领先公司的制度举例：
遥遥领先不仅使用代码量作为 KPI 的一部分，还有如下：
1. 代码严格 reivew ，每个 team 都有负责人，不可能让你随便造个轮子刷数据；
2. 项目严格工期控制，文档多久写完，写完文档要评估项目节点，包括 ut st 的时间节点也算上，每个点有没有按时达标，都是考量；
3. 一堆代码分析静态检查的工具（这个听起来烦人，实际也确实没啥用，但这个部分占比并不多）这个的处理也要算到 2 的工期里的，甚至函数长度太长，函数调用关系过于复杂，层数太多都是要被打回来的，当然不一定改，但要有合理解释；
4. 质量控制，如果代码合入之后发布了有问题的版本，直接小黑心，今年不可评优；

大公司很需要制度来运转，否则摸鱼的太多，付出再多的成本也是没办法的。

@Leviathann
@fredweili
@HXHL
如果严格执行 review 制度，且以这个算 KPI 是最好的，因为程序员的 KPI 并没有那么好确定。
这里一定要强调编码规范，严格 review 。
以上两点华为做的很好。
不过这里有两个引申话题：
1. 一个好的公司，要允许有闲人，特别是大牛更是有工作不饱和的表象；
2. 如果有些人觉得自己吃亏了，比如技术牛叉，一个 bug 别人解了半个月，你 5 分钟解决，就改了一行 code ，那么只能说明，你们的职位并不是单纯的 coder ，更像是 arch 或是 system debugger 。这个时候要引入另一种 KPI 计算机制，比如，以 bug 的难度来算，把解掉的 bug * 难度系数（严重级别）相加，诸如此类。