0%
加班与效率
又是一篇陈皓老师的文章https://coolshell.cn/articles/10217.html
还是那句不要脸的话，真的是深有同感，特别是里面关于效率和产品那块的表达，真是我经常在心里想的和同事们聊的，不过也仅限于聊聊。再往上就会触发各种不满了。
摘一些
认为加班是公司的核心竞争力，或是超越对手的手段，是一种相当 Ridiculous 的想法。
产品的发展不是短跑，而是长跑，甚至更像是登山，登山比的不是快，而比的是策略，比的是意志，目的是登顶。
工作狂往往不得要领。他们花大把大把的时间去解决问题，他们以为能靠蛮力来弥补思维上的惰性，其结果就是折腾出一堆粗糙无用的解决方案
很多人不知道什么叫效率，他们以为效率就是：单位时间单位人数下干更多的活。这是错的！效率不是比谁干的活多，而是比谁干得活有更大的价值。效率的物理公式是：有用功/总功。换句话说，效率就是：单位时间和人数产生的价值。
有用功的来源不是拼命做需求，而是砍需求。
效率不是每个团队各自的效率，而是整个团队对整个产品负责的共同使命，这样才会现整体的效率。没有整体的效率，只有个体的效率，最终也等于没有效率。
T-Shirt Size Estimation
个人
很多时候说是产品其实还是按照项目在做，就会有个人认为特别大的问题，一定要追求大而全，蛮力堆功能，宁可错杀一千不能放过一百。不然就拿不下某块领域的客户，但是真的只能这么做吗？肯定不是的，因为这么做肯定是活不长的，咱们干技术的就知道，啥都要就是一种幻想，现实往往是啥都不精，然后自己把自己给捆紧了，啥也不敢做也不能做了。
最后只有两条路：
1.就这么一直不停的缝缝补补、纠纠缠缠根本没时间和精力与时俱进。
2.挣脱出来重新来一遍。但是又有多少资源和时间能重来呢？
工程师文化
读陈皓老师的https://coolshell.cn/articles/17497.html有感。
https://brendansterne.com/2013/07/11/do-the-right-thing-wait-to-get-fired/
https://news.ycombinator.com/item?id=6029823
有段话印象很深刻：
计划就是瞎猜
除非你是算命先生，长期的商业计划是种幻想。有太多的事实证明那是超出你的掌控的：市场环境、对手、顾客、经济等等。做计划让你觉得一切尽在掌握但实际上你没有。
当你把计划变成猜测时，就等于进入一个危险的境地。做计划就是在用过去推导未来，等于给你戴上了眼罩。
感想：你有职业规划吗？如果你有的话，那么你就一定就错了。职业规划是一件很扯淡的事情。我和一些高手都交流过，其实这些人在当初都并不有什么职业规划的，要说有的话，也就是想把技术搞透搞精。这些人在一开始从来没有想过要当个什么经理或是什么架构师之类的东西，这些人就是对技术有非常大的热情，把身边的那些看得见够得着的事情做到好好地，并且保持不持续强大的好奇心努力地学习自己不懂的东西。一个坚定不移的决定和意志力会比任何的计划和职业规划都重要。你问问自己，想不想当程序员，能不能一辈子都当一个程序员，能不能写程序写一辈子？（关于做一辈子程序员这个事，大家可以看看我的新浪微博 ——没哪个行业能像计算机行业这么活跃、刺激和有趣了。不仅是新兴工业革命的主力，又渗入到所有的行业中，干一辈子值了。//@_你亲爱的偏执狂: 程序员首先是工程师，Professional，就跟律师，医生一样，给大家解决问题；但是另一面呢，又是艺术家，创造新奇好玩的东西。这样的职业做一辈子有什么问题？）
http://www.effectiveengineer.com/blog/what-makes-a-good-engineering-culture
https://www.quora.com/Software-Engineering/What-makes-a-good-engineering-culture/answer/Edmond-Lau?share=1
1.优化迭代速度。
- 快速的迭代速度增加了工作动力和兴奋度
- 在基础设施方面，优化迭代速度意味着构建持续部署以支持快速验证、高测试覆盖率以减少构建和站点损坏、快速单元测试以鼓励人们运行它们，以及快速增量编译和重新加载以减少开发时间。
- 团队方面，快速的迭代速度意味着拥有一组强大的领导者来帮助协调和推动团队工作。
2. 不懈地推动自动化。
- 自动化解决方案和编写重复性任务脚本很重要，因为它们可以让工程团队腾出时间来处理实际产品。自动化必须由数据和监控驱动。
3. 构建正确的软件抽象。
- 保持核心抽象的简单和通用可以减少对自定义解决方案的需求，并提高团队对通用抽象的熟悉度和专业知识。将团队的注意力集中在少数核心抽象上，这意味着通用库变得更加健壮，监控变得更加智能，性能特征得到更好的理解，测试变得更加全面。所有这些都有助于简化系统并减少操作负担。
4. 通过代码审查来关注高代码质量。
维护高质量的代码库可以提高整个工程团队的生产力。更简洁的代码更容易推理、更快地开发、更易于更改并且更不容易受到错误的影响。一个健康的代码审查过程使这成为可能。
建立一个及时的代码审查流程，无论是提交前还是提交后，都可以在几个方面提高代码质量。首先，知道有人会审查你的代码并且提交写得不好的代码可能会让你的队友失望的同行压力是对骇客、不可维护或未经测试的代码的强大威慑。其次，代码审查为代码审查者和作者提供了相互学习以编写更好的代码的机会。
如果工程团队的其他成员可以轻松访问代码审查，那么审查还带来以下好处：a）增加及时审查代码的责任，b）允许团队成员 - 特别是新成员 - 进行建模其他人的良好代码审查，以及 c) 加速传播最佳编码实践。
敏捷团队没有时间花在代码审查上的反驳忽略了很容易从编写不佳的代码中积累的技术债务。Ooyala 在其早期的启动阶段，用于优化以尽可能多地推出功能，而无需进行代码审查；结果是，虽然最初的产品可能更快地推向市场，但最终的代码修改起来很痛苦，我们花了一年多的时间重写脆弱的代码以消除技术债务。
就其规模而言，Google 会对所有代码进行预先提交的代码审查，但较小的团队不需要如此全面或严格，并且并非所有代码都需要以同样严格的方式审查。Ooyala 后来在我在那里时通过电子邮件对核心或有风险的更改进行了提交后审查。在 Quora，我们在Phabricator中进行了所有代码审查，主要是提交后，并对模型或控制器代码和视图代码应用不同的标准；对于敏感代码或新工程师的代码，我们要么进行预提交审查，要么尝试在提交代码后的几个小时内对其进行审查。
5. 保持互相尊重的工作环境。
同行之间的尊重构成了任何类型的开放式沟通的基础。一个人们乐于挑战彼此想法的地方是一个通过辩论形成合理想法的地方。人们容易被冒犯的地方是关键反馈被隐瞒的地方。
6. 建立代码的共享所有权。
虽然个人精通代码库或基础设施的各个部分是很自然的，但没有人应该觉得他们拥有或是任何一个部分的唯一维护者。
在组织上，共享代码所有权提供了三个好处。首先，保持总线因子大于 1 可以减轻维护者的压力，并降低团队在维护者离开时的风险。这也使那个人很难无忧无虑地休假。
其次，共享所有权使在特定领域不深入的工程师能够提供新的见解。它使工程师摆脱了他们被困在某些项目上的感觉，并鼓励他们从事各种项目，这有助于保持工作的趣味性并促进员工的学习和积极性。从长远来看，它降低了一些工程师感到停滞不前并决定离开的组织风险。
第三，共享所有权还为在需要更快地完成战略目标时让多个团队成员蜂拥而至（来自敏捷开发的一种技术）共同解决高优先级问题奠定了基础。对于孤立的所有权，负担通常落在一两个人身上。
7. 投资自动化测试。
单元测试覆盖率和某种程度的集成测试覆盖率是管理一大群人的大型代码库而不不断破坏构建或产品的唯一可扩展方式。自动化测试为提高代码质量所需的大规模重构提供了信心和有意义的保护。在缺乏严格的自动化测试的情况下，工程团队或外包测试团队进行手动测试所需的时间很容易变得令人望而却步，并且很容易陷入一种害怕改进一段代码的文化，因为它可能会破坏。
强大自动化测试将验证责任转移到原作者身上，减少不熟悉的人的投入。
8. 分配 20% 的时间。
9. 建立学习和持续改进的文化。
10. 雇佣最好的。
如果没有足够的工程经验，很难识别出要构建的正确抽象。如果没有其他聪明人来挑战你的想法并推动你走向简单，很容易陷入构建复杂事物的陷阱。
硅谷有句谚语，由史蒂夫·乔布斯（Steve Jobs）创造，“A 球员雇佣 A 球员。B 玩家雇佣 C 玩家。” 专注于招聘和聘用合适的人是困难的，但对于有效发展工程组织至关重要
因为低质量代码和团队中较弱的工程师带来的技术债务最终会伤害团队和产品。
绩效考核
最近在和领导对团队运行的方案。其中有一条是关于考核的，由于团队的动态轮换性，一开始我认为需要有个考核不然团队成员可能就没法认真对待，因为会想反正过一段时间就撤了。
后来看到了陈皓老师写的一篇文章https://coolshell.cn/articles/17972.html。
深表赞同，我一直就对绩效考核深恶痛绝总觉得它在否定我的付出，好像我做的所有事都不是我想做的而是绩效要求我做的。而且老感觉自己有意无意在违背自己的真实想法做事情。
值得警醒的是当自己成为参与规则制定的一员的时候竟然会想到用绩效考核，真是让我无地自容。值得好好深思到底自己哪儿出了问题。
摘抄一句话：
用一颗平常心来面对公司给你打的分数，因为那并不代表你的整个人生。但是，你要用一颗非常严肃的心来面对自己的个人发展和成长，因为这才是真正需要认真对待的事。
我把考核那一条往后挪了，第一条换成了目标达成路径，额外还加上了奖励机制。
考核在某些场景下还是需要的，但是也仅仅是作为一个信息的输入，而不是奉为圭臬。
努力就能成功？
最近有疑惑，又在开始看陈皓老师的文章。看到了这篇努力就能成功[1]。做个转载。
摘了其中一段文字，详细请点击原文。
你喜欢这句话吗？
“努力就会成功”，“加班就会有成就”，“勤劳就会致富”……是这样吗？
仔细思考一下，这些话存在严重的逻辑问题，我们在高中的时候学过“充分条件”，“必要条件”和“充要条件”！
“努力就会成功”这句话，把“努力”说成了“成功”的充要条件，这不就是错的吗？努力只是成功的必要条件之一。你在错误的方向或是格局很小的方向上努力，能有用么？你努力地要饭，你努力地当搬运工，你努力地打骚扰电话销卖保险…… 在错误和小格局的方向上努力，你还觉得努力还有用吗？
个人感悟
虽然一直知道努力就能成功不过是一句鸡汤，但是看了这篇文章还是有醍醐灌顶的感觉，work smart和work hard有着本质的区别，一个是通过技能挣钱一个是通过劳动力挣钱。所以应该是通过不断的学习和迎接挑战来提升自己的技能，而不是找个简单的，然后想着用蛮力堆出成功，过程中还把自己感动的一塌糊涂。
References
[1] 努力就能成功: https://coolshell.cn/articles/19271.html
精益产品开发
最近一段时间在断断续续看老板推荐的一本书《精益产品开发》
背景
最近一段时间在断断续续看老板推荐的一本书《精益产品开发》。
我这人不太爱看书，是因为看书要犯困，我也不知道为啥，我内心是想看书的，但是一看上就打瞌睡，太难受了，所以导致我看书的节奏是只能概看，偶尔能专注（比如遇到难理解的、有兴趣的）。
在这儿记个流水账啦。纯属个人观点，不喜就算了。
开始
XP方法
即极限编程，一开始以为XP是啥没听过的新东西，一查原来就是早有耳闻的极限编程。
这里想说一说，XP里有个点，正是我目前比较推崇且是这么做的-简单设计
极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。也就是不过度设计不追求完美不刻意追求可扩展（需要申明一下当你个人都不清楚或者不确定未来的场景的情况下），以最短的时间和最简单的方式实现。
这儿我不跟任何人抬杠，我目前就是认为“简单设计”是让我体验最好的编程方式。
我从中能获益两点，这两点带给我的正反馈是可以让我放弃追求完美和一定要可扩展的目标的。
时间，通常会加快我对产出的交付，特别是当我扮演的是生产者或者叫被依赖方时，会让使用方的用户体验比较好，比如写后端的时候前端开发者会少一些抱怨和矛盾，比如写前端的时候，产品、UE会比较满意。总体来说，不仅仅只是少花了一些时间，在各方的满意度方面都会有所提升，从而最终个人幸福感得到提升。多说一句，团队为啥搞敏捷，说的直白点，很大的一个因素不就是各位消费方都想尽快看到产出吗？而不是多方动不动就墨迹工期的问题。
可靠性，因为是简单设计，所以满足当前场景的出错概念低，且易于维护。
聚焦价值流动效率，而不是资源利用效率。
这一点是我一直比较坚持的观点（虽然没啥人听我的），只是不知道有这么个专业的词语“价值流动效率”，现在公司几乎我接触过的team，不管是办啥事一上来都是先聊资源问题，往往就把事情聊死了或者需要老大出面了。
其实我觉得，不管啥事先要搞清楚，这个事的背景，是为了解决什么问题，最终对于产品的价值的是什么。这就是我认为的价值流动效率，就是咱们得聚焦于交付的价值，而不是资源问题。
控制在制品的数量
其中有一节讲看板方法的实践，里面说到一个实践：控制在制品的数量。
个人认为，首先产品端要克制，每个迭代不要以故事数来定，而是基于故事闭环以及研发工作量，聚焦最终交付的价值
看板
可视化价值流动
看板系统设计的原则
体现价值
反映协作
暴露问题
- 分析价值流动过程
- 识别团队交付的价值类型（业务需求、技术改进等）
- 确定看板系统的基本流动单元（通常选取工作比重较大的价值类型，比如：业务需求。）
- 分析流动单元的流动步骤（分析、开发、测试等）
- 识别流动过程中的价值分解和合并（分解为多人完成再合并）
- 选取可视化设计元素
- 队列。形成的条件：某个状态存在一段时间的停留。比如：开发中、测试中等
- 列的划分可以很细，具体细化到哪个级别，依赖于:
- 工作是否会在该阶段显著停留。比如：待验证
- 使用者是否需要特别关注这些阶段。比如：自测阶段
- 列的划分可以很细，具体细化到哪个级别，依赖于:
- 泳道。表达流动单元的层级关系，起分割作用，常用的划分依据:
- 处理规则的不同，如:业务需求和现场问题。
- 需要给予不同的关注，如需求的受益方不一样。
- 区域。表示特定信息。
- 卡片及标识
- 队列。形成的条件：某个状态存在一段时间的停留。比如：开发中、测试中等
- 用看板墙建模价值流动过程
显示化流程规则
核心要求：团队成员对流程规则形成一致的理解和承诺。
six months learn a language
最近看到一个视频：如何在六个月内掌握一门外语挺让我惊喜的，里面的内容跟以往我看到的一些教学习语言的内容有挺大不同，做个记录。
开始
两大误解
- Talent（需要天赋）
- Immersion per se（沉浸式语言环境）
特别是第二点再没看到这个视频之前我一直以为学习一门新语言最好的方式是去到说该语言的环境中，沉浸式体验才能快速学会，看过视频后最起码让我觉得这应该不是最好的方式，因为我回过头来一想，之前在重庆上学的时候因为学校就在重大旁边，所以认识了几个公派留学生，他们在中国留学2年，据我的了解，这些留学生没一人能说超过10句中文，尽管他们天天待在中文的环境。