How to Not Die by a Thousand Cuts. Or, How to Think About Software Quality5 days agohttps://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html品质是过程的体验，优雅行事，让事物比发现时更好。软件产品是纯粹的概念，具有无限的可塑性，但需要持续维护以适应变化的世界。千刀万剐的比喻适用于软件：微小的伤害（热修复、投诉、崩溃）累积并降低质量。线性的软件工作流程（分析→产品→用户体验→开发→测试→生产）将风险集中在早期阶段，延迟反馈，并加剧债务。更多...
On Linus Torvalds, technical & corporate communications - Bert Hubert's writings7 days agohttps://berthub.eu/articles/posts/linus-communications/Linus Torvalds的沟通风格从粗犷退化到伤人，但他现在正在寻求帮助。三种沟通风格被对比：激进的诚实、符合企业人力资源部要求的长篇大论，以及简洁的工程师式直截了当。工程师式的回应被推荐，因为它直接且尊重，既避免侮辱也避免官僚式的冗词。Linus旧风格的支持者错误地将咒骂与诚实混为一谈，担心避免侮辱会导致企业式的废话。更多...
The just-say-no engineer was a ZIRP phenomenon7 days agohttps://seangoedecke.com/the-just-say-no-engineer-was-a-zirp-phenomenon/“只说不行”工程师是资深/主管工程师，他们通过阻止变更来维护质量，与优先考虑速度的“只说行”工程师形成对比。在ZIRP（零利率政策）时期（2008-2022），科技公司为低风险项目雇佣了大量工程师，使得“只说不行”工程师在防止因过度变更而导致的混乱方面很有价值。ZIRP结束后，公司专注于生产力和盈利能力，减少了对把关人的需求；这种转变常被错误归因于人工智能，但实际上是由经济因素驱动的。AI生成的代码增加了压力，但并非根本原因；“只说不行”工程师的角色是依赖于ZIRP时代的。更多...
How to be useful as a software architect9 days agohttps://swizec.com/blog/how-to-be-useful-as-a-software-architect软件架构师必须在改进未来代码和维护当前业务速度之间取得平衡。常见的架构师失败模式包括编写被忽视的文档、强制执行僵化的规则，或者因做所有清理工作而精疲力竭。高效的架构师构建能够使所有团队成员快速、安全地贡献的系统。代码审查和系统设计审查是关键，但它们不应成为瓶颈；自动化和文化有助于扩展这些流程。更多...
We pay engineers to cut our infra billa month agohttps://rootly.com/blog/we-pay-engineers-to-cut-our-infra-billRootly的工程师实施了ECR生命周期策略，每年节省了44,000美元，但仅获得了一个Slack点赞作为认可。由于缺乏激励措施，成本优化往往得不到解决，相比带有截止日期和OKR的功能工作，成本优化被视为'额外加分项'。行业中常见的方法如文化原则、可视化工具和游戏化机制存在，但可能无法为成本节约举措提供持久的动力。Rootly创建了'节省与分享'计划，提供按年度节省金额百分比计算的现金奖金，以激励全公司进行成本优化。更多...