1 .重建是程序员的主力技能。
2 .工作日志可以提高大脑的容量。
3 .使用轮廓仪进行调查之后，脸部最佳化。
4 .软件设计有两种方式。 一种方式是使软件过于简单，显然无缺陷的另一种方式是使软件过于复杂，无明显缺陷。
5 .大多数情况下，建立程序的过程基本上是调试规范的过程。
6 .注释不太高。 消除阿姨那样的“例注”。 满山碎念评论，其实是背景噪音。
7 .一般程序员+谷歌=超级程序员。
8 .软件开发通常还需要90%的开发时间，即使前90%的代码占前90%的开发时间，其馀10%的代码也需要90%的开发时间。
9 .单体测试总是合算的。
10 .不要先写框架，然后再写实现。 相反，最好从原型中提取帧。
11 .代码结构清晰，其它问题不存在。
12 .在数小时内制定计划，可以节省数周的编程时间。
13 .良好的项目风格是硬派的，测试、发表、布局是一键的腐朽项目天生猥亵，口口相传，不说话，神秘。
14 .代码不怕变化，要拥抱变化。
15 .任何傻瓜都能写出电脑能理解的代码。 好的程序员可以写人能读的代码
16 .常时充电。 程序员只有一个死法:土地死了。
17 .编程，隔离是方向，名字是重要的，测试是主角，调试是补充，版本控制是后悔药。
18. C语言容易给你出错c :￣222222222222222222222222222
19 .一行编码一名士兵。 只有实行建设制，才有战斗力。 工作场所规模不能太大，千人班，万人班容易成为万人坑。
20 .如果喜欢基础开发的话，不要勉强自己做VC，找到你最真实的想法。 程序员最不能忍受的是万精油。
21 .重建/优化/修复错误，同时只能有一个。
22 .简单模块注意包，复杂模块注意层次。
23 .人脑的性能有限，清洁优于杂乱。 阅读无法读取的代码并组织格式。如果您不想使用的接口，请尝试重新封装。
24 .迭代速度决定了工作强度。 想节约多快，始于简化开发过程，加快反复速度。
25 .忘记优化的写入代码。 过早的优化忘记与恶意破坏同等的代码进行优化。 优化基于性能测试，而不是字符行距。
26 .世界上只有两种编程语言。 一个总是挨骂，另一个决不用
27 .最好的工具是纸笔，其次是markdown。
28. leader问了任务时间，但是如果不能回答的话，任务的分割可能还不够。
29 .调试第一次看到的代码比写代码难一倍。
30 .倒不如多算一周，估计一天。 太“乐观”容易让老板吃惊。
31 .尝试解决无法理解的问题会导致复杂化。
32 .最有用的语言是English。 接下来可能是Python。
百闻不如一见。 一画结果，一目了然。 大大缩短了调试时间。
34 .质量、速度、廉价，选择其中两种。
35 .资源、代码必须一起进行版本控制。 与代码匹配错误相比，资源匹配错误更难以排除。
36 .不要根据想象开发，要根据原型开发。 原型的价值是快速检验想法，节省时间。
37 .生命太短，不得制造任何人不愿意的东西。
38 .序列化优先明文文本。 根据需要添加二进制文件、模糊、加密、压缩等。
39 .高质量代码对程序本身是最好的注释。
40 .编译器总是知道微观优化。 只能往不擅长的方向努力。
41 .你们大多熟悉程序员的美德，有三种。 那是懒惰、急躁和傲慢
42 .不要做太大、太远、太细致的计划。 决定也没用。
43 .至少有一半的时间花在整合上。 时间、时间和时间总是不够。
44 .用代码行数衡量开发进展。 就像用重量来衡量飞机制造的进展一样。
45 .作为一个程序员，忧郁的事情是即使面对代码块也无法修改。 更糟糕的是，这个代码块是自己写的。
46 .违反主流意见/方法/风格/习惯的，首先要考虑自己最可靠。
47 .如果bug出现，不管它是不是你的。 这可以激增你的业务能力，使个人形象急剧上升，如果你的错误被别人抓住……啊，你会被动的
48 .说什么也说不出来，有能力的话请给我看看你的代码
49 .不知道如何选择技术书时，请选择薄的。 至少不太贵，能读完。
50 .选择语言意味着也选择了技术和社区组。
51. git是最好的。 简单、可靠、免费。
52 .只主张"可预测的非合理性"。
53 .没有比空代码执行得更快的代码。
54. UNIX很简单。 但是，理解这种简单需要有才能的人。
55. Log写时间和分类。 必须能够重定向输出。
56 .评论是一份稍差的文件。 更好的名字是很清楚的。 在代码中讲述自己的故事。
57 .软件必须在可重复使用之前使用。
58 .想在你的代码中找到错误的时候，那很难。想到代码没有错误的话很难。
59 .制造车轮是很好的锻炼方法。 假设你看过其他车轮。
60 .我们世界上的一个问题是，愚人相信誓旦，智人怀疑满腹狐狸。
61. C程序员永远不会毁灭。 他们只是cast变成了void。
62 .是需要软件质量，还是需要指针算法，两者不能兼顾。
63. code review优选组/对的形式。 只要了解了业务，建议就更有价值(但不是绝对的)。 不会成为负担。 管理者个人的评论容易成为团队的瓶颈。
64 .如果debugging是消灭bug的过程，编程一定是放bug的过程。
65 .在提问前进行调查。 在这一点上受到鄙视，没有听说在浪费自己的时间。
66 .软件工程的目标不是通过控制复杂性来增加复杂性。
67 .控制的复杂性是计算机编程的本质
68 .计算机科学领域的所有问题可以用其他方法间接解决。
69 .这不是一个错误，这只是未列出的特性。
70 .切勿轻视程序媛
程序设计学习数据的获取方法:
转送文章+私人信【资料】接收的方式