This Time Is Different

Summary

Lauren Tan reflects on how experience weakened her faith in universal engineering best practices. New languages and paradigms exposed how strongly familiar tools shape judgment, and showed that techniques that look ideal in one context may be a poor fit in another. Software is a living, changing system, so good engineering is less about reaching a permanent state of perfection and more about making context-aware trade-offs and continuing to improve.

Why it matters

Engineering leadership requires resisting cargo-cult advice, including advice from respected experts. The durable skill is not finding a pattern that is always correct; it is understanding the problem, comparing alternatives, accepting opportunity costs, and revisiting decisions as the system and team change.

Key ideas

• Familiar languages and idioms create mental defaults that can make one technique appear universally correct.
• A shorter, more abstract, or more fashionable implementation is not automatically better.
• Every approach has a context in which it is useful; a simple loop may be preferable to a more theoretically elegant pattern.
• Popularity and authority are weak substitutes for reasoning about the problem, alternatives, and team constraints.
• Software changes as requirements, users, teams, and dependencies change. Decisions should be treated as provisional rather than permanent foundations.
• Improvement is an incremental process, not a destination where all engineering discomfort disappears.

Practical applications

• Before adopting a best practice, write down the problem it solves, the alternatives, and the costs it introduces for this team and codebase.
• Ask what new information would cause the team to revisit the decision, and record that as a trigger rather than defending the choice indefinitely.
• Deliberately learn outside the team's dominant language or paradigm to expose assumptions in its usual design vocabulary.
• In reviews, evaluate whether a proposed abstraction improves the current system instead of rewarding cleverness or conformity.

Open questions

• Which decision records best preserve the context behind a practice without creating documentation overhead?
• How can leaders make it safe for teams to abandon yesterday's “best practice” when evidence changes?