Reddit mentions of Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series)

Honestly from what I've seen, and I've been coding professionally for over a decade, no such an ideal environment with everything you describe applied everywhere doesn't really exist.

The best I've come across is organisations where the company culture is one of passion, continuous learning and improvement. In a place where people are skilled and care, not everything sucks, and the things that suck tend to get better over time.

All code seemed like a good idea to the author at the time they wrote it. They may have had goals that weren't explicitly "make this clean", or the one-clean code may now have enough other code around it that applying some additional abstractions would simplify things. If these abstractions had been applied earlier, it's highly possible that they would have been overengineering. Like it or not, a lot of development is working with and hopefully improving legacy code.

It can be hard sometimes but resist the urge to rewrite everything. Instead, when you come across some code you don't like, try to identify exactly what you don't like about it. There may be multiple things.

Pick whichever is the smallest, simplest change you can make. Implement only that change and nothing more. Initially this might be as simple as cleaning up some conditional logic, writing a missing test, or extracting a method or interface. Over time, the parts of the codebase you work with most frequently will be in better shape and it should be easier to change higher level structure where appropriate.

Sometimes chucking things out and rewriting is inevitable but being able to make small changes is important for several reasons.

• It's less risky. A small change has much less chance of making incorrect assumptions that burn you later.
  
• It's easier to back away from if it doesn't work out.
  
• All the code in the codebase provides value (almost) all the time. It's harder to end up in situations where you're blocked on writing code that provides actual business value (clean code in itself doesn't provide business value).
  
• It's easier for other people on your team to understand and learn from.
  
  You'll have a much easier time, and much more fun if you can get comfortable getting dirty with code you don't like.
  
  There's a couple of good books I always suggest to people in this situation.
  
  Working Effectively With Legacy Code by Michael Feathers https://www.amazon.com/Working-Effectively-Legacy-Robert-Martin-ebook/dp/B005OYHF0A/ref=mt_kindle?_encoding=UTF8&me= and Refactoring: Improving the Design of Existing Code by Martin Fowler https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Technology-ebook/dp/B007WTFWJ6/ref=pd_sim_351_1?_encoding=UTF8&pd_rd_i=B007WTFWJ6&pd_rd_r=VAYMVGWBAJ19REZTVRE8&pd_rd_w=sBy2z&pd_rd_wg=wTZty&psc=1&refRID=VAYMVGWBAJ19REZTVRE8 are both worth checking out.