"Clean Code" is bad. What makes code "maintainable"? part 1 of n

Summary

In this video script, the speaker critiques the conventional advice on code maintainability, arguing that much of it lacks practical principles and can even be harmful. They express a disdain for books like 'Clean Code,' which they believe promotes practices leading to team conflict and poor maintainability. The speaker emphasizes that maintainable code should be easy to understand for newcomers and stresses the importance of code isolation to prevent changes from causing unintended side effects. They also highlight the fallacy of top-down code reading and the inefficiency of hiding code logic behind abstractions, advocating for a more realistic approach to coding that acknowledges the inevitability of bugs and the need for easy debugging.

Takeaways

• 📚 The speaker criticizes common advice on writing good code, calling it 'crap' because it lacks real-world applicability and often leads to misguided practices.
• 📘 The speaker expresses a strong dislike for the book 'Clean Code', arguing that its advice is harmful and can lead to more problems in code maintainability.
• 🔍 The speaker emphasizes that code maintainability is about making the code easy for others to work on, especially those who are unfamiliar with it, rather than simplifying the writing process for the original author.
• 👀 The speaker points out that code is generally not read from top to bottom, and that the way most coding literature presents code is flawed and not reflective of real-world practices.
• 🔍 The speaker advocates for a bottom-up approach to understanding code, starting from a bug or error message and tracing back through the codebase to find the root cause.
• 🔗 The speaker discusses the problems with having many subclasses that are slight variants of each other, as it makes it difficult to trace through the code and understand the flow.
• 🛠 The speaker argues that changes made in one part of the application should not affect other unrelated parts, highlighting the importance of code isolation for maintainability.
• 🚫 The speaker criticizes the 'no global variables' and 'single responsibility principle' as being too simplistic and not necessarily preventing issues like the 'whack-a-mole' state of bugs.
• 🔑 The speaker uses an example from 'Clean Code' to illustrate how hiding decision-making within classes can lead to a lack of transparency and difficulty in debugging.
• 🛑 The speaker warns against the attitude of dismissing bugs that cannot be immediately reproduced, suggesting that this can lead to unresolved issues and a false sense of security.
• 🚫 The speaker concludes by stating that the philosophy behind books like 'Clean Code' is flawed, as it assumes that code can be made perfect through simplification, which is unrealistic.

Q & A

What is the main topic discussed in the video script?

The main topic discussed in the video script is code maintainability, specifically what makes code good or bad and the critique of common advice on writing maintainable code.

What does the speaker claim about most of the advice on writing good code?

The speaker claims that most of the advice on writing good code is 'crap' because it is not based on actual principles or heuristics and often does not translate to real-world improvements.

What does the speaker dislike about the book 'Clean Code'?

The speaker dislikes 'Clean Code' because they believe the advice in it is harmful, it's specific to a particular programming language, and it promotes practices that can create contention and confusion within development teams.

What is the speaker's view on the importance of code readability?

The speaker believes that code readability is crucial, but it should be about making the code easier to work on for someone unfamiliar with it, not just about writing code that is easy for the original author to write.

According to the speaker, what is the primary way developers understand a new code base?

The speaker states that developers typically understand a new code base from the bottom up, starting with a bug or an error message, and tracing the code by following function calls and logs, rather than reading the code from top to bottom.

What does the speaker suggest is a common mistake made by those who follow 'Clean Code' and similar advice?

The speaker suggests that a common mistake is the creation of subclasses that are tiny variants of each other, which can make it difficult to trace through the code and identify the source of bugs or features.

What does the speaker argue is the fundamental principle of maintainable code?

The speaker argues that the fundamental principle of maintainable code is to make it easy to find and fix bugs when they occur, and to write tests to prevent them from recurring, rather than trying to write code that can't have bugs.

Why does the speaker criticize the approach of hiding information within private classes as suggested in 'Clean Code'?

The speaker criticizes this approach because it prevents other parts of the program from accessing potentially relevant information for finding and fixing bugs, thus breaking the principle that changes in one part of the application should not affect other parts.

What does the speaker mean by the term 'whack-a-mole' in the context of software development?

The term 'whack-a-mole' refers to a state in software development where fixing one bug causes another feature to stop working, creating a cycle of constant bug fixing with no end, often due to poor architecture or practices.

What is the speaker's view on the importance of code tests and the 'Open/Closed Principle' in maintaining code?

The speaker believes that while code tests and principles like 'Open/Closed' are important, they are not sufficient on their own. They can still result in a 'whack-a-mole' state if the architecture and practices do not ensure that changes in one part of the application do not break other parts.

What does the speaker suggest is the attitude of some developers who follow the advice in books like 'Clean Code'?

The speaker suggests that some developers who follow this advice may develop an attitude of dismissing bugs that they cannot reproduce as not real problems, which can be detrimental to the development process and lead to unresolved issues.