To start off, make sure that every member of the team comprehends the significance of both security and performance. Regular training sessions, workshops, and e-learning courses can help keep the team updated on the latest best practices. Another item that I like to indicate for my teams is "Peer reviews." Pair programming helps to detect and mitigate issues early.

The single, most crucial aspect of a code review is to keep in mind that regardless of your role (reviewee or reviewer) the other person is, first of all, a person. Mocking or demeaning someone is extremely easy but completely unhelpful: understanding the other person's perspective and way of thinking can go a long way to uncover hidden and often wrong assumptions which then propagate through the code.

To help with developer productivity, ensure that the coding standard is able to be supported by tools. For example, document functions and their parameters in such a way that your editor can provide tooltips showing the parameter documentation when you’re writing a function call.

There is also a lot of intrinsic, long-term value in hackathons that make code toolable: many successful products have been around for many more years than a lot of most recent best-practices and unit testing is one of these, so there is a lot of value in transforming old code into new code that can be easily tested. Besides getting the code in better shape, such hackathons also spread knowledge across those invisible boundaries that invite mistakes.

Be quick to praise, slow to criticise. Hold back criticism until you have fully understood the flow of thought behind a certain change. Remember that even the most junior of developers can be right and occasionally the change that has been made should be the reference for the rest of the code and it may make sense to go in and change old code to the new way.

I personally take this a step further. On more complex or nuanced change sets where the why is not clear I "review" my own pull request with comments to help the actual reviewers understand the idea behind the decision. The primary reason is that sure the reviewer could look at the story/ticket/issue, then read all the changed code, then all the affected code that was not directly changed, etc. but that simply takes a lot of time and burden on the reviewer that is top of mind and easy to convey. The cost of doing so is much lower than the reviewer has to pay.

There is a lot of value in group reviews as well: sometimes having more people "taking shots" at a piece of code can unlock amazing insights and dispel very bad assumptions borne out of no one talking about what the assumptions should be. Also, sometimes assumptions have an expiry date and it would be best to review those as well and make sure they still align to reality.