小股东怎样保护自己的利益
这篇讲的是创业公司里小股东如何自保的实战心法。作者从小股东的尴尬处境切入——身份介于股东和打工者之间，话语权低，但完全放弃权益又极易被“复杂股权架构变更”掏空股份。文章的核心观点是：小股东必须主动行动，通过几个关键策略来对冲信息与权力的不对等。 具体策略包括：一是强化契约意识，任何涉及利益的条款都需法律保障，绝不能因“不好意思”而妥协；二是利用在公司任职的便利，通过非正式渠道（如与财务、人事同事交流）主动拼凑信息，预判风险；三是保持自身的“存在感”，确保个人价值不低于持股比例，避免被边缘化；四是及时评估大股东人品，发现问题尽早友好协商退出；五是永远保留独立创业的能力，作为谈判的底气。 文章也罕见地从大股东视角给出了避免冲突的建议，比如要求小股东现金购股、采用分期授予（vesting）机制、以及及时回购不称职者的股份。这使得讨论更为平衡，对创业双方都有参考意义。最后作者提醒，选择合伙人时需警惕纯粹重利、缺乏理想的商人，因为这决定了公司的底线。
朋友，不要再打听彼此薪水
这篇文章谈的是职场中一个微妙却普遍的现象：朋友间打听薪水。作者从财年季引发的讨论热潮切入，指出这种做法往往带来沮丧情绪，且弊大于利。 文章的核心观点很明确：了解行业薪资的大致趋势是必要的，这有助于判断个人价值与市场需求的匹配度。但打听具体个人的薪水，尤其是朋友间的薪水，则很容易引发心态失衡。作者生动地描绘了得知薪水差异后的两种典型负面情绪——“凭什么比我高”的郁闷，或“对方也就值这些”的轻视。这种情绪若演变为消极怠工，便可能形成一个从“郁闷”到“工作效率下降”，最终影响个人收入的恶性循环。 作者进一步分析，在满足短暂好奇心之外，打听薪水几乎毫无收益，反而可能给朋友关系贴上不必要的标签，徒增隔阂。因此，他提出了一个简单而有力的个人解决方案：为自己定下规矩，不再打听朋友的薪水，也不再回答此类问题。真正的友谊，其基础在于共同的兴趣与灵魂，而非工资条上的数字。文章最后那句“可以谈谈别的，比如其他人的薪水”，以一种幽默的方式，巧妙地重申了这一观点。
如何用“友好”的方式告诉经理：拥有一个好程序员是你的幸运？
这篇讲的是程序员与管理者在“工作时间”问题上可能产生的典型冲突。作者从一个真实案例出发：一家小公司的新经理，要求资深程序员必须严格坐班8小时，而这几位程序员恰恰是公司业务的核心支柱，并习惯于灵活安排时间。 文章没有鼓吹对抗，而是提供了一套“友好”的沟通策略。其核心观点是，有效的沟通始于理解对方立场。在提出自己的诉求前，先询问并理解经理推行新规的真实动机——是来自上级压力，还是对管理失效的焦虑。随后，在表达时应使用“我感觉这种变化有点突然”这样的句式，以寻求折中方案的姿态，代替直接的最后通牒。最终，无论结果如何，都应尊重对方的管理权威。 作者认为，这种将心比心、避免情绪化的沟通方式，比单纯强调个人贡献或以离职相威胁，更能争取到有利的协作空间。它提醒技术从业者，高超的沟通与共情能力，有时和专业技能一样重要。
那些被大佬带进沟里的名言
这篇文章在吐槽一个普遍现象：大佬们抛出的那些“武功秘籍”，比如“注重用户体验”、“小步快跑”、“不断试错”，在传播中往往只剩下了招式概要，缺乏前提和上下文，导致很多人盲目跟从反而“走火入魔”。 作者逐一拆解了这些被滥用的名言。比如，只谈“小步快跑”却不说跑完后如何经营，就像“旋风将军”连下数城却无分兵把守；只强调“不断试错”而不讲试错的风险与准备，就如同在黑暗森林中轻易暴露自己；而“做轻、小而美”在初期有效，但产品要常青，最终必须“深扎根”，处理好随之而来的各种“脏活累活”。 文章的核心观点是，产品成功的要素是多方面的，单纯依赖某个流行方法论是危险的。作者从重视设计、到认识价值的重要性，最终落脚到“运营的设计”与构建“产品循环”上，强调产品必然始于创意，但成功必然成于持续且系统化的运营。
领导需要比下属更懂技术吗？
这篇文章从作者自身的职场经历出发，探讨了一个常见的管理困惑：技术管理者是否必须比下属更懂具体技术？作者回忆了早年推动项目从Java 1.4.2升级到5.0时，被保守的项目经理质疑的经历。他当时认为领导因知识陈旧而抵触新技术，但后来理解到，领导的决策更多基于系统稳定性、风险评估与资源调配等更高层面的考量。 文章的核心观点在于，优秀的领导者需要具备的是“抽象”思维的能力。他们不必精通每一个技术细节，但必须能从过往经验中提炼出共性规律，从而准确判断任务的价值、难度与风险，并做出合理的资源分配决策。例如，即使不懂代码细节，领导也能评估一个搜索优化项目的周期和意义。当面临如代码管理工具从SVN切换到Git这样的具体技术决策时，领导应保持开放心态去了解，但决策焦点应放在评估切换的好处、团队适应成本及潜在风险上。 作者还提供了一种高效的知识更新方法：将团队视为自己学习的“延伸大脑”。通过组织技术分享会，鼓励成员讲解新技术，领导既能以最小成本保持知识前沿，又能促进团队整体成长和成员表达能力的提升。这篇文章最终给出的启发是，技术领导的核心价值不在于技术领先，而在于通过有效的组织和抽象思考，引导团队在正确的方向上创造价值。
领导如何应对员工离职
这篇讲的是管理者如何系统性地应对员工离职，尤其是技术团队中常见的程序员离职问题。作者没有纠缠于个案原因，而是直指核心：想留住人，必须满足“员工觉得公司有发展”和“觉得自身有发展”这两个条件。 对于如何让员工感知公司发展，作者批判了传统的“宣传”模式，认为其不可信。他提出的方案更根本：领导要为员工设定真正有意义的工作，并让员工看到自己工作的价值。比如，让程序员亲眼见证自己编写的程序如何大幅提升业务效率，这种实实在在的关联比任何口号都能建立归属感。 而在员工个人发展方面，文章强调领导不能只当任务分配者。需要主动了解员工的潜力和意愿，将挑战性任务与他们的成长阶段相匹配，并通过持续沟通提供发展建议。这不仅能预防因“没头脑”的跳槽造成的被动，也是团队建设的一部分。 最后，文章驳斥了那种认为“领导有权力就不怕离职”的观点，指出单纯依赖权力无法驱动知识工作者。好的领导必须通过赋能和成长来赢得团队，而不是仅仅依赖职级赋予的控制力。
享受造轮子的乐趣
这篇讲的是“重复造轮子”在技术圈内常被讳莫如深，但作者认为，有时大胆造轮子不仅无妨，反而是技术创新和团队成长的重要路径。 文章以Linux和搜索引擎领域的创新为例，指出若当年坚持“不造轮子”，可能就没有今天的开源系统和竞争格局。作者区分了“设计”与“使用”技术的不同层次，强调为用户提供更好方案的目标，常常需要我们跳出直接使用现有产品的思路。 更重要的是，造轮子本身的价值：它能帮助团队深入理解领域，启发重新思考与改进。同时，富有挑战的项目还能吸引顶尖人才——优秀开发者渴望解决难题，而这类“轮子”正好提供了舞台，从而通过技术杠杆推动业务。但作者也提醒，同一公司内无意义的重复不可取，关键在于把握“农闲”与“农忙”的时机，让积累在需要时发挥作用。
编程能力与编程年龄
程序员的职业寿命究竟有多长？“35岁危机”和“青春饭”的说法一直存在。本文通过解读一篇基于StackOverflow数据的研究，为这一争论提供了扎实的数据视角。 作者引用了北卡罗来纳州立大学对近8.5万名活跃开发者的分析。研究发现，程序员的技术能力并非在30岁达到顶峰后下滑，而是会持续上升，直到50岁左右。更重要的是，所谓“老程序员”学习新技术的能力并不比年轻开发者差。 基于这些数据，文章的核心观点非常明确：许多人的“35岁危机”实则是能力瓶颈。作者指出，如果30岁还没能成为合格的程序员，那恰恰是经验与能力积累不足的表现。真正的技术能力是随时间增长的硬通货，而非青春饭。这篇文章用数据为那些长期坚持技术深耕的从业者正了名。
十种更好的表达“你的代码写的很烂”的方法
如何指出代码质量问题是许多技术团队避而不谈的尴尬。直接说“你的代码很烂”可能引发对抗，而沉默或抱怨又无法解决问题。这篇文章正是从这个常见的协作困境出发，提供了十个具体、可操作的沟通策略。 作者并非空谈理论，而是结合了iOS开发者Tim Burks、Adobe研究员Tom Jacobs等业内人士的实践智慧。这些方法的核心思路是将“批评”转化为“协作邀请”。例如，“开门见山”法不是指责，而是诚恳地请求对方帮你理解代码逻辑；“糖衣炮弹”法则在提出改进点前后，先肯定代码中值得学习的部分；“偷换概念”法通过改变主语（如“我需要重构这段代码”而非“你写得乱”），有效降低对方的防御心理。 文章最实用之处在于，它揭示了所有这些技巧的共同点：将对话焦点从评判“人”转向优化“代码”本身。无论是通过非正式的啤酒聊天来理解对方的编码习惯，还是通过组织编程大赛来营造安全的讨论氛围，目标都是让代码质量提升成为团队共同追求的目标，而非个人之间的对错之争。对于任何需要进行代码评审或团队协作的开发者，这些沟通心法都值得借鉴。
(续)为什么很多技术合伙人参与创业时会先谈钱？
这篇回应文章深入探讨了前文引发的讨论，聚焦于技术合伙人参与创业时常被误解的三个核心问题。作者从实际的创业对接经验出发，澄清了几个常见误区。 首先，文章指出创业项目并不适合外包模式。因为创业产品的需求是动态且不确定的，需要持续的沟通和迭代，这与外包“需求明确、一次交付”的模式根本冲突。同时，愿意接受远低于市场薪资的人员，其合作心态也与外包截然不同。 其次，关于激情，作者认为技术人员的创业激情并非凭空设想而来，而是在产品上线、获得用户正向反馈的过程中逐步点燃的。这种基于逻辑和实际成果的激励，比空谈梦想更为持久和重要。 最后，文章探讨了技术合伙人的定位问题。创始人不能简单地将产品规划完全抛给技术方，双方容易因角色认知差异产生鸿沟。可行的方案是创始人学习制作产品原型，或引入产品合伙人作为桥梁，最终实现业务与技术视角的真正融合。 整体而言，文章并非否定谈钱，而是呼吁创业各方基于对彼此工作模式的深刻理解，建立更健康、对等的合伙关系。
如何写好一封邮件
这篇讲的是把“写好一封邮件”这件看似人人都会、却常常被忽视的职场基本功，拆解成一套可执行的系统。作者从知乎上的讨论出发，提炼出邮件沟通的三大核心原则。 首先是“礼貌原则”，它强调基本的尊重与专业，比如正确使用收件人与抄送栏、保持用词正式、及时回复。其次是“战地记者原则”，要求直切主题、内容单一、长度精简，确保信息高效传递。最后是“金字塔原理”，主张邮件结构应中心明确、分层叙事，并在开头用“四个W和一个H”（谁、什么、何时、为什么、如何）说清核心，引导收件人快速理解意图。 文章后半部分深入到容易忽视的格式细节。从标点符号的误用（如连续多个问号显得情绪化）、字体的谨慎选择，到段落对齐、行间距的视觉优化，都给出了具体建议。特别强调了工作邮件用词需朴实准确、多用短句、避免术语堆砌。 此外，文中还分享了重要的职场沟通智慧：邮件如同“白底黑字”，发出前需深思；避免在邮件中陷入多轮争论；抄送名单要精简且有关联。文章最后给出一个实用的写作顺序建议：先处理附件，再写正文，然后标题，最后填收件人，并在发送前出声朗读一遍。整篇文章将常见问题与解决方案结合，把邮件写作从习惯动作提升到了专业技能的高度。
如何更好用业余时间做互联网创业？
这篇讲的是作者从大量业余创业者的沟通中，观察到几个容易让项目陷入困境的共性问题。他发现，技术出身的创始人往往在产品开发上得心应手，但当项目进入运营阶段，由于身份和精力的限制，推广投入不足，很容易被后来者反超。团队也存在隐忧——很多成员的参与动力只是“最近有点空”，一旦本职工作忙碌起来就容易退出，影响整体士气。此外，同时兼顾两线作战带来的疲惫感，甚至可能波及家庭生活。 基于这些观察，作者给出了几条务实的建议：要像全职项目一样设定运营里程碑，哪怕目标定低一些；在产品设计上务必精简，只做核心功能，避免野心过大；他特别指出，业余创业是降低风险的起点，而非终点。当项目验证了正向反馈后，就应考虑寻找资源转向全职，因为“鱼和熊掌不可兼得”。文章为那些在理想与现实间寻找平衡的创业者，提供了一份清醒的行动参考。
技术人员的创业陷阱：我能，但不管用户在哪里！
这篇讲的是几位技术背景的创业者，如何因过于自信技术能力，而掉入“闭门造车”陷阱的真实观察。 作者走访了几个技术主导的创业团队，发现一个共同现象：团队技术实力过硬，产品原型也做得漂亮完整。但深聊后，问题浮出水面。比如一个“5分钟集成聊天功能”的云平台，功能模块化设计精巧，却无法与现有会员系统对接；一个功能齐全的宠物APP，同时试图满足有宠物和无宠物两类人群，结果定位模糊，难以推广；一个租房APP创始人，则在没有房源和用户的冷启动难题前，单纯寄望于寻找“强运营”。 这些案例揭示的核心观点是：技术创业者常因拥有快速实现的能力，而陷入“我能做，所以应该做”的思维定式，忽略了“用户是谁”、“痛点何在”、“如何启动”这些更前置、更根本的商业问题。这种“技术驱动”的创业路径，往往与市场需求脱节。 文章对技术人员的启发在于：创业之初，请克制住立即编码的冲动。先走出技术视角，去了解真实的市场与用户，甚至可以主动寻找传统行业的合作伙伴。只有将“我能做什么”与“用户需要什么”对齐，技术能力才能真正转化为成功的产品。
为什么很多技术合伙人参与创业时会先谈钱？
这篇讲的是不少技术合伙人在参与创业时，为何会先提出费用或兼职需求，而这常让一些创始人感到困惑，觉得对方不够“全情投入”。 作者从十多年与技术群体打交道的经验出发，剖析了这背后的理性考量。核心观点是，这并非不信任，而是技术人员因其职业特性（如黄金期短、技术成长至关重要）在进行必要的风险控制。文章指出，技术人员若在创业项目中失败，可能面临代码价值归零和职业成长中断的双重打击，因此他们对短期回报和风险的评估更为直接。 作者还澄清，兼职常是陌生合作下的过渡阶段，一笔象征性的费用能加速产品原型验证与信任建立。这恰恰给了创始人主导项目、证明自己想法可行性的机会。文章提醒，理解技术合伙人的立场，通过具体付出与协作逐步建立信任，比空谈未来更有效，毕竟把产品做出来才是第一步。
2014网易前端开发笔试题笔记
这篇讲的是作者2014年参加网易前端开发校招笔试的真实经历与考题回顾。文章从收到临时通知的匆忙赶场开始，生动还原了考场外的见闻：来自不同高校的考生、不少“霸笔”同学，以及外包给智联招聘的笔试组织形式。 核心部分聚焦于笔试本身。作者详细分享了两大板块的题目：第一部分是所有技术岗必考的计算机基础，涵盖文件组织、图遍历、无向图、可计算性、哈夫曼编码、死锁、数据库索引等经典问题，并附上了自己的解析。第二部分是前端开发专业题，题型包括不定项选择、填空、简答和编程题，重点考察JavaScript，例如要求手写闭包示例、阐述apply/call区别，并参照原型图实现交互页面。 除了考题，作者还观察到招聘可能存在学校偏好，并指出广州考生流动性较低的现象。整篇文章既是一次笔试的详细记录，也为后来者提供了宝贵的复习参考和实战视角。
我是如何变成一个Loser的
这篇讲的是一个技术团队管理者，通过复盘自己亲手将部门带向解散的全过程，为我们总结出了一份“避坑指南”。 作者坦诚地分享了自己在担任部门主管一年间的四大失误：对新加入的实习生队友缺乏足够的引导与关怀，未能形成团队凝聚力；在团队技术栈上反复摇摆（C#/PHP/Python/Node.js），导致多人多语言、项目零散，严重消耗了本就紧张的人力；在薪酬竞争力不足时，没有为团队描绘清晰的愿景，致使士气低落、成员相继离职；以及陷入“功能实现”的技术自嗨，忽略了产品本身的体验和价值。 这些看似是管理“大忌”的错误，恰恰构成了真实而宝贵的反面案例。文章没有空谈理论，而是用具体的项目选择、团队配置和个人心路历程，刻画了技术驱动型团队可能面临的典型困境。对于每一位带团队或即将带团队的技术人来说，这些从“Loser”视角提炼出的教训，或许比成功经验更值得引以为戒。
打开视野
这篇讲的是作者在ThoughtWorks做面试官时，观察到一种普遍的成长瓶颈。许多在原公司表现不错的程序员，面试时却在宏观思考和问题陈述上显得零散，因为他们长期只负责执行被“嚼碎”的具体问题，视野被日常项目所限。 作者指出，视野的局限会让程序员误把“局部峰值”当成自己的水平。他给出的解药是主动打破环境限制：通过互联网接触更广阔的天地和高手的思维方式；阅读经典书籍进行系统学习；以及走出去参加技术聚会，以近乎零成本的方式与不同经验的人交流。 文章最后，作者用自己早年的故事做了印证：当他在东软感到能力“过饱和”时，正是凭借对外部世界的好奇和探索，最终加入了能持续激发成长的ThoughtWorks。他想提醒的是，具体学什么、怎么学是后话，程序员最怕的是固步自封，第一步永远是把视野打开。
产品汪想跳槽
这篇谈的是产品经理遇到职业瓶颈时，该不该跳槽的经典困境。作者从三封真实来信切入，这三位产品汪的痛点各有不同：有的苦于薪资倒挂和决策权缺失，有的被僵化的考核制度和团队氛围拖垮，还有的因为短期经历过多而陷入自我怀疑。 作者没有直接给出“跳或不跳”的答案，而是点出了问题的核心：产品汪的成长极度依赖“好项目环境”——项目合理、资源到位、上司懂行。但这类环境在整个行业中占比可能不到30%。许多有潜力的产品人并非天赋不足，而是被糟糕的管理、不懂产品的上司和消耗性项目给废掉了。 文章也提醒，来信中呈现的多是“一面之词”。产品决策高度依赖经验与直觉，冲突在所难免。与其断定上司愚蠢，不如尝试像作者的朋友那样，抛开立场，理性对比方案，或许会发现自己与上司的判断本就一致。最终，这篇文章提供的不是解决方案，而是一种更冷静的思考框架：在冲动离职前，先理性评估环境是否真的已无成长空间，以及自己是否已尽力沟通与适应。好的选择，往往伴随着痛苦的思考过程。
又是一年校招时 – 关注简历书写的细节
这篇从技术招聘方的视角出发，基于实际筛选数十份校招简历的经验，总结了直接影响简历通过率的16个关键细节。作者为每一项建议设置了加分值，让要点的重要性一目了然。 其中，拥有高质量的技术博客、开源项目或实际产品，以及获得ACM等重量级竞赛奖项，被视为最具竞争力的亮点，单项加分高达9分。相比之下，简历文件名的规范、排版专业性、是否有英文版等细节虽然单项分值不高，却能体现候选人的做事习惯和细心程度。 文章也直指常见误区：简单罗列课程或参与过的项目往往无效；使用“全程参与”、“持续参与”等模糊描述无法展现个人贡献；技能栏仅写“了解”或“熟悉”难以获得面试官认可。对于硕士生，明确“精通”或“深入研究”某项技术更为重要。 对于本科生，作者建议更需主动挖掘和突出一两个技术亮点。整体上，这份清单提醒求职者，一份好的简历是精准的自我营销，需要站在筛选者的角度，用具体成果和清晰表述来争取机会。
普通设计师与顶级设计师的区别是什么？
这篇讲的是顶级设计师与普通设计师的核心区别。作者从自己认识的几位国内优秀设计师出发，观察到他们的出色并不源于某种神秘的方法或工具，而在于一些基础但关键的品质。 首先是极致的热爱与专注。文章举了一位游戏模型设计师的例子，他能为一条模型的布线完美修改两年，这种近乎偏执的打磨精神是很多设计师所缺乏的。其次是深刻的同理心与尊重。优秀设计师能看透需求背后的人与矛盾，他们会调整工作习惯以配合队友，甚至会为保洁阿姨方便打扫而主动整理好自己的桌面。最后是可贵的谦卑与持续学习的习惯，即使能力已很突出，仍自发地拓宽视野，每天坚持阅读大量行业资讯并动手练习。 作者最后点明，优秀与否根本上是人的性格、习惯与责任心的差别。这些特质经时间积累，会转化为设计师的格局与气场。对于设计从业者而言，与其寻求捷径，不如先审视自己是否具备了这些“普通”却又难坚持的品质。
