作者：GXSC
链接：https://www.zhihu.com/question/24614033/answer/497338972
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
Soft Skills
Soft Skill下列出的那些管理技术和交流技术并没有错。 Soft Skill 不是 IT 行业产生的, 用来区分于technical skill。
我经理有次告诉我， 这个概念应该是来源于军队或者制造业。
早在1950年左右 Soft Skills 的概念就出现了。 1972年曾经军队开过专门关于 Soft Skills 的讨论会。 当时 IT 行业还不存在。
Soft Skills 的定义是“难以测量的技能”（比如你的工厂里的人是否融洽）。
它相对的其实就是Hard Skills（而不是网上说的technical skills）， 就是一些“可以测量的技能”（比如你一天生产量是多少之类的）。
虽然难以测量， 因为Soft Skills是一些技能， 所以它们还是可以通过学习、锻炼来获得提高的（相对于天赋）。
这些技能是有系统的， 有专业的（管理能力、行为影响能力、政治能力等所相对的学科：管理学， 心理学，政治学 ）。 所以它们也可以说是technical的。
写程序容易懂
这种设计方面的技能.
因为难以测量， 所以是一个Soft Skill. 但是这个技能可以通过不断地锻炼和学习来提高。
软件架构
架构就是所谓的 Architecture。 这个词是从建筑学来的， 在软件行业里被滥用 。
我很长时间都不信这个词。 其实这个词还是有用的，它指的是把资源、空间以某种方式分配， 让在这之上的设计自然趋向于好的。
两个组距离远， 系统耦合度就小， 就是其中一个例子。 如果我们希望某些系统能融合， 把开发它们的小组并到一起就好。 如果我们想分割一个系统， 就把开发它的组员分成不同的小组。
架构也可以是电脑相关的工具， 比如用 functional language 去写一个系统会让组员更多去思考运算， 更少去思考物件（更有可能会招不到员工）。
现实中， 分组、合组都是很复杂的事情。 这关系到大组结构的影响.
怎么说服别人，怎么用人， 怎么调整过程中和之后的人际关系，怎么调整每个组的开发流程，怎么定义每个组的职责等等。这些技术往往是无法直接测量能力高低的，比如管理技术和交流技术。属于Soft Skills的范围。
设计上的容易懂都是需要Soft Skills的.
每个 Soft Skill 都是一门技术. 我们更有效地去探索其中的机制, 通过实验得出的结论， 而不是单纯地利用直觉（intuition）、好的意向（good intention）、和“成功人士”讲的“道理”。
比起从建筑学、工程学借用一些工具， 软件开发其实更适合借用心理学、社会学、管理学、经济学、以及政治学里的工具。 大概因为建筑学和工程学的媒介（比如木头）和限制（比如万有引力）， 都来源于物理。 而软件的媒介（想法）和限制（思考方式）， 都来源于人的思想。
比如我们之前提到， 软件设计最重要的是"容易懂"。
"容易懂" 是认知心理学的概念(cognitive ease) 。 通过学习认知心理学， 我们能够有机制地让软件更容易懂， 而不是单纯地借助直觉。
Conway's Law， 它提到软件结构通常来源于部门的交流结构。这是社会学的范围。 通过学习社会学， 我们可以有机制地优化部门之间的交流模式。
SDE II 之后 technical path 最需要的是系统地学习 Soft Skills , management path 也得学。
大多数亚马逊成功的 SDE III 的 Soft Skills 都是比较强的。 尤其在沟通能力和处理人之间的矛盾上， 他们大多都很有天赋。
这方面的天赋不强， 作为技术来学了。
SDE III 的职业发展可以参考 Daniel Kahneman 的《Thinking, Fast and Slow》。
I spent a few minutes to simplify the structure of content. The article was written to mix arguments and statements and facts together.
Soft Skill下列出的那些管理技术和交流技术并没有错。 Soft Skill 不是 IT 行业产生的, 用来区分于technical skill。
我经理有次告诉我， 这个概念应该是来源于军队或者制造业。
早在1950年左右 Soft Skills 的概念就出现了。 1972年曾经军队开过专门关于 Soft Skills 的讨论会。 当时 IT 行业还不存在。
Soft Skills 的定义是“难以测量的技能”（比如你的工厂里的人是否融洽）。
它相对的其实就是Hard Skills（而不是网上说的technical skills）， 就是一些“可以测量的技能”（比如你一天生产量是多少之类的）。
虽然难以测量， 因为Soft Skills是一些技能， 所以它们还是可以通过学习、锻炼来获得提高的（相对于天赋）。
这些技能是有系统的， 有专业的（管理能力、行为影响能力、政治能力等所相对的学科：管理学， 心理学，政治学 ）。 所以它们也可以说是technical的。
写程序容易懂
这种设计方面的技能.
因为难以测量， 所以是一个Soft Skill. 但是这个技能可以通过不断地锻炼和学习来提高。
软件架构
架构就是所谓的 Architecture。 这个词是从建筑学来的， 在软件行业里被滥用 。
我很长时间都不信这个词。 其实这个词还是有用的，它指的是把资源、空间以某种方式分配， 让在这之上的设计自然趋向于好的。
两个组距离远， 系统耦合度就小， 就是其中一个例子。 如果我们希望某些系统能融合， 把开发它们的小组并到一起就好。 如果我们想分割一个系统， 就把开发它的组员分成不同的小组。
架构也可以是电脑相关的工具， 比如用 functional language 去写一个系统会让组员更多去思考运算， 更少去思考物件（更有可能会招不到员工）。
现实中， 分组、合组都是很复杂的事情。 这关系到大组结构的影响.
怎么说服别人，怎么用人， 怎么调整过程中和之后的人际关系，怎么调整每个组的开发流程，怎么定义每个组的职责等等。这些技术往往是无法直接测量能力高低的，比如管理技术和交流技术。属于Soft Skills的范围。
设计上的容易懂都是需要Soft Skills的.
每个 Soft Skill 都是一门技术. 我们更有效地去探索其中的机制, 通过实验得出的结论， 而不是单纯地利用直觉（intuition）、好的意向（good intention）、和“成功人士”讲的“道理”。
比起从建筑学、工程学借用一些工具， 软件开发其实更适合借用心理学、社会学、管理学、经济学、以及政治学里的工具。 大概因为建筑学和工程学的媒介（比如木头）和限制（比如万有引力）， 都来源于物理。 而软件的媒介（想法）和限制（思考方式）， 都来源于人的思想。
比如我们之前提到， 软件设计最重要的是"容易懂"。
"容易懂" 是认知心理学的概念(cognitive ease) 。 通过学习认知心理学， 我们能够有机制地让软件更容易懂， 而不是单纯地借助直觉。
Conway's Law， 它提到软件结构通常来源于部门的交流结构。这是社会学的范围。 通过学习社会学， 我们可以有机制地优化部门之间的交流模式。
SDE II 之后 technical path 最需要的是系统地学习 Soft Skills , management path 也得学。
大多数亚马逊成功的 SDE III 的 Soft Skills 都是比较强的。 尤其在沟通能力和处理人之间的矛盾上， 他们大多都很有天赋。
这方面的天赋不强， 作为技术来学了。
SDE III 的职业发展可以参考 Daniel Kahneman 的《Thinking, Fast and Slow》。
Actionable Items
I spent a few minutes to simplify the structure of content. The article was written to mix arguments and statements and facts together.
No comments:
Post a Comment