职业与工作方法starling-software.com
程序员能力矩阵表
Programmer Competency Matrix
2010 — 2012，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是一个程序员能力矩阵，将程序员在编程知识、代码质量、工具使用等多个维度上的水平分为0到3级。它由Starling Software公司发布，常被用作讨论如何评估程序员技能的框架。
为什么经久不衰：它用一张简洁的表格把模糊的“程序员水平”拆成可讨论的维度，尽管争议不断，却持续引发关于招聘、技能衡量和CS知识的经典辩论。
HN 评论精选
批评矩阵过于武断、忽略软技能，无法衡量真实能力。
这只是某个人非常主观的看法做成的表格。评估技能是软科学，招进来几个月才能真正确认水平。有些人擅长修bug但语言经验窄，有些人团队协作好、产品反馈强，这些在这张表上完全没有。经验不是看年限，而是看学到多少。这个表漏洞太多，作者似乎很想把人简化成一个数字，这很糟糕，也会骗到自己。
andrewvc查看英文原文
This is someone's (very arbitrary) opinion in a grid. I hope you don't actually interview people. Figuring out someone's skill level is a soft science; it takes months after a hire to really know where someone is. Some people I know are great at fixing bugs but have narrow language experience. They're damn valuable. Others integrate well into teams and provide great product feedback. Where's that on here? Experience isn't measured in years but in knowledge gained. You really start seeing it 4-5 years in, some people move forward, some don't. There are so many holes in this. I feel like whoever wrote this has a strong desire to reduce people to a number. It's not only terrible, it's a great way to fool yourself.
认为编程能力在于按需研究解决问题的能力，而非全盘掌握CS知识。
我不确定这和‘能力’有多大关系。我高中时用光子映射做光线追踪器，写了个kd-tree。我知道我的n^2算法慢，Google一下就会写这种结构了。我不是程序员（我是化学工程师），不会立刻知道各种算法的复杂度，按这篇文章我就‘不合格’。但真要实现东西时，我会研究并找出最高效的算法。编程好坏可能更多在于知道什么时候需要什么知识，而不是掌握一大堆CS知识。
Xcelerate查看英文原文
I'm not sure this has anything to do with "competency". When I was in high school, I implemented a kd-tree for a ray tracer using photon mapping. I knew that my n^2 algorithm was slow and that there was probably a better way, so I Googled and figured out how to write code for such a structure. Since I'm not a programmer (I'm a chemical engineer), I don't instantly know all of the orders of various algorithms (which according to this article makes me "incompetent"). But you can bet that when it comes to implementing something, I'll research and figure out the most efficient algorithm available and use it. I'm not sure being good at programming has much to do with having a whole bunch of CS knowledge; rather, it's being able to figure out what knowledge you need to know -- when you need to know it.
用幽默方式给读者反应分级，暗示自我认知和行动比表格本身更重要。
我的版本：0级：看了标题，觉得自己能力很强，不需要看。1级：看了，发现很多不懂，但没打算去学。2级：看了，把里面不懂的东西都学了一遍。3级：看了，判断哪些不懂但可能需要或想学，然后去学那些。另外特殊-1级：看了，发现很多不懂，然后断定这文章很蠢，因为自己显然是个了不起的程序员，文章不认同这个自我评价。
lathamcity查看英文原文
Here's mine: Level 0: Saw the post title and didn't think he needed to look at it because he was so confident in his abilities already. Level 1: Read the post, noticed a lot that he didn't know but didn't intend to do anything about it. Level 2: Read the post and went out and learned everything in it that he didn't know. Level 3: Read the post, figured out which things from it he didn't know but might need to or want to, and learned those. Oh, and a special level -1: Read the post, noticed a lot of things that he didn't know, and decided the post was stupid because clearly he's an amazing programmer and the post didn't agree with that self-assessment.
指出矩阵的工具列表中遗漏了Unix/Vim/Emacs等经典工具，有平台偏见。
这个表有点Windows中心。我从来没听说过“Scott Hanselman的power tools”。里面完全没提Vim、Emacs或UNIX。
naz查看英文原文
Seems a bit Windows-centric. I've never heard of "Scott Hanselman's power tools". Not a single mention of Vim, Emacs or UNIX.
历次讨论
同类还值得读
用十年时间自学编程（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