Every database person I’ve ever met writes at least some code at some point in their career. That code might be incredible, mediocre, absolute trash or anywhere in between. And that may all be from the same person on the same day. One thing I’ve found over the years that can really help is code reviews. Both reviewing your own code and someone else’s. So this month I’d like you to make a point of reviewing at least a few pieces of your own code, both recent and older stuff (if you have and can find some) and find a willing friend or co-worker or two and review some of each others code.

Now, remember when you are doing a peer review there are a few goals. Firstly you can learn a lot by looking at how other people do things, and secondly, you can give helpful advice to someone else. When you are giving feedback it must be constructive. Explain what you think could be changed and why it should be changed. One of your top goals here should be to practice giving constructive advice in a way that the person is happy to get it. Of course, the reverse is also important. You have to learn to take advice. The whole point of this is to find mistakes. This can be upsetting but it’s an important learning experience.

Here are a few posts I’ve found on code reviews to help get you started.

• SQL Shack
• Wikipedia
• Best practices for peer code review

Twitter conversation I had on the subject: