# Shortform-The Clean Coder  Author:: Robert C. Martin ## Highlights > Tests double as documentation. The TDD unit tests act as instructions for how to use the program because they cover every piece of the system > They facilitate good (decoupled) design. Decoupled code is easier to work with because when a test identifies a problem, you can quickly find it—there aren’t layers of code the wade through. > The cycle time is fast. Since you write and test only a little bit of code at a time, you regularly execute the code. > There are three rules to TDD:You can’t write code until you write a unit test that fails. (The test will fail because it needs code to evaluate, and the code isn’t written yet.)For example, if you plan to write a function, you’ll have to mention its name in the test. The test will fail because the function doesn’t exist yet.You can’t write any more of the test beyond the first failure. (Not compiling counts as a failure.)You can’t write more code than you need to pass the test. > Tests ensure that a system works, but that’s a happy bonus, not their main purpose. The most important purpose of a test is to communicate, specify, and document how a system is supposed to work and how it actually works. - Note: I can't disagree more. Tests are NOT documentation. Documentation is an entirely separate line of work that cannot, and should not, be replaced with tests. > in test-driven development (more in Quality #4), you alternate writing short tests and short pieces of code > Finish properly. Completely finish all tasks before declaring them “done” and define “done” as “passed all tests” (for more on tests, see Quality #4). Don’t accept partial completion for any reason, including if you’re short on time. > Avoid the “zone” when you’re working. The “zone” is a state of mind that makes you feel focused, productive, and invincible. In reality, you’re not being more productive—the zone is just a meditative state in which parts of your brain shut off. You’ll write more code, but because you’ve got tunnel vision, you’ll probably have to revise what you’ve written so it fits into the larger structures > Don’t wallow in writer’s block. When you’re feeling stuck, try the following techniques to get past the block:Increase your content consumption. Consuming creative content (like reading sci-fi novels) will help you output creativity—inspired by someone else’s work, you’ll want to create your own.Pair program. Working with someone else will nearly always refresh you. Martin feels a physiological change when pair programming. > Personally and regularly test all of your code. Before you release your code to anyone, including Quality Assurance, make sure you know that it works. > to be a professional, you should spend 20 hours per week of personal time on improving your programming skills and learning new ones. --- Title: Shortform-The Clean Coder Author: Robert C. Martin Tags: readwise, books date: 2024-01-30 --- # Shortform-The Clean Coder  Author:: Robert C. Martin ## AI-Generated Summary None ## Highlights > Tests double as documentation. The TDD unit tests act as instructions for how to use the program because they cover every piece of the system > They facilitate good (decoupled) design. Decoupled code is easier to work with because when a test identifies a problem, you can quickly find it—there aren’t layers of code the wade through. > The cycle time is fast. Since you write and test only a little bit of code at a time, you regularly execute the code. > There are three rules to TDD:You can’t write code until you write a unit test that fails. (The test will fail because it needs code to evaluate, and the code isn’t written yet.)For example, if you plan to write a function, you’ll have to mention its name in the test. The test will fail because the function doesn’t exist yet.You can’t write any more of the test beyond the first failure. (Not compiling counts as a failure.)You can’t write more code than you need to pass the test. > Tests ensure that a system works, but that’s a happy bonus, not their main purpose. The most important purpose of a test is to communicate, specify, and document how a system is supposed to work and how it actually works. Note: I can't disagree more. Tests are NOT documentation. Documentation is an entirely separate line of work that cannot, and should not, be replaced with tests. > in test-driven development (more in Quality #4), you alternate writing short tests and short pieces of code > Finish properly. Completely finish all tasks before declaring them “done” and define “done” as “passed all tests” (for more on tests, see Quality #4). Don’t accept partial completion for any reason, including if you’re short on time. > Avoid the “zone” when you’re working. The “zone” is a state of mind that makes you feel focused, productive, and invincible. In reality, you’re not being more productive—the zone is just a meditative state in which parts of your brain shut off. You’ll write more code, but because you’ve got tunnel vision, you’ll probably have to revise what you’ve written so it fits into the larger structures > Don’t wallow in writer’s block. When you’re feeling stuck, try the following techniques to get past the block:Increase your content consumption. Consuming creative content (like reading sci-fi novels) will help you output creativity—inspired by someone else’s work, you’ll want to create your own.Pair program. Working with someone else will nearly always refresh you. Martin feels a physiological change when pair programming. > Personally and regularly test all of your code. Before you release your code to anyone, including Quality Assurance, make sure you know that it works. > to be a professional, you should spend 20 hours per week of personal time on improving your programming skills and learning new ones.