Leadership Principals

Principals I try to follow whilst leading my team of software developers:

1. Sometimes overtime is unavoidable. But if I'm working overtime, I do everything I can to make it invisible to my team: no email, notifications, pushed commits, etc. I want it to be invisible because I never want my team to feel implicitly pressured to work overtime just because I am. Working 80 hour weeks or being up at 3AM working isn't healthy and I never want anyone on my team to feel guilted into doing something that isn't healthy.
2. I have preferences on ways to write both documentation and code. Everyone does. But when I'm reviewing code, I try hard to only make suggestions that I have an objective reason for. In other words, if somebody wrote something in a way other than how I would have done it, I try harder to accept their way, rather than request my way. I'll only suggest my way if I can come up with definite reasons why my way is better in some important, non-subjective way.
3. Rewriting another developer's work as a form of code review is my absolute last resort. The only reason I'd do this is if the project is approaching a deadline and I see no redeeming value in what they've built so far. It's a last resort because it's utterly demoralizing to the other developer. Instead, I make every effort to work with the other developer and guide their implementation towards acceptance by comments and suggestions. This way (1) they aren't demoralized, feeling that their work had no value and (2) they learn from the process, so that next time their work is better from the outset.