在超过三十年的写作、编辑和出版生涯中，我据我所知，已经介绍、节选、出版或再版，并阅读了几乎所有用英语创作或翻译的经典励志文学作品。基于经验，有效生活的“准则”——至少是我认为适合一个有道德和负责任的人的准则——可以归纳为以下几点：
拥抱行动，但要明白事情会发生变化。相应地进行设计。做出有意且易于逆转的决策。留出空间，以便在出现问题时进行调整。设计能够在需要扩展时发出警报的系统。
很明显，有些程序员的工作效率远远高于平均水平，而且对世界仍然需要的解决方案有着敏锐的触觉。一个程序的成功可能是运气或巧合，但这一系列的成功似乎有其系统性
我写代码赚钱已经有 15 年了。我尝试过其他角色–产品管理、分析、测试–但都没有坚持下来。这些年来，我发现自己很笨。很不幸。
找到自己喜欢做的事情，因为喜欢所以去做。如果有必要，可以为自己制定一些目标，但绝不是为了你的 “观众”。
我发现在玩 RPG 游戏时，我经常会囤积药水和卷轴等一次性物品，留待将来的关键时刻使用。在玩完《天际》等游戏时，我的背包里装满了未使用的资源，这些资源都是为了应对从未出现过的危机。那么，这些物品有什么用呢？
我读过无数的博客，看过很多关于解决这个问题的视频，尝试过不同的方法，但都失败了。这是抑郁症还是多动症的表现？
让精细运动系统参与手写字母对学习和记忆有积极影响
我不希望这变成一场语言大战。我的问题是出于善意，而且我确实想从在这里发表评论的人们那里汲取智慧。使用 Rust 的时间比我长得多的人可以提供我可能不知道的宝贵见解。因此，为了避免 “火焰战争”，请允许我尽可能具体地说明这个问题：
面试中没有正确答案。也没有错误的答案。这个世界太微妙、太复杂了。
我不做程序语言（PL）的工作已经半年了。在这半年里，我变得快乐了很多，对世界也有了新的观点。现在我想来讲一讲，我为什么不想再做 PL 的工作和研究。我只希望这些观点可以给正在做 PL，或者考虑进入这个领域的人们，作为一份参考。
理 想的工作-休息比例是 52 分钟的工作之后进行 17 分钟的休息。按照这种时间分配，工作时会格外集中注意力。约 1 小时的时间里，大脑会 100% 专注于将要完成的任务，而不会去刷微博或被邮件分心；1 小时结束大脑开始感到有些疲劳时，完全放下工作，短暂地休息一会，又有助于在接下来的 1 小时重新高效率工作。
不论在哪个国家，IT 公司中的项目经理，很大一部分都是技术出身。的确，工程师背景的项目经理，在开发人员选择，开发进度控制，客户需求把握等诸多方面，有得天独厚的优势，从程序员到 leader 再到项目经理也是常见职场发展方向之一。
与其他互联网热词一样，全栈工程师也是英译过来的，英文全文是：Full-Stack Developer，你想啊，中国人民怎么会用客栈的栈、堆栈的栈来形容工程师呢？
对于团队来说，我们希望程序员具有第一种编程高手的天份，同时写出来的代码要像第二种编程高手那样方便理解。需要注意提升的是第三种编程高手，他们缺乏第一种编程高手的天资，同时还没有掌握第二种编程高手的技能，经常自己被自己写出来的代码搞糊涂。
关于技术领导力已经有很多的讨论，我自己也写过好几篇文章。这次我避免“大而全”地讨论技术领导力，只简单谈谈技术领导力的几个主要侧面，供大家在自己的工作中参考。首先要明确的是，我们谈的是“技术领导”而不是“技术管理”。
“华为”成为媒体热词。“华为人”成为网民关注的对象和群体。甚至连其工资收入等敏感问题都已被脱敏晒在互联网上。我们常被各种各样的统计数据平均，这次也不例外。华为人的年收入也被“人均80万”了。这是一个令人羡慕的数字。然而身边的华为人对此嗤之一笑说“对不起，我拖后腿了”。
经常有人发帖讨论「怎么做一个成功的程序员」，「如何才能成为一个优秀的程序员」，我并不太同意这些文章中的看法，想在这里我想提出一些我对于程序员这个职业自己的想法。
我专业从事软件开发工作已超过 10 年的时间，我热爱这份事业，希望有一天我会被人们称呼为老程序员。但这一路走来，我经历了许多可怕的事情，这些事情让我讨厌我的工作。在职业生涯早期，我曾期望有人能给我一份职场指南，这样当遇到之前未曾遇到的事情时，我就不会感到如此的孤单和沮丧。
总有人质问：“我现在学编程晚吗？”，“我 30 岁之后还能继续写程序吗？”，“学编程难吗？”看完这篇文章后，我相信你不会再问了，因为如果你真的是热爱编程，你就应该像我父亲那样，无论现实如何逼迫，初心永远不忘。
十一回来，第一天上班，领导找我说，你的人都划入各个事业部，管理权也都放在各事业部，于是我就成了一个光杆司令，后续未知。小组是个技术团队，现有10人左右，承接着公司各个事业部的技术开发任务。公司业务人员已经分成了事业部，由于技术的平台性和共享性，技术一直是以研发中心存在的单独部门，没有分开。
“换一个灯泡需要多少个______？” 类似的笑话有无数个版本。
多年以来，软件行业一直在使用一种类比，即以建筑行业来做参考和比喻。这种比较在软件语言里随处可见，比如架构（architecture）、地基（foundation）、建造者（constructor）、项目（project）、施工规范（building code）等。这些说法是如此之流行，以至于影响到了我们对软件开发的理解。不幸的是，这种比喻从根本上来说是不恰当的，它的缺陷已经把我们引向了一些错误的道路。
“吃饭、睡觉、写代码、周而复始”这句口号在会议期间随处可见。我之前也读到过，只是这一次尤其触动我，或许原因是如此重要的技术大会不遗余力的大势宣传。毫不夸张地说，我的确确在见到标语时发出了一声感叹。
项目开始，晃晃悠悠 项目收尾，点灯熬油的情况 大家一定经历过很多吧？在这个行业里面都说，女人当男人用，男人当牲口用。虽然程序媛们很辛苦，但我想也一定是累并快乐着吧。经历过赶场似的项目，累归累 但也学到了很多东西不是吗？各位职场新人们，如果你们有什么感悟的话，欢迎在下面留言，和大伙儿分享一下吧。
高效生活的101条法则
微软希望Windows Update能够管理所有应用程序
对 Rust 10 年的押注以及我对未来的期待
苹果： 密码监控服务从 Java 迁移到 Swift
关于 JavaScript "工作证明（proof of work） "防抓取系统的思考
关于程序员过时的传说
这是 JavaScript 吗？
为什么DeepSeek在规模化部署时成本低廉，但在本地运行时却成本高昂？
为什么 2025/05/28 和 2025-05-28 在 JavaScript 中是不同的日子？
为什么原始的Macintosh屏幕分辨率是512×342，而不是人们可能预期的512×384
