注

读了这本书后，我发现很多书里面的内容，只有你有相关的经历的时候你才会有很深的感触，这是我第一次看这本书，他就给我带来如此惊讶的感觉， 同时也希望读了这本书之后的我能成为一个务实（靠谱）的程序员

书里给我印象最深刻的内容

如果这些内容可以总结成一句话，那一定是“如何成为一名务实的程序员”

务实程序员的特质

务实的程序员的特质是什么？ 是他们面临问题的时，在解决方案中透出的态度、风格及理念。他们总是越过问题的表面，试着将问题放在更宽泛的上下文综合考虑，从大局着想。 毕竟，如果不了解来龙去脉，结合实际如何谈起？ 又怎能做出明智的妥协和合理的决策呢

书中关于对程序员工作的看法

你试着把工作记录成文档，以便他人理解；你试图将工作工程化，这样别人就可以友好地和你协作；更重要的一点在于，你尝试想在项目时钟的滴答声中完成所有这些工作。 可以说你每天都在创造小小的奇迹。

 这段话可能对一些人不适用，但是我觉得这大体描述了我在字节的工作经历，会写各种各样的文档 以便别人可以快速的了解项目的背景，会想要在正常的上班时间内完成所有的工作。 但是我从我的这段经历来看，我是一个努力但是不够主动了解更多的人。

和书中完全一致的看法

你不应该拘泥于任何特定的技术，而应该拥有足够广泛的背景和经验基础，以便在特定情况下选择合适的解决方案。你的背景来自于对计算机科学的基本原理的理解，而你的经验来自广泛的实际项目

这其实很好描述了我对自己的定位。 为了足够广泛的背景，

1. 我学习了MIT的6.s081 <操作系统> 这一门课，这门课给我打开了操作系统的大门，让我足够清晰的认识到一个操作系统是怎么样管理各种资源的，一个程序是怎么被加载到内存里面等等的知识
2. 我学习了StandFord的 CS144 <计算机网络> 这一门课， 这门课告诉了我 一个数据包是怎么从一台主机发向另一台主机的，为什么TCP协议可以保证可靠传输，为什么TCP协议需要有滑动窗口/超时重传/选择重传这些特性 ，TCP的状态机是怎么运转的等
3. 因为觉得自己的背景不够广泛以及一些原因，选择从字节离职。 重新学习操作系统/数据结构与算法的知识 涉足数据库/分布式原理/编译原理/前端的内容

为了广泛的实际项目

1. 选择了去字节，当一名iOS开发工程师，原因在于我想看一下大厂里面项目是怎么运行的，工程师之间是如何进行协作的，我不会拘泥于 是否我要在iOS这个方向有着足够的背景，或者我以后就会被局限于在这个方向里面。而是我觉得这份工作能带给我不一样的视野，让我真实的参与到工业界的项目中，让我了解庞大的项目是如何运转的。最后，这段经历也不负我所望，给我带来了我觉得很多很有价值的经历，就在字节的一年来说，我成长的比以往更快，学到了也比以往更多的知识。我觉得是非常值得的
2. 尝试去给感兴趣的开源项目提PR

你有权进行选择

 这句话我觉得说的也是很好的， 无论是从工作上,还是从离职的决定上。工作上，你的交付质量/技术方案选择 你都有极大的自由，你只需要给你的技术方案负责到底，这就是一个务实的程序员的表现，当然这个选择并不是说固执己见，而是说你有最后的决定的权利，而且你需要对这份权利背后的义务负责。 其次，就是我离职的选择， 说实话，我在字节工作的时候，我们团队的氛围还是很不错的，基本上我们小组内的owner同学，我觉得都称得上是“务实”的称号，从他们身上我学到了很多。如果不是工作地点/绩效/工作时间/我觉得现阶段的我如果继续呆下去，成长是没有之前快的问题， 我可能真的一干就是好多年。 很幸运，我的第一份工作就遇到了一群比较靠谱的人，说实话刚开始的我是不大靠谱的。 不过现在对于我的职业生涯来说还早，我还是有很多机会成为“务实”的程序员。

工作中遇到的情况

思考！ 思考你的工作

 在字节的时候，我们小组有个成员，他所做的每一个需求都会被人吐槽，在工程里面看到很难看的代码，第一时间会想到有没有可能是他写的，然后打开代码对应的commit 一看，果不其然 就是他。所以很重要的一点，在于对你自己的工作思考，如果你自己不思考自己的工作，你就会沦落为毫无思想的需求机器，你不会关心需求的background/context 那你又怎么能很好地胜任这份工作呢？在做事情的时候，思考一下自己正在做什么。 不是说对当前实践做的一次性审计——而是对每天里的每一个项目所做的的每一个决定进行批判性的评估。即时地批判自己的工作，虽然这会占用宝贵的时间，但是从长期来看，这份时间投资将得到回报，因为你和你的团队将变得更加高效，能编写出更容易维护的代码，并且在会议上花的时间更短。

不要放任破窗

 不要搁置“破窗”(糟糕的设计、错误的决定、低劣的代码)不去修理。每发现一个就赶紧修一个。 说实话我对这一句话有感触，但是不太深刻。因为如果项目有破窗的话，你非常容易陷入这样的想法“反正代码所有其他部分都是一坨屎，我只是随大流罢了”。 其实我在真正项目的时候还是没有遇到这种情况的， 我接受的项目虽然有破窗，但是我重构的时候还是很好地把这些破窗给他修复好了。同时我也告诉自己，不要打破窗户。

我的源码被猫吃了

不要把问题归咎于别人或其他的事情上，也不要寻找借口。不要把所有问题都归咎于供应商、编程语言、管理或是同事。这些因素可能都是问题的一部分。他们的的确会对解决方案造成影响，但不是给你的借口。 这是你（一个务实的程序员）需要解决的问题

 在真正的工作生活中，因为技术方案选型错误/有其他高优事项插入/错误评估需求难度/进度被与上下游合作方阻塞等原因，我们的交付被推迟了， 这是刚入职的同学经常遇到的问题，如何合理高效地去解决这些问题，其实也体现了入职同学的工程素养。书中说到**“在你的职业发展中、学习教育、以及你的项目、每天的工作等各方面对你自己负责，对你的行为负责，这是务实哲学的基石之一”**。 一个需求，只要交付了给你，你就需要为这个需求负责到底。并不是说出现之前的情况就可以双手一摊，说“不是我的原因，不关我的事情” ，真正务实的程序员，会推动事情的进展，同时给出潜在的解决方案。毕竟公司招你来，是让你解决问题的，而不是让你提出问题的。

• Case1 技术方案选型错误， 一般这种情况很少发生，因为在一个成熟的团队，你的每一个技术方案都会被审视，你的同事也会给你的技术方案提出合理可行的建议，如果是不可行的话，基本上都会被否决掉。 但是也不是说，一定不会发生，只有你自己才是最了解这个需求的人，所以发现技术方案选型错误的时候， 一种方案是 你可以直接向其他同事反馈，寻求他们的帮助； 务实程序员的方案是“不仅在提出问题，而且在尝试给问题提出潜在的解决方案”。 这也是书中提及的提供选择，别找借口
• Case2 有更高优的事项插入， 这种情况发生的情况会更多。因为意外总是经常发生。当你意识到这个高优事项可能会影响到你当前的需求进展的时候，你应当做的是及时暴露风险给leader，involve其他人来做共同决策，是不是确实更高优。一名务实程序员的做法是“在involve更多人做共同决策之前，尝试给出几个可行的方案，比如砍掉需求的不高优但是比较耗时的部分/请其他同事支援该项目等”
• Case3 进度被上下游合作方阻塞， 这种情况发生的很多，这个时候一方面你可以向合作方暴露风险，你主动承担责任 推进进度，合力解决导致进度推迟的原因。如果在反馈无效的情况下，involve更多人来对项目的进展分析，并讨论这样下去，项目进展可能会延迟。 这里面很关键的点在于，主动承担责任，做变革的推动方。其实这也是字节常说的“owner”意识