Mooreds

mooreds.com，Dan Moore 关于软件开发、认证、授权与开发者关系的博客。

给非技术创始人的建议：如何找到合适的技术联合创始人（2021）

作者从两次创业和早期技术合伙人/顾问的一手经验出发，给非技术创始人找技术联创的实操建议。核心论点：大多数人不缺 CTO，而是缺"创始工程师"；要明确自己要解决什么问题、手里有什么资源、能给出什么条件。技术人才的机会成本高，作者估算纯股权加盟意味着每年净损失约 15 万美元，因此要舍得给双位数股权并预留稀释池；同时要展示自己能"把事做出来"，用 no-code 和手工流程先验证想法。找人的渠道包括技术 Slack/Meetup、Angellist 公司页、以及在 Reddit/HN 评论区做定向外联；发帖前先融入社区。接触候选人后让其他技术人验证其能力、先合作小项目、设定股权归属期，并提前谈控制权、退出机制和角色边界。整体偏实操清单，适合早期非技术创始人参考。

收藏8 天前

软件何时才算做完？

作者提出判断软件功能是否“完成”的框架：发现（Discovery）、使用（Usage）、幸福（Happiness），三者缺一不可。核心观点：当 AI 大幅压低开发成本后，瓶颈已转移到分发与用户沟通端；团队需让用户发现新功能、愿意尝试并愿意将其纳入工作流才算完成。文章按角色拆解了不同人对“完成”的定义——开发者看合并/部署，市场看发布，商业看首单，用户看首次使用——并指出这些都只覆盖框架的一部分。对科技从业者有实用启发，尤其是把“churn”和用户体验张力纳入判断标准；观点清晰但偏常见框架化梳理，新事实与争议度有限。

收藏9 天前

技术认证到底有什么用？

Java认证考试能证明基础能力、拓宽技术视野、加深理解深度，还能作为学习目标。作者手持SCJP证书并正在备考SCWCD，认为认证虽不能替代真实项目经验，但对求职和技术成长都有实际帮助。

收藏18 天前

从RDS备份恢复单个数据表

从RDS备份恢复被误删的单表数据。先按删除时间点启动新实例，修改安全组允许MySQL访问，用mysqldump导出目标表，再导入生产库。若删除后表有写入，需手动合并当前数据。整个过程需在备份保留窗口内完成。

收藏38 天前

玩 Spelling Bee 教会我的三件事

一位开发者用 NYT Spelling Bee 游戏引出三条职业建议：卡住时换个角度、不确定方向时先行动、有起色的事就加码而不是总看别处。文中提到自己 quit 了 head of engineering 职位、做了季度休假、离开共同创办的食品创业公司，以及参加 meetups 的职业价值。

收藏46 天前

领导工程团队是怎样的体验？评《CTO in the Loop》

Mooreds 书评《CTO in the Loop》，认为该书通过主角 Sam 的职业轨迹，真实描绘了工程师向管理层晋升时的抽象层级提升及与一线脱节的问题。文章特别赞赏书中关于管理困境（裁员、解雇）及商业诚信（如数据导出便利性）的探讨，指出高层面临的诱惑与挑战。建议早期或中期职业生涯的软件从业者阅读，以了解不同层级的实际工作状态。

收藏71 天前

争取“不被反对”，而非“获得许可”

文章提出一种职场沟通策略：与其请求老板批准（ask for yes），不如告知计划并设定截止日期，让老板有机会反对（ask for no）。作者认为这种方式能减少老板的认知负担，避免因等待批复而停滞，同时保持信息透明。通过GitHub Action安装的例子说明，明确的时间节点能促使管理者更快响应或默认同意，从而推动执行者保持行动力。

收藏100 天前

当我感到嫉妒时，我没看到的那些事

作者面对同龄人取得世俗成功（财富、自由、名声）时的嫉妒心理进行剖析。核心观点是：我们往往只看到他人光鲜的一面，而忽略了背后的代价、风险和个人牺牲。作者提出应对策略包括：意识到自己不了解全貌、想象对方付出的努力、利用自身能动性改变现状，以及培养感恩心态。文章强调通过换位思考和自我反思来化解嫉妒，而非单纯的情绪压抑。

收藏100 天前

AI无法真正在乎

本文提出一个被忽视的观点：AI真正无法做到的不是判断，而是"在乎"。AI不在乎答案对错，不在乎读者是否被误导或浪费时间。而关心读者，是沟通的根本。作者认为AI适合做辅助工具——帮忙起草、查资料、改措辞，但绝不应该直接发布。那些一眼能看出是AI生成的帖子，本质上是在贬低读者的信任。短小精悍，观点鲜明，适合所有在AI时代坚持真诚创作的读者。

收藏116 天前

自由职业软件开发经验谈（2005）

一位软件开发者在结束两年合同制工作、转全职后，对比两种工作模式的切身感悟。核心看点：合同制让你被迫学会销售与财务、接触更广泛的技术栈（作者两年用了6种编程语言）和商业场景（从小公司到大企业，从创业团队到成熟组织）；时间与金钱更灵活，可自主取舍；相比全职，合同制因技术决策不具永久性、不卷入内部政治，压力更小。缺点是难融入团队、每次切换项目需快速上手。作者建议有6个月生活费缓冲即可尝试。文章充满具体细节和个人判断，是同类主题中少见的真诚、有厚度的经验分享。

收藏148 天前

会议是一种强制推进机制

核心看点：作者以亲身管理经验论证，定期站会（Standing Meeting）是多线程长周期项目中最被低估的推进武器。当一项重要工作不属于任何人的全职职责，日常琐事很容易让它沉到待办清单底部。作者指出关键不在于会议形式（线下或视频均可），而在于两条硬规则：坚持维护议程，以及每次会议先回顾上轮待办项。这种机制制造出温和但真实的社交压力——当你知道下周会被问"上次说的X进度如何"，自然会在混乱中挤出时间推进。文章还举了咨询公司vs客户团队的协作场景来说明跨组织同样适用，并给出从周会到月会的节奏建议。一句话：把会议当成一种"强迫函数"，不是浪费时间的无效沟通。

收藏157 天前

新角色，老东家：从管理层回归独立贡献者之路

一位技术管理者自曝职业生涯中的反复模式：被升为经理→做一段时间→不开心但不敢说→最终辞职离开。在 FusionAuth 带领 DevRel 团队四年后，他再次站在同样的十字路口，但这次他选择主动找老板摊牌——明确表示自己不想做管理，想做高价值独立贡献者（IC）。让他意外的是，公司听到了他的诉求，专门为他设立了 Principal Product Engineer 岗位，并外聘了一位真正热爱管理的负责人来接替。他坦言，过去不敢开口是出于恐惧和不信任，以为公司不需要一个不做管理的技术人；这次经历让他意识到，很多看似无解的困境，其实缺的只是一场坦诚对话。文章为那些厌倦管理、想回归技术但担心没有退路的人提供了一个真实案例和具体做法。

收藏158 天前

面向开发者产品的营销思路（2019）

一位有技术背景的作者为朋友公司的开发者工具产品支招，提出7条务实的冷启动营销策略：先读《The New Kingmakers》理解开发者生态；去Reddit、IETF工作组等现有社区做贡献而不只是推广；写真实用户案例；找垂直领域分析师/博主做产品演示；在博客上写有技术深度的内容而非产品广告；投稿技术会议或线上meetup；用Google Alerts追踪竞品讨论并伺机提供价值。全文核心原则是"别做推销，让开发者日子更好过"。建议中肯实用，带有亲历者视角，不是营销号套话。

收藏171 天前

如何规划大型教育项目（2025）

核心看点：作者以亲身经验分享规划大型教育项目（如写书、做课程）的实操方法——从主题大纲入手，拆解成10篇博文标题并逐一完成，推荐Leanpub等工具实现边写边发布，同时强调建立邮件列表收集感兴趣用户，以及至少花10%时间思考和执行推广策略（LinkedIn、Slack、播客、CFP、Reddit答疑等）。文章源于作者在私信中的回答，经整理公开发布，语气真实随性，没有套话包装，对正在筹划教育类内容项目的人有直接参考价值。

收藏185 天前

并非裙带关系的信任

核心看点：年轻时作者认定空降高管带进自己人就是裙带关系，不公平、不尊重现有团队。但多年间目睹多家公司易帅换将后，他开始重新理解这件事。新高管接手时本身承受巨大交付压力，环境还没摸熟，愿景还没定准，最本能也最理性的选择就是雇佣自己信得过的旧部。这不是任人唯亲的腐败，而是在高压与不确定下的人性决策。全文以第一视角娓娓道来，没有空泛道理，只有一次认真、坦诚的认知升级。对在技术或管理岗位的读者尤其有共鸣和讨论价值。

收藏197 天前

初创公司的机遇与收益（2024）

一位曾创办公司并早期加入过五家初创的过来人，用亲身经验定义了什么是真正的初创公司：核心在于可规模化增长，而非注册形态。他用洗车店vs管理软件、房产中介vs技术经纪平台等生动对比，划清了小生意与初创的界限。加入初创的最大收益不是金钱，而是增长压力下被迫涉足开发运维、招聘、产品、流程设计、冲突处理、客服、销售等多个领域——这些交叉能力在大公司很难获得。文章坦诚地承认有机会成本，但选择聚焦受益面，且不回避个人阶段不同选择也会不同。没有模板化包装，没有虚张声势，就是一个有真实经历的人在聊真实体感，适合正在考虑加入或创办初创的人看看。

收藏205 天前

你想建立一个用户来搜索还是来闲逛的社区？

核心看点：这篇文章用一个简洁有力的框架帮你判断——你要建的开发者社区是"Facebook型"（用户来闲逛社交）还是"Google型"（用户搜到答案就走）？作者以亲身经验分析了两种社区的本质区别：StackOverflow 是典型的"Google型"，用户快速找答案后离开；Ruby 社区、Rands Slack 则是"Facebook型"，用户留下来聊天交友，话题广泛，甚至延伸到线下聚会。文章指出大多数社区天然倾向某一端，建设者需要有清晰的定位认知。实操层面给出了从"Google型"起步、逐步向"Facebook型"演进的建议：高质量文档、可搜索问答库、清晰路线图、多渠道反馈、成员展示、线上线下 meetup 等。核心洞察：帮助建立信任，信任是更深层社区的地基。这是一篇有个人经验、有框架思考、有具体建议的好文章，适合所有关注社区建设的人。

收藏224 天前

感恩有内存管理功能的编程语言（2025）

一位二十年Web开发者的感恩独白：编程生涯恰好赶上内存托管语言（Java、Perl等）兴起。从Pascal入门、16张软盘装Slackware Linux、Java RMI毕业设计，到第一份工作周工时96小时——作者用亲身经历论证，当开发者无需为malloc/free分心，才能专注数据模型与领域理解。不是技术教程，是一篇有温度、有细节的个人技术回忆，能让Web开发者产生共鸣。

收藏245 天前

如何成为出色的会议演讲听众（2022）

作者以亲身经历分享如何成为会议演讲的优秀听众。作为曾同时担任演讲者和听众的技术人，给出了8条实用建议：不感兴趣就安静离场、专注听讲、用点头/皱眉等面部表情给演讲者即时反馈、适时举手提问、会后给出建设性意见而非客套话等。核心观点是：做好听众不仅是对演讲者的尊重和鼓励——毕竟公开演讲是常见的恐惧来源——更能让自己从专家身上学到更多东西。文章语气亲切自省，坦诚承认自己有时也会走神，区别于"参会礼仪"类的教条清单，充满了真实的人际观察和换位思考。对经常参加技术/行业会议的人群有直接参考价值。

收藏255 天前

MVP 本该令人尴尬

如果第一版产品不让你感到尴尬，那就发布得太晚了。本文作者以亲身创业经历说明 MVP 的核心精神：与其追求完美功能堆砌，不如尽早把不完善的原型放到真实用户面前。文章给出四种低成本验证方法——纸面/可点击原型测试、Beta 计划招募早期用户、伪造功能手动验证需求、视频对话走查观察真实操作痛点。核心观点：商业风险未知时，用熟悉技术栈降低技术风险；早期用户更关心问题能否被解决而非界面精致度；持续改进会让用户更包容初期缺陷。引用 LinkedIn 创始人 Reid Hoffman 经典名言，贯穿始终的呼声是聚焦用户而非软件功能，是典型的"人味优先、经验驱动"的创业反思文章。

收藏262 天前

支持工单到文档的生命周期：为何它是技术写作的宝藏

开发者关系和技术写作者如何将用户支持工单转化为文档的实战方法论。作者基于亲身经验分享了完整流程：阅读所有工单、延迟处理、提炼问答发布到论坛、重复问题则升级为独立文档。核心洞察在于解释为什么先发论坛而非直接写文档——论坛帖子带时间戳，只需对当下负责，维护成本远低于技术文档；同时论坛的Q&A格式有利于LLM抓取和搜索引擎长尾流量。文章还诚实讨论了该方法的局限性：不能为不存在的工单创作内容、在大型组织较难实施、需结合整体文档架构。有明确操作步骤、有决策理由、有风险提示，是一篇有温度有干货的DevRel实践分享。

收藏268 天前

AI时代新程序员须知：核心职责不变，学会判断与驾驭AI而非盲从

作者此前写过《给新开发者的信》，如今AI浪潮下再写续篇。核心观点清醒且反套路：开发者的使命从来不是写代码或喜欢技术，而是用技能解决业务问题——这一点在AI时代没有变。 AI更像是搜索引擎结果，而非确定的编译器报错，新人必须学会判断何时信任、何时警惕。文章给出具体可操作的策略：从小处着手，用AI编写单元测试、只读SQL查询等容易验证的低风险任务，逐步建立对AI输出的直觉和判断力，而非盲目依赖或彻底抛弃。作者还顺带推广了自己的书，不过核心建议本身扎实、来自一线经验，对刚入行的开发者有实际参考价值。

收藏282 天前