I couldn't disagree with the author's claims more. In fact, I come to this discussion from an oddly prescient position: I'm a former longtime googler who also j

I couldn't disagree with the author's claims more. In fact, I come to this discussion from an oddly prescient position: I'm a former longtime googler who also just happenened to have read the book recently, after years of knowing I should. My takeaway is: thinking the book is just for hacking around legacy code is wrong. It's both a way to fix that kind of code, yes, but in the process lays out the blueprint for not ending up in that situation in the first place. Besides there being plenty of shitty code (read: no tests, and untestable) scattered around the Google codebase that I had to deal with there was learning how to write my own code better - make it more testable. If I'd read this book sooner I would have been spared a lot of pain in code reviews, where someone who HAD read and understood the book was trying to help me avoid all the pitfalls I was traipsing right into. "Yes I know it's a big class, what's the goddamned problem" I would think, begrudgingly making changes requested and thinking I could be done with all this by now if it wasn't for all this stupid refactoring for no reason other than "testing is easier". In retrospect I (eventually) learned already most of the lessons this book teaches you... but far more painfully than if I'd read it sooner. Short version: it's not just for if you have to work with legacy code. It's so you can avoid writing it yourself.