习而学的软件工程教育
这篇文字探讨了习而学的软件工程教育，里面讲到
以桥梁建筑专业为例，大学一年级先学施工条例，二年级则学设计规范。这些学习内容不必解释条例和规范的理论基础，只说明其内在的联系。到三年级可以学结构力学，四年级则学微积分、线性代数、概率论和普通物理。但桥梁专业的微积分和物理学可以不同于机械系的，它们各有侧重点，有各自的例题和习题。学生越是到高年级，越是明白自己在低年级所学的道理，也就明白还有哪些道理至今在科学上还没有办法解释。于是学习成为一个自然的延续过程，成为一种终身的事业：活到老、学到老。
这种方式的学习其实很像learning by doing的学习方式，让学生在实践中掌握知识。比如软件工程这门课，一开始在看书，以及听老师讲课的时候并不能感受到结对编程这种方式的作用，或者好处，但经过两次的结对编程，感觉的确有互相进步，优势互补。还有就是代码的结构，规范和单元测试这一方面，只通过老师讲述并不能很好的体会到它的重要性，但是在做我们的团队项目的时候，一开始虽然有代码规范，但是我自己并没有遵守，导致最后强行规范代码的时候规范出来了一堆bug....代码的结构体现在，因为是一个团队项目，我们必须合理的划分工作，这样每个人写的代码尽量独立，同时我因为我自己负责各个模块流程的整合，要求大家的接口都规范好。所以我觉得软件工程这门课从实践中学习是最好的方法。但是这个方法的缺点就是，一些知识不太适合习而学，比如数学、物理等等。
软件工程≠计算机科学
这篇文章讲了软件工程和计算机科学的不同，让我更好的了解了软件工程。首先软件工程和计算机的不同，作者提到： ”“直接涉及人类活动的” 属性。软件工程有这个属性，而传统的计算机科学没有。“ 在软件工程课上，涉及到大量的程序编写、软件的实现，最终评价是软件的可维护性/可用性/可需求性等等。我自己课程中最大的体验就是，软件工程不像算法课、数学课，它更推崇实践出真知这种方法。因为软件最终是要给人来用的，软件的过程需要团队合作等人类活动。 其次比如我们的Julia for AI项目，做之前我真的不明白用Julia有啥好的，用pytorch不行嘛。。但是经过两位研究员的解释，发现他们看的更远，比如框架的演化。。。但这些做AI的人并不关心，或许这也是两者不同的一个证明把。
美国视界（1）：第一流的本科教学课堂该是什么样
这篇文章讲了美国一所高校的本科教学的一些比较好的经验，比如
- 课外阅读材料
“不止有科学进展，还关注工业产业创新，相比国内课堂的内容陈旧和照本宣科，这里的学生真幸福”
我对这一点有比较深的感触，学校里老师教的技术，很多都已经过时了，有些老师可能自己都不去接触一些前沿，有的教材就是翻译国外的教材来的，然后之后的每一届都在用，在课堂上，也很少有老师会结合现代企业的一些技术来举列。我觉得这门课的好处就是，我们的团队项目是来源于真实的场景和需求，而不是过时的、无意义的需求。让学生多去实习，或者邀请企业的专家，都是让学校里的学术接触到一些新的技术的好方法。
- 成绩 vs 奖学金 :
美国学生要想在课程上拿满分几乎是不可能的，从我所在的课程看，不仅考察基础知识、实践操作，还有书本之外的宽泛知识，有些还是很新的科学发现。
钱学森教育思想中“不鼓励学生拿100分，有个八十分就够了，把更多时间花在理解和思考上”，他真是受美国观念影响的人。期末成绩可以拿去竞争奖学金吗？我的了解中是没有机会的。
不予置评成绩不参与奖学金这一点，但是对于考试的内容方面，我觉得我上过的课有些做的是不够好的。自我感觉考试内容更像在鼓励学术去死记硬背、靠前刷往年考题，对于实践操作，书本之外的宽泛知识涉及不够。 比如C语言考试，大家上机编个程不好吗？
The Cathedral and the Bazaar
软件开发的两种模式：大教堂和市集模式。大教堂模式，投入很多人的心血，历经长时间的建设，才能使用，市集模式是天天开放在那里，从无到有。市集模式下，代码始终公开，大教堂模式，代码团队共享，代码发行后公开。
"given enough eyeballs, all bugs are shallow"
我们的团队项目采用的是市集模式，源代码在github上，供所有人审阅，在代码短时间可运行之后，公开源码，一方面能让所有人监督你的软件，多听取他人的意见，另一方面可以向用户展示这个软件在未来是有希望变成”大教堂“的。
What Should We Teach New Software Developers? Why?
这篇文章讲述的是工业界和学校存在gap的现象。 比如在我本科期间，没有写过完整/真实的软件，学校里面教授的技术和工具和实际存在差距，写的代码基本上run一下就完事了，从来没有考虑过代码的可维护性，文档等等....但是公司期望的是掌握了新技术和工具的学术，重视团队合作，但是在学校里几乎是个人项目，团队作业也很容易变成抱大腿的单打独斗... 因此减少这种gap,可以鼓励学生实习，邀请一些工业界专家上课等等。
The PhD Grind
这篇文章讲述了作者在standford读phd的经历。自己马上踏入博士的旅程了，记录一下读这个文章中的心得
厚积薄发，作者读博的读博前3年没有paper发表，看似是白白浪费，其实作者在过程中锻炼的coding能力，不断试错等过程中得到的经验，也为他之后打下了基础。另外我觉得博士很多时间都在做实验，验证想法，coding能力也是很重要的，现在的”杂活“可能是自己牢固基础的最好时机，不能眼高手低，不过博士期间面临着毕业的压力，心态也一定要好吧。
Big Ball of Mud
A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design.
在Alpha阶段，为了能快速做出一个可以运行的代码，我们的项目存在这种大泥球现象，但这种现象也是一种无奈之举，开始的时候大家对julia不是非常熟悉，一些数据预处理部分为了项目能快速run起来甚至用python写了一小部分，但是随着大家对这个项目的理解和熟练，重新整合了我们的这部分代码，还好代码不是特别多....
The Rise of ``Worse is Better''
worse-is-better:
Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. >Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
这里面强调了简单是最重要的考虑因素，我觉得我们的项目实现初期的确考虑了这个原则。为了让系统能先尽快run起来，当然是越简单越好，有些复杂的情况可以不用考虑，比如实现CRF版本的NER，完全用Julia实现数据预处理等等，在后期，不断发展的过程中，才会去考虑保证完全正确/完整性等情况。