Bad Code vs Good Code

“Bad code” isn’t a single technical category so much as a mismatch between what software must do and what it costs to change when reality shifts. Across the discussion, the most consistent through-line is that code quality should be judged by two practical outcomes: whether it fulfills its purpose and whether it’s easy to modify when new requirements arrive. When those outcomes fail—because the problem is inherently hard, because the system’s assumptions no longer hold, or because the design makes small changes cascade into big rewrites—people experience the code as “bad,” even if it was reasonable at the time.

A key disagreement centers on the common claim that “hard to work with” automatically means “bad.” The counterpoint is that difficulty often comes from the domain and constraints, not just the code. A concrete example comes from building accessibility focus behavior for Netflix on TV. Web platforms provide focus and focus order; TV platforms don’t, so teams had to create their own focus ring and focus system. That work is inherently complicated, and labeling the resulting code as “bad” confuses the complexity of the topic with the quality of the implementation.

The discussion then pivots to a data-structure story about movie recommendations and badging. When two lists point to the same underlying movie object, changing the “reason you liked it” badge for one list would unintentionally change it for the other. The fix required restructuring the graph—splitting fields so the badge reason could vary per list rather than per shared object. That meant adding a new node type and updating the data model across the system. The takeaway: if a change is difficult because the underlying assumptions of the model don’t support the new requirement, the “badness” may belong to the problem framing and constraints, not to the programmer’s skill.

From there, the conversation broadens into a pragmatic definition of quality. Lists of “bad code” symptoms—poor readability, convoluted logic, performance problems, resource leaks, security vulnerabilities, and higher debugging costs—are treated as reminders rather than true definitions. The more foundational test remains: does the code do what it’s meant to do, and can it be changed without excessive friction? Even security and reliability are framed as context-dependent: a system that isn’t resilient may be “bad” for a business where uptime matters more than scalability.

The transcript also challenges the idea that “good code” is always about elegance or minimalism. Over-engineering can happen when teams chase abstractions, patterns, and testability scaffolding that don’t pay off. At the same time, under-engineering can create technical debt that slows future work. The practical middle ground is iterative design, modularity, and tests that support refactoring—without turning mocks and abstractions into a maze that makes debugging harder than the bug itself.

Ultimately, the debate lands on subjectivity: different engineers experience “easy to change” differently based on familiarity, domain knowledge, and the system’s age. But the shared standard is concrete: code quality should be measured by outcomes—correct behavior and manageable change—rather than by aesthetic preferences or whether the code looks “nice” on first inspection.