【原创】【1】Jamie Zawinski
这篇书评可能有关键情节透露
http://docs.google.com/View?id=dgnd783p_276gttrjjc7
jwz是绝对hacker类型的老派程序员，绝对的duct type、实用主义。
不过他已经不再编程了，所以他的一些意见，有些已经显得距离遥远。
关注底层、追求效率、对方法论嗤之以鼻、坚信模块化是唯一正确的方式，靠感觉（taste）、靠天赋、靠认了一条理就打破砂锅问到底。
他鄙视c++、鄙视thread、鄙视design pattern、对unit test也不认同。
他认为改别人的代码，不如自己写一个来得快，同时更cool。
正如Joel所说，最可贵的一点，他按时ship了交给他的产品。
他不是科班出身，甚至只有高中学历。一切来自自学。
他不擅长数学，且认为不一定需要数学才能成为好的程序——他接触的程序大部分是直接面向业务的。
他不喜欢过多的修饰，只喜欢直接，所以他形容design pattern:
the inverse, reverse, double-back-flip pattern—whatever. Oh, you mean a
loop? OK.
（无疑，这一点他是对的！但这并不是design pattern本身的错，而是使用者的问题。时刻看清楚需求是什么、然后用最恰当的方式来达到需求。）
他认为程序员不是科学家、不是工程师，因为那两项职业太过正式。
他更愿意把程序员看作是介于craftsman和artist之间。
他如何做到成功的？其实他没讲清楚。他说出来的无非是：
关注用户的需求、强调代码的功能性，不过度设计。
没有必要，不要rewrite代码，不要陷入second-system syndrome。
专注、坚持——一周80小时的工作。
一个4-5个聪明人组成的团队。
好的模块/任务划分。
加上上面那些hacker的素质，并把它们做到极致。
他形容编程：
you’re writing a story and you’re trying to express a concept to a very dumb person—the computer—who has a limited vocabulary.
而code taste的好坏，就好象是只是把故事说清楚了，还是把故事说的又清晰又生动。
他觉得作为导师，给予学生最大的帮助，是知道何时需要让学生level up。
他觉得最好的学习代码，是从完成一个工作入手。
他学习代码，主要靠eyeball来读，去理解思路，而不是用debugger来step（这点喜欢～）
同样，他不相信debugger，至少在c/gdb中。他找bug，会从读代码入手，在感觉有问题的地方用print
对于assert，他赞同，但也提出问题：
在发布版的程序中如果遇到错误，与其直接把错误丢给user然后退出，倒不如允许内存泄漏、忽略错误而让程序继续运行更加user friendly。
他提到java的exception handle这方面比c来的好。
他不坚持top-down或者bottom-up。
他提到他的习惯：先把所有功能实现在一个文件中，然后等到文件不断变大时，再自然划分。
他相信design只有在程序最后完成时才会同时完成。
他相信组织团队的方法，是划分好模块、定义好模块直接接口，然后放手让各个模块去实现。
他不同意“代码责任共享”。
然而话说回来，有些方法论其实在他那里是与生俱来的，比如版本控制。
所以好程序真不一定会是好老师：他们会认为那些东西生来应该如此，于是在谈起时，反而忽略了它们的重要性。
技术关键词：
Lisp, XEmacs, Netscape, C, XScreenSaver
jwz是绝对hacker类型的老派程序员，绝对的duct type、实用主义。
不过他已经不再编程了，所以他的一些意见，有些已经显得距离遥远。
关注底层、追求效率、对方法论嗤之以鼻、坚信模块化是唯一正确的方式，靠感觉（taste）、靠天赋、靠认了一条理就打破砂锅问到底。
他鄙视c++、鄙视thread、鄙视design pattern、对unit test也不认同。
他认为改别人的代码，不如自己写一个来得快，同时更cool。
正如Joel所说，最可贵的一点，他按时ship了交给他的产品。
他不是科班出身，甚至只有高中学历。一切来自自学。
他不擅长数学，且认为不一定需要数学才能成为好的程序——他接触的程序大部分是直接面向业务的。
他不喜欢过多的修饰，只喜欢直接，所以他形容design pattern:
the inverse, reverse, double-back-flip pattern—whatever. Oh, you mean a
loop? OK.
（无疑，这一点他是对的！但这并不是design pattern本身的错，而是使用者的问题。时刻看清楚需求是什么、然后用最恰当的方式来达到需求。）
他认为程序员不是科学家、不是工程师，因为那两项职业太过正式。
他更愿意把程序员看作是介于craftsman和artist之间。
他如何做到成功的？其实他没讲清楚。他说出来的无非是：
关注用户的需求、强调代码的功能性，不过度设计。
没有必要，不要rewrite代码，不要陷入second-system syndrome。
专注、坚持——一周80小时的工作。
一个4-5个聪明人组成的团队。
好的模块/任务划分。
加上上面那些hacker的素质，并把它们做到极致。
他形容编程：
you’re writing a story and you’re trying to express a concept to a very dumb person—the computer—who has a limited vocabulary.
而code taste的好坏，就好象是只是把故事说清楚了，还是把故事说的又清晰又生动。
他觉得作为导师，给予学生最大的帮助，是知道何时需要让学生level up。
他觉得最好的学习代码，是从完成一个工作入手。
他学习代码，主要靠eyeball来读，去理解思路，而不是用debugger来step（这点喜欢～）
同样，他不相信debugger，至少在c/gdb中。他找bug，会从读代码入手，在感觉有问题的地方用print
对于assert，他赞同，但也提出问题：
在发布版的程序中如果遇到错误，与其直接把错误丢给user然后退出，倒不如允许内存泄漏、忽略错误而让程序继续运行更加user friendly。
他提到java的exception handle这方面比c来的好。
他不坚持top-down或者bottom-up。
他提到他的习惯：先把所有功能实现在一个文件中，然后等到文件不断变大时，再自然划分。
他相信design只有在程序最后完成时才会同时完成。
他相信组织团队的方法，是划分好模块、定义好模块直接接口，然后放手让各个模块去实现。
他不同意“代码责任共享”。
然而话说回来，有些方法论其实在他那里是与生俱来的，比如版本控制。
所以好程序真不一定会是好老师：他们会认为那些东西生来应该如此，于是在谈起时，反而忽略了它们的重要性。
技术关键词：
Lisp, XEmacs, Netscape, C, XScreenSaver
