He wrote for example the books Clean Code and Clean Architecture which are IMO opinion really good books although I don't agree with every point he makes.

Some really good points he makes are for example:

• Functions that only do one job
• Testing makes refactoring easier
• The standard SOLID OOP stuff.
• Tech debt is bad
• Abstraction and encapsulation is good and allows developers to interact with the code on a higher level in terms of actions instead of writing verbose stuff. Essentially saying less code leads to less bugs
• Insulate yourself from change
• Duplication is bad
• Two use cases that are very similar is not duplication and common code shouldn't be factored out.
• Don't mix high level code with low level.
• Build solid Entity classes to model the data and their interactions.
• Don't write multithreaded code if you don't have to.
• If you have to do your best to write it so they don't share memory.

Those comes with examples. He's a tad bit overly idealistic in my opinion. These books fail to mention a couple of things:

• Refactoring is expensive and the cost is often not justified.
• Premature abstraction is the absolute devil
• You don't need to insulate from things that are very unlikely to change (like going from SQL to Document DB)
• Less changes also lead to less bugs.
• Too much emphasis on functions being few lines of code instead of just being simple.

All in all though, very solid books. I read Clean Code in university and Clean Architecture in my first job and it really helped me wrap my head around different ways to solve the same problem. Excellent ideas but it's not the holy truth. The only reason I remember all of these points is that I encountered all of them on the job and saw the benefit.

In my opinion new programmers should read it and take inspiration. Craftsman level developers should criticise and maybe pick up a few brain concepts to sort some concepts out in their brain. Experts will get little benefit though.