I read through this book relatively recently and agree with the praise here for the core idea that legacy code is code that is untested. The first few chapters are full of pretty sharp insights that you will nod along to if you've spent a decent amount of time in any large codebase.

However, most of the content in the last half of the book consists of naming and describing what seemed like obvious strategies for refactoring and rewriting code. I would squint at the introduction to a new term, try to parse its definition, look at the code example, and when it clicked I would think "well that just seems like what you would naturally choose to do in that situation, no?" Then the rest of the chapter describing this pattern became redundant.

It didn't occur to me that trying to put the terms themselves to memory would be particularly useful, and so it became a slog to get through all of the content that I'm not sure was worth it. Curious if that was the experience of anyone else.

▲ michaelfeathers 3 days ago | parent | next [-]

Thanks. After I wrote it a friend said "I think you just gave people permission to do things that they would've felt bad about otherwise." I think he was right, in a way. On the other hand, not everything is obvious to everyone, and it's been 20 years. Regardless of whether people have read the book, the knowledge of these things as grown since then.

▲ ebiester 3 days ago | parent | prev | next [-]

I think of the second half much more as reference. I can give it to a junior engineer or early mid-level and say "here is an example."

It's harder if they can't read the older examples, but I can google for a more modern example as well. It gives nomenclature and examples.

▲ dotancohen 3 days ago | parent [-]

  > It's harder if they can't read the older examples, but I can google for a more modern example as well. It gives nomenclature and examples.

Don't do that. Ostensibly you're giving these people the book so that they'll learn to deal with legacy code. Those older examples are exactly what they need to see, even if they're in a language that those devs are not using.

▲

ebiester 2 days ago | parent [-]

Junior developers in javascript codebases of 7-10 years old will not have the experience necessary in some cases. I am coaching them as a manager trying to introduce a concept, not a professor.

I may be doing a disservice to their long term development at the cost of short term gains. However, I don't think this is true. There are a lot of developers who will never work in a C, C++, C#, or Java codebase. And I try to adhere to Krashen's "comprehensible input" theory as it has a lot of application to learning the language of software development as well.

(See https://www.languagehumanities.org/what-is-the-input-hypothe... )

	▲	dotancohen 2 days ago \| parent [-]
		Why do you have junior developers maintaining codebases older than themselves? ))

▲ iteria 3 days ago | parent | prev [-]

I happen to read this book in my early career. I was mid-level. Beyond struggling with codebases, but hadn't yet developed an intuition with codebases. This book blew my mind then. It gave me whole new ways to thinking. I recommend it all the time to people in early career because how to handle a massive legacy codebase isn't obvious at all when you haven't been doing it for a long time.