How I guide my development teams: 1. Write code that does something correctly. Let it do that thing for a while, keep an eye on it. 2. Then come back to it w

How I guide my development teams: 1. Write code that does something correctly. Let it do that thing for a while, keep an eye on it. 2. Then come back to it with fresh eyes a few weeks/months later and refactor it. Maybe just a critical chunk, maybe top-down. 3. Repeat. By revisiting your own code and iterating on it, you also update the design patterns you intuitively apply when faced with a problem. And importantly, you upgrade your ability to a better version of yourself. I've tried giving examples, setting coding standards, etc; but it's really hard to code in someone else's style. We can't all be Jeff Dean or Salvatore Sanfilippo, and their styles/languages/approaches don't suit every intuition. Also, that "great" code is rarely where the project began, so it's like comparing a beginner's first draft with Hemmingway. Code reviews are difficult for the opposite reason. Even feedback from a much more senior developer usually lacks the contextual knowledge to really know what's going on, so they're just shooting from the hip. Code reviews catch edge cases well precisely because they take the reader out of the "expected" control flow; and they generate lots of "cute trick" advice at a tiny tactical level. They're good correctness & social tools, but not so helpful for self-improvement.