0. 产品经理提的需求是可以驳回的。
哪怕他是你上级，只要需求不合理，就勇敢地驳回。又想要快，又想要完美的功能，怎么可能呢？
1. 客户是看不到你的代码的，所以没必要刻意追求永无止境的优雅，能跑就行。
2. 很多技术难题，不是你能力不行，而是根本没必要解决。
让手机壳根据手机壁纸变色，这种需求也是需要解决的。
必须解决掉提出这个需求的人，越快越好，免得祸害人间。
3. 你写的大部分代码，最后都是给交接的人看的。
代码测试通过之后，基本你就不会再看了。至于交接的人怎么看——
那是周树人的事，关我鲁迅什么事。
4. 技术再牛，也不如把需求讲清楚更能减少加班。
你敲代码可以很快，一秒五喷也好，才思泉涌也好，但一定没有动嘴快。
据理力争让客户领导知道做这玩意没必要，才是最快的。
做得快只会有越来越多的工作，但是能合理地推掉工作，对于此刻、未来都有极大的好处。
5. 网上吹的高薪神话，大多过滤了苦逼、运气和时机。
拿了高薪的永远不相信、也不承认自己的运气，自己曾经很苦逼，自己刚好踩上风口。
他们只是一味地说自己足够努力，然后卖课。
就跟那些所谓成功的老板一样，一样把自己的成功总结为自己的努力。
对于时代的发展、政策的支持、亲朋的帮助，闭口不提，张口闭口就是努力、奋斗。
6. 埋头死磕技术，不如把问题讲明白升职更快。
无论是你遇到的问题，还是解决过的问题，讲清楚让别人知道，对升职一定更有帮助。
而不是埋头卷技术，只做个懂技术的工具人。
7. 你以为在优化代码，其实很多时候只是在自我感动。
回看第1点，买单的人看不到，看到的人不买单。
没bug能正常运行不就完了，还要看有没有按照规范来？
拉完屎还要检查💩的形状是怎么样的、有没有擦干净？
对，没错，说的就是那些动不动就代码评审的小领导们。
8. 能稳定运行的老项目，千万别随便重构。
哪怕你十分清楚老项目的业务逻辑，你也别动。
并不是说你没办法完全重写里面的逻辑，是因为只要你动了，后面出问题就一定是你负责。
别揽没必要的锅到自己身上，你有多宽的后背自己心里要有数。
重构好了，没人夸你，大家都觉得反正你是按照旧项目来的。
但重构一旦有问题，你就全是问题：
"有老项目照着抄都有问题"
"本来没问题的，你一弄就有问题"
吃力不讨好的事别干，碰都别碰。
9. 程序员最大的本事，不是写代码，而是快速定位别人的坑。
自己拉屎容易，但要在别人拉的💩山里找到问题的关键，一定是个技术活。
你先要把别人的💩闻透了，搞清楚当前遇到的问题，才能最终找到那一坨。
为经常在💩山里遨游的各位亦菲、彦祖点个赞👍🏻
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！