Joel Spolsky，生于美国新墨西哥州，著名的软件工程师，作家，软件开发相关博客“JOEL ON SOFTWARE”的作者。1991 年毕业于耶鲁大学，在1991年至1995年间，他担任了Microsoft Excel小组的程序管理经理。2000年，他创立了Fog Creek Software 公司（其核心产品有Trello、Glitch、FogBugz等），并开设了博客，命之为“JOEL ON SOFTWARE”。在2008年，在与杰夫·阿特伍德的合作下，他推出了面向程序设计的问答网站Stack Overflow。依靠Stack Overflow所基于的软件Stack Exchange，Stack Exchange已托管了过百个问答网站。Joel Spolsky 同时也是 HASH.AI 的联合创始人。
Joel Spolsky在新墨西哥州的阿尔伯克基一直生活至15岁，此后便和家人搬到以色列耶路撒冷。在耶路撒冷，他就读高中，并于其后以伞兵的身份服兵役。1987年间，他返回美国读大学。他在宾夕法尼亚大学就读一年后，转学到耶鲁大学，就读其下属的皮尔逊学院，并于1991年毕业，获得计算机科学最优等理学学士学位。
1991年间，Joel Spolsky 开始受聘于微软公司，担任 Microsoft Excel 团队的程序管理经理。在任职微软期间，他设计了Excel Basic，并主掌着微软的Visual Basic for Applications战略。在1995年，他迁至纽约市，并先后就职于维亚康姆传媒公司与朱诺在线服务公司。
在2000年，他创建了Fog Creek Software公司，并开设了名为“Joel on Software”的博客，这也是“由企业主开设的最早的（几个）博客之一”。
2005年间，Joel Spolsky与他人合作摄制了纪录片《Aardvark'd: 12 Weeks with Geeks（英语：Aardvark'd: 12 Weeks with Geeks）》，记录了 Fog Creek Software 在开发远程协助工具 Project Aardvark 时的一些片段。另外，Joel Spolsky也和杰夫·阿特伍德共建了一个面向软件开发者的问答社群——Stack Overflow。他现任 Stack Exchange Network 的首席执行官。
2011年间，基于看板管理理论，Joel Spolsky 开发了一个简洁的在线项目管理应用Trello。
他还是“乔尔测试”的发明者。另外，在流程改善领域，Joel Spolsky 提出了一个术语“修复两次（fix it twice）”，即是说，当出现问题时，先用快速、直接的方法修复之，而后针对根本原因，再用较慢的方法再度修复，以避免同一问题再度出现。
Joel Spolsky 的观点
- 不要总去创造市场，而是看看用户迁移到你的产品有什么障碍
成熟的战略方法不是强迫潜在用户接受，而是在你弱小的时候，通过兼容巨头的功能，消除迁移障碍。 - 创造热情的用户
- 阅读代码比写代码更难
但这不是重构的理由。程序员往往被比喻为建筑师，他们到了一个新地方感兴趣的就是推倒重建，建造一些宏伟的东西，而对渐进式改造不感兴趣：修补、改善、种植花园。 - Fire & Motion
所有军事行动都是基于 Fire & Motion。其根本原因就是，每天必须向前迈进一小步。别管输出的东西有多烂，只要你还在前进，时间就站在你这边。你迟早会赢，因为你的软件每天都在变的更好。所以，每天最关键的就是，清晨打开编辑器。 - 修复两次 | fix it twice
当出现问题时，先用快速、直接的方法修复之，而后针对根本原因，再用较慢的方法再度修复，以避免同一问题再度出现
一些语录
- 设计增加价值的速度快于增加成本的速度。
- 好的软件，就像葡萄酒一样，需要时间。
- 如果你的目标是生产一些具有永久价值的东西，你就会开始在网站上以不同的方式思考你想要的东西。
- 生活有时有点艰难，有时你必须挺身而出，打一场你从未报名的战斗。
- 谨防方法论。它们是将每个人提升到令人沮丧但尚可的绩效水平的好方法，但与此同时，它们也限制了更有才华的人，他们对施加在他们身上的限制感到恼火。
- 当程序的行为完全符合用户的预期时，用户界面就经过精心设计的。
- 永远不要把自己放在一个如果你做出错误决定就会让自己处于危险之中的位置。我们在一切事情上都花了现金。做出"All in"的决定是时髦的，但不要这样做。
- 巨无霸汉堡的秘密不在于他们多好，而在于他们是标准化的，无论背后操作的人是否是白痴。
- 避开攻击最好的方法，就是让攻击看上去好像成功了。
- 在软件中，对你最重要，最关键的部分，一定要用更原始的工具来开发。
- 不要因为有些事不得不做，你就去做，不得不做不是一个足够好的理由。
- 别给用户太多选择，太多选择会损害我们内心的幸福感。
Joel Spolsky 谈服务客户
- 两种解决问题的方案：解决当下问题，但后续还会重复。彻底解决掉问题，这个过程需要有调试能力。
- 让有问题的用户检查基础设置（比如重启下，重装下）
- 彻底的解决用户的需求，让用户对你着迷。这样他会比没有问题时更喜欢你。
- 承受责备，主动认怂。
- 学会说软话，不要在客户投诉时感情用事。最重要的是承认错误，然后解决掉问题。
- 做一个木偶，因为同客户争吵，你永远不会是赢家。因为赢了丢失顾客，输了自己郁闷。其实顾客不是针对你，而是这家公司的服务，试着将自己的身份抽离出来。
- 对待顾客慷慨（比如良好的退换货政策），降低顾客的不满。贪婪最终一无所获。 参考文章：https://www.joelonsoftware.com/2007/02/19/seven-steps-to-remarkable-customer-service/
Joel Spolsky 对管理方式的看法
身份视角的管理
核心是通过让人们认同你试图实现的目标来管理，核心是创造内在动机。要使用这种方法，必须让你的员工认同组织的目标，这样他们就有很高的积极性，然后你需要给他们所需的信息，以朝着正确的方向前进。就像 Apple 那样，在 84 年通过超级碗的广告 —— 反对极权主义，让整个公司和粉丝都拥有了近乎狂热的身份认同。在 Fog Creek 的方法很朴素，一起吃午饭，给实习生福利，让他们喜欢上纽约，这样他们毕业后就愿意来这个城市工作。 创造身份管理的方法一般有：
- 需要创建一个有凝聚力的团队，感觉像一个家庭，这样人们才能对同事有忠诚感和承诺。
- 为他们提供他们所需要的信息，引导组织朝正确方向发展，而不是保密文化盛行。
纯粹经济视角的管理
引入经济刺激的前提是假设组织的每个人都接受金钱的激励，所以这就成了管理的主要手段。问题在于，这样让外在动机取代了内在动机。当你付钱给人们让他们去做想做的事情时，都会遭遇过度合理的情况，当你减少金钱刺激的时候，他们已经不再关心对应的事情了。另一个问题是，这种管理会让人们倾向于找到将局部最优解，而不是全局最优解。他们会优化特定的东西，但你永远无法找到你真正想要的东西。 罗伯特·奥斯汀（Robert Austin）在他的《衡量和管理组织中的绩效》提到引入新绩效后的两个阶段：
- 起初，你实际上得到了你想要的，因为没有人想出如何作弊。
- 你实际上会得到更糟糕的事情，因为每个人都想出了最大化你正在衡量的事情的诀窍，即使以破坏公司为代价。 在这个情况下调整指标是无法避免这种问题的，因为从根本上来说，Eco101 管理根本不是管理，更像是对管理的放弃，他们不知道如何教人们做的更好，而是迫使系统中每个人都想出方法来做到这一点。作为管理者的责任是设计一套系统来解决问题，因为一线的人没有精力和信息来设计更好的系统，而管理者并不能通过贿赂员工来规避培训员工。一般来说管理层需要建一个系统来让人们把事情做好，避免用外在动机取代内在动机，而恐惧和命令无法让这个系统走的更远。
命令的视角管理
指挥和控制管理形式以军事管理为基础。但这种方法在高科技团队中有三个缺点。
- 人们讨厌折这种方法，扼杀了每个人的才智。没有用到所有人的大脑。
- 管理层实际上没有时间在这个层面进行微观管理，缺少时间了解和纠错。
- 高科技公司中，个人贡献者比领导者拥有更多信息，反而处于决策的更佳位置。管理者的信息是最少的。 军队之所以这么做，是因为让人们冲过雷区。但这种方式对高科技公司不起作用。
关于设计 - Joel Spolsky
- 虽然产品中经常出现二八法则，八成用户使用两成的功能，但是不意味着你实现20%的功能就能达到 80%的销量，原因很简单，每个人使用的是不同的 20%。
- 让20%的产品变得简单是一个很好的启动策略，但不是长期策略，因为这样并没有壁垒。
- iPod 并不是仅仅是简单，还要看到背后的营销、设计、反馈、内容等多方面的，因素，这些都是「功能」。只不过在 iPod 的设计方面，选择了干净和简单。
- 做加法才是增加覆盖率和营收的方式。
- 产品应该追求的是「简单」，即让用户很好地上手。而简洁更像是一种审美的喜好。
- 没有很多功能或者只做一件事并且做的很好，一个故意忽略相关功能的产品，很难走得远。
- 购买者更喜欢功能更强大的设备，而不是功能较弱的设备。他们将控件的表面简单性等同于缺乏功能：复杂性等同于功能。这并不意味着每个人。然而，它确实意味着大多数，这就是公司营销专家的目标。
- 正是表面上的复杂性推动了销售。是的，正是同样的复杂性让这些人在以后感到沮丧。但到那时，为时已晚：他们已经购买了该产品。
- 用户不并愚蠢，只不过并不想把注意力投入到你的产品中。
- 应该默认来设计产品不需要手册。
- 选择是美妙的，但是用户让他们对漠不关心的事情进行选择，会惹恼用户。用户关心的事情比你想象的要少得多。
- 用户只关心任务，并不关心其他的东西。所以设计师有义务帮他们做出选择，而让用户选择是一种傲慢的态度。
- 总的来说，应该减少人们必须做出决定的数量。但这不意味着消除所有选择，而对于他们正在解决的任务，可以提供更多的选项。
参考文章：
- https://www.joelonsoftware.com/2006/12/09/simplicity/
- https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
- https://www.joelonsoftware.com/category/uibook/
- https://www.joelonsoftware.com/2006/11/21/choices-headaches/
Joel Spolsky ，Trello 和 Stack Overflow 背后的人
你提高已有技能而不是学习新的技能。你消费的是你已经保存的各种媒体，而不是去获取更多。今年不允许有新的爱好、器材、游戏或书籍。相反，你必须在你已经拥有的或者已经开始的东西中找到价值，深入挖掘价值和充实他们。转向已在你的房子里的那些财富进行选择。 如果今天问程序员是否使用过 Stack Overflow，就像问你今天是否体验了地心引力一样。之所以选择研究他，是因为在翻看所有内容的过程中，许多价值观非常接近，比如对于企业的路线选择（更偏向于独立企业），公司的管理（以归属感和创造力为核心），产品的设计等；另一方面里面其文字具体而真实，能看到是亲自尝试过之后得到的经验总结，而且极端务实，比如尽量避免重构，如何当好一个客服等。 他的成名很早，2000 年伊始，就开始打理 Joel on Software 网站 —— 或者说应该称之为叫 Blog，只不过比 Blog 这个名词出现的还早。他也是是 Fog Creek Software 的创始人之一，在创业的一路上围绕「如何帮助世界上最好的开发人员制作更好的软件」这个思路，诞生了 Trello 、Glitch、以及 Stack Overflow。 除此之外，他还于 91 年在 Excel 团队中工作过一段时间，任 Excel5.0 VBA 的项目经理，所以有一些关于历史竞争的回溯，值得我们去学习思考 —— 当年微软弱小的时候，是如何成长起来的。另外他还当过一阵时间的以色列伞兵，鉴于部队的经历，反而很讨厌自上而下的集权控制。但军队给他了一些另外的启发，写出了那篇比较知名的《Fire & Motion》，也间接让我从一个人生的低谷走出。由于水平有限，下列文集推荐仅是个人视角，比较偏重企业经营和产品设计。其博客中还有许多关于技术和开发的观点，如有兴趣可以自行翻阅。
巨无霸汉堡的价值与代价
世界上许多大的咨询公司看起来都很单调死板，而许多小的新兴的咨询公司很快都能后的一些列的成功，但很快就会陨落。这个问题的答案来自于麦当劳。因为巨无霸的秘密不在于他们有多好，而在于他们完全相同 —— 无论在什么样的环境中，你都能得几乎一模一样的汉堡。 另外一个秘密是，巨无霸汉堡的制作，是最聪明的和最白痴的人都能胜任的，其秘密在于麦当劳庞大的操作手册，以惊人的细节描述了每个特许经营上在制作巨无霸汉堡时需要遵循的确切程序。这些规则是聪明人精心设计的，以便让傻瓜可以像聪明人一样遵循他们。事实上这些规则还包括了一系列的系统规则，比如各种计时器，烹饪设备等。这个系统基本假设是，每个人都会犯一堆错误，但出来的汉堡会是一致的。而另一面，如果有一个电视上的天才厨师，希望能自己开店经营，虽然自己能做出来比麦当劳更好吃的东西，但是很快就会遇到规模化的问题。要么聘请和自己也一样优秀的厨师，但是人家为何不自己做？要么聘请一些年轻的厨师，但是口味就无法得到保障。 最好的方案还是聘请没什么经验的厨师，然后让他们遵循详细的规则。但事情并不会如此，因为你的厨师总还是有即兴发挥的事情，他们可能要处理非标准化的蔬菜问题，奇怪的口味需求问题等等。所以在麦当劳背后，还有非常多的供应链优化，以至于他们根本不须要有「厨师」技能的人来操作也可以保证口味一致。 所以整个循环就是：
- 有些事情需要天赋才能做好
- 人才很难扩展
- 人们试图扩大规模的方式是让有天赋的人为没有天赋的人制定规则
- 由此产生的产品质量非常低。 但故事还有另一面，谨防方法论。虽然方法论可以把每个人提升到及格的水平，但是与此同时也有才华的人发挥 —— 一个有才华的人不会喜欢在麦当劳做汉堡。所以要明白你是要做麦当劳，还是做一家有特色的餐厅 —— 不同的是互联网和软件让我们交付的能力大有不同。所以选择是：如果我们雇用不到好的人，我们就不扩大规模。
《软件随想录》
- 优秀的人才从不在市场上求职
- 将一个互联网编程框架上升到某种“美、幸福和激励” 。
- 从经营一家公司的角度来看，一个理解基本商业规则的程序员会更有价值。
- 如果你想把事情做完，无论合适，你一定要想清楚什么是眼下最重要的、必须马上做好的事。如果你不做这件事，你就不能以最快的速度取得进展。
- 不懂编程的人管理软件公司，就好像不懂冲浪的人硬要去冲浪。
- 公司完蛋的另一个可能的原因是，既然雇用了一个不合格的程序员，就可能雇用一大堆不合格的程序员
- 许许多多人选择编程，首要的原因就是，他们宁愿将自己的时间花在一个公平有序的地方，一个严格的能者上庸者下的地方，一个只要你是对的就能赢得任何争论的地方。（真的泪目o(╥﹏╥)o）
- 1984年的美式橄榄球超级碗决赛时，苹果公司播放了一支广告。从那时起一直到今天，它一直在加固自己反对传统文化的形象：追求自由，反对独裁；追求自我，反抗压迫；追求色彩，反抗单调。就像广告里的内容一样，苹果公司是一个穿着明亮的红色运动短裤的漂亮姑娘，奔跑着穿过身穿制服被洗过脑的人群。但是，我不得不说这里面的含义其实是奥威尔式的反讽。巨型公司用一种不合理的方式操纵它们的公众形象——嗯，比方说，他们是一家计算机公司，那么与反抗独裁有什么关系呢？真是活见鬼——成功地创造出一种自我认同的文化，使得全世界各地购买计算机的用户感觉他们买的并不仅仅是一台计算机，觉得自己通过购买而参加到了一场运动中。当你购买一台ipod时，你当然是在支持甘地反抗大英帝国的殖民主义统治。每台被卖出的MacBook都表达了一种反抗独裁和饥饿的立场！（ 这里面涉及的苹果广告链接：http://www.youtube.com/watch?v=OYecfV3ubP8 ）
- 他们实际上不在乎钱，出发你在其他事情上搞砸了。如果你开始听到有人在抱怨薪水，而以前并没有出现这种情况，这经常就是一种信号，表明人们并不真地喜欢他们的工作... 我们说程序员不在乎钱，并不意味你可以向他们支付低工资。因为程序员对公正公平是在乎的...
- 命令和控制式的管理源于军事管理。大致上这种管理方法的思想是，人们只做你告诉他们去做的事情。如果他们没有做，你就对着他们吼，直到他们做了为止。如果他们还是不做，你就关他们禁闭。 但是，事实表明，用这种方法管理高科技团队，有3个缺点： 首先，人们并不喜欢被这样管理，尤其是那些对智商很自负的程序员。这些人实际上确实非常聪明，习惯于认定自己比别人直到得更多。要是这种自我认定恰恰时正确的，那么当他们被 “ 出于各种理由”，命令去做事时，他们会非常反感。 第二个缺点时操作层面得，就是说，没有足够得时间用在微观管理上，原因很简单，因为经理得人数不够。在军队中，同时向大家发布一道命令时可行得，因为军队得通常情况就是每个人都在做同一件事情。在软件开发团队中，每个人干的活都不一样，所以如果想进行微观管理，就会变成 “ 打了就跑” 的抽风式管理。第三个缺点是，在高科技公司中，负责干活的人总是比 “ 领导者 ” 有更多的信息，所以他们其实是做决策的最佳人选。两个程序员在争论压缩图像的最好方法是什么。他们已经争论了两个小时，这时正好老板走进了办公室，听见了争论。那么在这三个人中，信息最少的那个人就是老板。所以你绝不要去做任何技术上的决策。
- 程序员在基层，最了解情况。如果你们试图在微观层面进行管理，或者实行大声喊口令的军事化管理，很可能会导致不太理想的结果...当你创造一种制度的时候，你不能放弃自己的指责，不能通过给你的员工发钱的方式来训练他们。原则上，管理需要制度，这样人们才能完成工作。你们应该避免用外部激励取代内部激励。使用恐惧进行管理或者使用大声喊口令进行管理都不会很有效。
- 认同法要求你创造一个有凝聚力的、像胶水一样粘在一起的团队，就像家庭一样。这样一来，人们就会对他们的同事产生忠诚感和义务感。
- CS 323有一个最大的优点，那就是它让许多人明白了原来自己不是编程的那块料，永远也成不了程序员。这是一件好事。
- 当程序员遇到问题的时候，他们会把问题重新定义，使得这些问题可以用算法解决。这样一来，问题转化成他们可以解决的形式，但是实际上，哪些问题是一种“琐碎”问题。也就是说，程序员解决的只是问题的某种外在形式，而并没有解决真正的问题，原因是这些问题非常难，不是表面的算法可以概括的。
- 管理只是一种不得不做、让人厌烦的杂物活，之所以公司需要管理，就是为了不影响人聪明人的工作，让他们把事情做完。
- **能不能清晰地写出技术内容的文章决定了你是一个口齿不清的程序员还是一个领袖。 **为什么C语言是最流行的语言，原因就是创始人 Brain Kernighan 和 Dennis Ritchie 写了一本伟大的书《C程序设计语言》
- 一个普通程序员与一个优秀程序员的区别，不在于他们懂得的编程语言谁多谁少，也不在于他们喜欢用Python语言还是喜欢用Java语言，而在于他们是否与他人交流思想。
- 第一点。如果你说不清楚你的软件解决了什么棘手问题，就不要去开软件公司。 第二点。不要独自一人创办公司。 第三点。一开始不要抱太高期望。
- 个人办公室，带有可以关上的门，这是绝对必需的，不能协商。
- 办公室应该是一个窝，一个能够很愉快度过时间得地方。
- 程序员受到一种愿望的驱使，渴望方方面面都照顾到，让每个人都感到满意。但是这种愿望的基础其实是一个不正确的认识，更多的选择会不会让用户感到更幸福，我们需要重新思考这一点。
- 指针和递归的真正价值在于那种你在学习它们的过程中所得到的思维深度，以及你因为害怕在这些课程中被淘汰所产生的心理抗压能力，它们都是在建造大型系统的过程中必不可少的。
- 许多程序员都深受古老的 “80/20” 法则的诱惑。这条法则看上去似乎意义重大， 80% 的用户使用 20% 功能。你因此说服自己，只要开发 20% 的功能就行了，软件的销量依然会保持在八成左右。 不幸的是，那个 20% 是一个变量。每个人需要的功能都不一样。
- 被收拾得干干净净的办公桌可能是一个信号，表明你的工作效率不高。
📖 最近看的文章
愿意看起来愚蠢
这篇文章中，博主 Dann Lu 认为愚蠢有时候并不是坏事，甚至有很多好处，包括：
- 更快地学习和改进。当别人指出你的错误时，你可以把这视为学习机会,而不是觉得尴尬。
- 思考被普遍认为愚蠢的想法，这些想法往往被忽视，但可能包含高价值的洞见。
- 更容易发现高投资回报率的创新想法，因为你不会排除那些乍看起来愚蠢的想法。
- 建立更深入的理解，而不仅停留在表面。愿意问“愚蠢”的问题可以揭示更深层的真相。
- 建立更坚实的人际关系。你对别人的判断不会过于在意，关系中也更可能体现真诚。
- 减少在社交场合中维持形象的心理负担。
- 鼓励别人也敢于提出看似愚蠢的想法和问题。
- 减少自我设限，让你的潜力得到更好的发挥。
如何撰写读书笔记才能做到旁征博引？
这是少数派作者雯子的文章，介绍了她关于读书笔记的分类和做法，她将读书笔记分为三类，
- 观点论证类
- 非虚构记叙类
- 文学类 然后举了例子进行了介绍，非常棒，我相信对于很多尚在记录读书笔记迷途的人来说，会很有启发，推荐阅读。
如何找到优质信源：重要的不是降噪，而是挑选
少楠在这篇文章里整理了下自己的对于如何获得优质信息的方法。 关于选书和读书的原则：
- 避免看热榜的书，去看经受时间考验的书。
- 进入新领域，重要的不是读经典，而是激发自己的兴趣。
- 未必要读完，把自己能用得到的感兴趣的看完即可。
- 把注释当做挖掘新书的方法。
- 同时读许多本书，甚至摊在桌子上一起读。
- 问问身边的人，你最近在「重读」什么书。 少楠还提出了获取信息的观点 —— “主动获取，避免推送”
- 控制好时间投入，不要一头扎进去出不来。
- 做好浏览记录，方便下次再回来。
- 信源并非是越多越好，还要能消化掉。目前的选择是，尽量在日常上为获取信息留出足够时间（阅读和自由时间都是在干这个），有了固定时间之后，就不用随时响应朋友发来的内容或者其他产品的推送，确保不被分心。
- 碎片化收集和学习并非没有用，前提是你还有完整的时间来进行归纳和整理。 不光要收集信息源，还要有固定的频率消费避免囤积过多，并且在消费过程中产生积极的互动。 PS：对于信息源收集和整理，我也踩过很多坑，最开始时候，疯狂收集各类知识导致囤积无法消化，也过于碎片化，我后来到现在的做法是，把文章收藏进cubox，放进收件箱里，每天睡觉前看一两篇，做好批注和高亮后，每三天或者每周进行分类，而不是在收藏的时候就开始分类，之后周末把精华提炼出来，放进Obsidian或者heptabase形成链接，把知识串起来。
到底有多少青年人失业？
唐涯的一篇对清华大学环境资源能源法学研究中心主任王明远教授写的《到底有多少青年人失业》的评论，我对于文章最后一句话非常认同：
一个有前途的社会，必然是年轻人都在积极去创造和实现各种梦想，而不是都在考编的路上。
国内有哪些真正称得上「兵家必争之地」的地方？
很有意思的文章，推荐阅读
