HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    职业与工作方法commoncog.com

    隐性知识比刻意练习更重要

    Tacit knowledge is more important than deliberate practice

    2次上首页
    1年跨度
    758累计得分
    254条评论

    2020 — 2021,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    这篇文章讨论隐性知识(tacit knowledge)为何在专业技能中比刻意练习更关键:刻意练习依赖成熟的教学法,而许多领域的关键知识无法言传,只能通过经验、模仿和判断力积累。文章还介绍了从专家身上提取隐性知识并用于训练的思路。

    为什么经久不衰:它挑战“刻意练习万能”的流行观念,给出理解专家直觉、判断力和技能传承的框架,对学习与组织培训都有持久启发。

    关键词 隐性知识刻意练习专家判断技能习得

    HN 评论精选

    刻意练习有适用边界;没有成熟教学法的领域,可用认知任务分析提取专家隐性知识并建案例库来加速培训。

    对这个问题可操作层面感兴趣的读者,应该读这个系列的最后一篇。基本观点是:1)刻意练习只适用于有良好教学法发展历史的技能;如果没有这样的教学法积累,就无法进行刻意练习。来源应读《Peak》或 Ericsson 的原始论文,不要读第三方或科普转述。2)意识到这一点后,下一个问题就是:在缺乏良好教学法的技能领域,如何有效学习?美国军方和一部分专家研究学者正好在追问这个问题。3)诀窍是用认知任务分析从现有专家头脑中提取隐性知识。这些专家是靠试错和运气建立专长的,不是靠刻意练习;但你可以把他们的知识提取出来作为捷径。然后,用提取出的隐性知识建立模拟案例库,按难度排序作为培训项目。不必执着于刻意练习——让刻意练习成功所需的教学法发展太耗时了。大致来说,刻意练习和隐性知识提取代表了获取专长的两种不同思路。

    shadowsun7查看英文原文

    Readers who are interested in the actionable aspects of this topic should probably read the last instalment in this series: https://commoncog.com/blog/accelerated-expertise/ The basic idea is this: 1. Deliberate practice only works for skills with a history of good pedagogical development. If no such pedagogical development exists, you can’t do DP. Source: read Peak, or any of Ericsson’s original papers. Don’t read third party or popsci accounts of DP. 2. Once you realise this, then the next question you should ask is how can you learn effectively in a skill domain where no good pedagogical development exists? Well, it turns out a) the US military wanted answers to exactly this question, and b) a good subsection of the expertise research community wondered exactly the same thing. 3. The trick is this: use cognitive task analysis to extract tacit knowledge from the heads of existing experts. These experts built their expertise through trial and error and luck, not DP. But you can extract their knowledge as a shortcut. After this, you use the extracted tacit knowledge to create a case library of simulations. Sort the simulations according to difficulty to use as training programs. Don’t bother with DP — the pedagogical development necessary for DP to be successful simply takes too long. Broadly speaking, DP and tacit knowledge extraction represent two different takes on expertise acquisition. For an overview of this, read the Oxford Handbook of Expertise and compare against the Cambridge Handbook of Expertise. The former represents the tacit knowledge extraction approach; the latter represents the DP approach. Both are legitimate approaches, but one is more tractable when you find yourself in a domain with underdeveloped training methods (like most of the skill domains necessary for success in one’s career).

    隐性知识本质上是判断力:专家知道什么重要、什么可忽略,从而降低认知负荷;这也解释了面试为何常考偏门细节。

    在我看来,隐性知识就是我们过去所说的判断力。判断力基本上就是知道一堆东西,但很清楚哪些东西比另一些更重要,尤其知道哪些事值得花时间、哪些不值得。就像我看到有人谈金融期权时,把什么东西都一股脑列在黑板上:看跌期权和看涨期权是什么、铁蝴蝶和其他策略是什么、需不需要懂收益图、Black-Scholes 呢、希腊字母呢、什么时候行权等等。这些专业期权交易员都知道,但作为专业人士,你会减少认知负担,因为你知道真正重要的是什么,不会同时应对所有这些概念。这也是面试时让人沮丧的来源。比如你写了很多年 C++,你可能并没有准备好回答语言各个角落的问题,尽管从某种意义上说你是专家。相对较新的人可能更擅长这种任务,因为他们正在大量思考所有东西,包括那些他们还没判定为不重要的东西。

    lordnacho查看英文原文

    IMO Tacit knowledge is what we used to call judgement. Judgement is basically knowing a bunch of things but having a good idea of which things are more important than others, and especially knowing which things are worth spending time on any which aren't. It's like when I see someone talking about financial options and they put everything on the board at once: what are puts and calls, what's an iron butterfly and other strategies, do they need to know the payoff diagram, what about black scholes, what are the Greeks, when should I exercise, and so on. They are all things that a professional option trader knows, but when you're a pro you reduce your cognitive load because you know what actually matters and you are not juggling all these concepts at the same time. It's also the source of frustration when interviewing. Say you've written CPP for many years, you're probably not prepared to answer questions on all corners of the language, even though you're an expert in some sense. Someone relatively newer might be better at that task, because they're thinking a lot about everything, including things they haven't decided are unimportant yet.

    刻意练习与隐性知识并非对立:前者本就要求背景知识、教练和体验,文章夸大了分歧。

    抱歉,我以前非常投入刻意练习那一套,然后读到这篇文章,心想“天哪,我是不是全搞错了?”于是我去读了他引用的书《Source of Power》。你知道吗?它和刻意练习有大量重叠。刻意练习的提倡者从来没有说“只要反复做就行”——你必须有背景知识、老师/教练等等,也就是隐性知识。其中一部分是别人教给你的,一部分是你被置于某种情境中去亲身体验的。看起来这种“对立”被夸大了。

    voiper1查看英文原文

    I'm sorry, I was really into the whole Deliberate practice thing and then I read this and thought "Oh no, did I have it all wrong?" So I read the book he quoted - "Source of Power". And you know what? It has a tremendous overlap with Deliberate Practice. The proponents of Deliberate Practice never claim to "just do it over and over" - you have to have background knowledge, a teacher/coach, etc... the tacit knowledge. Part of it is given to you and part of it is something that you're put into a position to experience for yourself. It seems the "divide" is overstated.

    隐性知识对软件工程有招聘和培训含义:经验有成本,导师制比文档更重要,且带薪学习是一种特权,不能简单归因于自学。

    这篇文章里有很多精彩观点适用于软件工程。如果隐性知识真如作者所说那么重要,那么雇用“年轻枪手”相比雇用做过此事的人,总是会有成本。作为一名年长开发者,这对我很有意思。但一个相反的观点是:也许所有业务都是新的探索领域,所以你不如付最便宜的人来发展你所在领域特定的隐性知识。如果隐性知识不是靠阅读就能获得的,那么培训和导师制就比把所有东西写进 wiki、或确保一切都在写得好的 pull request 中异步完成,要好得多(甚至可以说至关重要)。如果隐性知识那么重要,那么获得它就是一种特权。如果你处在可以带薪发展这些技能的位置,而不是只能在孩子睡后晚上自学,那是一种特权。很多人没有这种特权,但软件行业部分地以“你必须自学”为荣;如果你不这样做,你就不会在工作中成功。隐性知识不是那么回事。

    xrd查看英文原文

    So many amazing thoughts in this article that apply to the world of software engineering. If tacit knowledge is as important as the author makes out, then hiring "young guns" is always going to have a cost over hiring people that have done it before. As an older developer, that's interesting to me. A contrary point, however, is that maybe all businesses are new domains of exploration, so you might as well pay the cheapest person to develop your domain specific tacit knowledge. If tacit knowledge is not something you can get by reading, then training and mentoring is much better (dare I say vital!) than documenting it all in a wiki, or just making sure everything is done asynchronously in a well written pull request. If tacit knowledge is that important, then getting it is a privilege. If you are in a position where you can be paid to develop those skills and don't just have to read up in the evenings after your kids have gone to bed. Many people don't have that privilege but the software industry prides itself partially on the idea that you just have to self teach yourself; if you aren't doing that, you won't be successful in your job. Tacit knowledge is not that.

    历次讨论

    同类还值得读

    1. 用十年时间自学编程(1998)

      Teach Yourself Programming in Ten Years (1998)

      Peter Norvig 1998 年的经典文章,回应“21天/24小时学会编程”一类速成书,主张真正精通编程需要约十年持续、有意识的练习。

      职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选
    2. 如何成为一名程序员:简短、全面而个人的总结

      How to be a Programmer: A Short, Comprehensive, and Personal Summary

      一篇广为流传的程序员成长指南,作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。

      职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选
    3. 不要自称程序员

      Don't Call Yourself a Programmer

      经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上,而要从公司业务角度说明自己创造的价值;文中讨论了成本中心与利润中心、头衔、求职与职业选择,也顺带批评了学术界的价…

      职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选
    4. 创作者的日程与经理的日程

      Maker's Schedule, Manager's Schedule (2009)

      Paul Graham 在这篇文章里把时间表分成两类:管理者的日程以小时为单位,会议可以填满一天;创作者(程序员、写作者等)的日程则以半天为单位,需要长时间不被打断的连续块。

      职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选
    5. 为什么程序员的薪酬不与生产力成正比

      Why programmers are not paid in proportion to their productivity

      讨论为什么程序员的薪酬往往不随其生产力成比例增长:生产力难以客观量化,薪酬更多受组织预算、岗位定价和个人议价能力影响。

      职业与工作方法上首页 5 次 · 2009–2022johndcook.com

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。