I read Clean Code at a point where programming was becoming more than syntax for me. The deeper question was starting to appear: how do you write something that remains understandable after the first little victory of getting it to run?
The book has a strong tone, almost priestly at times. Names matter. Functions should be small. Side effects should be contained. Tests should protect behavior. You can disagree with details, but the general pressure is useful. It asks you to treat code as something other people will have to live inside.
What stayed with me most is the moral weight of naming. A bad name is a tiny lie that keeps charging interest. A good name gives the reader one less thing to hold in their head, which is already busy enough pretending to understand build tools.
I also keep some distance from the book. Any style guide can become theater when people use it to win arguments and forget the system. Clean code is a direction of care, not a personality costume.
The lesson I still like is simple: code is read under pressure, by tired humans, including future you. Leaving it clear is a small act of mercy. Future you is usually grateful, although rarely polite enough to send flowers.