15
Jul 12

The Art of Doing Science and Engineering

这本书是根据Hamming在美国海军研究院授课的课堂录音整理成的,主要内容是用自己做计算机相关研究的亲身经历讲述科研和工程的心得。对这本书感兴趣纯粹是因为Bret Victor同学给了一个6星级评分。看下来感觉还可以(虽然稍微贵了点。。。)。计算机和通信相关专业的同学对Hamming应该都不陌生,86年就因为在数值方法,自动编码系统,错误检测和纠错码的贡献获得了图灵奖。这本书因为只是课堂录音整理,并且估计也没什么Marketing之类的,所以影响力似乎并不大。中间的一些部分如果不是专业出身可能也比较枯燥,所以我想发行量不会很大。好在这门课程全部数字化了,大部分内容都可以在这里找到,有些章节只是节选,如果不想花31刀买书的话,就看这里的电子版吧。95年的最后一学期讲课的全部录像在这里也能下到,感觉那时候思维还很敏捷啊,怎么96年就挂了。。。他还有一个很有名的演讲,You and Your research,这里有一篇还不错的翻译。下面是一些很有意思的摘要(Kindle做这个还是很方便的,只是因为我经常在PC/手机/Kindle上同时看一本书,多设备同步还是有bug,有时候会覆盖掉。。。)

Education is what, when, and why to do things, Training is how to do it.

In science if you know what you are doing you should not be doing it. In engineering if you do not know what you are doing you should not be doing it.

All of engineering involves some creativity to cover the parts not known, and almost all of science includes some practical engineering to translate the abstractions into practice.
Often it is not physical limitations which control but rather it is human made laws, habits, and organizational rules, regulations, personal egos, and inertia, which dominate the evolution to the future.

you must try to foresee the future you will face. To illustrate the importance of this point of trying to foresee the future I often use a standard story. It is well known the drunken sailor who staggers to the left or right with n independent random steps will, on the average, end up about steps from the origin. But if there is a pretty girl in one direction, then his steps will tend to go in that direction and he will go a distance proportional to n. In a lifetime of many, many independent choices, small and large, a career with a vision will get you a distance proportional to \(\sqrt{n}\), while no vision will get you only the distance In a sense, the main difference between those who go far and those who do not is some people have a vision and the others do not and therefore can only react to the current events as they happen.

To what extent history does or does not repeat itself is a moot question. But it is one of the few guides you have, hence history will often play a large role in my discussions—I am trying to provide you with some perspective as a possible guide to create your vision of your future.

In forming your plan for your future you need to distinguish three different questions: What is possible? What is likely to happen? What is desirable to have happen? In a sense the first is Science—what is possible. The second in Engineering—what are the human factors which chose the one future that does happen from the ensemble of all possible futures. The third, is ethics, morals, or what ever other word you wish to apply to value judgments.

Lastly, in a sense, this is a religious course—I am preaching the message that, with apparently only one life to live on this earth, you ought to try to make significant contributions to humanity rather than just get along through life comfortably—that the life of trying to achieve excellence in some area is in itself a worthy goal for your life.

It has often been observed the true gain is in the struggle and not in the achievement—a life without a struggle on your part to make yourself excellent is hardly a life worth living.
Notice I leave it to you to pick your goals of excellence, but claim only a life without such a goal is not really living but it is merely existing—in my opinion. In ancient Greece Socrates (469–399) said: The unexamined life is not worth living.
Indeed, one of the major items in the conversion from hand to machine production is the imaginative redesign of an equivalent product. Thus in thinking of mechanizing a large organization, it won’t work if you try to keep things in detail exactly the same, rather there must be a larger give-and-take if there is to be a significant success.

You must get the essentials of the job in mind and then design the mechanization to do that job rather than trying to mechanize the current version—if you want a significant success in the long run.
We must not forget, in all the enthusiasm for computer simulations, occasionally we must look at Nature as She is.

The Buddha told his disciples, "Believe nothing, no matter where you read it, or who said it, no matter if I have said it, unless it agrees with your own reason and your own common sense". I say the same to you—you must assume the responsibility for what you believe.

"Almost everyone who opens up a new field does not really understand it the way the followers do". The evidence for this is, unfortunately, all too good.

It has been said in physics no creator of any significant thing ever understood what he had done. I never found Einstein on the special relativity theory as clear as some later commentators.

The reason this happens so often is the creators have to fight through so many dark difficulties, and wade through so much misunderstanding and confusion, they cannot see the light as others can, now the door is open and the path made easy.

Hence I expect a lot of trouble until we do understand human communication via natural languages. Of course, the problem of human-machine is significantly different from humanhuman communication, but in which ways and how much seems to be not known nor even sought for. Until we better understand languages of communication involving humans as they are (or can be easily trained) then it is unlikely many of our software problems will vanish.

There are many things we can do to reduce "the software problem", as it is called, but it will take some basic understanding of language as it is used to communicate understanding between humans, and between humans and machines, before we will have a really decent solution to this costly problem. It simply will not go away.

"Is programming closer to novel writing than it is to classical engineering?" I suggest yes!

Give the same complex problem to two modern programmers and you will, I claim, get two rather different programs. Hence my belief current programming practice is closer to novel writing than it is to engineering. The novelists are bound only by their imaginations, which is somewhat as the programmers are when they are writing software.

What you learn from others you can use to follow; What you learn for yourself you can use to lead.

Mathematics is nothing but clear thinking. Mathematics is the language of clear thinking.

Platonic school (most) formalists When rigor enters, meaning departs. logical school intuitionists constructionists fallacies: 1) we do not actually "prove" theorems! 2) many important programming problems cannot be defined sharply enough so a proof can be given, rather the program which emerges defines the problem!

Man is not a rational animal, he is a rationalizing animal.

I often suspect creativity is like sex; a young lad can read all the books you have on the topic, but without direct experience he will have little chance of understanding what sex is—but even with experience he may still not understand what is going

An expert is one who knows everything about nothing; A generalist knows nothing about everything. In an argument between a specialist and a generalist the expert usually wins by simply (1) using unintelligible jargon, and (2) citing their specialist results which are often completely irrelevant to the discussion.

All impossibility proofs must rest on a number of assumptions which may or may not apply in the particular situation. "If an expert says something can be done he is probably correct, but if he says it is impossible then consider getting another opinion."

What you did to become successful is likely to become counterproductive when applied at a later date. "There is never time to do the job right, but there is always time to fix it later." especially in computer software.

Hamming’s rule: 90% of the time the next independent measurement will fall outside the previous 90% confidence limits!

Most of the time each person is immersed in the details of one special part of the whole and does not think of how what they are doing relates to the larger picture. It is characteristic of most people they keep a myopic view of their work and seldom, if ever, connect it with the larger aims they will admit, when pressed hard, are the true goals of the system. This myopic view is the chief characteristic of a bureaucrat.

Systems engineering is the attempt to keep at all times the larger goals in mind and to translate local actions into global results.But there is no single larger picture

The first rule of systems engineering is: If you optimize the components you will probably ruin the system performance.

Rule 2: Part of systems engineering design is to prepare for changes so they can be gracefully made and still not degrade the other parts.

Rule 3: The closer you meet specifications the worse the performance will be when overloaded.

Westerman believes, as I do, while the client has some knowledge of his symptoms, he may not understand the real causes of them, and it is foolish to try to cure the symptoms only. Thus while the systems engineers must listen to the client they should also try to extract from the client a deeper understanding of the phenomena. Therefore, part of the job of a systems engineer is to define, in a deeper sense, what the problem is and to pass from the symptoms to the causes.

The deeper, long term understanding of the nature of the problem must be the goal of the system engineer, whereas the client always wants prompt relief from the symptoms of his current problem. Again, a conflict leading to a meta systems engineering approach!

You may think the title means if you measure accurately you will get an accurate measurement, and if not then not; but it refers to a much more subtle thing—the way you choose to measure things controls to a large extent what happens.

For example, in school it is easy to measure training and hard to measure education, and hence you tend to see on final exams an emphasis on the training part and a great neglect of the education part


06
May 12

本博方针说明

只发本人原创文章,欢迎转载但请大家注明出处。基本保持至少每周一文的更新频率。内容主要是游戏制作相关的,包括引擎开发,图形学,工具制作,项目管理,读书笔记等。


19
Feb 12

对有效学习的一些思考

Motivation

今天主要想谈的是一些关于怎么样有效学习的话题,其实只要是从事创造性工作,那么如何不断提升自己的专业能力,就是一个职业发展生涯的重大问题。可能刚毕业的时候还意识不到这一点,那时候工作的要求也很单纯,就是高质量的满足别人给出的需求即可,基本是实现层面的东西,甚至大部分问题别人都已经解决过了。对自己的思维能力要求不高。只要是足够勤奋,不需要什么特别的方法,就可以很容易的超出上级的预期了。但是随着自己的成长,大家恐怕都会发现,是要自己去提出需求了,因为已经没人可以什么事情都帮你分析帮你决策了。而自己在团队中的价值也就在于是否能对公司的产品和发展提出有意义的新方向。从单纯的“业务实现”到了“业务智能”的阶段。这个时候,要面对就不光是具体的技术问题,而是结合了设计与商业的业务问题,这个时候技术之外思维方式就很重要了。比如对游戏来说,海量资源的制作是一个大问题,那么如何能够重构工具管线,提升资源制作效率,这就不光是技术能解决的问题了,从本质上讲,工具就是流程的固化,所以也要涉及各个部门的工作流程,沟通方式的改变,如何架构,推进这种事情也是很复杂的工作。再举一个例子,游戏中新效果的实现,看暴雪的游戏,我们就会发现,技术层面都比较简单(之前也分析过暗黑3的一些算法,比如这里这里),但是结合到游戏中,就是能起到很好的作用,无论是提升打击感,还是增加带入感,怎么样才能有这样的发散和设计能力?

不管怎么说,要解决这个问题,只能通过项目来提升自己能力,并且一定要有意识的提高自己学习的效率,否则再多的经验也是没有意义的,一方面追求技术的广度和深度。一方面开拓视野,了解设计层面的东西,最后再加上对思维能力的刻意训练,我想也许是一条出路。说句题外话,现在回过头来看自己的大学生活,简直是太浪费了,在思维最活跃的黄金年代,学校里面却没有任何思维训练的课程,计算机系的教育方法就是彻头彻尾的瞎搞。这恐怕是中国大学真正的悲哀,也是为什么国外大学本科毕业生就能写出Protocol Buffer这样的库。而在中国却很难。

Methods


刻意练习法

而对学习方法,心理学家们似乎已经有了非常靠谱的结论,并且有了几本经典著作:

The Cambridge Handbook of Expertise and Expert Performance

Development of Professional Expertise:Toward Measurement of Expert Performance and Design of Optimal Learning Environments

简单总结一下:

1. 在“学习区”练习

通常我们都喜欢待在舒适区,用已经掌握的工具和技能去解决问题,但是在舒适区练习是不能提升自己能力的,所以为什么每一个C++程序员都应该学习至少一门函数式语言(比如Scheme,Erlang等)并实际使用这种语言来解决问题。只有使得自己用不同方式思维的语言才是值得学习的。这就是在学习区练习的典型例子。当然,说起来容易,做起来就难了,我就遇到过一些这样的老程序,对新语言新工具毫无兴趣,认为自己在以前某大公司积累的东西就足够用了,为什么要改?

2. 大量重复训练

这也是学习的关键,必须要有大量的练习支撑,才能把技能固化。但是一定是要在学习区的重复训练!

3. 持续获得有效的反馈

这恐怕是离开学校之后最难做到的了,就是除了在学习区不断训练,还需要有获得自己的练习行为是否有效的反馈。这种反馈越即时越好。所以为什么每个软件团队都应该有一个方便的Code Review机制。从自己项目的经验和带新人的经验来看,新人如果有一个每次提交代码都得到审核和具体修改意见的过程,那么成长速度会非常快,对尽快融入团队非常有帮助。而定期的进行重要模块的代码交叉Review,对老程序自己也是一个很好的学习机会。

从另一方面讲,学会从旁观者的角度观察自己的行为,并每天反思,总结,恐怕是一个不错的反馈机制。也就是为什么日记和时间卡片这么管用了。这里推荐一个小软件:ProcastiTracker,可以很方便的记录在电脑上每个应用软件花的时间,比如今天QQ聊天用了多少时间,写代码用了多少时间,看网页又是多少时间,并且可以按时间段形成报表,对反思自己的行为很有帮助。

4. 精神高度集中

刻意练习没有“寓教于乐”这个概念。所以说,这个时候就体现出兴趣的作用了。很难想象没有强烈的兴趣可以坚持枯燥而专注的练习太长时间。

阅读方法

另外一个想讨论的话题是有效阅读,因为知识最廉价以及系统的来源就是书本了,这里要说一下,中国的书真是很便宜的。但是如何阅读也是要注意的,有的书可能只是快速翻阅即可,有的书可能就需要深入下去,这方面技巧最好的恐怕就是How to Read A Book这本书了,初版1940年,后来一直不断再版,可见这本书是很受认可的。下面是我的一些总结,当然阅读的技巧是要不断提升的,我现在也不能做到很好的主题阅读,只是有了这本书指导,前进的方向是很明确的,剩下的,就是不断磨练了。

<How to read a book>

这是一本关于如何阅读的经典著作,提出了如何做一个主动阅读者,让一本书真正属于自己。

阅读的几个层次

  1. 基础阅读,不多写了
  2. 检视阅读,快速的决定这本书是否值得细读,在主题阅读前,这一步是简化书目的关键,并且值得分析阅读的书并不多,没有必要每本书都花上相同的精力
  3. 分析阅读,透视一本书,了解这本书的整体架构,作者的逻辑思路
  4. 主题阅读,以一个主题为依据,通过检视阅读找到相关的书,在阅读的过程中形成自己对这个主题的大框架和术语,把不同的书的内容通过分析阅读统一到这个框架中来,也就是把不同作者对相同术语不同的表达都统一起来,最后获得对一个主题很深入的理解,并能够提升自己的思考能力

如何做一个主动的阅读者

一本好书是不能用很随意的方式来阅读的,至少对缺乏经验的阅读者是这样的,就好像一个初学滑雪的人和一个滑雪大师的区别一样,有经验的阅读者可以把阅读的各种技巧很灵活自然的运用起来,而刚开始意识到需要主动阅读的人还是需要一段比较长的训练期才能比较熟练的掌握主动阅读的技巧的。总的来说,看一本书我们一定要提出四个问题

  1. 整体来说,整本书是讲什么的
  2. 作者细部说了什么,是怎么说的,要对作者主要的论点,想法,声明都能够了解
  3. 这本书说的有道理吗?是全部有道理还是部分由道理
  4. 这本书和我自己的关系,对我的启发等

如何让一本书真正属于自己

对于真正值得读的好书,需要做一份自己的读书笔记,才能完成对这本书智力上的拥有。实际上,很多大师都是不保留书本身,只保留读书笔记的。而且现在网络资源检索很方便的情况下,在只有读书笔记的情况下,一些细节直接上网搜索就能很快的获得了。这么一份笔记才是我们最重要的智力资产啊。不管硬盘上放了多少的电子书,如果没有自己的读书笔记也没意义

三种读书笔记:

结构笔记:这本书是什么样的书?整本书是讲什么的?作者借着怎么样的整体架构来发展他的观点或者陈述他对这个主题的理解? 这种笔记一般是在做捡视阅读时做的。

概念笔记:作者的观点到底是什么?作者对主题表达的一些观点和相关的概念,以及自己对这些疑问的答案。这种笔记需要在分析阅读的层次才能完成。

辩证笔记:这种笔记是针对一场讨论情景的笔记,可能会涉及同一主题的很多书和不同的作者,就某一个主题,把所有的疑问和陈述记录下来。这是主题阅读才能做的笔记。

主题阅读的步骤

0.运用检视阅读的技巧,快速的获得和感兴趣的主题相关的书目

1.在这些书中找到相关的章节,因为对主题阅读来说,主题才是最重要的,而不是完整的去阅读每一本书

2.带领作者与自己达成共识,这一步非常的难,因为值得阅读的书的作者都是比我们自己高明的人,我们会倾向按他的思路走,但是在主题阅读的时候,这样就行不通了,因为每个作者的思路是不一样的,我们必须以自己的概念来统一这些不同的作者的概念。

3.厘清问题,实际上就是建立我们的主旨,一般来说,可以提出一些可以把我们的主题说的比较明白的问题,然后让这些作者来回答这些问题

4.界定议题,在上面一步中,我们提出的问题可能有一些是很清晰的,而所有作者都谈论到了,并且是以不同的方式,那么这种问题就可以成为我们的重点议题了,就好象我们组织了一次这些作者之间的辩论会似的。

5.分析讨论,在把值得讨论的议题都界定出来之后,我们就可以进入到最后一个阶段了。对这些问题的分析讨论。首先是对这些议题的不同答案进行分析,需要清晰的按顺序呈现不同作者对这些问题的观点,并且尽量做到辩证的客观。

时间管理与GTD

我之前写过自己实践GTD的方法,这里再说一下现在遇到的问题:

反思一下最近半年的GTD实践。发现还是没有真正利用好这个方法,时间管理和任务管理上还是有很大问题的

1.任务收集的问题,对任务的划分不够细,导致执行起来可操作性不强

2.任务没有按时间进行分类,地点分的也有问题,导致不能有效的安排任务的执行

3.没有根据自己的状态选择合适的任务,不同的时间段效率是不一样的