职业与工作方法overreacted.io编辑精选
截至 2018 年，我还不知道的事情
Things I Don’t Know as of 2018
2018 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Dan Abramov 在 2018 年写的一篇自述，列出自己作为 React 开发者尚未掌握或只略知一二的技术领域，例如容器与 DevOps、函数式编程等。文章的重点不是技术教程，而是坦承知识边界，说明开发者不必样样精通。
为什么经久不衰：它用具体清单打破“资深开发者无所不知”的幻觉，缓解冒充者综合征，并鼓励按需学习。
HN 评论精选
DevOps/K8s 很难向产品开发者有效科普，演示有效但日常推广困难。
文章很棒！我喜欢更坦率地面对自己不知道的东西这个想法。我一直在努力梳理教育开发者 DevOps/Kubernetes 的方法。我坚定认为 Kubernetes 是救命、颠覆性的，但向产品导向开发者解释常失败——要么太低层，要么太高层含糊，或者他们听完只觉得“有一天可能很酷”，而不是“我们今天就能上手”。最成功的做法是演示，比如用 4 个树莓派搭 K8s 集群，拔电源/网络/磁盘展示自愈和自动发现，但在日常压力大的公司效果不佳，而且演示也只触及 Deployment API 的表面。
erulabs查看英文原文
This is an awesome article! I like the idea of being more forthcoming with what we don't know. > Containers. I have no idea about how to use Docker or Kubernetes. (Are those related?) I have a vague idea that they let me spin up a separate VM in a predictable way. Sounds cool but I haven’t tried it. > Deployment and devops. I can manage to send some files over FTP or kill some processes but that’s the limit of my devops skills. I'm working hard on trying to tease out a method to educate developers about DevOps / Kubernetes... It's hard to explain to people who have not been on-call or walked into a company on their first day as a devops, but I am strongly in the camp of "Kubernetes is live-saving, game-changing, etc". I tend to fail to explain to most product-focused developers successfully - Either too low level, too high level and hand-wavey, or they walk away with a sense of "man one day, that might be cool", rather than "We could get going on this _today_!". The most success I've had is in demonstrations (I have a raspberry Pi Kube cluster with 4 pies, with which I can physically unplug power, network, disk, etc and show off Kube's self-healing and auto-discovery powers), but at companies with day to day stresses, not so much. Plus the demo only scratches the service of cool features of even the Deployment API object. Shameless self promo, but I'm working on a project with a friend that hopefully helps. I want product-focused developers to have a "Heroku" moment about kube and understand the immense benefits they get from designing their applications with a "cloud-native" mindset. That the small cost is _vastly_ worth the benefit. The project is here: https://kubesail.com/. My "thing I dont know as of 2018", just for good measure: How to build complex front-end applications without making a complete mess of things!
用清单逐个浅尝，能打破对陌生技术的心理障碍并拓宽视野。
不想偏离核心信息，但我过去喜欢的一种学习方式是：列出这样一份清单，然后试着每个都学一点。不需要深入，只要 hello world 或类似基础来试水。如果只学解决当前问题的技术，很难拓宽广度，所以有时单纯探索一门技术、看看它是什么样也很有趣。有了更扎实的基础理解，未来可能识别出它有用的场景，或适合放进 side project。当然这不代表你就掌握这些，但一点小经验能打破心理障碍，从令人生畏的未知变成稍微具体一点的东西。
alangpierce查看英文原文
Not to derail the core message, but one learning approach I've enjoyed in the past is to come up with a list like this and then try to learn a little bit about all of them. Doesn't need to be deep knowledge, just a basic "hello world" or equivalent to get your feet wet. It's a lot harder to get breadth when you stick to technologies that solve a problem you're facing, so sometimes it's fun to just explore a technology for the sake of seeing what it's like. Maybe with a more solid basic understanding, you'll recognize a case in the future where it could be useful or where it would be fun to throw into a side project. Also, some technologies may stand out as more fun and things that you naturally want to dig into further. Of course, that doesn't mean you now know any of these things, but even some small experience breaks through a psychological barrier, from something intimidating and unknown to something a bit more tangible.
作者不精通函数式编程让评论者意识到自己把 React 社区对 FP 的推崇投射成了普遍标准。
很惊讶他不精通函数式编程……我一直以为 React 背后的人都希望让 Web 编程更函数式，并认为这是目标，而且这建立在对 FP 的深入理解上。这曾激励我多学 FP，这当然不坏。但我想我是在投射：我有个一直觉得比我聪明的朋友盛赞 FP，我就以为这是聪明人普遍认识到的编程真理。知道 Dan 其实并不那么宗教化挺好。我想知道其他 React 开发者怎么想。
oraphalous查看英文原文
Very surprised that he is not expert at functional programming... I always assumed that all the folks behind React were driven by a desire to make web programming more functional generally - that this was an ideal toward which they thought we should be working. And furthermore assumed that this was informed by a deep understanding of functional programming generally and the reasons why it is desirable as a programming methodology. That inspired me to learn more about functional programming... which definitely wasn't a bad thing to do. But I guess I have just been projecting - I have a friend who I've always considered smarter than me who raves about functional programming... and I guess I just thought this is what smart people generally have come to realise is the god's truth about programming. It's good to know in a way that Dan is not in fact this religious about it. I wonder how other React devs feel.
编程领域很宽，专精于游戏/实时 3D 的人可以完全不懂 Web 技术也取得成功。
我喜欢这份清单。我最喜欢的一点是：我不仅不知道其中大多数东西，而且我根本不想知道。我的背景是电子游戏，专攻实时 3D 应用。我认为 Web 技术是过度复杂、层层堆叠的残渣。编程是一个宽广多样的领域。Web 开发占编程工作的绝大多数，但你可以完全不懂这些，仍然拥有非常成功的职业生涯。
forrestthewoods查看英文原文
I love this list. My favorite thing about it is not only do I not know most of those things I don’t _want_ to know them. My background is video games. I specialize in real-time 3D applications. I think web tech is an overcomplicated embarrassment of cruft built on cruft built on cruft. Programming is a wide and diverse field. Webdev is the overwhelming majority of programming jobs. But you can have a very successful career not knowing _any_ of that stuff.
历次讨论
同类还值得读
用十年时间自学编程（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