低效能程序员的行为与思维，共勉

[young1lin]

不是感情宣泄，因为其中有些行为或思维也是我以前作为低效能程序员的总结。

排过序

1. 不写单元测试。
2. 不主动学习，不看书。
3. 总是拿没时间作为借口。
4. 不会做任务拆解，也没有记录拆解的任务。
5. 做事没耐心。
6. 不 Review 自己的代码，做过的事情，犯的错误。
7. 从不了解架构，不了解设计（设计就是架构）。
8. 不了解敏捷开发，更没有想了解的意愿，也不会去实施。Scrum Standup 、Kanban Board 是能提高工作效率的。
9. 喜欢埋怨别人，说在公司学不到技术，也不积极主动学习。
10. 认为重复的 CRUD 很无趣，总想着换个工作能好点。
11. 对每天做的事情不做记录。这里不是指日报，这里指的是你对每天工作是否有计划，将大的任务，拆成足够小的子任务。按优先级，有次序得完成任务。
12. 喜欢口述需求，不做文本化记录、转达。来自同事
13. 喜欢 “多线程” 处理任务。也就是同时做多件事。
14. 命名无关紧要。
15. 从不重构以前的代码。
16. 喜欢一个方法写一大段代码。
17. 对自己的代码质量没有追求。没有匠心精神，只是个开发（ Developer ），而不是工程师（ Engineer ）。
18. 和上面一样，认为敲代码来钱快，觉得以后要转其他职业的。来自以前的一些同事。
19. 喜欢盲目追逐新技术，不深入了解类似技术的本质。
20. 喜欢闭门造车，不了解业界成熟的内容本质，不会多维度比较。
21. 喜欢看“垃圾博客”（这里特指 CSDN 上的大部分博客），而不是看书了解技术。
22. 对别人产生严重依赖。例子：连 SQL 的关键字 AFTER 也要去问别人得到答案，而不是自己搜索。
23. 工作能力很差，但总喜欢教别人工作之外的事情（例如 “做人” 的那些 “大道理”）。
24. 思维固化，不听取他人意见，只会反对（无理无据，没有拿出实际论证的内容那种）。
25. 在没有完全掌握或了解的情况下，擅自使用 “新技术”。例如在没有完全掌握多线程和函数式编程的情况下，喜欢 "滥用" 多线程、函数式编程。我说的掌握，前提是看过相应的书籍，例如《 Java 8 实战》、《函数式编程》、《 Java 并发编程实战》这些书籍，并且真正理解其中的内容。在不了解 Kafka Streams 的情况下，直接引入对应的 Spring Cloud Stream 进行新项目的开发，从而引入天坑。
26. 碎片化工作。上班一半以上时间都是在刷手机摸鱼，没有完整的大段的深度工作的时间，把工作时间碎片化了。
27. 喜欢将 5 天的事情，拖到 6 天 “做完”。当然，这里和公司也有关系，垃圾公司是比较喜欢 996，大小周，以为能多压榨下员工。
28. 从不看计算机操作系统的相关内容。
29. 喜欢过度设计。这个 “过度”，仁者见仁，智者见智，分不同场景下有不同的解释。
30. 引用别人的内容，从不标注出处。

参考自

正例

《高效能人士的七个习惯》

《深入理解计算机操作系统》

《 Clean Code 》

《 Clean Architecture 》

《重构》

The skill of self confidence | Dr. Ivan Joseph | TEDxRyersonU - YouTube

芯片工程师的一天 | 我如何每天高效工作 12 小时？ [经验分享]

《 10x 程序员工作法》

如果你没有看过《高效能人士的七个习惯》、《金字塔原理》、《 Clean Architecture 》、《重构》、《实现领域驱动设计》、《微服务架构设计模式》、《测试驱动开发》、《敏捷软件开发：原则、实践与模式》（后面两年本我也没看过，只看过相关的书籍，例如大学学的《软件工程》），你又想短时间内提升自己，你可以挑着这个专栏，如果和你意你可以考虑买一下。我没收过极客或者作者一分钱，只是觉得还行，有一定收获。当然，看了专栏不代表这些书就可以不看了，这些书籍我也看了大半，尤其是《 Microservices Patterns 》也就是《微服务架构设计模式》，力荐。

反例

一年前的自己

历任同事（不包括所有）

我知道我不能说 CSDN 上全是垃圾博客，全是讲一半害人，抄书上的内容，你可以很 “轻易” 得找出能反驳我的博客。每个人都有自己不同的看法，我的看法就是认为 CSDN 是垃圾网站。

——来自一个告 “深山猿” 直接抄袭复制《 MySQL 实战 45 讲》的人，询问 CSDN 客服，告诉极客时间专栏作者。

我刚看到别人的《极客与团队》的笔记，这里说的，和我说的好像不谋而合了。

哪些人可以称为害群之马？

1. 不尊重别人的时间 ：比如很容易就能找到答案的问题还去麻烦别人。——对应 22. 对别人产生严重依赖，SQL 那个。
2. 自负 ：比如无法尊重和倾听其他人的观点。——对应 24. 思维固化，不听取他人意见，只会反对
3. 过分索求 ：比如喜欢抱怨而不愿意自己动手。——对应第 9. 喜欢埋怨别人，说在公司学不到技术，也不积极主动学习。
4. 幼稚或是莫名其妙的交流 ：比如用户名很奇怪，经常改变，不同的地方用户名不一样。
5. 偏执妄想 ：比如心里总是有各种阴谋论。
6. 完美主义 ：太追求完美也会影响到项目的开发与进展。在《设计模式之美》-王争里面也提到了，先写最小原型代码，再对代码进行逐步优化迭代，我之前也是一直想一次直接写出完美的代码，导致想的实在太多，耽误事情。

我已经下了单了，还有《卓有成效的程序员》、《高效程序员的 45 个习惯》、《成为技术领导者》、《系统架构》。

等我看完这些，再做一次补充吧。预计一个月之后，6 天一本，国庆有很多时间，看得更快。今年已经超额完成目标了，包含技术书籍和非技术书籍，已经超过了 50 本。上个月在微信读书上看了 50 个小时，包括纸质书观看，应该超过 100 个小时了。

还有就是有效的沟通确实很重要，我也正在改正我的坏脾气，这条应该加上，共勉。

很明显，我没有对我的承诺准时的付诸实践，没有对自己应该写的内容进行规划，只是按部就班的看完了这几本书，拖延到了现在。我可以找各种借口（国庆回家给家人庆祝生日，忙前忙后，年底工作很重，滨江三大垃圾厂的原则是 124 加班，大小周上班所以没时间，可能有抑郁症了等等），I had a damn good excuse. 但我不喜欢找借口，没做好就是没做好，我会怀有歉意，对我抱有期望的那些人说声对不起。我会去把它做完，有规划有条理的做好后续的每一个步骤。

当然，这期间我还看完了其他书，只是和这个无关，例如《数据密集型应用系统设计》（神书），快看完了《深入计算机操作系统》、《也许你该找个人聊聊》、《真实的幸福》等等，再看了遍《当幸福来敲门》。

续

1. 编写垃圾代码。

   是的，这个和 15，16，17 其实是一个意思，需要再三强调。

   什么是垃圾代码？难读懂，一个方法超级多行，也没有注释，更别说在一个方法里，把不同抽象层级上代码混合在一起。写代码并不是什么高难度的活，是个人都能写代码，但是能写出让人看得懂的代码才是真正的开发人员。

   尽量让你的代码保持简单，KISS 原则，Keep It Simple, Stupid。但并不是说所有代码都应该写简单，如果是复杂的事物，必须得用复杂代码实现的，那只能这么做。架构也是如此，请让你的设计尽量保持简单。

2. 对人不对事，喜欢一味指责别人。

   每一个的抱怨的背后都隐藏了一个事实。找出真相，修复真正的问题。需要你有结构化思维，自顶向下，探清问题本质。如果不会，请参照《金字塔原理》。

   请做一个积极主动的人，从自身出发，影响他人。自控力是可以传染的，应该以我如何如何出发，而不是别人如何如何。消极的人，很难进步。

3. 现在项目紧，先把功能写上去，测试后面再补，你先写测试代码慢，你也别写测试了。

   （来自从来没写过测试的人说我践行 TDD 有问题，后面当然没有补过测试代码）

4. 你不用管别人代码写得怎样，你管那么多干嘛呢，又不是人人都像你这样，先把功能做了。

   （这是低能说的话，不是低效能，全部习惯，只有这个铁板钉钉低能说的话）

5. 想靠别人的指导来让自己的能力提升，依赖别人。

   有点关联第 22 个，但不全是。

6. 分享垃圾知识，没有竭尽全力去搜寻有价值的信息。

   人一步步地做有挑战的事情才能进步，知其然不知其所以然注定学不到东西。很多时候，你想要了解的知识书上都写了。认为看书很难，英文官方文档不看，转而看那些 CSDN 的垃圾文章都是很低效的行为。

7. 不懂得对不重要也不紧急的事情做丢弃。

   艾森·豪威尔矩阵将事情分为，重要紧急，重要不紧急，不重要紧急，不重要不紧急。《高效能人士的七个习惯》里面提到过，《整洁架构》里面也提到过，前者让我们着重做不重要但不紧急的事情，因为如果你只做重要紧急的事情，最后都会成为重要紧急的事。重要但不紧急的事情，例如锻炼身体，学一门乐器，这些都是需要长时间投入，且平时可能觉得收效甚微的事情，但是当你坚持下来一个月，半年，一年，你一定会和从前大不一样。

   你一定也有一些一拖再拖，但是其实是很重要的事情。你应该大部分精力做这些事，一部分精力做重要且紧急的事。我看过一些其他工程师的视频，他们介绍他们在一些顶级公司（FAANG）是如何处理那么多的事情，处理开不完的会。一个主要的建议就是把你的事情一个个列出来，定个 Priority，一件件执行。是的，是一件件执行，不要做并发执行，你的人脑是单核，也做不了并行处理，最优的方式是事件循环 Event Loop 处理方式。那些让你同时做多件事的人，非蠢即坏。

8. 我会用就行了，我管这个怎么实现。

9. 将所有事情拖到一个时间，而不是有节奏地做事。

40. **每天，甚至几天提交一次代码**。

每次提交代码又臭又长，没测试类也没一点描述。我发现周围很多人都是这样的，我已经尽量和他们解释该什么节奏来提交代码，让你提交简洁明了，描述详细，本地提交，每天 Push 到远端。是的，没有 Code Review ，公司比较大，我做了很多努力，都无疾而终。按照我的标准，一行代码都不会让他们提交，明显线程不安全的代码也不测试，我用肉眼就能看出有很大 Bug 的代码直接提交了。我在半年前在公司已经做过代码规范的分享了，也比较频繁得教导该如何写，我尝试了很多方法，都是徒劳。

不论你是 Trunk-based Flow 、Aone Flow 、GitHub Flow ，你都应该至少做到每两个番茄钟提交一次代码，做两次重构及自我 Review 。关于代码管理的，我会在另一篇介绍一下 Bob 大叔的故事，来自《 The Clean Coder 》。即时反馈，是构建心流的条件之一，关于心流的部分，你可以看 米哈里·契克森米哈赖 的[《心流》]( https://weread.qq.com/web/reader/65e328b05e10e265eb76e03)，也可以看我等会发的另一篇 10X 程序员。

请小步快跑，逐步迭代，切记不要一次迈太大的步子。请保证你的项目时刻可以发布，保证你的系统随时可以编译、运行、测试并立即部署。
41. **管他呢，这个之后再考虑，先把功能做了，再集成代码**。

42. **每次都需要手工部署代码，即时在测试环境**。

这个手动部署真的很累，公司的 GitLab 服务器和测试服务器不在同一网段，对应 Gitlab Runner 部署不了，Windows 版本部署到本地也不行，又是半封闭式开发，我把能想到让项目自动化部署的方案尽量想过了。

43. **遇到问题从不及时沟通，喜欢自己憋住**。

44. **从头到尾只是按照既定计划实施，绝不做动态调整**。

实现心流的几个步骤。

1. 确立一个总目标，并尽可能包含多个实际可行的子目标。
2. 找出评估目标进度的方法。
3. 保持精神集中于所做的事情上，并且对活动涉及的挑战进行越来越精细的区分。
4. 培养随机应变所需的技巧。
5. 在活动变得令人厌倦时，随时提高挑战难度。
45. **忽略团队，过于自我**。

软件开发离不开团队，请珍视你的团队，培养你们自己的团队文化，不要过于自我。Linus 的固然很好，一人写下了 Linux ，但后续新的 feature 开发，维护，BugFix 都是离不开团队的。榜样固然重要，离开了团队，在软件开发中是很难做出很好的项目的。

什么是领导力（ Leadership ）？我不是领导，我为什么要拥有 Leadership ？

所谓领导力，就是创造这样一个环境，每个人都能在其中发挥出更多的能力。——《成为技术领导者》

领导只是做催化剂，不直接参与反应，但是能让每个人发挥最大效用。并且作为 “领导”，你应该沉稳。《极客与团队》的其中一个故事总结。

在《[高效能人士的七个习惯]( https://weread.qq.com/web/reader/56d325907203e8a856def7fkc81322c012c81e728d9d180)》中，第五个习惯就是 [知己解彼] 。在日常工作中，除了普通同事，和你沟通最多的应该是领导，如果你了解了身为领导他是怎么想的，他该怎么做的，你就能更多得应对工作、挑战。如果你的领导让你带人，你也不会做得很烂（是的，之前带人做得不怎样，事无巨细的指导带领的人让我心力交瘁）。

这里会一直提及《高效能人士的七个习惯》里的积极主动、以终为始、要事第一、双赢思维、知彼解己、统合综效、持续更新。

46. **从不记录以前解决问题的思路，方法，步骤**。

上次犯的错，这次还要犯，一次又一次。

不一定说每个公司都要有 AIOps ，或者有公共的服务记录上次犯的错，出现的问题。最起码你应该有自己的错误记录的文件，任何格式都可以。

1. 我是为公司工作。

   如果你这么想，你很难在工作中达到心流状态。在《心流》这本书中介绍了庖丁解牛、热爱生命的莎拉菲娜、与世无争的柯拉玛，你需要重新设计工作，使得它尽可能接近心流活动，你还得培养自得其乐的性格，加强技巧，选择可行的目标。

   其实你真正是在为你自己工作，我也是在为我自己工作，如果可能的话，在公司我自己培养了极其自律的习惯后，我会尝试创业。当然，这个事还没有说一定会去做，也算不上什么目标。

   我并不是说要天天加班（垃圾厂124加班不成文规定），大小周恶心员工。相反，我想你应该尽可能在工作时间内完成你的工作，而不是拖到加班。如果你把工作等同于赚钱，那你应该了解赚钱的等级分 4 种，

   1. 用你的时间换金钱。同一份时间，只能出售一次。
   2. 工作的同时，你做了更多的事，得到了成长。一份时间，出售了两次，一次给公司，一次给你自己。这也是巴菲特说的复利，
   3. 一次创造，永久收入。一份时间，多次售卖。售卖你录制的课程，写书。
   4. 用钱买别人的时间，给你自己赚钱。没错，就是你当老板，资本家。

   我工作是因为我能给公司创造价值的同时，让自己更加进步，公司给我一个能犯错、成长的环境，我会竭尽全力做很好，顺便让自己得到成长。当然，别强调加班，如果你的工作效率已经达到甚至超过了公司对你期望，但你的领导只想让你加班，你该早点考虑换下一家公司。Bob 大叔是这么看待加班的，必须满足以下所有条件，才能考虑加班

   1. 你能挤出这些时间

   2. 短期加班，最多加班两周

   3. 你的老板要有后备预案，以防万一加班措施失败了

2. 没有目的的开会，为了开会而开会。

   在敏捷开发中，每日的 Standup 是必须的。每人 1-2 分钟，来阐释

   1. 我昨天做了什么。
   2. 我今天准备做什么。
   3. 我遇到了什么问题。

   并不是领导说要开会而开会，为了开会而开会，既然开会，就要有开会仪式，尊重他人的时间。在开会前准备好你要说的内容，写下来，梳理演讲内容，和他人达成一致。

结尾

在《程序员修炼之道》里面也提到了，你不应该只局限于技术书籍的阅读，你应该读读其他类型的书籍。

福特公司开发了世界上第一条流水线（Pipeline），影响了电影制作、CPU、Spring 框架。你们可能觉得这些好像毫无关系，制作汽车的公司怎么会影响制作电影的，还会影响 CPU？事实上，流水线在我们生活中无处不在。

大制片厂的最大特点是流水线（Pipeline）的生产方式。1908 年美国人福特开创性以流水线生产方式，通过组装配件进行汽车生产，从而极大降低了成本，也使大规模的批量生产成为可能，被誉为现代大机器生产的代表。

1913 年，美国独立制片人兼导演托马斯·英斯意识到这种生产方式的价值，便建立了类似的电影生产模式，从此 “流水线的生产方式” 就成为了好莱坞电影工业的标志。

随后，在好莱坞的鼎盛时期，这种方式不断成熟。从而既保证了片源的丰富与稳定，又催生了电影类型片的出现。在这种流水线的生产方式中，导演对电影的整体把控权被剥夺了，取而代之的是强化了制片人的控制权，即形成了制片人中心制。

Spring 的 BeanFactory 是工厂模式，创建 Bean 的各个阶段的 BeanPostProcessor，以及各个阶段都影响着 Bean 这个产品，可以根据不同时间做不同的事情。甚至工厂本身，都能做 BeanFactoryPostProcessor。

多读书，读好书。Read More, Read Better.

这根本不是什么码农成功学，只是在说一些低效习惯罢了。

这些都是些低效能的习惯/思维/语句，我尽我所有做到不会有这些。

参考书籍

1. 《程序员的职业素养》The Clean Coder: A Code of Conduct for Professional Programmers
2. 《高效程序员的 45 个习惯》Practices of an Agile Developer: Working in the Real World
3. 《极客与团队》Team Geek: A Software Developer's Guide to Working Well with Others
4. 《卓有成效的程序员》The Productive Programmer
5. 《程序员修炼之道——从小工到专家》The Pragmatic Programmer
6. 《心流》Flow: The Psychology of Optimal Experience
7. 《成为技术领导者》——Becoming a Technical Leader: An Organic Problem-Solving Approach

[learningman]

认为重复的 CRUD 很无趣，总想着换个工作能好点。
不认同，CRUD 就是很没有意思啊

[wangxn]

楼上+1

[dongcidaci]

目前作为一个低效能程序员，对楼主说的很有体会和感悟

[WispZhan]

总结的挺好

[young1lin]

@learningman 你可以看下文中的这个 The skill of self confidence | Dr. Ivan Joseph | TEDxRyersonU - YouTube，链接点进去。或者你可以看看这个。

3 rules to quickly improve your life

从重复中找到乐趣，找到自信。成功的人不是每天做不一样的事，而是每天重复做同一件事，不断突破自己，不断踏出自己的舒适圈，不断成长。

如果你 CRUD 这些小事做不好，领导是不会说让你想什么技术解决方案的，小事都做不好的人，难做成大事。你可以每次只迈一小步，做任务拆解，从而完成大的任务。而且，CRUD 并不简单，任何事都不简单，你没遇到，不代表不存在。

换一个工作并不能改变这些，这是真的。很多公司是靠业务活的，不是靠创新活的。创新也要了解已有内容，在其基础上进行突破、改进。并且在计算机领域内，如果你不是专门研究某一块知识的人，很多时候，你的任务就是按部就班地完成和实现它。

有些时候，我们改变不了问题，但我们可以改变对问题的态度。或者说，只要能够看到问题的存在，就已经改变了面对问题的态度。

[xianyukang]

加一条不怎么相关的

31. 融入世俗, 没有享受过用编程进行创造 or 自我表达的快乐

[young1lin]

@xianyukang 对应 17 的匠心精神，以及 18 来钱快。

写代码是快乐的，而不是痛苦的，为了养家糊口的活动。

[janus77]

我感觉有些似乎自相矛盾或者不够说服力吧
比如上面说不喜欢新技术，后面又说滥用新技术的
比如碎片化工作和拖工期，我觉得空闲时间自己学习并没有什么问题，除非你所指的“低效能”只特指公司工作而不包括个人成长
另外我觉得每天高效工作 12 小时是值得尊敬的事，但不能成为值得推广的事

[w7938940]

除了第 24 条，说的就是我

[yrj]

不幸命中 29

[7gugu]

CRUD 确实很无聊😂

[zhoudaiyu]

建议加一个，从来不用百度以外搜索引擎搜索技术资料，我亲眼见过我曾经的组长用谷歌搜索百度，然后打开百度再搜索技术相关的文章

[young1lin]

@janus77

上面说的是， [喜欢盲目追逐新技术，不深入了解类似技术的本质] 。如果你说敏捷开发是新技术的话，可能你不是科班出身的，或者上课没认真听讲。可以看看相关书籍，我下面也有提到，或者再看看教材，我们那时候的是当时最新的《软件工程导论》-晏峰写的。

如果了解过一两个框架的源码或者中间件的源码，例如 Spring 的源码，你知道 BeanFactoryPostProcessor，BeanPostProcessor，BeanWrapper 等等，并且你还知道流水线（ Pipeline ）思想，很多源码，都不是问题。还有 Environment 抽象，你也可以在其他中间件实现类似的，例如 Flink，实现多 Environment 源，用 Spring EL 替换。如果都没看过对应的源码，那么看相应的书籍，可以帮你快速入门如何高效看源码。例如《通用源码阅读指导书》，这本书我看了部分，还是可以的，是可以作为源码阅读的入门书的。

碎片化工作，我们的理解可能出现了分歧，粒度可能不一样。我这里指的是，每过 10 分钟甚至更短，就看一会手机或者干工作之外的事情。如果你理解内存分配，内存碎片的内容，这部分你应该懂了。

如果你真正高效工作的话，一天 12 个小时高效工作，这个是很难做到的。你试过就知道了，我是这样，每天早上把今天的任务拆解了，拆到足够细了，开始工作，每工作 45 分钟，站 3 分钟，期间包括喝水、上厕所，结束后，再进行下一轮的工作周期。借鉴的番茄钟学习法，因为这个真的是有效的。

还有就是，我近半年没加过班了，不是说我不忙，任务不重，或者说公司大部分人都不加班。事实上正好相反，大部分人都 “加班”，由于是弹性打卡，他们早上在公司另一块园区的食堂打卡，然后 9 点多到工位，晚上拖到 8 点算是加班两个小时了。我一般是早上 7 点多到公司，看半小时到一小时书（ 8:30 上班），再开始一天的工作计划安排。有时候是 6 点 50 多到公司，所以我每天都是 17:30 准时下班。

有计划，有组织地去完成任务，这是很高效的。你也可以试试。光有目标，没有详尽的计划，这种是很难坚持下来的。让你的工作产出可视化，让你的工作内容有所记录，都是能切切实实提升你的工作效率的。

[young1lin]

@zhoudaiyu

这个我也想加的，而且我想加的是，不会用英文在 Google/Bing 搜索技术问题。但是这个很容易引战，因为会有一大波人跳出来，我就觉得百度好用、你这用 Google 翻墙是犯法、你不支持国产搜索引擎你不爱国之类的话。

用 Google 搜索切切实实得改变了我的一些坏习惯，也提升了我的英文水平（虽然现在一般），我已经可以不看英文字幕，听得懂说话算是标准美式发音（不要经常有缩读、省读、连读等）的视频了。

[fatigue]

《码农成功学》

[young1lin]

@w7938940

是可以改的，人是会变的，可以一小步一小步地改正。如果现在是，不代表以后也是。

如果想成为更好的自己，那就得付诸一些切实可行的行动。

就算每天只前进 1%，一年后就是 37 倍的成长。如果不知道如何养成一个好习惯，可以看看《 Atomic Habits 》这本书，中文名《掌控习惯》。将养成习惯拆解成了 4 个阶段，提示、渴求、反应、奖励。如何养成一个好的习惯，就是增加 /增强提示，增加渴求，降低反应成本，让奖励可视化。

上面说得可能有些抽象，更为具体，例如你每天做 10 个俯卧撑，限定了当时的环境，比如穿的鞋子，场地还有时间。比如我到 20 点了，穿上运动鞋了，到了某个地方，就该做俯卧撑了。你渴望拥有八块腹肌，以及健硕的胸肌，那么就得把这些渴求展现出来。降低反应成本就是你一天只做 10 个，多了就不做，一天做 10 个应该不难吧，对于大多数人来说。这里有个理论是 Five-minutes Rule，意思就是你只做 5 分钟，超过了就不做，但事实上你做了一般都会超过 5 分钟。书上说的是两分钟，和这个是类似的。让奖励可视化，是我们习惯了即时性满足，我们就要让做完这件事奖励马上有反馈。你可以买个习惯笔记本，每天记录自己做了这个习惯，做了就打勾，没做就打叉。看看自己坚持的情况，这也是可以让你的习惯坚持下去的。

上面的习惯记录，让奖励可视化，其实在 Scrum 的 Kanban 也是如此的。

如果你对如何养成习惯感兴趣的话，可以深入看看这本书。或者《微习惯》、《弹性习惯》，都是类似的。

[charlie21]

7. 从不了解架构，不了解设计（设计就是架构）
29. 喜欢过度设计

[Dragonphy]

中了好多，也感谢您的资料分享🎉

[whileFalse]

@zhoudaiyu 他要是开着翻墙打开谷歌就能封神了

[shm7]

我做深度学习的，模型部分单元测试真就等同于系统测试…

[hockor]

总结的很好~

[SekiBetu]

这些要求忽略了项目时间要求、家庭，只有初入社会的程序员能做到吧，现在的公司项目要求多少天就要多少天做完，哪有那么多时间给你去思考，能抄别人的想法就抄就完事了

[40EaE5uJO3Xt1VVa]

你说的对

[Turkestan]

你说的对

补充一点：31. 沟通能力极差，比如只会在 v 站发泄情绪

感觉这一点比上面的条条框框都重要

[chendy]

@SekiBetu #22 所以成为低效程序员了啊

[lanlanye]

可是写不写单元测试经常取决于 deadline 怎么破？

[chaleaoch]

我就知道有一本很有名的
深入理解计算机系统
深入理解计算机操作系统 是什么? 有链接吗大佬?

[young1lin]

@chaleaoch 我写错了，就是《深入理解计算机系统》就是那个黑皮书，如果有人把上面的题目全部做完做对了，可以说是深入理解了。

我买的是这个，其实如果认真看，这个不是很难的，一步步来，https://detail.tmall.com/item.htm?id=560961072406&spm=a1z09.2.0.0.459f2e8d3OJGZx&_u=b23btt1t3854

[young1lin]

@Turkestan 是的，要做个积极主动的人，并且要学会有效沟通。后面这个，我正在改，已经写到了下半年的绩效考核中，自我练习以及查看对应书籍，如《金字塔原理》、《卓有成效的管理者》。

[young1lin]

@lanlanye 可以先尝试写一部分，熟练了后，再慢慢累加，到都写。

[ruixue]

“比如用户名很奇怪，经常改变，不同的地方用户名不一样。”

这有什么问题吗？用户名不包含和自己相关的真实固定信息、不同时间 /不同地方使用不同的用户名都是很好的保护自己隐私的习惯，可以大幅降低遭到人肉搜索网络暴力的可能性。怎么就成了“害群之马”了？

难不成大家都从接触互联网开始就决定好一个固定的网络 ID，哪里都用这个，一直用到去世，才能不被归为“害群之马”？

[HytonightYX]

最近做一个新的功能，看到第 29 条突然醒悟到自己是过度设计了，而且在非核心功能上花了太多的时间，感谢楼主

[godpeo]

CRUD 是什么

[WilliamYang]

楼主总结的很厉害，是一个真正会写代码的工程师

[secondwtq]

高质量主题的特点：
木有二维码

[Brentwans]

这些楼主是照着某位同事总结的吗？有些好具体啊。

[BiteTheDust]

感觉太过上纲上线了

[zhoudaiyu]

@whileFalse 是啊 开着代理打开谷歌，然后在谷歌搜索百度，然后点开百度再搜索别的，我服了

[chenyu0532]

中了 1 、28 、30
1：我确实不大喜欢写测试单元，写的也比较少，个人觉得还是打 log 比较好
28：确实没看过操作系统的书。平时工作业务逻辑的东西占了绝大多数，个人觉得设计模式更重要一些，所以平时看的也更多
30：少数时候确实忘了

[hanxiV2EX]

那我就推荐这本书吧

程序员修炼之道：通向务实的最高境界（第 2 版）

[JounQin]

写单元测试这个事儿吧，写 Library 那肯定得写，而且必须 100% coverage，但是写 App ？哪有那么多时间啊，需求天天催，自己天天义务性主动加班可能都来不及，所以先把功能做完，后面有时间了再慢慢加。

[Lemeng]

有些同意，有些有点偏薄

[aLazarus]

关于 CURD 的那一条，我认为楼主想的是，在 CURD 的基础上去寻求突破或者优化。而不是眼睛都不睁开一下就一直在 curd 。
这点我在新公司发现尤为明显，大家都在考虑如何高效并且更高可用性的去优化 curd，这个过程带来的进步是让人享受的。甚至实习生都在问“怎么能把这段代码写的漂亮点”

[TUNGH]

总结的不错

[Saxton]

事实上，只要不被老板压榨什么都好，我这个星期连续上了 7 天班，现在还在上班，加班给所谓有钱的客户开发定制功能，星期五提出需求，星期日就要，你跟我谈什么架构，什么设计模式，直接就是 ifelse 上去了，脱了工期都没得饭吃

[JerryCha]

哈哈哈，楼主快去应聘招银网络科技体验一把 kanban board 带来的效率提升

[EPr2hh6LADQWqRVH]

这帖子这么火难以置信，

这么多人活在臆想里吗


上来就给我单元测试，
你真写过单元测试？
你见识过高效能 HR 办理离职手续的速度吗

[CX]

从最初的热爱到养家糊口，浮躁的行业风气也有一定责任吧？

[datafeng]

学院派？

[ClericPy]

有一说一, 除了 29 条正在改正, 其他的居然几年前就纠正过来了, 这么一想还是挺感谢前东家的

[Brixen]

@young1lin 看了这个系列的其他视频，对我很有启发。谢谢！

[6IbA2bj5ip3tK49j]

为何现在这么流行这一套话术：居高临下指指点点，然后再加上一句“共勉”。

[rus4db]

①感谢分享
②标准是用来要求自己的，不是用来要求别人的
③标准是因人因时因地因事而异的
④要区分“术”与“道”

[winrar]

CSDN 属实垃圾

[index90]

CRUD 怎么无聊啊，CRUD 最难了
读写缓存，分布式事务，一致性
别跟我说什么都依赖 RDBMS

[wtdd]

其实用一个字“菜”就能结束的话题……

[lshero]

虽然说得很好，但是还是很想知道因果关系。

[hyy1995]

某同事读了不知道一本什么书，书中写道：“好的代码是不需要注释的，代码本身就是注释，写注释只会加重负担，因为你代码改了，注释也得改”，然后他自己的代码就真的没有注释……


还好我跟他之间目前没有业务交集，这类人合作起来是真的难受

[hyy1995]

@hyy1995

补充一下，他看的应该是那本《 Clean Code 》。许多人都以为自己的代码很优雅，实际上根本达不到书籍作者的一成功力，业务关键逻辑不加注释的话，别人读了根本狗屁不通。

[Rexviv]

@xgfan 每个人读完文章感受不同，我以及楼里对楼主表示称赞的并没有感受到楼主的居高临下。虽然楼主的总结不适用于所有人，甚至很大可能只适用于包含他在内的少部分人，但是楼主经过总结分享出来让大家参考，是不错的举动。为什么要对其进行阴阳怪气呢？（如果你是因为经常看到带有“共勉”的文章里都是输出自己的观点并强加别人，所以对这类文章感到反感，那么你在别人的贴里输出自己的情绪是不是应该反思“己所不欲，勿施于人”）
为楼主鸣不平确实有点越俎代庖，我也不想引起一场骂战，我没有针对你的意思，但是“居高临下”真的很刺眼。

[zhuzhibin]

看完了 开始焦虑了 卷

[6IbA2bj5ip3tK49j]

@Rexviv 低能效都让 lz 定义完了。这还站的不高？
你没感受到那是你的事。再说了，我也没阴阳怪气啊。

[auh]

书中写到，认真耕地，你就是牛

[Rexviv]

@xgfan 首先，我关注的重点在于他分享出来可以供大家参考，你关注的重点是他凭什么有资格进行这样的定义。在这方面，楼主到底是自我感觉良好才发出来以博关注，或者发出来用以分享自己的感悟，我不得而知。但你说得对的一点是，每个人都有自己的感受，我修为还是不够回复了你。你就当我没回复过你，仅仅只表达了“我没感到楼主居高临下，感谢分享”。

[crclz]

个人认为，最重要的书籍是 DDD 、IDDD （ lz 也提到了）；再配上足够的实践量和回顾书籍（看很多遍）。
基于这些你才有可能 clean code 、clean architecture 、tdd 、能够写单元测试、避免过度设计、减少单个函数行数……

[zoharSoul]

自相矛盾 没啥意义.
建议写明是后端程序员的感悟

[young1lin]

@hyy1995 我没说 《 Clean Code 》全部接受，如果你看过我下面提到的《设计模式之美》——王争写的，他在里面提到过，好的代码无需注释有点极端了，我也是认同他的话的。我看一本书，是觉得他有可取之处，不是说全部接受的。

[young1lin]

@lshero 根据那基本书，和这些视频（当然不止这些，有些不是特别特别好，我就没发了），还有我以前 /现在，还有我的历任同事（不包含全部）。我写完后，才发现原来这些早有前人总结过了。

我的下半年绩效考核里面，就有 30% 是有效沟通，是我自己写的，这方面我是有待改进的。有些问题我也不是全部都改掉了，但我想写下来，记录下来。正如我发的评论的视频，3 rules to quickly improve your life 最后一个就是 Record Everything，是有效的。

[young1lin]

@WilliamYang 其实，还有待改进

[young1lin]

@xgfan 我只是记录下，就算我不写这些，如果你看了那些书，Review 以前的自己，看看历任同事，抑或是极客的专栏，或许你写得比我更多。

[young1lin]

@xgfan 我没说说已经总结完了，我说了我后面看完这些书后回继续总结的。我只是总结完了我的那部分。

[volvo007]

和乙方打交道还真遇过一个……
因为刚上手任务，又是跨行业，我建议他不要只盯着当前 task 的客户数据看，而是把整体的数据都看一下了解一下数据特点。
一周之后我问看了没有，答曰看了。我随便问了几个数据特征相关的，比如目前有多少客户的数据、有没有特别有特点的（比如周期出现大幅波动），就开始不高兴了。我追问了一下之后居然发火了，反问我看这些东西对当前业务有什么帮助……真牛，干了不到一个月跳槽走了，希望他在下家做得开心。

[jsjjdzg]

已经开始焦虑了，卷起来 😃

[dawdling]

这些其实不仅仅是一个体现在工作上的低效能程序员，就是人本身比较低效能。

[SWALLOWW]

你们卷把，我是咸鱼，看完前两条就不想看了，想点踩，
道理我都懂，可不适合我

[mac20221225]

第 22 条中了

[Akiya]

上班一半以上时间都是在刷手机摸鱼，你是装了监控吗

[iugo]

对于团队

我觉得这几点需要在团队中特别强调:

- 不做任务拆解, 没有记录拆解.
- 不 Review 自己的代码(哪怕是 stage 时稍微看看自己将要提交的内容).
- 不写单元测试.
- 沟通选择口述, 不做文本和图片记录.
- 命名无关紧要.

另外, 这些我也很看重:

- 遇到问题选择忽略, 而不是思考各种可能性及解决方式并且记录.
- 知其然, 不想知其所以然.
- 抵触修改自己或团队内部其他人之前写的代码.