Bullsh*t Enginners Say Tier List | The Standup

A group of programmers and engineers ranked common “thought-terminating clichés” in software engineering—phrases that shut down discussion instead of clarifying tradeoffs. The central takeaway: many of these lines are harmful not because they’re always wrong, but because they prematurely end the reasoning needed to choose the right technical path, often masking uncertainty, shifting blame, or locking teams into bad decisions.

The discussion put “premature optimization is the root of all evil” at the bottom (F tier). The complaint wasn’t that optimization is never needed; it was that the word “premature” makes the advice meaningless. Optimization can be appropriate early, and the phrase gives no actionable criteria for when to measure, what to optimize, or what “premature” even means in context. Closely related, “never do a full rewrite” also drew heavy criticism, landing near the very bottom (F tier in the group’s final leaning). While the phrase is often treated as a rule of thumb, the participants argued that full rewrites can be justified—especially when baked-in complexity, missing knowledge, or a fundamentally broken design makes incremental change too risky. Still, the group agreed that “never” is too absolute, and in practice it can trap teams in legacy code.

Other clichés earned mid-to-high rankings depending on how honest they were about tradeoffs. “Programmer time is worth more than CPU time” landed around B/C. The group disliked the attitude when it becomes an excuse to ship inefficient software indefinitely, but they acknowledged it can be a pragmatic business stance when the goal is to buy compute rather than engineer performance. The phrase “make it work, make it right, make it fast” was also graded as B: it sounds reasonable, yet it often gets used to defer the hard requirements work until later, encouraging teams to ship something that works but is structurally hard to optimize. Participants suggested a more truthful framing—prototype first, or “make it work but don’t ship it,” then iterate.

Several “process” phrases were treated as especially unhelpful in team settings. “Don’t repeat yourself” (DRY) was debated: it can be valuable for individual code, but becomes thought-terminating when used to force abstractions that add complexity, create “util” graveyards, or block straightforward, readable duplication. “Use the right tool for the job” split the room: one side saw it as S tier because it should mean choosing tools based on constraints (e.g., Rust for memory safety, C when you intentionally need unsafe control), while others argued it’s often used as a lazy justification for whatever stack is fashionable—like defaulting to TypeScript for everything.

The group also ranked “best practices” talk as a frequent red flag. “Use my phone / use my best practices” was treated as S tier because it offers no evidence, changes over time, and turns engineering judgment into authority. “You ain’t going to need it” was discussed as an “ultimate self-terminating” cliché, but the participants admitted they hadn’t encountered it often enough to rank confidently.

Overall, the ranking exercise framed these phrases as shortcuts that can end productive technical debate. The most consistent remedy across the conversation: replace absolutes with context—measure, prototype, and be explicit about goals—so teams don’t confuse slogans with engineering decisions.