作者小时候在纸上写程序，父亲的朋友读过后指出错误，这让作者首次看到人脑作为解释器和编译器的工作以及测试的过程，从此对编程中的测试产生好奇。多年在电子、自动化和软件行业工作中，作者一直质疑工作和产品质量，直到导师[John Arundel]在[Introduction to Test-Last Development - TLD]一文中捕捉到技术卓越的本质，文中给出了关于工程卓越的建议：

• “Don't make me think!”：认为思考很困难，现在没人愿意做，不用先设计产品，快速发布并打破东西。
• “Real programmers don't design stuff”：觉得任何白痴都能为已存在的东西写测试，在构建实物前先思考、写作和建模很难，没人愿意做。
• “Just practice TLD - Test-Last Development”：这是最直接的工程方法，直接写东西，从 Stack Overflow 复制或用 ChatGPT 生成，混合、搅拌、发布，然后从管理层获得奖金，不用管客户。
• “Be a hero in management's eyes”：当被问开发为何需要 4 个冲刺而不是 1 个时，用技术术语搪塞，让自己安心继续写代码、编译和看起来忙碌，最终产品卖得快，股价上涨更重要。
• “Relentlessly practice the all-purpose test excuse list”：如果必须写测试可以继续使用 Test-Last Development 延迟实践，写的第一个测试可能会发现严重 bug 导致无法进展，写测试很无聊且客户不付测试代码的钱，只关注产品。
• “The goal is to reach 100% test coverage”：在行业现状下很容易让“AI”助手生成所有测试，不在乎产品是否按预期工作，总能达到 100%测试覆盖率，就像让 mechanic 调整旧车测试以通过年检一样，反正下周要卖车，对质量的追求结束了，不要听关于测试优先设计、质量和可靠性的话，遵循简单直接的路径。

作者认为软件工匠有时应停下来反思，从不同角度看待工作。