编码并不是最困难的部分，而是需求的定义。作者通过自己的经验和例子，强调了需求的不明确、不一致或错误是导致软件问题的主要原因
不是强迫的喜欢，没用的，反而会让自己陷入误区，因为你不是在用一种自己不喜欢的角度去看待这个产品，你只是在用一种第三方的眼光去思考，去做这个产品，和真正喜欢这个产品的用户的诉求是不一样的。
需求工具要活学活用，知道每个工具制作背后的原理或者方法论，如果不理解，就是拿到工具，估计也不太会使用。工具或模板往往浓缩了知识、方法论的精髓，悟性高的项目经理往往能自己制作工具或模板，这才是将学到的东西提炼到一定的高度，继而提高工作效率，让自己能懒出境界。
所有问题其实都可以归结为人的问题。规则是死人是活，不同人在不同情况，对事情往往会有不同的处理方法。但在此就不展开讨论了，遇到问题想办法解决就是。
我经常在Stack Overflow上看帖子，见过不少各式各样的求助帖，有些帖子写得好，回复的也切题有些则不知所云。我觉得，优秀的开发者/程序员必须学会如何“在最短的时间内获得最好的答案”，下面是我总结出几个写求助帖提问交流的技巧。
最近有位刚做 PM（产品经理）的小伙跑来跟我控诉，说公司技术部的 RD 们（程序员）个个不给力。需求过了千百遍还是理解错，或者就是简单回一句 “做不了”，表情如死灰。
你确定你真的知道到底是什么促使一个程序员高效率的吗？是因为使用了 VIM 和 Emacs 这些强大的编辑器，还是因为应用了最新的 Haskell Web 框架，抑或是你最喜欢的 NoSQL 数据库？
用户并不一定知道自己想要什么
是客户真的需要“一个会躲避鼠标点击的闪光的按钮”吗？还是他们需要的是另外一个功能——他们不了解的功能，需要你去帮他们定义的功能？这种事情同样会发生在你自己身上！你真的需要用程序打开一个文件，往里面写入一些信息吗？还是，你真正需要的是一个日志系统？
应该还能用
【外评】谷歌：从源头消除内存安全漏洞
【外评】在 RiSC-V 上运行《巫师 3》游戏
【外评】法官驳回大部分 GitHub Copilot 版权索赔要求
谷歌内部推出 SQL 中的管道(Pipe)语法
你们干扰不了我写开源代码
【外评】FreeBSD 将 Rust 纳入基本系统
【外评】电脑从哪里获取时间？
【外评】为什么 Stack Overflow 正在消失？
有时
