职业与工作方法training.kalzumeus.com编辑精选
不要空手结束一周（2014）
Don't End the Week with Nothing (2014)
2014 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Patrick McKenzie（patio11）2014 年的一篇职业建议通讯：不要把一周过完却没有任何可展示的产出。作者主张工程师持续制造并公开分享工件（代码、文章、演讲等），把工作转化为可见的职业资本，让机会更容易主动找上门。
为什么经久不衰：它把职业发展落到“每周留下可展示的产出并公开分享”这一可执行动作上，十几年后仍是关于可见性、个人职业资本的长青建议。
HN 评论精选
博客等公开输出能弥补学术或工作成果缺乏可见信号的问题，直接帮助求职。
我喜欢这个框架。读研时，我干了两年多才发表第一篇论文；期间通过了博士资格考试、上课、写代码、读论文、学数学等等，但申请实习时没有雇主感兴趣。我怀疑是因为我没有任何具体信号表明自己懂这个领域。写第二篇论文时我开始写博客，用这篇文章的话说，就是开始为自己积累公共智力资本。我确实感受到这种资本对后续求职的影响：现在我可以让人看博客，展示同行评审论文之外的 knowledge、技术技能和沟通能力。而且博客贡献者是谁没有疑问，学到新东西也能很快外化出来。
gwgundersen查看英文原文
I like this framing. In graduate school, I worked for 2+ years before my first paper was published. In that time, I passed my PhD qualifying exam, took classes, wrote code, read papers, learned math, and so forth. Yet when I applied for internships, I received no interest from employers. I suspect this was because I had no concrete signal that I knew anything in my field. While working on my second paper, I started blogging. In the language of this article, I started generating public intellectual capital for myself. I have definitely experienced the effects of this capital on subsequent job hunts. Now I can point people to my blog to demonstrate knowledge, technical skills, and communication skills beyond the scope of my peer-reviewed work. Furthermore, there is no question about who contributed to my blog, and when I learn something new, I can externalize that quickly.
Fog Creek/Stack 的“默认开放”实践表明，公开工件未必直接帮到公司，却显著提升个人职业。
嘿 Patrick，谢谢文章。“产出工件”正是我们在 Fog Creek 的叫法，Stack 那边的同事可能用不同术语但精神相似。直到现在我才意识到这是来自我们那个软件小世界的词。Stack 早期有“默认开放”政策，所有工件——代码、公司写作等——都公开，这启发了 FC 很多人。我们加倍公开工件，产生了开源贡献、博客、会议演讲。有趣的是，这些公开工件大多对公司影响不大，但毫无疑问强化了创造者的职业生涯。我仍把“确保工作产生工件；收集并分享工件以放大影响”列为软件人职业建议前列。
blinkymach12查看英文原文
Hey Patrick! Thanks for the article. "Producing Artifacts" is definitely what we called that at Fog Creek, and I think our cousins at Stack may have used a different term but followed much the same spirit. I didn't realize until now that that was a term from our little software microcosm, I had assumed it was one of the terms that was known broadly in the startupverse. I definitely came to my opinions around it through my interactions with the Business of Software conference and (later) Microconf, and I think in parallel Stack Overflow came to much the same conclusions as we did at FC. Stack also lead with something in its early days which pushed us to go further, which was that they had a "default open" policy on all their artifacts-- code, company writing, etc. This specifically was inspiring for us at FC and many of us sort of implicitly adopted it. We doubled-down on our artifact publishing, leading to a bunch of open source contributions, blog posts, conference talks, etc. Interestingly (and to your point!) I think that those public artifacts for the most part didn't impact the company very much (as much as we did try to harvest the artifacts for blogging/marketing/recruiting purposes), but they unquestionably strengthened the careers of the folks who created them. "Make sure your work is creating artifacts; Collect and share your artifacts to multiply their impact." Remains among my top items of career advice for software folks.
质疑文章以可见性衡量价值：不起眼公司的内部优化同样有巨大社会价值。
“别试图在一家没人听说过的公司里，靠优化一个业务应用偏好页的 SQL 查询来打造职业生涯。那不是让别人知道你能够做有意义工作的直接路径。”这太可悲了。优化那个 SQL 可能需要非常聪明，也可能为一家没人听说过、但也许正在为半个国家提供不性感却有用服务的公司带来巨大价值。我从没听说过为附近电厂运行软件的公司，但它肯定比 Facebook 这类“性感”公司对社会更有用、反馈更正面。
piokoch查看英文原文
"Don't try to make a career out of optimizing the SQL queries to display a preference page on a line of business app at a company that no one has ever heard of. That is not the straightforward path to having other people learn you are capable of doing meaningful work." This is so sad. Optimizing that SQL might require being really clever and can bring enormous value for the company that maybe nobody heard about but might be providing some not so sexy but useful service for half of the country. I've never heard about company that is building software that runs nearby power plant, but certainly this company is much more useful and have more positive feedback for the society than something "sexy" like Facebook.
公开作品集在小型或非热门技术市场仍不足以克服地域和雇主市场结构。
美国和比利时差距巨大：我有不错的 GitHub 公开主页，是经验丰富的 Python/Haskell 开发者，正在做 Reesd（冗余存储服务），包括 Docker/Open vSwitch、Web 前端、SCP 重实现、冗余存储、后台 SHA1 检查、Stripe 支付、HAProxy、Mandrill 邮件、PostgreSQL 同步复制等。我觉得已经向潜在雇主充分证明了自己，但不移居国外仍极难找工作：比利时非 Java/.NET/C# 开发者市场很小，Python 职位公开只有一两个，薪水低因为市场在雇主一边。看到硅谷的待遇觉得疯狂。顺便问，这大概是我第三次在 HN 评论里贴 Reesd，是否合适？
thu查看英文原文
The disparity between the U.S. and Belgium is huge: I have a nice GitHub public profile. I am a capable and experienced Python and Haskell developer. I am building Reesd (https://reesd.com), a redundant storage service made of: - Several Docker containers, linked through Open vSwitch, - Web frontend, - SCP reimplementation with account permissions and bucket plan limits, and on-the-fly SHA1 check, - Redundant backend store, - Background jobs to check files SHA1 to detect early corruption, - Payment done through Stripe (almost done), - HAProxy, - Email through mandrill, - I'm working on adding PostgreSQL synchronous replication. I think I have largely proved myself to possible employers. Still it is excessively difficult to find a job without moving abroad: the belgian market for non-Java/.Net/C# developers is small. Search for a Python developer position, you'll find 1 or 2 public postings. And they will offer you a ridiculously small salary since the market is on their side. When I see the perks you are offered in the SV this is crazy. And then you have posts like these to move you forward. A chance HN is accessible abroad :) B.t.w. it's maybe the third time that I post Reesd as part of a comment on HN. I think it made sense to include the link in my comment; but still, is it ok to do so regularly even if the subject makes sense ? Edit: hey, thanks for the replies!
历次讨论
同类还值得读
用十年时间自学编程（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