Chapter 5 of The Software Craftsman has the exact same message as Chapter 2 (about how to say “No”) of The Clean Coder. Basically boils down to make sure you understand what you and your team can handle in terms of projects, and stand up to management if your team cannot handle the task. Also make sure that what you are working on is transparent to, not only, your team, but the managers and business people as well.
Chapter 6 goes on to talk about how developers should be in the habit of writing clean and maintainable code that won’t have to be refactored later. If the code does end up needing to be refactored, the previous developer show have been professional enough to have made unit tests for that piece of code. This way new developers are not scared to break the system since they know that they can easily run some test to find out if the new code works the same (or better) as the old code. The main thing that I got out of this chapter (because most of it is repeated in The Clean Coder) was when he talked about working with legacy code. It feels like an obvious answer, but I never thought of taking a small portion of the code, figuring out what it is suppose to do, and then writing a unit test for it (if it doesn’t have one yet). Doing this will not only make it easier to understand the code, but it will let you clean and refactor the code easily.