职业与工作方法blizzard.cs.uwaterloo.ca编辑精选
如何阅读一篇论文
How to Read a Paper (2016) [pdf]
2017 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 S. Keshav 的经典短文《How to Read a Paper》，提出用“三遍法”阅读科研论文：先快速浏览摘要、引言和结论抓住大意，再细看图表与方法，最后深入细节、以近乎复现的方式理解。文章也谈到文献调研和审稿场景下如何高效筛选与精读论文。
为什么经久不衰：方法简单、可操作，几乎适用于任何学科，多年后仍是科研入门和高效筛论文的实用指南。
HN 评论精选
只读文本不够，还要理解论文的研究范式与历史语境。
这篇对如何读论文正文给了不错的提示，但我认为它漏掉了理解论文所需意识到的所有重要方面，特别是论文所属的研究范式或研究纲领、历史背景等。我最近写了一篇关于这个的文章。
tpetricek查看英文原文
This has some nice hints on how to read the text of a paper, but I think it misses all the important things that you need to be aware when you want to understand a paper. In particular, things like the research paradigm or research programme in which the paper fits, its historical context etc. I wrote a post about this recently: http://tomasp.net/blog/2017/papers-we-scrutinize/
质疑 ML 论文难以判断可复现性和结果可靠性，不能只靠同行评审。
我知道这里有大量 ML 研究者和从业者，可惜我读 ML 论文的经验很浅，对近期成果更是如此。但我必须问：你怎么判断内容看起来是对的，而不只是忽悠？改进通常只在 1% 范围，模型又复杂，还常常缺代码、实现和实验流程。基本上我不知道论文是否可复现、结果是否从上千万次运行中挑出来的、是否只是包装巧妙、数字注水以拿经费。目前我只能依赖同行评审专家的保证，但心里仍怀疑他们是否有时间严格评审。如今 ML/AI 论文产出惊人，系统又复杂，我不信单个博士后或研究者有时间复现结果。
TrackerFF查看英文原文
I know there are a lot of ML researchers and practitioners here - and I have unfortunately only a very shallow experience with reading ML papers, more so with the recent output. But, I have to ask, how do you get a feel that the content actually looks correct, and not just only quack? The improvements are usually in the 1% range, from old models to new models, and the models are complex. More often than not also lacking code, implementation / experiment procedures, etc. Basically, I have no idea if the paper is reproducible, if the results are cherry picked from hundreds / thousands of runs, if the paper is just cleverly disguised BS with pumped up numbers to get grants, and so on. As it is right now, I can only rely on expert assurance from those that peer review these papers - but even then, in the back of my mind, I'm wondering if they've had time to rigorously review a paper. The output of ML / AI papers these days is staggering, and the systems are so complex that I'd be impressed if some single post. doc or researcher would have time to reproduce results.
把三遍法改造成阅读代码的流程：先看结构入口，再看调用图，最后细读关键函数。
能把步骤套用到读源码吗？我的改编是：1）有 README 就读，浏览源文件列表了解模块化，找入口点，从 main 判断程序类型（服务器、CLI 还是图形应用）。2）有调用图工具就跑，从入口研究调用树，只读函数名并记录各层执行方式，比如读输入后进无限循环、等网络包、update/render 循环等；快速扫一眼标记函数是否琐碎。3）忽略琐碎函数，细读非琐碎函数，记录算法、数据结构和依赖。
tjchear查看英文原文
Can we apply the steps to reading source code? Here's my take on adopting it to reading code: 1. Read readme if available, read the list of source files to get a sense of how the project is modularized. Identify the entry point. Identify type of program from main entry point: is it a server, a CLI, or a graphical app? 2. Run call graph analysis tool if you have it, so you can study callgraph tree starting from main entry point. Read just the function names and start making notes of how the execution works at various levels, e.g does it read input then enter an infinite loop, does it wait on network packets, does it use update/render loop, etc. Also make note of whether a function is trivial/non-trivial based on quick glance at the code. 3. Ignore the trivial ones, and read the non-trivial ones in detail. Make note of the algorithm, data structures, and dependencies.
原以为只是摘要+结论+图表，实际给出了更细的递进阅读法，值得重读。
我本来准备好嘲讽说，我读大多数论文只有 1）读摘要 2）读结论 3）看图。结果发现这基本就是论文说的，但它进一步讲了如何进一步深入。至少值得再读一遍。
AndrewOMartin查看英文原文
I was all ready to mock this by saying how most papers get only 1) Read the abstract, 2) Read the conclusion, 3) Look at the graphics, from me. Turns out that it's basically what the paper says, but then goes into more detail about going into more detail. Worth at least a second pass :)
历次讨论
同类还值得读
用十年时间自学编程（1998）
Teach Yourself Programming in Ten Years (1998)
Peter Norvig 1998 年的经典文章，回应“21天/24小时学会编程”一类速成书，主张真正精通编程需要约十年持续、有意识的练习。
职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选如何成为一名程序员：简短、全面而个人的总结
How to be a Programmer: A Short, Comprehensive, and Personal Summary
一篇广为流传的程序员成长指南，作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。
职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选不要自称程序员
Don't Call Yourself a Programmer
经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价…
职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选创作者的日程与经理的日程
Maker's Schedule, Manager's Schedule (2009)
Paul Graham 在这篇文章里把时间表分成两类：管理者的日程以小时为单位，会议可以填满一天；创作者（程序员、写作者等）的日程则以半天为单位，需要长时间不被打断的连续块。
职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选为什么程序员的薪酬不与生产力成正比
Why programmers are not paid in proportion to their productivity
讨论为什么程序员的薪酬往往不随其生产力成比例增长：生产力难以客观量化，薪酬更多受组织预算、岗位定价和个人议价能力影响。
职业与工作方法上首页 5 次 · 2009–2022johndcook.com