现在相信的事情：
- 当您和不同经验水平的团队合作时，使用类型语言会更好（不是动态语言）
- 敏捷的站立会议实际上对于新手很有用。
- Sprint 刺有自己的存在价值，前提是只要他们是实际路线修正（即“神圣的狗屎，那又不好！”），而不是一些神可怕的“敏捷” /“scum大师”驱动大家的时间浪费。
- 软件架构可能比什么都重要。一个好的抽象的糟糕实现不会对代码库造成任何损害。糟糕的抽象或缺失的层会导致一切腐烂。
- Java 并不是一种可怕的语言。
- 聪明的代码通常不是好的代码。清晰胜过所有其他问题。
- 糟糕的代码可以用任何范式编写
- 所谓的“最佳实践”是有上下文的，并不广泛适用。盲目跟风让你白痴
- 在不会让您成为糟糕工程师的情况下设计可扩展的系统。
- 静态分析很有用
- DRY 是关于避免特定问题，而不是其本身的最终目标。
- 一般来说，RDBMS > NoSql
- 函数式编程是另一种工具，而不是灵丹妙药。
我一路相信的意见：
- YAGNI, SOLID, DRY
- 铅笔和纸是最好的编程工具，但很少使用
- 交易纯度以换取实用性通常是一个很好的选择
- 很少情况下添加更多技术是好的选择
- 直接与客户交谈总是能在更短的时间内以更高的准确度揭示更多有关问题的信息
- “可扩展”这个词在软件工程师的头脑中有一种神秘而令人震惊的力量。仅仅一句话就能让他们陷入堕落的疯狂。使用这个词来证明严酷的行动是合理的
- 尽管被称为“工程师”，但大多数决策都是纯粹的唯物崇拜（cargo-cult ），没有支持分析、数据或数字
- 90%——也许是93%——的项目经理，明天可能会消失，要么没有效果，要么效率净增。
- 在进行了 100 多次面试之后：彻底崩溃了。我也不知道如何真正让它变得更好。
旧观点不变：
- 强调代码风格、linting 规则或其他细节的人是疯狂的怪人
- 代码覆盖率与代码质量完全无关
- Monoliths单体/整体在大多数情况下都非常好
- TDD纯粹主义者是最糟糕的。他们脆弱的小头脑无法处理不同工作流程的存在。