Clean code isn't what I thought it was

The author shares their experience working on real systems, which changed their perception of what constitutes "clean code." Initially, the author believed clean code meant neat appearances, small and well-structured functions, and a strong emphasis on code reusability. However, as they worked on larger systems with real users and constraints, they noticed that the rules they had learned didn't always hold true.

The author shares examples of messy codebases that still functioned effectively, even though they were far from the idealized "clean" code style they had previously embraced. They argue that messy code is not the enemy, as long as it works and users are satisfied. The issue lies in code that is difficult to understand and change, regardless of its appearance.

The author reflects on the cost of early abstraction, noting that duplicating code is often more flexible than tightly coupled, early-abstraction-driven designs. They share an experience with a project where they intentionally avoided early optimization and duplicated code to save time. When the project pivoted later, the duplicated code saved them from unnecessary effort in refactoring.

Ultimately, the author emphasizes that architecture matters more than code style. They argue that understanding where code lives in the overall system is crucial for maintainability and that overly focused attention on code aesthetics can lead to unnecessary complexity and difficulty in navigating large codebases.