在杭州工作（2013年版）
一位在北京学习工作七年后转战杭州的程序员，结合自己四年的亲身经历，分享了对这座城市的感受。文章从工作、生活、消费等几个维度展开，并与北京做了直观对比。 工作层面，作者坦言杭州的互联网机会相对集中，主要就在阿里和网易，选择面不如北京广，但电子商务氛围浓厚。生活则是杭州的强项，城区紧凑，周末去龙井、梅家坞聚会爬山都很方便，运动环境极佳。作者用“分分钟秒杀北京”来形容生活便利性上的优势。消费水平被认为与北京接近，但夏天的闷热被指出是明显的缺点。 最后，作者给出了“超出期望”的总体评价。这篇文章没有宏大的叙事，却通过通勤时间、聚会开销、爬山路线等真实细节，为考虑来杭发展的技术人提供了一份接地气的参考。
为什么程序员总是不能准确预估工作量
这篇讲的是程序员预估工作量不准这个经典难题。作者从一个项目经理的生动比喻切入：拿到估算后先乘以π，再把单位往下换一级，比如1天会变成3.14周，才能接近真实耗时。 文章指出，时间估算本身就很困难。有经验的开发者有一个“现实的估算区间”，在此区间内估算相对靠谱；低于区间意味着忽略了构建、测试等必要开销，高于区间则说明任务过大难以把握。而初级开发者往往缺乏这个区间，既会低估琐碎环节的时间，又无法预估复杂任务。 作者还强调了一个关键点：编程经验并不等于估算经验。不被纳入估算流程、没有将实际耗时与估算做比较的开发者，很难提升估算准确性。文章最后给出了一个具体可行的提升方法：接手任务时先独立估算，完成后对比实际用时与计划，通过这种持续的反馈循环，既能更深入地理解任务细节，也能逐步磨练出更精准的估算技能。
提高代码可读性的注释技巧
这篇讲的是如何通过注释让代码更“友好”。作者从最实用的技巧出发，强调注释应与代码结构同步：比如为类和方法添加标准化摘要，或在每个独立功能块前用分段注释说明意图。文章特别指出了几个容易踩的坑：要避免写“if (a==5) // 判断a是否等于5”这类冗余的“傻瓜注释”，更要杜绝在注释里抱怨前同事或用户——毕竟你不知道将来谁会读到这些字句。 更进阶的建议包括：使用像“TODO”这样的团队通用标签来高效沟通，最好在写代码的同时就完成注释，这时思路最清晰。最终目的是让注释成为未来的你和其他开发者之间的清晰桥梁，而不是单纯应付任务的填充物。整篇文章给出了从态度到具体操作的完整清单，让注释真正服务于代码的可读性。
编程珠玑番外篇之番外篇-N 答 UNIX 痛恨者王垠
这篇讨论 UNIX 与 Windows 设计哲学之争的文章，从王垠批评 UNIX 的观点出发，深入剖析了两者的核心差异。作者指出，UNIX 的图形系统（如 X Window）与操作系统内核的松耦合，反而为针对不同设备（如移动平台）定制高效 GUI 提供了灵活性，而微软 NT 内核与 UI 的深度绑定，则导致其在跨平台时面临复杂的兼顾问题，迭代缓慢。 文章进一步探讨了工具设计的复杂性根源。以 TeX 为例，作者认为其“复杂”源于要解决排版领域本身的精确控制问题，而非设计失败。这揭示了一个重要观点：工具设计的简单或复杂，应取决于其要封装的“领域模型”的固有难度，而非简单地追求操作极简。将 Unix 工具比作“魔鬼棋”的类比，可能忽略了这一层因果关系。 最后，作者提出了一个有趣的角度：真正的 Unix 用户恰恰是其“痛恨者”，因为深刻理解其缺陷是高效使用它的前提。这种基于开放环境竞争、不断吸收优秀设计的演进模式，而非某种“宗教”，才是 Unix 家族最终胜出的关键。
程序员的五个阶段
这篇讲的是程序员职业发展路径中常见的五个阶段，作者从实际工作场景出发，描绘了一幅清晰的进阶地图。 文章首先勾勒出前两个“执行层”阶段：从拿到详尽设计文档、只做编码实现的“编码机器”，到能独立完成模块设计与实现的“独立实现者”。这两个阶段虽然能产出代码，但工作本质上仍是被动的、残缺的。 真正的分水岭出现在第三阶段“项目沟通者和管控者”。此时程序员需主动参与需求澄清、技术难点攻关与项目计划管理，沟通成本急剧上升，其协作能力直接影响团队效率。国内许多公司的工程师正处于这一承上启下的位置。 后两个阶段则标志着思维质变——从“做项目”跃升至“做产品”。这意味着思维重心需从倾听和交付，转向深度思考用户痛点与产品定位，并承担长期的产品维护与迭代。最高阶段“产品成长的见证人”，则描述了参与产品从0到1甚至更迭全过程的完整体验，充满了探索、试错与坚持。 文章的核心观点是：一个完整的程序员不能止步于编码，沟通能力与产品思维是通往更高阶段的关键阶梯。
从WordPress看开源平台的发展
这篇讲的是开源平台如何从技术理想走向商业现实的深度思考。作者从一组惊人数据切入：全球六分之一的网站基于WordPress搭建，其在头部网站中的渗透率甚至超过了Facebook这类中心化开放平台。 文章的核心观点犀利：开源平台（如WordPress）的价值不仅在于像传统开放平台那样“释放控制权”，更在于“释放所有权”——即使开发公司消失，用户依然能安全使用。这种模式通过构建可持续的多方受益生态来实现商业价值：WordPress严格区分核心代码与插件版权，允许开发者自由选择授权并盈利，而官方则通过托管、安全等增值服务变现，形成了缓慢但稳固的增长飞轮。 更巧妙的是对用户行为的引导。WordPress并未强硬禁止修改代码，而是提供“一键升级”的极致体验——这实则激励开发者将个性化改动封装为插件，一举实现了优秀的用户体验、核心代码稳定性和生态繁荣的三重目标。 文章最终跳出了代码细节，揭示了开源项目成功的关键在于艺术地平衡多方利益，实现真正的共赢。对于想理解开源生态运作逻辑的读者，这提供了一个从实践到哲学的观察样本。
技术人员如何去面试？
这篇讲的是跳槽季里，技术人员从决策到拿offer的全流程经验。作者从实际问题出发，拆解了跳槽动机分析、目标公司选择（大厂平台 vs. 潜力公司）、以及内推/猎头/海投等渠道的优先级。 面试部分尤其详实。作者指出流程旨在规避主观偏见，但仍需做好应对准备：针对性技术复习、保持干净得体的外在、注意面试时的空间距离与座位角度（推荐L角）。沟通上建议语气平稳、逻辑清晰。他具体区分了技术面试中“封闭式”与“开放式”问题的应对策略——前者精准作答，后者可先追问明确方向再分层阐述。对于“离职原因”等敏感问题，则建议客观陈述，避免抱怨。 谈薪环节被单独强调，作者提醒要了解行业浮动惯例（通常涨幅在20%-30%），并基于自身预期和市场行情谨慎沟通，避免因狮子大开口或过于被动而受损。 全文是作者作为程序员的切身观察与总结，跳出了具体技术语言，为不同阶段的技术人提供了从简历投递到薪酬谈判的实用指南。
实践中的重构
这篇讲的是，许多程序员对“重构”这件事怀有误解，而作者的核心观点是：重构绝非特殊阶段的“大工程”，而是贯穿日常编码的微习惯。 作者从日常工作切入，指出重构应和写代码、测试一样，是每个开发者的常规动作。他特别澄清了“重构”与“重写”的混淆——调整模块设计可能需要沟通技术债，但执行时仍需遵循重构原则。一个关键的前提是：“没有测试的重构就是耍流氓”，必须先为代码补足测试保障。 那么如何安全地重构？文章给出的标准是：能够“随时随地停下来，且不破坏任何测试”。这依赖于“小步重构”的实践——将大刀阔斧的修改拆解为一系列可验证的微小步骤。作者坦言，这需要刻意练习，与内心急于“一路劈杀”的冲动对抗。 重构易知难行，其精髓正在于将这种小步快跑的纪律，内化为肌肉记忆般的编码习惯。
textmate常用快捷键备忘
这篇讲的是TextMate编辑器的常用快捷键，堪称一份详尽的备忘录。文章直接按功能模块，列出了从视图切换、文件导航到代码编辑、查找替换等方方面面的高效操作方式。比如用“Cmd + T”快速定位项目文件，用“Cmd + /”一键注释代码，或是利用“Cmd + Option + A”进行多行同步编辑。 它不仅覆盖了通用操作，还特别整理了针对HTML和Rails开发者的Bundle快捷键，例如自动生成标签或在Controller、View、Model间快速跳转。对于列编辑模式这种特殊技巧也做了说明。对于使用TextMate的开发者而言，这篇文章就像一份随时可查的效率手册，把零散的操作技巧系统化地呈现出来，能有效帮助提升日常编码的流畅度。
GitHub 是怎么火起来的
这篇讲的是GitHub的早期发展史与技术传播逻辑。作者从2009年Ruby大会的亲身经历切入，指出GitHub在获得巨额融资引发大众关注前，早已在Ruby社区奠定了坚实基础。 文章的核心观点在于，Git和GitHub的爆发是技术需求驱动社区自然演进的结果。Ruby/Rails框架虽开发高效，但多人协作时面临传统版本控制系统（如CVN/SVN）的冲突痛点。Git的分布式与分支管理特性完美契合了这一场景，使得Ruby社区几乎全员迁移至Git生态。而GitHub正是诞生于这一浪潮，由湾区Ruby开发者为解决Git托管需求而创造。 更深层的传播链条清晰可见：Rails项目率先迁移到GitHub形成示范，社区内包管理工具Gem的全面接入形成网络效应，最终带动了关系紧密的JavaScript与iOS开发社区跟进。作者强调，这种由核心开发者社区向外扩散的“涟漪效应”，是GitHub增长的关键动力，而其高估值则更多源于云计算SaaS平台的商业模式。文章为我们提供了一个观察技术如何通过解决具体痛点、依托社区凝聚力实现指数级增长的经典案例。
大公司的创新思考：基因延伸性创新
这篇讲的是大公司如何在新时代实现创新成功。作者从Scott的“新企业车库”时代论出发，提出了一套更细致的创新分类：基因延伸性创新与颠覆性创新。 作者认为，大公司依靠资源、规模和品牌取得的创新成功，本质上是一种“基因延伸性创新”。公司的“基因”——即其在核心竞争领域长期优化形成的独特优势——既是护城河，也可能成为拓展新领域的障碍。文章拆解了新浪微博和微信的成功案例，指出它们都精准地将母公司在媒体运营和通讯工具上的基因，延伸到了移动互联网新战场。 基因延伸性创新要成功，必须满足两个条件：一是创新方向必须符合公司基因，否则如Google+之于Google、新浪游戏之于新浪都难以成功；二是延伸的新领域必须有足够的市场空间，文章以Apple TV的有限市场想象空间作为反例。而另一种“颠覆性创新”由于会重构游戏规则，往往难以在大公司内部存活，更多由创业公司驱动。 最后，作者也提到通过收购来改变公司基因（如苹果收购NeXT）是大公司实现颠覆性创新的艰难但可能的路径。文章的结论是，未来将是大公司与创业公司各展所长的创新时代，而非一家独大。
代码审查：ThoughtBot官方给出的代码审查指导原则
这篇讲的是如何让代码审查变得更高效、更友好。作者从 ThoughtBot 的官方指南出发，总结了在 GitHub 上进行代码审查时，审查者和被审查者双方都应遵循的一系列核心原则。 文章为审查者提供了具体的沟通心法：要记住编程主张常是个人观点，因此应多提问少命令、请求说明而非指责、避免代码归属之争，并且绝不能人身攻击。审查评论应清晰谦逊，避免使用“总是”“从不”等夸张修辞。如果讨论过于深入，可以转到线下进行。 而对于被审查的代码作者，文章建议要主动感谢建议、理解对事不对人、解释代码背后的思考，并在一个独立的 push 提交中集中处理反馈。关键流程包括：基于反馈更新代码、注明审查链接、等待所有审查者退出后再合并，并确保持续集成测试通过。 此外，文章还提倡建立统一的代码风格指南。当出现分歧时，应在指南仓库中发起讨论，而非在审查评论中争论。这些具体而微的实践，旨在将代码审查从一场潜在的技术辩论，转变为一次促进团队学习和代码质量提升的协作。
是是非非本寻常，我们要不要跳槽
这篇讲的是作者从个人跳槽经历出发，对“要不要跳槽”这个职场难题的深度思考。他以自己因高管承诺未兑现而冲动加入阿里、反而获得快速成长的经历为引，提出了一个核心观点：许多跳槽源于职场中的“不爽”与误解，但逆境才是真正塑造能力的环境。 作者指出，个人价值往往由直接上级决定，向上沟通和客观自省至关重要。他冷静分析了跳槽的隐性成本：不仅包括脱离熟悉环境的投入，更涉及机会与风险的对等博弈——高薪挖角可能伴随“无法着陆”的风险。他特别强调，“剩者为王”，在平台中日耕月耘的积累，其长期回报可能远超频繁跳槽带来的短期薪资涨幅。 最终，文章给出了务实的建议：在能力与火候未到时，不必主动求职，好的机会自会找上门；而转行则需极其谨慎，应在现有领域深耕后再做考量。文章将个人选择与平台价值紧密关联，为身处职业十字路口的人提供了一套理性决策的思考框架。
GA SEO报告中的Not Provided和Not Set
用GA追踪SEO时，看到自然搜索流量里冒出来的“(not provided)”和“(not set)”总是让人一头雾水。这篇文章就专治这种困惑，作者从GA报告的具体路径入手，一步步拆解了它们的来龙去脉。 核心问题在于，(not provided)并非GA的故障，而是Google为保护已登录用户的隐私而采取的加密措施。当用户通过加密的HTTPS链接访问网站时，搜索关键词信息就被隐藏了，GA自然也就“无从得知”。这也解释了为什么付费广告数据通常不受影响——Google对广告主还是“网开一面”。而(not set)则更像是一个占位符，用于表示那些本身就没有关键词维度的流量来源，比如直接访问。 文章还指出了一个现实：随着浏览器安全策略的收紧，(not provided)的比例可能远超预期。既然精确获取关键词已无可能，作者建议利用GA的“二级维度”功能，通过分析对应的着陆页来间接推断用户意图。这篇分析把GA报告里一个看似技术性的小问题，讲透了背后的逻辑和应对思路。
学习周鸿祎的产品推销手法
这篇讲的是，作者通过拆解周鸿祎在《天天向上》节目中的一次产品宣传，深入剖析了一套极具个人色彩的产品推销“方法论”。 文章以2013年周鸿祎上《天天向上》推广360产品为案例，提炼出其手法的“三板斧”与更多内核。首先，最核心的一点是“始终高举用户利益旗帜”，将产品行为与“为用户服务”的叙事牢牢绑定，建立天然的道义制高点。其次，是精准运用“同理心”，以“我和你一样”的姿态拉近距离，让产品行动显得是为共同利益而战。再者，善于在对比中凸显自身优越，通过树立明确的“敌人”来定义自己。 更值得玩味的是其“武学正宗”级别的场景化推销能力——在节目中直接放出手机号演示防骚扰功能，堪称将产品卖点融入具体场景的经典示范。此外，作者也提及了周鸿祎娴熟的“打太极”式沟通技巧。 总结来看，这篇文章并非简单复述事件，而是将一次公开亮相解构成了可供产品经理借鉴的“推销心法”：即如何围绕“用户利益”的基石，综合运用同理心、对比、场景营销等技巧，将产品叙事植入人心。对于理解如何进行有策略、有层次的产品沟通，提供了非常具象的参考。
如何管理程序猿
这篇讲的是作者从管理一支“程序猿”团队的日常出发，总结出几条核心管理心法。作者认为，虽然程序员有着独特的思维和作息，但管理他们的黄金法则依然是“己所不欲，勿施于人”，关键在于特别留意他们“痛恨且不擅长”的小事。 一个鲜明的例子是：团队里没人愿意写周报，作者便选择自己根据成员活动总结，每周写15份，这反而比催促他们更高效。其他要点包括：尽可能为他们减少官僚流程；分配有挑战性、甚至有竞争感的任务；主动分享公司业务动态，帮助他们寻找解决方案；以及建立定期的一对一谈心机制。 作者也指出，管理要避免过度“优待”个别人，而是让整个团队感受到灵活度和尊重。最后，文章提及了一个关于管理大型团队的演讲视频链接，并强调，只要方式得当，管好这支特殊的团队能带来丰厚的回报。
一路读来 – 那些曾改变我思维轨迹的书
作者在新年假期整理了一份改变自己思维轨迹的书单，从学习方法、软件开发、设计思维延伸到商业与人生。这份清单的核心脉络，是一位技术人如何通过阅读构建起跨领域的认知框架。 起点是高中读的《学习的革命》，它引发了作者对传统教育的质疑。到了大学阶段，《程序员修炼之道》与《敏捷软件开发》将敏捷开发从理念落地为具体实践，确立了实用主义的工作方式。而《交互设计之路》和《设计中的设计》则引导他将视角从纯技术转向用户心智和产品体验，认识到设计是产品不可分割的一部分。 思维的拓展不止于技术本身。《富爸爸，穷爸爸》重塑了他的财富观，强调资产与事业的构建；《精益创业》则将敏捷思想扩大为完整的产品制造方法论，其“验证认知”和MVP理念极具工具价值。此外，《引爆点》解析了产品流行的机制，《日本漫画为什么有趣》训练了他从符号本质看事物的能力。最后，书单以《生命之光》收束，指向对身心平衡与生活细节的珍视。 这并非一份简单的书目罗列，而是一位创作者思维演进的连续体。作者通过定期重读，不断校准和深化自己在技术、商业与生活层面的思考。
技术人员的未来：做技术还是做管理？
这篇文章讲的是许多工作数年的技术人员都会遇到的十字路口：未来该走技术专家路线，还是转向管理岗位？作者从个人职业规划出发，探讨了这个普遍而重要的选择。 文章首先指出，这个选择不能盲从“当官才有出息”的社会观念，而应基于性格、兴趣和个人目标来判断。作者用出租车司机老师傅拒绝当小组长的真实故事说明，有人天生不擅长或不喜欢管理人，专注于技术反而能做得更好。 接着，文章梳理了两条路线的不同要求。技术路线可以深耕为技术专家、架构师或业务专家，核心在于专业深度或广度与解决问题的能力。而管理路线则更侧重沟通、判断、执行和团队协作等综合软技能，与技术能力的要求差异很大。 最后，作者建议，明确目标是第一步，然后将目标拆解为可学习的步骤，并持之以恒地实践。他强调，选择与自身性格和热爱相符的道路，职业发展会更顺畅，人也活得更自在。 希望每位读者都能找到属于自己的答案。
被“绑架”的产品经理
这篇文章探讨了一个产品团队中常见的现象：产品经理如何被各方需求与意见所“绑架”，以及如何找回工作的自主权与初心。 作者从个人体验和观察出发，描绘了产品经理面临的典型困境——来自上级的指令、技术的实现边界、UI/交互的设计追求，以及市场运营的诸多诉求，常常让人疲于奔命，最终迷失了产品的方向与自我的判断。文章犀利指出，当产品经理的专业技能无法超越团队中任何一员时，其立足之本便值得深思。 在剖析了“被绑架”的根源后，文章提出了具体的“挣脱”建议：学会对不合理的需求说“no”；了解基本技术实现以拓宽思路；培养冷静的判断力，甚至敢于离开不适合的环境；同时学会放下执念，对自己与他人保持宽容。这些建议旨在帮助产品经理构建强大的内心与清晰的专业边界。 最终，文章落脚于对职业初心的叩问。它认为，正是一次次被“绑架”的经历，反而锤炼了产品经理的心智。正是出于对产品纯粹的热爱，才能让人在无数次想放弃时，依然选择坚持走下去。
程序员新年计划
作者从同事一篇关于新年计划的文章受到启发，结合自己近20年的开发经验，提出了几项对程序员职业发展切实可行的反思性目标。 他认为，职业生涯中应避免成为“最聪明的人”，因为那意味着无人可问。为此，他倡导双向的指导关系：一方面主动寻找并请教你尊敬的导师，无论是圈内专家还是圈外长者；另一方面，也应成为他人的导师，通过倾听和陪伴，在对方需要时提供方向指引。 在代码层面，他回归了经典原则。首先是KISS——坚持“保持简单”，因为维护代码的时间远多于编写，故而应花时间重构，让代码短小易读、可被接手。其次是RTFM——认真阅读需求文档，这是项目知识的基石，与其盲目开干，不如多与需求提出者沟通。最后是DRY——杜绝重复，提醒我们不要在多个项目中复制粘贴同一段代码，这无异于为未来埋雷，应善用工具将重复片段重构为方法。 这篇文章并非技术清单，而更像一次职业心态的梳理，提醒程序员们在编码之外，关注协作、沟通与代码的长期生命力。