{讨论}The TL Test: 12 Steps to Better Programmer
224 views
Skip to first unread message
pongba
Nov 30, 2009, 10:39:54 PM11/30/09
to TopLanguage
相信很多人知道 "Joel关于优质代码的12条测试”吧。
1. 对语言和技术细节的掌握（甚至背诵）——不管实际工作中是否用到那么细。
2. 对项目经验的询问——这类问题似乎总是容易忽悠，难以问出实质的东西。
3. 部分底层知识。——随着各类平台架构越来越成熟，底层知识的市场也在缩水（做平台的厂家应该会大浪淘沙剩下有限的几个），能迅速敏捷吸收新知识并解决实际问题的程序员应该会越来越受欢迎。
4. 学历。
但是，这几点在以前还是有一定道理的，但是越来越显得过时。所以想和大家讨论讨论，现如今究竟怎么才能算是一个优质码农 :) 并给出明确的准则。
我试着给出几个，不分优先级：
1. 你是否经常关心新技术的进展。（细分：Amazon上的新书，Reddit上的新话题，国外著名技术博客，以及你所专注的技术领域最大的社区的动静）
2. 你是否每两个月阅读一本好的技术书籍。（你是怎样判断一本技术书籍值不值得读的？）
3. 你是否经常查Wikipedia。
4. 你是否阅读《Code Complete》，《The Pragmatic Programmer》 （大家继续补充）
5. 你在编写代码的时候是否关心可读性，可维护性，还只是实现功能便万事大吉。
6. 你经常阅读别人的代码吗？（开源库？）你会阅读自己以前写的代码吗？
7. 你有过花上半天甚至一天时间苦思冥想一个问题最终想出答案的经历吗。（比如 debug。）
8. 你怎么度过大学生活的？
9. 你在你所关注的技术领域的最大社区发过帖子吗？参与过讨论吗？
10. 遇到问题你一般是怎么解决的？
11. 身在这个领域，你感到总是有新的乐趣和挑战吗？
因为我工作不久，所以很多问题带有面向刚工作的应届生的意味，这里有丰富工作经验的老兵请补充 :)
--
刘未鹏(pongba)
Blog | Mind Hacks
http://mindhacks.cn
TopLanguage
http://groups.google.com/group/pongba
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
1. 对语言和技术细节的掌握（甚至背诵）——不管实际工作中是否用到那么细。
2. 对项目经验的询问——这类问题似乎总是容易忽悠，难以问出实质的东西。
3. 部分底层知识。——随着各类平台架构越来越成熟，底层知识的市场也在缩水（做平台的厂家应该会大浪淘沙剩下有限的几个），能迅速敏捷吸收新知识并解决实际问题的程序员应该会越来越受欢迎。
4. 学历。
但是，这几点在以前还是有一定道理的，但是越来越显得过时。所以想和大家讨论讨论，现如今究竟怎么才能算是一个优质码农 :) 并给出明确的准则。
我试着给出几个，不分优先级：
1. 你是否经常关心新技术的进展。（细分：Amazon上的新书，Reddit上的新话题，国外著名技术博客，以及你所专注的技术领域最大的社区的动静）
2. 你是否每两个月阅读一本好的技术书籍。（你是怎样判断一本技术书籍值不值得读的？）
3. 你是否经常查Wikipedia。
4. 你是否阅读《Code Complete》，《The Pragmatic Programmer》 （大家继续补充）
5. 你在编写代码的时候是否关心可读性，可维护性，还只是实现功能便万事大吉。
6. 你经常阅读别人的代码吗？（开源库？）你会阅读自己以前写的代码吗？
7. 你有过花上半天甚至一天时间苦思冥想一个问题最终想出答案的经历吗。（比如 debug。）
8. 你怎么度过大学生活的？
9. 你在你所关注的技术领域的最大社区发过帖子吗？参与过讨论吗？
10. 遇到问题你一般是怎么解决的？
11. 身在这个领域，你感到总是有新的乐趣和挑战吗？
因为我工作不久，所以很多问题带有面向刚工作的应届生的意味，这里有丰富工作经验的老兵请补充 :)
--
刘未鹏(pongba)
Blog | Mind Hacks
http://mindhacks.cn
TopLanguage
http://groups.google.com/group/pongba
pongba
Nov 30, 2009, 10:41:37 PM11/30/09
to TopLanguage
忽然想到，这些问题很有点测试 "12 steps to a better Geek"的意思，呵呵。
2009/12/1 pongba <pon...@gmail.com>
1. 你是否经常关心新技术的进展。（细分：Amazon上的新书，Reddit上的新话题，国外著名技术博客，以及你所专注的技术领域最大的社区的动静）
2. 你是否每两个月阅读一本好的技术书籍。（你是怎样判断一本技术书籍值不值得读的？）
3. 你是否经常查Wikipedia。
4. 你是否阅读《Code Complete》，《The Pragmatic Programmer》 （大家继续补充）
5. 你在编写代码的时候是否关心可读性，可维护性，还只是实现功能便万事大吉。
6. 你经常阅读别人的代码吗？（开源库？）你会阅读自己以前写的代码吗？
7. 你有过花上半天甚至一天时间苦思冥想一个问题最终想出答案的经历吗。（比如 debug。）
8. 你怎么度过大学生活的？
9. 你在你所关注的技术领域的最大社区发过帖子吗？参与过讨论吗？
10. 遇到问题你一般是怎么解决的？
11. 身在这个领域，你感到总是有新的乐趣和挑战吗？
sagasw
Dec 1, 2009, 12:03:55 AM12/1/09
to pon...@googlegroups.com
Pongba给出来的有些松散，比如8，10，11其实已经超过了一个programmer的范畴。
我们公司（罗克韦尔）的logo上有三个单词，我觉得算是解决问题的common rule：
listen，think，solve。
对于任何一个好的程序员来说，他解决bug、完成features、设计架构，都差不多是基于这三个词。在解决问题的同时，也要总结问题，防止在同一个地方反复跌倒。
另外不断学习以及掌握最新技术发展趋势也是程序员需要的，包括学习英语日语韩语，订阅maillist、blog以及浏览各大网站，学习视频教程、书籍、文档、论文等等。
我建议可以在groups主页创建一个How-to的wiki页面，使用SMART方式自己制定自己的目的、实现方式、计划等等，真正做到可用。http://en.wikipedia.org/wiki/SMART_criteria
我们公司（罗克韦尔）的logo上有三个单词，我觉得算是解决问题的common rule：
listen，think，solve。
对于任何一个好的程序员来说，他解决bug、完成features、设计架构，都差不多是基于这三个词。在解决问题的同时，也要总结问题，防止在同一个地方反复跌倒。
另外不断学习以及掌握最新技术发展趋势也是程序员需要的，包括学习英语日语韩语，订阅maillist、blog以及浏览各大网站，学习视频教程、书籍、文档、论文等等。
我建议可以在groups主页创建一个How-to的wiki页面，使用SMART方式自己制定自己的目的、实现方式、计划等等，真正做到可用。http://en.wikipedia.org/wiki/SMART_criteria
2009/12/1 pongba <pon...@gmail.com>
sagasw
Dec 1, 2009, 12:17:10 AM12/1/09
to pon...@googlegroups.com
smart单词含义：基本上外企都有类似的年度评估。我们可以自己建立一个更实用的，类似年初wishlist的列表。
S=Specific具体性
M=Measurable可量性
A=Attainable可实现性
R=Realistic现实性
T=Time bound时限性
另外试着答一答pongba的问题：
1. 你是否经常关心新技术的进展。（细分：Amazon上的新书，Reddit上的新话题，国外著名技术博客，以及你所专注的技术领域最大的社区的动静）
2. 你是否每两个月阅读一本好的技术书籍。（你是怎样判断一本技术书籍值不值得读的？）
能拿到0.5吧，看的少多了。
3. 你是否经常查Wikipedia
Y
能拿到0.5吧，看的少多了。
3. 你是否经常查Wikipedia
Y
4. 你是否阅读《Code Complete》，《The Pragmatic Programmer》 （大家继续补充）
Y
5. 你在编写代码的时候是否关心可读性，可维护性，还只是实现功能便万事大吉。
Y，另外对于代码也会做反复重构，因为每个时期的可读性、可维护性的理解不太一样。
6. 你经常阅读别人的代码吗？（开源库？）你会阅读自己以前写的代码吗？
Y，最近在读Lua。
7. 你有过花上半天甚至一天时间苦思冥想一个问题最终想出答案的经历吗。（比如 debug。）
Y，如果一天两天没有思路。可以跟他人一起讨论，另外可以让脑袋放空一阵。
8. 你怎么度过大学生活的？
N，我想这个问题的本意是你觉得大学生活过的有没有意义吧。有一些收获，但是不明显。
9. 你在你所关注的技术领域的最大社区发过帖子吗？参与过讨论吗？
Y
10. 遇到问题你一般是怎么解决的？
这个问题可以缩小范围到”编程问题“么？一般是
1）试图重现，简化问题过程，抓住问题关键步骤，
2）查看相关代码、文档。
3）Trace/Debug，
4）查找在线帮助或者Google有无类似问题的解决方案。
5）试图自己解决
6）问其他专家，或者在专业论坛发帖。
11. 身在这个领域，你感到总是有新的乐趣和挑战吗？
Y，虽然我做的是桌面软件，但现在web开发是主流，正在学习ROR。5. 你在编写代码的时候是否关心可读性，可维护性，还只是实现功能便万事大吉。
Y，另外对于代码也会做反复重构，因为每个时期的可读性、可维护性的理解不太一样。
6. 你经常阅读别人的代码吗？（开源库？）你会阅读自己以前写的代码吗？
Y，最近在读Lua。
7. 你有过花上半天甚至一天时间苦思冥想一个问题最终想出答案的经历吗。（比如 debug。）
Y，如果一天两天没有思路。可以跟他人一起讨论，另外可以让脑袋放空一阵。
8. 你怎么度过大学生活的？
N，我想这个问题的本意是你觉得大学生活过的有没有意义吧。有一些收获，但是不明显。
9. 你在你所关注的技术领域的最大社区发过帖子吗？参与过讨论吗？
Y
10. 遇到问题你一般是怎么解决的？
这个问题可以缩小范围到”编程问题“么？一般是
1）试图重现，简化问题过程，抓住问题关键步骤，
2）查看相关代码、文档。
3）Trace/Debug，
4）查找在线帮助或者Google有无类似问题的解决方案。
5）试图自己解决
6）问其他专家，或者在专业论坛发帖。
11. 身在这个领域，你感到总是有新的乐趣和挑战吗？
2009/12/1 sagasw <sag...@gmail.com>
Fuzhou Chen
Dec 1, 2009, 12:30:02 AM12/1/09
to pon...@googlegroups.com
我补几条测试专用的吧，别的我也不会。
1. 你做测试计划么？
2. 你能够总结一些对特定功能代码需要的基础测试用例集合么？例如，对字符串缓冲区的操作代码总是需要给出一定的边界测试。
3. 你能够指出测试计划中每一个测试用例与产品功能点的对应关系么？
4. 你能清楚地解释每一个测试计划的目的么？例如，为什么你的产品需要或不需要压力测试（或其他）。
5. 你能够指出你的产品进行测试需要的工具和资源要求么？比如多少台机器，集线器或路由器，100M或1KM网卡，何种的网络拓扑等等。
6. 进行性能测试时，你能给出定量的性能测试标准么？
7. 在设计测试自动化工具时，你能够定量地指出自动化节约了多少人力或设备资源么？
8. 你使用代码覆盖率统计测试漏洞么？
9. 你是否主动使用单元测试或者fault injection等手段用于测试错误处理代码？
10. 如果你的你的产品需要与第三方软件交互，你能够给出典型的测试用例么？
11. 你是否在测试计划中包含国际化和本地化的测试用例？
12. 当产品代码发生改变时，你能指出哪些测试用例需要重新运行么？
13. 当时间和资源不允许的情况下，你能解释并确定一个经过裁减的最小化方案保证基本的测试质量么？
2009/11/30 pongba <pon...@gmail.com>
--
《采莲》·江南
为卿采莲兮涉水，为卿夺旗兮长战。为卿遥望兮辞宫阙，为卿白发兮缓缓歌。
另抄自蒜头的评论：http://www.douban.com/review/1573456/：
且祭一束紫琳秋，为一段落花流水的传说
且饮一杯青花酒，为一场几多擦肩的错过
且焚一卷旖旎念，为一腔抛付虚无的惜怜
且歌一曲罢箜篌，为一刻良辰春宵的寂寞
Fei Yan
Dec 1, 2009, 8:04:27 AM12/1/09
to pon...@googlegroups.com
sagasw提到的宝贵经验非常有借鉴意义，应该是关于Self management的范畴，属于common sense；不管做什么都会用得上。
这些方法和原理在不同的应用领域里边运用的比较好，都更容易在对应的领域里取得更大的成功。
从这个意义上来说，a good programmer should also be a good employee in general.
从我个人的经验来看，其实我们这一行对于个人有计划的学习、自我提高的要求是比其它行业要高的；
至少不思主动进取，除了工作相关的的东西之外不主动拓宽自己知识面的行为容易更快的摸到自己的天花板。
其实pongba在自己博客里边曾经提到的一种做法：
经常主动学习自己将来可能会用到的东西而不是等需要用的时候才去学（原话可能不是如此，但印象中大意应该如此）
我觉得这一条会对很多人都有益处（至少我自己是产生了深深的共鸣）；能坚持下去就很容易积少成多。
从我自己这几年的工作来看，从被别人面试、招聘到慢慢开始参与到招聘别人、面试别人的过程中，candidates之间的沟通和比较，这方面的差异似乎很容易造成结果上的明显差异。
对于其他行业而言，我觉得这一条可能是一个可选要求，但是对于professional programmer而言，倒是一个必须的基本技能。
这些方法和原理在不同的应用领域里边运用的比较好，都更容易在对应的领域里取得更大的成功。
从这个意义上来说，a good programmer should also be a good employee in general.
从我个人的经验来看，其实我们这一行对于个人有计划的学习、自我提高的要求是比其它行业要高的；
至少不思主动进取，除了工作相关的的东西之外不主动拓宽自己知识面的行为容易更快的摸到自己的天花板。
其实pongba在自己博客里边曾经提到的一种做法：
经常主动学习自己将来可能会用到的东西而不是等需要用的时候才去学（原话可能不是如此，但印象中大意应该如此）
我觉得这一条会对很多人都有益处（至少我自己是产生了深深的共鸣）；能坚持下去就很容易积少成多。
从我自己这几年的工作来看，从被别人面试、招聘到慢慢开始参与到招聘别人、面试别人的过程中，candidates之间的沟通和比较，这方面的差异似乎很容易造成结果上的明显差异。
对于其他行业而言，我觉得这一条可能是一个可选要求，但是对于professional programmer而言，倒是一个必须的基本技能。
2009/12/1 sagasw <sag...@gmail.com>
图灵刘江
Dec 1, 2009, 2:04:25 PM12/1/09
to TopLanguage
图灵刘江
Dec 1, 2009, 2:08:00 PM12/1/09
to TopLanguage
关于2.你是怎样判断一本技术书籍值不值得读的？
在SD大会我主持的那个软技能沙龙上，两位嘉宾唐赓和张银奎就起了争执。
唐说，读得懂、读得进去的才是好书。而张则坚持好书往往是比较难读的。
4. 你是否阅读《Code Complete》，《The Pragmatic Programmer》
我认为对于程序员，至少《重构》、《编程珠玑》和《人月神话》也是不可少的。
sagasw
Dec 1, 2009, 7:30:59 PM12/1/09
to pon...@googlegroups.com
背景不同，想到的問題，看到的現象，得出的結論也是不同的。
我google了一下唐賡，應該是這位”曦力软件 CTO 唐赓“吧，作為CTO，務實最重要。
而张银奎他作為intel的高級工程師，明顯平時做的是類似科研工作。
寫過論文的朋友都知道，劣質論文的特點就是難讀，亮點不過一下下而已，前後的都是敷衍。
好書難讀，我是不認同的。
我也是工程師，但不是张银奎這樣的科研工程師，只是做項目的，平時做的東西也不需要晦澀難懂。
比如《The Pragmatic Programmer》這樣淺顯的，或者Code Complete大全式的書，都不能算是難懂。
判斷技術書籍值不值得讀（對於劉江，更重要的應該是值不值得買吧？），步驟很簡單，
1看目錄，2看作者，3看出版社，4看譯者
我google了一下唐賡，應該是這位”曦力软件 CTO 唐赓“吧，作為CTO，務實最重要。
而张银奎他作為intel的高級工程師，明顯平時做的是類似科研工作。
寫過論文的朋友都知道，劣質論文的特點就是難讀，亮點不過一下下而已，前後的都是敷衍。
好書難讀，我是不認同的。
我也是工程師，但不是张银奎這樣的科研工程師，只是做項目的，平時做的東西也不需要晦澀難懂。
比如《The Pragmatic Programmer》這樣淺顯的，或者Code Complete大全式的書，都不能算是難懂。
判斷技術書籍值不值得讀（對於劉江，更重要的應該是值不值得買吧？），步驟很簡單，
1看目錄，2看作者，3看出版社，4看譯者
2009/12/2 图灵刘江 <liuj....@gmail.com>
莫华枫
Dec 1, 2009, 8:55:14 PM12/1/09
to pon...@googlegroups.com
2009/12/1 pongba <pon...@gmail.com>
忽然想到，这些问题很有点测试 "12 steps to a better Geek"的意思，呵呵。2009/12/1 pongba <pon...@gmail.com>1. 你是否经常关心新技术的进展。（细分：Amazon上的新书，Reddit上的新话题，国外著名技术博客，以及你所专注的技术领域最大的社区的动静）
2. 你是否每两个月阅读一本好的技术书籍。（你是怎样判断一本技术书籍值不值得读的？）
3. 你是否经常查Wikipedia。
4. 你是否阅读《Code Complete》，《The Pragmatic Programmer》 （大家继续补充）
5. 你在编写代码的时候是否关心可读性，可维护性，还只是实现功能便万事大吉。
6. 你经常阅读别人的代码吗？（开源库？）你会阅读自己以前写的代码吗？
7. 你有过花上半天甚至一天时间苦思冥想一个问题最终想出答案的经历吗。（比如 debug。）
8. 你怎么度过大学生活的？
9. 你在你所关注的技术领域的最大社区发过帖子吗？参与过讨论吗？
10. 遇到问题你一般是怎么解决的？
11. 身在这个领域，你感到总是有新的乐趣和挑战吗？
这是我们小组挑人的标准嘛。
--
反者道之动，弱者道之用
longsh...@gmail.com
http://blog.csdn.net/longshanks/
wave开通
Fei Yan
Dec 1, 2009, 11:36:08 PM12/1/09
to pon...@googlegroups.com
我发现一个有意思的现象：
和这些要求符合的程度与实际年龄基本成反比。
30岁以上的programmer，符合的条件数基本比26岁的要少很多；30+的则更少。。。
也许就是这些决定了在中国生存的职业programmer 是否会遇到年龄上的麻烦。
满足这些要求和能够加多少班干活关联度甚小。
和这些要求符合的程度与实际年龄基本成反比。
30岁以上的programmer，符合的条件数基本比26岁的要少很多；30+的则更少。。。
也许就是这些决定了在中国生存的职业programmer 是否会遇到年龄上的麻烦。
满足这些要求和能够加多少班干活关联度甚小。
2009/12/2 莫华枫 <longsh...@gmail.com>
pongba
Dec 2, 2009, 1:12:57 AM12/2/09
to pon...@googlegroups.com
这个话题，大家再参与参与哈，说不定我们能整出一个实用的12条规则来。对这里需要找人的朋友有帮助，对需要入行的朋友也有帮助。
Kenny Yuan
Dec 2, 2009, 2:16:49 AM12/2/09
to pon...@googlegroups.com
感觉这辩题，很像是电视大专辩论会，最后的结果八成是不比知识和逻辑，专比“气场”，哈哈
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL1: http://csbabel.wordpress.com/
URL2: http://blog.csdn.net/yuankaining/
2009/12/2 图灵刘江 <liuj....@gmail.com>
在SD大会我主持的那个软技能沙龙上，两位嘉宾唐赓和张银奎就起了争执。
唐说，读得懂、读得进去的才是好书。而张则坚持好书往往是比较难读的。
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL1: http://csbabel.wordpress.com/
URL2: http://blog.csdn.net/yuankaining/
Kenny Yuan
Dec 2, 2009, 2:29:44 AM12/2/09
to pon...@googlegroups.com
再多说一句，引文中的这种对立观点的形成，往往不是经过双方的深思熟虑的。比如，某一个人刚刚说完一句话，另一个人立即就插嘴说“不见得”，于是两人立马就杠上了，而且一杠起来就没完了……
——以上场景常见于各种大大小小的会议。
——以上场景常见于各种大大小小的会议。
2009/12/2 Kenny Yuan <yuank...@gmail.com>
Kenny Yuan
Dec 2, 2009, 2:34:53 AM12/2/09
to pon...@googlegroups.com
似乎又跑题了，为了救赎，贴一个最近写的东西吧，这个和主题有点相关。
这是你应该做的（draft）
——“阿姨！你的钱包掉了！”
——“谢谢你！小朋友！你真是一个心灵高尚的人！”
——“不用谢！这是我应该做的，我的名字叫少先队员……”（伴随着一串银铃般地笑声，小朋友消失在风里，没有留下姓名……）
嗯，我承认这是恶搞了一把那个年代的小学生作文——韩寒出现之前的那种小学生作文。这种作文中有一个隐含的前提：“拾金不昧、做好事不留姓名”这种事情，在那个时代的背景下，会被判断为“这是我应该做的”。
那么，在换了一个时代背景之后，什么才是“你应该做的”呢？
在一个特定的职业中（比如与我这个BLOG相关的“码农”职业），什么才是“你应该做的”呢？
好吧，现在我们就假设你是一个码农：
你精通各种算法，宰杀了无数遍“猪”与“鸡”（珠与玑），对RBTree/BSPTree/SuffixTree/HashTree的原理和应用张口就来；你会估计和比较各种算法的O/Θ/Ω/OO；你知道如何深入浅出地讲解算法，知道如何编程实现和实测表现，你还能够在实际工作中选用正确的算法……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你精通不少语言，也精通一些很“难”的语言中的很“讨厌”的特性，比如C++中的重载决议/偏模板特化/名字空间/多继承/etc，你还能够紧追语言的“最新发展”，对GC/closure/multimethod/Continuation/AMB这些“新发明”东西了如指掌（嗯，好吧，其实这些不是新的，只是从LISP那里借鉴了一下下）……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你懂得多数流行平台的开发，掌握多数开发包的API；你能够使用各种辅助工具进行综合、高效地调试；在解决问题时你有丰富的经验和清醒的头脑，以及实证至上的谨慎；你对开发/profiling/testing有良好的理解和实践，模式/重构/TDD/etc对你来说是合手的工具而不是限制你的牢笼……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你了解不同用户的兴趣在哪里、对软件错误的容忍度有多高，你知道不同设备上的用户习惯于如何操作，你知道用户愿意在哪个功能上掏钱，你懂得如何借鉴和超越竞争对手的产品，你能够跟上当前用户对功能的期望（甚至预见到未来的）……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你了解可用性的意义，能够设计出有条理、不凌乱的界面，还能够使用PS/AI/Painter制作并用程序实现你的设计……那么，你觉得自己很优秀，还是说“这是你应该做的”？（另，引用：说一个软件具有“可用性”，能算是一种赞美吗？只是合格罢了！）
你精通计算机原理结构，知道各种外设的IO速度，对它们访问方式有精晰的理解，会写device driver，而且你还知道典型外设产品的可靠性在什么样的数量级上……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你设计过不同规模的系统，知道在什么样的级别下应该使用什么样的技术；你知道性能热点通常在哪里，也精通于查找和解决热点；你知道如何平衡功能、时间和质量，知道如何在特定情况下取舍；你知道流行的架构的优缺点，你知道哪种硬件能够构成什么样的系统、当机时间控制在什么样的级别上；你知道如何安排指标去区分高低端产品，知道在给定的预算/成本下能够提供什么样的产品，你还知道如何对系统进行cost down却不会损失可靠性……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你熟悉各种软件开发模式；你有丰富的知识积累，却又不守旧、勇于接受新鲜事物；你非常善于开会，能够在很短的时间内取消语言表面上的分歧让大家达成一致……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你勤劳肯做，工作中不偷奸耍滑，很有大局观而且也重视细节问题；你性格温和，乐于助人，团队成员都说你是一个非常好相处的人，连没见过面的同事也对你赞不绝口……那么，你觉得自己很优秀，还是说“这是你应该做的”？
……
你能够……能够……还能够……即使在…的时候也能够……那么，你觉得自己很优秀，还是说“这是你应该做的”？
……
如果你做到了以上若干条，那么在我看来，你成功地完成了你自己的本职工作，完成了自己做为一个工程师（而不是科学家）的“应该做的事情”——也许你比身边人的平均水平要高出一截，也许你超过了整个业界的平均水平，但那是不是就意味着“优秀”呢？如果那仅仅是你“应该做到的”呢？
最后，你做为一名人类，能够进行独立的思考，在清晰逻辑和丰富知识的基础上拥有批判性的思维，你懂经济、懂民主；你不愤青、不脑残、不意淫、不从众；你不受洗脑和煽动的影响、不信武术和中医……那么，你觉得自己很优秀，还是说“这是你应该做的”？
延伸阅读
（下面的每一个链接都能对应到上面文章里的某句话，用来例证，而不是证明）
Teach Yourself Programming in Ten Years, by Peter Norvig http://norvig.com/21-days.html
快排为什么那样快, by Pongba http://mindhacks.cn/2008/06/13/why-is-quicksort-so-quick/
Beating The Averages, by Paul Graham http://www.paulgraham.com/avg.html
http://www.xys.org/xys/ebooks/others/science/dajia10/zhongyi2621.txt
这是你应该做的（draft）
——“阿姨！你的钱包掉了！”
——“谢谢你！小朋友！你真是一个心灵高尚的人！”
——“不用谢！这是我应该做的，我的名字叫少先队员……”（伴随着一串银铃般地笑声，小朋友消失在风里，没有留下姓名……）
嗯，我承认这是恶搞了一把那个年代的小学生作文——韩寒出现之前的那种小学生作文。这种作文中有一个隐含的前提：“拾金不昧、做好事不留姓名”这种事情，在那个时代的背景下，会被判断为“这是我应该做的”。
那么，在换了一个时代背景之后，什么才是“你应该做的”呢？
在一个特定的职业中（比如与我这个BLOG相关的“码农”职业），什么才是“你应该做的”呢？
好吧，现在我们就假设你是一个码农：
你精通各种算法，宰杀了无数遍“猪”与“鸡”（珠与玑），对RBTree/BSPTree/SuffixTree/HashTree的原理和应用张口就来；你会估计和比较各种算法的O/Θ/Ω/OO；你知道如何深入浅出地讲解算法，知道如何编程实现和实测表现，你还能够在实际工作中选用正确的算法……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你精通不少语言，也精通一些很“难”的语言中的很“讨厌”的特性，比如C++中的重载决议/偏模板特化/名字空间/多继承/etc，你还能够紧追语言的“最新发展”，对GC/closure/multimethod/Continuation/AMB这些“新发明”东西了如指掌（嗯，好吧，其实这些不是新的，只是从LISP那里借鉴了一下下）……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你懂得多数流行平台的开发，掌握多数开发包的API；你能够使用各种辅助工具进行综合、高效地调试；在解决问题时你有丰富的经验和清醒的头脑，以及实证至上的谨慎；你对开发/profiling/testing有良好的理解和实践，模式/重构/TDD/etc对你来说是合手的工具而不是限制你的牢笼……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你了解不同用户的兴趣在哪里、对软件错误的容忍度有多高，你知道不同设备上的用户习惯于如何操作，你知道用户愿意在哪个功能上掏钱，你懂得如何借鉴和超越竞争对手的产品，你能够跟上当前用户对功能的期望（甚至预见到未来的）……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你了解可用性的意义，能够设计出有条理、不凌乱的界面，还能够使用PS/AI/Painter制作并用程序实现你的设计……那么，你觉得自己很优秀，还是说“这是你应该做的”？（另，引用：说一个软件具有“可用性”，能算是一种赞美吗？只是合格罢了！）
你精通计算机原理结构，知道各种外设的IO速度，对它们访问方式有精晰的理解，会写device driver，而且你还知道典型外设产品的可靠性在什么样的数量级上……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你设计过不同规模的系统，知道在什么样的级别下应该使用什么样的技术；你知道性能热点通常在哪里，也精通于查找和解决热点；你知道如何平衡功能、时间和质量，知道如何在特定情况下取舍；你知道流行的架构的优缺点，你知道哪种硬件能够构成什么样的系统、当机时间控制在什么样的级别上；你知道如何安排指标去区分高低端产品，知道在给定的预算/成本下能够提供什么样的产品，你还知道如何对系统进行cost down却不会损失可靠性……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你熟悉各种软件开发模式；你有丰富的知识积累，却又不守旧、勇于接受新鲜事物；你非常善于开会，能够在很短的时间内取消语言表面上的分歧让大家达成一致……那么，你觉得自己很优秀，还是说“这是你应该做的”？
你勤劳肯做，工作中不偷奸耍滑，很有大局观而且也重视细节问题；你性格温和，乐于助人，团队成员都说你是一个非常好相处的人，连没见过面的同事也对你赞不绝口……那么，你觉得自己很优秀，还是说“这是你应该做的”？
……
你能够……能够……还能够……即使在…的时候也能够……那么，你觉得自己很优秀，还是说“这是你应该做的”？
……
如果你做到了以上若干条，那么在我看来，你成功地完成了你自己的本职工作，完成了自己做为一个工程师（而不是科学家）的“应该做的事情”——也许你比身边人的平均水平要高出一截，也许你超过了整个业界的平均水平，但那是不是就意味着“优秀”呢？如果那仅仅是你“应该做到的”呢？
最后，你做为一名人类，能够进行独立的思考，在清晰逻辑和丰富知识的基础上拥有批判性的思维，你懂经济、懂民主；你不愤青、不脑残、不意淫、不从众；你不受洗脑和煽动的影响、不信武术和中医……那么，你觉得自己很优秀，还是说“这是你应该做的”？
延伸阅读
（下面的每一个链接都能对应到上面文章里的某句话，用来例证，而不是证明）
Teach Yourself Programming in Ten Years, by Peter Norvig http://norvig.com/21-days.html
快排为什么那样快, by Pongba http://mindhacks.cn/2008/06/13/why-is-quicksort-so-quick/
Beating The Averages, by Paul Graham http://www.paulgraham.com/avg.html
http://www.xys.org/xys/ebooks/others/science/dajia10/zhongyi2621.txt
Tinyfool
Dec 2, 2009, 2:43:08 AM12/2/09
to pon...@googlegroups.com
唉，按照你的要求，咱们就别混了，我连猪和鸡都还没看完呢
--
Tinyfool的开发日记 http://www.tinydust.net/dev/
代码中国网 http://www.codechina.org
myTwitter: http://twitter.com/tinyfool
2009/12/2 Kenny Yuan <yuank...@gmail.com>
--
Tinyfool的开发日记 http://www.tinydust.net/dev/
代码中国网 http://www.codechina.org
myTwitter: http://twitter.com/tinyfool
Mikster.Z
Dec 2, 2009, 3:39:16 AM12/2/09
to pon...@googlegroups.com
这么多应该做的，我kao，看来不该做的事情做多了。
--
EX - EMBEDDED SYSTEM DEVELOPER
SOFTWARE ENGINEER
Name : Mikster
去问问高爷爷，不知道高爷爷会怎么说。
其实俺还觉得问问一个programmer对数学和物理感兴趣否，顺带问问一些相关的小问题，这玩意跟理解力还的相关度还是挺高的。
2009/12/2 Kenny Yuan <yuank...@gmail.com>
--
EX - EMBEDDED SYSTEM DEVELOPER
SOFTWARE ENGINEER
Name : Mikster
liuxinyu
Dec 2, 2009, 4:14:01 AM12/2/09
to TopLanguage
跑题一下。
大公司会不断给员工洗脑，讲process, tools, methods等等
讲values, strategy, vision等等。
并且这些后面还有很多科学的依据，研究成果和方法论在支撑。所以很少有青年学生能幸免不被洗脑的。
并且被洗脑后，会积极主动的研究新的方法论去洗别人的脑....
所以我觉得保持一颗青年学生的“淳朴”的心是一种境界。
我觉得有些人骨子里是学者，应该想想什么才是自己想要的。
可以尝试不要把自己仅仅停在programmer的境界。即使我们白天种地，去挣奶粉钱。但不妨碍我们课余去research去学习。
刘江
Dec 2, 2009, 4:27:26 AM12/2/09
to TopLanguage
精彩，kenny还是有才啊。
ps：你这文章怎么在CSDN博客上没找到？
yinfei yang
Dec 1, 2009, 8:29:35 PM12/1/09
to pon...@googlegroups.com
可能是刚毕业的缘故， 同样带有面向刚工作应届生的味道， 我恰恰觉得第8、11是另我感触最深的， 其中对于刚毕业programmer来说， 8是反映了11的， 因为自己所工作的领域能给自己带来挑战和乐趣， 所以整个大学生活觉得充实，谈到他的时候也会无比激动。
2009/12/1 sagasw <sag...@gmail.com>
alsor zhou
Dec 2, 2009, 1:57:37 AM12/2/09
to pon...@googlegroups.com
没法，屁股决定大脑。 国外有些很牛鼻的hacker在结婚之后也销声匿迹了，要么转型，要么平衡家庭去了。 如果到了30＋，还能保持那么强烈的技术热情，往好了说是业界的楷模，往不好了说是不称职的丈夫老婆，父母，儿女。 这里面不仅仅有金钱的因素:0
------
@veiz : Design is making function beautiful.
Gtalk: alsor...@gmail.com
LinkedIn: http://www.linkedin.com/in/veizhou
------
@veiz : Design is making function beautiful.
Gtalk: alsor...@gmail.com
LinkedIn: http://www.linkedin.com/in/veizhou
2009/12/2 Fei Yan <skyscr...@gmail.com>
sagasw
Dec 2, 2009, 8:19:24 AM12/2/09
to pon...@googlegroups.com
搜索一下to better programmer，发现不少已有的观点。
http://www.google.com/search?hl=en&safe=off&client=firefox-a&rlz=1R1GGGL_zh-CN___CN349&hs=iNp&q=to+Better+Programmer&start=10&sa=N
比如这个书单：
http://www.amazon.com/Become-a-better-programmer/lm/R12NJSAQYBR84Y
在43things上，也有人期待成为一个好的程序员：
http://www.43things.com/things/view/295/become-a-better-programmer
而且有人提出比较可行的步骤：
http://www.43things.com/entries/view/4170551
比较邪乎的是这篇文字
http://samizdat.mines.edu/howto/HowToBeAProgrammer.html
尽管自称是一个简单说明，其实非常非常长。
http://www.codelathe.com/blog/index.php/2009/04/07/5-sure-fire-ways-to-become-better-at-programming/
这篇也可读
http://users.actcom.co.il/~choo/lupg/essays/becoming-a-real-programmer.html
这篇文章的当前版本号1.0.0。
coding horror也有一篇雄文:如何不编程就能成为优秀程序员-（我猜应该是通过吃地瓜来升级）
http://www.codinghorror.com/blog/archives/000543.html
这个算是最可行的，六分钟保你成功！！！
http://www.secretgeek.net/6min_program.asp
http://www.google.com/search?hl=en&safe=off&client=firefox-a&rlz=1R1GGGL_zh-CN___CN349&hs=iNp&q=to+Better+Programmer&start=10&sa=N
比如这个书单：
http://www.amazon.com/Become-a-better-programmer/lm/R12NJSAQYBR84Y
在43things上，也有人期待成为一个好的程序员：
http://www.43things.com/things/view/295/become-a-better-programmer
而且有人提出比较可行的步骤：
http://www.43things.com/entries/view/4170551
比较邪乎的是这篇文字
http://samizdat.mines.edu/howto/HowToBeAProgrammer.html
尽管自称是一个简单说明，其实非常非常长。
http://www.codelathe.com/blog/index.php/2009/04/07/5-sure-fire-ways-to-become-better-at-programming/
这篇也可读
http://users.actcom.co.il/~choo/lupg/essays/becoming-a-real-programmer.html
这篇文章的当前版本号1.0.0。
coding horror也有一篇雄文:如何不编程就能成为优秀程序员-（我猜应该是通过吃地瓜来升级）
http://www.codinghorror.com/blog/archives/000543.html
这个算是最可行的，六分钟保你成功！！！
http://www.secretgeek.net/6min_program.asp
2009/12/2 alsor zhou <alsor...@gmail.com>
yinfei yang
Dec 2, 2009, 4:18:37 AM12/2/09
to pon...@googlegroups.com
windstorm
Dec 2, 2009, 4:09:41 PM12/2/09
to pon...@googlegroups.com
能达到这里所有要求的码农，当一个公司的技术主管问题也不大了吧
----------------------------------------------------------------------------------
Yours Sincerely
Kun
www.forwind.cn
http://twitter.com/lk_517
2009/12/2 Kenny Yuan <yuank...@gmail.com>:
ts
Dec 3, 2009, 9:13:16 PM12/3/09
to pon...@googlegroups.com
补充几个从InfoQ看来的checklist。
题外一下，欧美似乎有这种整理checklist的习惯，类似列表小到买车租房、大到结婚生子都能找到，行动前参考参考一般都能获益。
我想这也是一种黑盒测试的思路，复杂系统如果没法/没条件弄清内部机理，经验地形成一个测试用例集也很不错(再比如工程领域大量的各种常数表)，这应该可以算做几百年工业化下来形成的工程师文化了吧。
allen xu
Dec 4, 2009, 2:08:11 AM12/4/09
to TopLanguage
我估计没有哪个公司的技术主管能达到这个水平。闻道有先后，术业有专攻。人的精力也是有限的，什么都懂都会做那不成超人了。
等你达到这些要求之后，恐怕你身体也垮掉了。实际工作当中，也不需要对什么都精通，知识面可以广，但是你没办法什么都精通。
成功的管理者不是像诸葛亮那样鞠躬尽瘁，事必躬亲，而是善于计划、组织、控制，善于授权，善于挖掘人员的潜能、借助外部力量达成目标，
有很强的人际交往能力、沟通能力和应变能力。
等你达到这些要求之后，恐怕你身体也垮掉了。实际工作当中，也不需要对什么都精通，知识面可以广，但是你没办法什么都精通。
成功的管理者不是像诸葛亮那样鞠躬尽瘁，事必躬亲，而是善于计划、组织、控制，善于授权，善于挖掘人员的潜能、借助外部力量达成目标，
有很强的人际交往能力、沟通能力和应变能力。
On 12月3日, 上午5时09分, windstorm <likunarmstr...@gmail.com> wrote:
> 能达到这里所有要求的码农，当一个公司的技术主管问题也不大了吧
>
> -----------------------------------------------------------------------------------
> Yours Sincerely
> Kun
>
> www.forwind.cnhttp://twitter.com/lk_517
>
> 2009/12/2 Kenny Yuan <yuankain...@gmail.com>:
>
>
>
> > 似乎又跑题了，为了救赎，贴一个最近写的东西吧，这个和主题有点相关。
>
> > 这是你应该做的（draft）
>
> > ----"阿姨！你的钱包掉了！"
> > ----"谢谢你！小朋友！你真是一个心灵高尚的人！"
> > ----"不用谢！这是我应该做的，我的名字叫少先队员......"（伴随着一串银铃般地笑声，小朋友消失在风里，没有留下姓名......）
>
> > 嗯，我承认这是恶搞了一把那个年代的小学生作文----韩寒出现之前的那种小学生作文。这种作文中有一个隐含的前提："拾金不昧、做好事不留姓名"这种事情，在那个-时代的背景下，会被判断为"这是我应该做的"。
>
> > 那么，在换了一个时代背景之后，什么才是"你应该做的"呢？
> > 在一个特定的职业中（比如与我这个BLOG相关的"码农"职业），什么才是"你应该做的"呢？
>
> > 好吧，现在我们就假设你是一个码农：
>
> > 你精通各种算法，宰杀了无数遍"猪"与"鸡"（珠与玑），对RBTree/BSPTree/SuffixTree/HashTree的原理和应用张口就来；你会-估计和比较各种算法的O/Θ/Ω/OO；你知道如何深入浅出地讲解算法，知道如何编程实现和实测表现，你还能够在实际工作中选用正确的算法......那么，你觉得自己-很优秀，还是说"这是你应该做的"？
>
> > 你精通不少语言，也精通一些很"难"的语言中的很"讨厌"的特性，比如C++中的重载决议/偏模板特化/名字空间/多继承/etc，你还能够紧追语言的"最新发-展"，对GC/closure/multimethod/Continuation/AMB这些"新发明"东西了如指掌（嗯，好吧，其实这些不是新的，只是从L-ISP那里借鉴了一下下）......那么，你觉得自己很优秀，还是说"这是你应该做的"？
>
> > 你懂得多数流行平台的开发，掌握多数开发包的API；你能够使用各种辅助工具进行综合、高效地调试；在解决问题时你有丰富的经验和清醒的头脑，以及实证至上的谨-慎；你对开发/profiling/testing有良好的理解和实践，模式/重构/TDD/etc对你来说是合手的工具而不是限制你的牢笼......那么，你觉得自-己很优秀，还是说"这是你应该做的"？
>
> > 你了解不同用户的兴趣在哪里、对软件错误的容忍度有多高，你知道不同设备上的用户习惯于如何操作，你知道用户愿意在哪个功能上掏钱，你懂得如何借鉴和超越竞争对-手的产品，你能够跟上当前用户对功能的期望（甚至预见到未来的）......那么，你觉得自己很优秀，还是说"这是你应该做的"？
>
> > 你了解可用性的意义，能够设计出有条理、不凌乱的界面，还能够使用PS/AI/Painter制作并用程序实现你的设计......那么，你觉得自己很优秀，还是说"这-是你应该做的"？（另，引用：说一个软件具有"可用性"，能算是一种赞美吗？只是合格罢了！）
>
> > 你精通计算机原理结构，知道各种外设的IO速度，对它们访问方式有精晰的理解，会写device
> > driver，而且你还知道典型外设产品的可靠性在什么样的数量级上......那么，你觉得自己很优秀，还是说"这是你应该做的"？
>
> > 你设计过不同规模的系统，知道在什么样的级别下应该使用什么样的技术；你知道性能热点通常在哪里，也精通于查找和解决热点；你知道如何平衡功能、时间和质量，知-道如何在特定情况下取舍；你知道流行的架构的优缺点，你知道哪种硬件能够构成什么样的系统、当机时间控制在什么样的级别上；你知道如何安排指标去区分高低端产品-，知道在给定的预算/成本下能够提供什么样的产品，你还知道如何对系统进行cost
> > down却不会损失可靠性......那么，你觉得自己很优秀，还是说"这是你应该做的"？
>
> > 你熟悉各种软件开发模式；你有丰富的知识积累，却又不守旧、勇于接受新鲜事物；你非常善于开会，能够在很短的时间内取消语言表面上的分歧让大家达成一致......那么-，你觉得自己很优秀，还是说"这是你应该做的"？
>
> > 你勤劳肯做，工作中不偷奸耍滑，很有大局观而且也重视细节问题；你性格温和，乐于助人，团队成员都说你是一个非常好相处的人，连没见过面的同事也对你赞不绝口...-...那么，你觉得自己很优秀，还是说"这是你应该做的"？
>
> > ......
>
> > 你能够......能够......还能够......即使在...的时候也能够......那么，你觉得自己很优秀，还是说"这是你应该做的"？
>
> > ......
>
> > 如果你做到了以上若干条，那么在我看来，你成功地完成了你自己的本职工作，完成了自己做为一个工程师（而不是科学家）的"应该做的事情"----也许你比身边人的平-均水平要高出一截，也许你超过了整个业界的平均水平，但那是不是就意味着"优秀"呢？如果那仅仅是你"应该做到的"呢？
>
> > 最后，你做为一名人类，能够进行独立的思考，在清晰逻辑和丰富知识的基础上拥有批判性的思维，你懂经济、懂民主；你不愤青、不脑残、不意淫、不从众；你不受洗脑-和煽动的影响、不信武术和中医......那么，你觉得自己很优秀，还是说"这是你应该做的"？
>
> > 延伸阅读
> > （下面的每一个链接都能对应到上面文章里的某句话，用来例证，而不是证明）
> > Teach Yourself Programming in Ten Years, by Peter Norvig
> >http://norvig.com/21-days.html
> > 快排为什么那样快, by Pongba
> >http://mindhacks.cn/2008/06/13/why-is-quicksort-so-quick/
> > Beating The Averages, by Paul Grahamhttp://www.paulgraham.com/avg.html
> >http://www.xys.org/xys/ebooks/others/science/dajia10/zhongyi2621.txt
>
> > --
> > Kenny Yuan
> > C++, UI, LISP, MMA, Psychology and Automobile.
> > BLOG: CS巴别塔(Computer Science Babel)
> > URL1:http://csbabel.wordpress.com/
> > URL2:http://blog.csdn.net/yuankaining/- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Kenny Yuan
Dec 4, 2009, 4:33:56 AM12/4/09
to pon...@googlegroups.com
多谢夸奖，实在是不敢当。当时是草稿，就直接贴了，结果有一个关键的注释当时还没有写……
注：上面列举了许多的条目，但是这些条目涉及了很多领域，所以并不要求一个人同时具备这些能力。
P.S. 想看修订的全文配图版的，请移步俺的web log一观
注：上面列举了许多的条目，但是这些条目涉及了很多领域，所以并不要求一个人同时具备这些能力。
P.S. 想看修订的全文配图版的，请移步俺的web log一观
ps：你这文章怎么在CSDN博客上没找到？
张慧聪
Dec 18, 2009, 12:16:14 AM12/18/09
to pon...@googlegroups.com
2009/12/4 Kenny Yuan <yuank...@gmail.com>
多谢夸奖，实在是不敢当。当时是草稿，就直接贴了，结果有一个关键的注释当时还没有写……
注：上面列举了许多的条目，但是这些条目涉及了很多领域，所以并不要求一个人同时具备这些能力。
嗯，福尔摩斯就“不知道”地球围着太阳转。Kenny这个写得太N了，分类很精到
于是，关于pongba的问题，我觉得可以反推，要衡量一个码农，那么首先确定，这个码农的职责是什么？显然，如果他能迅速而高质量地完成自己的任务，那么当然就是个好码农了。一但职责确定了，那么所需要什么能力就明显地反推出来了。
于是，关于pongba的问题，我觉得可以反推，要衡量一个码农，那么首先确定，这个码农的职责是什么？显然，如果他能迅速而高质量地完成自己的任务，那么当然就是个好码农了。一但职责确定了，那么所需要什么能力就明显地反推出来了。
P.S. 想看修订的全文配图版的，请移步俺的web log一观ps：你这文章怎么在CSDN博客上没找到？
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL1: http://csbabel.wordpress.com/
URL2: http://blog.csdn.net/yuankaining/
--
----文艺型程序员+围棋偶饭+SC剩菜饭+前科幻迷+数学习饭
居振梁
Dec 18, 2009, 12:48:27 AM12/18/09
to pon...@googlegroups.com
哈哈，这个对招人的目标职位还行，但是对于被招的人，他的确只需要显示对招人方有用的一面就行了。
但是就不说这个人可能跳槽了，即使是录用之后，还是可能被指派去“帮助一下其他人”，所谓“……是块砖，哪里需要哪里搬”。
这些软技能我觉得是必须的，甚至可以因此预计其表面现象以外对于完成既定的任务是否合适，能合适多长时间。
--
战斗暴龙：理论由自己理论，由这理论演绎实践；实践由自己实践，由这实践归纳理论。事事都理论+实践太累了。
http://wargrey.yo2.cn [黑客精神；团队精神；清心寡欲；像孩子一样思考]
http://wargrey.blogspot.com [BY-BLOG；自然语言试练场]
http://juzhenliang.blogspot.com [中文译出]
但是就不说这个人可能跳槽了，即使是录用之后，还是可能被指派去“帮助一下其他人”，所谓“……是块砖，哪里需要哪里搬”。
这些软技能我觉得是必须的，甚至可以因此预计其表面现象以外对于完成既定的任务是否合适，能合适多长时间。
2009/12/18 张慧聪 <zhcfr...@gmail.com>
2009/12/4 Kenny Yuan <yuank...@gmail.com>多谢夸奖，实在是不敢当。当时是草稿，就直接贴了，结果有一个关键的注释当时还没有写……
注：上面列举了许多的条目，但是这些条目涉及了很多领域，所以并不要求一个人同时具备这些能力。嗯，福尔摩斯就“不知道”地球围着太阳转。Kenny这个写得太N了，分类很精到
于是，关于pongba的问题，我觉得可以反推，要衡量一个码农，那么首先确定，这个码农的职责是什么？显然，如果他能迅速而高质量地完成自己的任务，那么当然就是个好码农了。一但职责确定了，那么所需要什么能力就明显地反推出来了
--
战斗暴龙：理论由自己理论，由这理论演绎实践；实践由自己实践，由这实践归纳理论。事事都理论+实践太累了。
http://wargrey.yo2.cn [黑客精神；团队精神；清心寡欲；像孩子一样思考]
http://wargrey.blogspot.com [BY-BLOG；自然语言试练场]
http://juzhenliang.blogspot.com [中文译出]
Xu Yi
Jan 6, 2010, 4:27:09 AM1/6/10
to pon...@googlegroups.com
Better这个词很有意思，如果上面都是better的标准，那么“good programmer”的标准是什么呢？
better、bigger、smarter都是没有止境的东西，随便列出些标准来要求人们去遵守实在太过容易。我倒是觉得评判任何东西是否better还是要看结果（result），能够完成本职工作那就是good，能够超过工作职责完成更多的事务则并不一定就是better，必须得仔细地分析这些事务对整个系统所产生的影响。
以及，better总是有一个角色定义上的限制，很多条款似乎并非只是针对一个programmer而言，而是适用于很多其他的角色，甚至于，在不同的公司里，同一个词programmer都还有不同的权责定义呢。。。
--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
- - - - - - - - - -
--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
- - - - - - - - - -
Jeff Chen
Jan 6, 2010, 4:45:55 AM1/6/10
to pon...@googlegroups.com
Do you use source control?
Yes,clear case
Can you make a build in one step?
No,No need
Do you make daily builds?
No,it is not proper for our project.
Do you have a bug database?
Yes,clear request
Do you fix bugs before writing new code?
yes
Do you have an up-to-date schedule?
yes
Do you have a spec?
config spec ? yes
Do programmers have quiet working conditions?
yes
Do you use the best tools money can buy?
yes
Do you have testers?
yes
Do new candidates write code during their interview?
yes,little
Do you do hallway usability testing?
yes
2010/1/6 Xu Yi <kave...@gmail.com>
--
My Blog：http://jeffchen.cn
Reply all
Reply to author
Forward
0 new messages