Underused Techniques for Effective Emails · Refactoring English9 months agohttps://refactoringenglish.com/chapters/techniques-for-writing-emails/有效的电子邮件应当清晰、以行动为导向、内容相关、高效且简洁。优先传递最重要的信息，使用单行摘要或项目符号列表。使用Markdown Here浏览器扩展插件来优化邮件格式。撰写完整回复以减少邮件往来次数。当讨论范围变化时拆分邮件线程并更新收件人列表。使用标题和段落分隔来优化长邮件的可读性结构。
Keeping Up with AI: The Painful New Mandate for Software Engineers9 months agohttps://thenewstack.io/keeping-up-with-ai-the-painful-new-mandate-for-software-e...到2028年，90%的企业软件工程师将使用AI编程助手，较2024年初不足14%的比例大幅提升AI原生的软件工程实践将优化基于AI的工具使用，用于开发和交付软件系统开发者将从AI辅助开发转向完全AI原生开发，实现端到端工作流自动化AI工具将作为创意伙伴，提升开发者、产品负责人和UX设计师等角色的创造力多模态AI工具可将文本提示或草图转化为可视化原型，简化设计工作流程开发者需用自然语言清晰表述需求，以最大化AI工具效能开发者角色将演变为AI驱动工作流程的协调者，类似乐团指挥AI原生实践可在产品设计和功能优先级等上游流程中加速决策通过AI扩展开发者产能，可释放人力专注于更关键任务技术领导者应采取分阶段策略：评估、试点、整合、持续改进挑战包括思维转变、安全风险和知识产权侵权，需平衡自动化与人工监督安全风险涉及攻击面扩大，需建立自动化测试和治理政策领导者应优先选择低风险高价值的AI用例，并利用自主改进闭环
I Made a Realtime C/C++ Build Visualizer9 months agohttps://danielchasehooper.com/posts/syscall-build-snooping/许多软件项目因可修复的低效问题而遭受构建速度缓慢的困扰。What the Fork 是一款跨平台工具，旨在识别并帮助优化构建流程。该工具适用于任何构建系统或编程语言，而不仅限于 C/C++。它通过可视化构建时间线来突出问题，如缺乏并行性、某些文件耗时过长以及不必要的命令。低效案例包括使用'make'时未添加'-j'参数，以及CMake构建中重复的环境检查。工具名称源自'fork()'系统调用，使用时需在构建命令前添加'wtf'前缀。它特别有助于优化CI构建（这类构建通常缺乏缓存且需要完全重建）。不同操作系统需要不同的API来监控进程执行，但该工具已处理这些复杂问题。案例研究表明，该工具成功揭示了Delta、Mozilla和Apple项目中出人意料的构建低效问题。该工具已在Windows、Linux和macOS平台开放早期测试版本。
Modifying other people's software9 months agohttps://natkr.com/2025-08-14-modifying-other-peoples-software/修改他人构建的软件是常见行为，但由于修改的专一性、时效性或个人偏好，将变更反馈至上游往往难以实现。Git虽在版本控制方面功能强大，但其基于线性前进的历史模型难以长期维护独立补丁。柔术（jj）支持历史重写，但缺乏操作日志共享功能，导致协作困难。Linux发行版使用.patch文件和Quilt等工具管理补丁，但这些方案存在局限性和可用性问题。Lappverk作为解决方案被提出，采用类Git工作流管理补丁集，支持便捷的补丁集导入/导出并维护补丁历史。该工具显著简化长期维护补丁的过程，无需完整分叉即可轻松应用个性化或环境特定的修改。其设计灵感源自Patchable等内部工具，旨在提供更符合Git使用习惯的补丁管理方案。
The trap of tech that's great in the small but not in the large9 months agohttps://surfingcomplexity.blog/2025/08/16/the-trap-of-tech-thats-great-in-the-sm...Shell脚本非常适合小型任务，但随着复杂度增加会变得难以维护Makefile在简单任务上表现良好，但难以扩展规模YAML适合小型配置，但在大规模场景下难以管理电子表格被广泛使用，但当作数据库使用时容易产生问题Markdown非常适合简单文档，但不适合书籍等大型项目
The Enterprise Experience9 months agohttps://churchofturing.github.io/the-enterprise-experience.html作者回顾了在$ENTERPRISE工作一周年的经历，分享了从初创公司转型到大企业的适应过程。重点指出大企业效率低下和官僚主义问题，例如难以找到工具和项目的实际负责人。批评企业环境中资源浪费和问责缺失现象，与小型公司的高效运作形成鲜明对比。探讨职场中荒诞的生存法则，包括无能员工未被解雇、绩效与人事决策脱节等现象。分析企业工作中不同形式的「紧迫性」，区分真实危机与人为制造的紧急状态。评论企业安全防护的形式主义——指标考核往往凌驾于真实风险评估之上。分享对管理层重蹈覆辙的观察，指出组织缺乏从历史错误中学习的能力。描述企业内部各「封地」间工程标准执行不统一的现象。尽管提出诸多批评，作者仍表示享受当前岗位，并列举了值得肯定的体验。文末附联系方式，邀请读者通过邮件深入交流。
A programmer's field guide to assertions9 months agohttps://typesanitizer.com/blog/assertions.html代码中的断言在特定点验证条件，若为假则中断正常流程。触发断言的常见响应包括抛出异常、恐慌或终止程序。断言可根据构建配置条件化：仅调试模式（开发环境）或全构建模式（生产环境）。断言与测试、类型不变量等其他健壮软件技术互为补充。文章分享了断言的实际应用案例，包括单调映射构建和数据库查询扫描。有效使用断言需对断言条件有充分把握，且避免对外部系统做断言。在团队中推广断言需要解决文化抵触和技术质疑。常见反对意见包括性能开销、代码可读性及生产环境故障风险。在线系统中使用断言应搭配粗粒度恢复机制。文章最后建议通过开源项目实践来深入理解断言的应用。
Ralph Wiggum as a "Software Engineer"9 months agohttps://ghuntley.com/ralph/拉尔夫·维格姆（Ralph Wiggum）是一种软件工程技术，核心是通过Bash循环调用@sourcegraph/amp等AI工具进行开发该技术专为绿地项目设计，可替代大量外包工作，但存在可识别且可修复的缺陷方法本身是确定性的，但运行在不确定的环境中，需要根据大语言模型行为观察持续调优该技术正用于构建名为CURSED的新编程语言，证明了AI无需训练数据即可工作的能力使用拉尔夫需要相信最终一致性并放手让AI编码，信任AI能在每个循环决定最重要任务关键原则包括：单循环单任务、最小化上下文窗口、通过子代理实现并行操作同时保持控制规范（specs）至关重要，需通过与AI的初始对话形成，确保实施前达成清晰共识测试/静态分析/安全扫描等反压机制对验证AI生成代码和保持正确性不可或缺文档和测试说明对后续循环至关重要，因为AI不会保留跨迭代的上下文记忆拉尔夫能自我改进：更新AGENT.md指令文件，在fix_plan.md中记录错误和学习成果该技术不适用于现有代码库，但在新项目引导方面表现出色，可能取代传统绿地项目的软件工程角色仍需要资深工程师指导拉尔夫，驳斥了AI能完全取代人类工程师的观点当前构建CURSED的提示词强调：严格遵循规范、避免占位实现、保持计划和文档实时更新
Sequoia Backs Zed's Vision for Collaborative Coding9 months agohttps://zed.dev/blog/sequoia-backs-zedZed宣布由红杉资本领投的3200万美元B轮融资，总融资额超4200万美元。愿景是通过将对话直接关联到代码来改变软件协作方式，超越静态截图模式。正在开发DeltaDB——基于操作的版本控制系统，支持人类与AI实时协同编程。DeltaDB采用CRDTs技术实现增量变更追踪，兼容Git系统，支持字符级永久链接。Zed致力于使代码库成为活态历史，保存讨论与修改记录以实现情境感知的AI交互。采用开源模式，为Zed和DeltaDB提供可选付费服务。正在积极招聘工程和产品设计人才，以推动协作式软件开发进程。
Zed for Windows: What's Taking So Long?9 months agohttps://zed.dev/blog/windows-progress-reportZed的Windows移植工作正在推进，有四名工程师全职投入开发。团队创建了新的DirectX 11渲染后端替代Vulkan，确保兼容大多数Windows用户并降低内存占用。使用DirectWrite重新实现了字形光栅化，提升调试便利性并修复了裁剪问题。通过改进MSAA方案优化了VRAM使用，全平台性能得到提升。针对Windows设计了新的自动更新策略，以解决.exe文件限制问题。更新了崩溃报告系统，支持收集minidump文件用于服务端符号化分析。未来将重点开发键位绑定、SSH远程连接、WSL支持、扩展功能和性能调优。欢迎参与Beta测试和贡献代码，文末附有参与方式和招聘链接。
Why do software developers love complexity?9 months agohttps://kyrylo.org/software/2025/08/21/why-do-software-developers-love-complexit...大金字塔象征着人类巨大的努力，正如当今软件开发人员构建复杂系统一样尽管工具先进，软件却常变得不必要的复杂，这与KISS（保持简单）原则背道而驰营销往往偏爱复杂性而非简洁性，诸如'Penzilla'或'catzilla'等夸张产品案例就是明证复杂性可以传递努力、专业性和排他性信号，使其成为身份象征而非实际需求现代软件分层（依赖项、框架）可能掩盖实质内容的缺失，就像金字塔里的空室简洁性常被忽视，但因其功能可靠性往往成为长期赢家React与原生JavaScript的对比，展示了框架相较简单方案带来的不必要复杂性开发者拥抱复杂性源于创作诱惑、遗留系统、团队动态和创新压力像古埃及人一样有目的地构建，才能创造价值而非给未来维护者留下空洞的复杂负担
It's okay to solve a problem twice9 months agohttps://til.andrew-quinn.me/posts/it-s-okay-to-solve-a-problem-twice/作者反思了'同样的问题绝不应该解决两次'这一格言，以及自己在职业生涯初期对其过于字面化的理解。起初他更倾向于系统管理工作而非软件开发，认为使用Awk等现有工具比编写新代码更高效。随着时间推移，他意识到与那些从零构建解决方案的同龄人不同，自己的做法未能展现雇主所看重的问题解决能力。作者承认反复解决问题往往是必要的，犯错也是学习过程中不可或缺的部分。他对比了两位求职者：一位从基本原理构建解决方案，另一位依赖现有工具，认为前者更能体现专业能力。作者最终得出结论：承诺绝不重复解决相同问题是不现实的，真正的精通往往需要重复练习并从错误中学习。
Naming Things: The Most Underrated Skill in Software Development9 months agohttps://andreacanton.dev/posts/2025-08-23-naming-things/命名是软件开发中被低估但至关重要的技能糟糕的命名会导致混乱、延误和开发成本增加一个真实案例显示误导性名称('物料清单')如何引发连锁问题不良命名影响新人上手、团队沟通、开发速度并可能引入缺陷科学研究证实：有意义的名字提升理解力并降低认知负荷优秀的命名能构建团队共同语言，成为活的文档命名框架三要素：清晰性、描述性、相关方理解度通过反馈和协作才能确定最佳命名前期在命名上投入时间能为后期节省大量精力每个命名选择都将影响未来开发效率和团队协作
The World Runs 20B Instances of Curl. Where's the Support?9 months agohttps://thenewstack.io/the-world-runs-20-billion-instances-of-curl-wheres-the-su...Curl作为命令行工具和库，已在全球超过200亿个实例中安装使用。尽管影响巨大，curl的创造者Daniel Stenberg仍独自维护着这个项目。开源软件估值已达8.8万亿美元，但企业支持仍然不足。开源项目维护者承受着巨大压力，数百万个项目依赖个人开发者支撑。Linux基金会报告指出，企业高管层对开源战略价值的认知存在缺口。欧盟《网络弹性法案》和AI技术进步进一步加重了开源维护者的负担。
What the interns have wrought, 20259 months agohttps://blog.janestreet.com/wrought-2025/在Jane Street的实习项目包括优化神经网络序列模型、为构建系统添加构建优先级，以及为交易系统创建自动化测试。Leo Gagnon为JSQL（Jane Street的内部SQL方言）开发了一个更高效的评估器，利用索引技术提升性能。Aryan Khatri通过引入张量内存管理的引用计数机制改进了OCaml torch绑定，优化了GPU内存使用。Anthony Li创建了一个跨进程内存管理库，采用引用计数技术，消除了共享内存通信中对序列化的需求。这些项目展示了针对技术难题的创新解决方案，为Jane Street的系统带来了显著的性能提升和新功能。
Interview with Dennis Ritchie, Bjarne Stroustrup, and James Gosling (2000)9 months agohttp://www.gotw.ca/publications/c_family_interview.htmC语言家族（C、C++、Java）主导商业编程领域已超过30年C99标准于1999年12月正式发布，延续了C语言的影响力，尤其在嵌入式系统领域ISO/ANSI C++标准的首次官方更新于2000年10月完成Java持续流行，Sun公司决定放弃正式标准化努力丹尼斯·里奇、本贾尼·斯特劳斯特鲁普和詹姆斯·高斯林讨论各自语言的成就与未来C语言的成功部分归功于其作为Unix系统通用语言的地位C++早期的流行很大程度上得益于与C语言的兼容性Java最初的热潮是由强势营销推动的三位创始人探讨各自语言的设计目标、挑战与经验教训重点指出了开发者在使用C、C++和Java时的常见错误关于编程语言正式标准与事实标准重要性的辩论探讨软件开发与编程语言的未来趋势
Cognitive Load is what matters9 months agohttps://github.com/zakirullin/cognitive-load认知负荷是软件开发中的基本约束条件，会影响理解能力和工作效率。内在认知负荷是任务固有的，而外在认知负荷由信息呈现方式引起，可以通过优化设计来降低。实际案例表明，减少外在认知负荷能显著提升代码可读性和可维护性。具有简单接口的深层模块优于交互复杂的浅层模块。过度遵循DRY（不要重复自己）原则可能导致紧耦合并增加认知负荷。框架和微服务若使用不当，会引入不必要的复杂性和认知负担。抽象应该基于实际需求而非架构纯粹性来添加。领域驱动设计(DDD)常被误读，过度关注解决方案空间而非问题空间。团队拓扑结构比DDD更能有效管理跨团队认知负荷。简化代码和降低认知负荷应作为提升可维护性的系统性工作。
Bear is now source-available9 months agohttps://herman.bearblog.dev/license/Bear最初采用MIT开源许可，旨在保持透明度和促进学习。经历了分叉项目被用于创建竞争服务的痛苦。改为Elastic License许可，以防止托管/管理服务的竞争。Elastic License与MIT类似，但限制商业托管行为。承认开源项目更新许可以防止竞争是行业趋势。强调Bear的独特价值在于其社区和长期稳定性。承诺保护平台未来，即使这意味着限制代码使用权限。
Zig Software Foundation 2025 Financial Report and Fundraiser8 months agohttps://ziglang.org/news/2025-financials/Zig软件基金会（ZSF）是一家501(c)(3)非营利组织，资金使用高效，主要支付给项目贡献者。2024年总支出520,748.91美元，其中92%用于承包商和员工薪酬。2024年重点项目包括Zig 0.13.0和0.14.0版本发布、跨平台编译支持扩展，以及语言功能和库的重大改进。2024年捐赠额呈缓慢下降趋势，基金会已启动新筹款活动以维持运营。2024年总收入670,672.59美元，主要来自GitHub Sponsors、Mitchell Hashimoto以及Bun、TigerBeetle等企业的显著贡献。GitHub问题数量持续增加且解决周期延长，表明ZSF面临日益增长的用户需求压力。基金会正寻求更多定期捐赠以续签合同并引入新的核心团队成员。推荐通过Every.org进行捐赠，并呼吁企业、员工、风险投资机构及个人参与支持。
Look Out for Bugs8 months agohttps://matklad.github.io/2025/09/04/look-for-bugs.html编程职业中期转变：重点在于不写bug，而非反复迭代修复它们。仔细阅读代码有助于发现并修复软件中现有的bug。高效阅读代码的技巧：建立心智模型、审查整个子系统、跟踪控制流和状态。利用代码中的特定模式或异味来识别潜在bug。主动阅读代码能暴露问题；为平静而彻底的阅读创造空间。