本书是笔者上一篇读书笔记高效能程序员的修炼的姊妹篇，同样介绍了一些程序员需要了解的，有关于编程本身以外的一些事情。
和上一篇读书笔记的风格类似，笔者摘录了几段原书内容并结合了作者的感悟写下了这篇读书笔记。笔者还是深切希望各路英雄能提出宝贵的意见和想法。
关于 To-Do list
这个冗长的To-Do列表始终存在着，像一把悬挂在我头顶上的利刃，而且每天都在变得更加沉重和锋利。
每天早上使劲想出这天你需要做的最重要的3件事。
其实对于待办事项列表，笔者也读过相关的书籍，一般都是不推荐使用待办事项列表的。笔者总结出原因有二：
待办事项列表上面的待办事项只是列出了还未完成的事情而已，并不带有“何时开始进行”和“何时完成“的信息。简单说，就是只有“what to do”而没有“when to do”和“when to finish”。也就是它本身能带给列表主人的驱动力不够高。
正是因为待办事项列表带给主人的驱动力不高，那么结果就是它们一直会躺在列表里持续很长时间。那么它们的主人在潜意识中一直挂念着它们，分散了主人的精力。因为主人“知道”总有一些事情还是没有完成的。
关于探索的态度
比起专业技能或者智商，成功更需要一种探索的态度，它是一种对于可能性和失败后果的执着。那些具备良好潜质的人总是会做出类似的回答“我总是在犯一些作物。昨天刚发生了一件挺严重的事情，前因后果是这样的。。。”。
相反，那些回答“我并没有犯过大错误”或者“我犯过一些严重的错误，但是错误的原因并不在于我”的人是不会成为杰出的外科医生的。
探索的态度对于程序员也是尤为重要的。笔者在开始写代码的时候总是以“解决问题就万事大吉”的标准，遇到了可能的坑却睁一只眼闭一只眼。但是每每这样的时候，后来总是会出bug。
其实这就是逃避，就是一种缺乏探索精神的表现。其实我把那些坑弄懂了也不需要多少时间嘛。弄懂了，以后再遇到就稳稳当当搞定了。没弄懂，就还是踩坑。突然想到了一句话：遇到问题，你硬着头皮解决了一半，就只剩下一半的问题。但是你逃避，就是两个问题了。
不管你在做什么项目，怀揣着学习和锻炼的态度去完成它吧，这是绝对值得的！与项目结果相比，过程才是最大的财富。如果你没能从一个项目的过程中学到一点东西，这才是真正失败的项目。
关于专家
这个世界上只有少数的专家，却有大量的普通人。当你想要建立一个包含各种信息的网站时，这些普通人的贡献是最重要的。这是一个不规则的世界，里面装满了无穷无尽的细节。
作为专家，重要的是不是告诉别人你知道什么。而是要清楚你应该问什么样的问题，并且灵活运用你所掌握的知识去解决眼下的具体问题。作为专家，你的作用是提供明确的，可执行的方向。
读到这些，笔者觉得专家理应受到种种质疑，而为了能经得起这些质疑，那么就不应该跟人家说“我读了神马神马著作，精通神马神马技术，你看我的论文，你看我的研究成果等等”，真正证明自己是专家的途径，一般只有帮助非专家人士或者别的专家高效地解决问题。
其实，庞大的知识体系也是对解决问题帮助很大的：因为这些有着庞大知识体系的专家的晶体智力水平很高，很多时候，他们并不需要动脑子(也就是流体智力)，直接调出相应知识就能解决。所以说，那些自称专家的人如果连连无法解决问题的话，那么真的是low爆了。
关于软件项目管理
鼓励并强制要求程序员创建一张他们所要做的全部事情的列表，然后尽可能添加所有的子项，这样就能估算这个任务话费多少时间了。
如果有人问你的时间表，你应该拿出一张你要做的所有事情的列表。如果拿不出来，你所要做的第一件事情，就是要做出这么一张列表。
这种列表和待办事项列表稍有不同。这种列表属于“时间表”，它的目的是监控进度:所以说，它的时间总长度是不变的。但是待办事项列表的时间总长度是趋于“无限的”(当然，只对于执行力很差的人来说)。
关于“一夜成名”
一夜成名的传说容易让人误入歧途，并且遗毒不浅。如果你打算做一个全新的东西，要有打持久战的准备。
勤于练习：不是一遍又一遍的简单重复，而是要不断挑战略微超出自身能力之外的任务-努力尝试，并在做的同时以及之后对自己的表现进行评估，然后纠正错误，如此反复。
这里谈到了程序员对自己本身的迭代：快速迭代。其实同软件开发是一个道理：软件迭代的速度远重要于迭代的质量。也就是说，我们在学习的过程中，对自己的提升也应该是快速而轻盈的。
切忌一口气吃个胖子，肯定是吃不消的。应该结合自己已有的知识水平，再寻找对自己来说稍微有点挑战性的技术来攻克，一来学习效率高，二来可以提升自信，进入到新一轮的学习中去。
关于优秀和平庸程序员之间的鸿沟
- 成为更加优秀的程序员的方法是抛开编程。
- 你的兴趣越广泛，就能越胜任你的工作。
- 为了真正地成为一名更好的程序员，你必须培养自己对于编程周边所有事情的热情。
- 单单靠编程，你只能补足或者增强自己已有的变成技能，永远也无法成为一名优秀的程序员。你需要尝试去了解你的客户，你所处的行业以及相关的业务。
- 聪明的开发者知道，他们的工作远远不止编写代码和发布产品：他们的工作是开发出人们真正想要使用的软件。这当然包括编码，但还有大量全局性的其他事情，比如撰写技术文档，交互设计，培养用户社区，乃至产品愿景，这些对于软件的全貌成功都是至关重要的。
关于修复bug
在对报告数据的广泛分析之后，我们看到：80%的客服问题在修复了用户报得最多的20%的bug之后就得到解决。即使修复用户报的最多的1%的bug，也能解决50%的客服问题。这个分析结果通常对于各家公司都是成立的。
如果你修复了一个真实用户永远也碰不到的bug，那你修复有什么价值呢？
你越快将你的软件推到真实用户面前，就会得到越多的数据来改进你的软件。问题不在于你在发布软件的时候带去了多少bug，而是在于你能多快地修复那些bug。
因此，笔者认为在bug管理的问题上，要注意两点：
- 不要怕将bug暴露在用户面前，尽早地收集用户的反馈数据是关键。
- 而且，在收到大量的反馈数据之后，也应遵循二八定律，要以bug的影响程度来划分bug的优先级,不应盲目排列修改bug的顺序。
关于衡量软件的成功
多少用户在真正使用你的软件？这才是衡量成功的终极标准。
其实无论交互多绚丽，功能多么吊炸天，一旦用户不需要，用户不喜欢，不掏钱，其实是没有任何卵用的。而且在一定的技术水准上，如果无法“说服”大量客户使用产品，也同样是让人心痛的。
- 技术再牛也要从用户体验出发，少做一些中看不中用的东西。想出数百个功能很容易，但是从中挑出几个可以提升用户体验，真正能吸引用户，让用户掏腰包的功能实在不易。
- 产品做出来了，产品有没有人用，营销和推广同时占有举足轻重的作用。突然想到以前在一本营销书籍看到的：能做出比麦当劳好吃的汉堡包很容易，但是能比麦当劳卖得好却是很难得，众人难以模仿麦当劳整体的营销模式。相同的，像ZARA品牌的生产模式和营销模式之高效，是其他品牌无法超越的，这也是其风靡全球的原因。
关于用户的谎言
- 我们必须根据用户的实际行为模式来设计产品。
- 他们会说喜欢你的软件。但是我们应该去观察他们是否使用了软件，以及他们是怎么使用的。基于行为数据去设计软件，而不是靠用户说的“谎言”。
笔者认为，我们很少能从用户言语上得到用户特别真实的感受。那些善良的客户们有时碍于面子，有时想当和事老，凭着“你好我好大家好”的原则，说一些心里没有的，善意的谎言。
所以那些问卷调查什么的，走街串巷访问什么的其实意义不大。真正能“窥视”用户内心的是那些技术埋点。我记得有一次参加一个分享会，触宝科技的CEO跟大家分享了他们的埋点:他们通过埋点的方式，甚至会知道导致用户删掉app的是哪几个界面和动作。这让我感触很大，既然能做到这些，那么如果想知道用户喜欢点击那里，喜欢看哪里，喜欢做那几个动作，岂不是轻而易举？知己知彼，百战岂殆？
最后作者推荐的书籍
- 《代码大全(第二版)》
- 《点石成金：访客至上的网页设计秘籍》
- 《人件》
- 《程序员修炼之道：从小工到专家》
- 《软件工程的事实与谬误》
其中第1本和第4本笔者在看。第1本对于非科班出身的笔者来说实在是晦涩难懂。不过既然作者说读完此书就能超过90%的程序员，那么不失为一个节省时间的好方法。以后有机会的话，希望能和各路英雄讨论讨论个中奥妙。
笔者最后的话
其实还是希望能和各位相互讨论，其实相比于文章被“喜欢”，笔者更希望诸位能留下评论，毫不留情地指出小弟想法中的不妥之处，这些是远比“打赏”和“喜欢”更让小弟高兴的呢！
本文已经同步到我的个人博客：传送门，欢迎常来^^
本文已在版权印备案，如需转载请访问版权印。48422928
-------------------------------- 2018年7月16日更新 --------------------------------
注意注意！！！
笔者在近期开通了个人公众号，主要分享编程，读书笔记，思考类的文章。
- 编程类文章：包括笔者以前发布的精选技术文章，以及后续发布的技术文章（以原创为主），并且逐渐脱离 iOS 的内容，将侧重点会转移到提高编程能力的方向上。
- 读书笔记类文章：分享编程类，思考类，心理类，职场类书籍的读书笔记。
- 思考类文章：分享笔者平时在技术上，生活上的思考。
因为公众号每天发布的消息数有限制，所以到目前为止还没有将所有过去的精选文章都发布在公众号上，后续会逐步发布的。
而且因为各大博客平台的各种限制，后面还会在公众号上发布一些短小精干，以小见大的干货文章哦~
扫下方的公众号二维码并点击关注，期待与您的共同成长~
