If that would make you feel any better, nobody wants to be criticized about their code quality. Even more extrovert developers who are confident in their code quality style feel intimidated by code reviews – especially during the first few weeks or even months.
I’ve been in that situation myself plenty of times. I work on projects with different teams, contribute to open source products, commit code when my colleagues are off that may get refactored later.
In fact, I co-authored a major performance patch for WordPress several years ago. The main developer in charge of my review was also hesitant to give a green light due to the risk of ruining the Pages screen for tens of millions of installs. He pushed back the patch until he wasn’t the main lead of that component, approved it, and delegated it to the next guy to take responsibility if something goes wrong.
Luckily, everything went smoothly!
Even if you’re absolutely confident in your code quality skills (adhering to the language/framework standards, implementing the right design patterns, optimizing for speed and security), there are business-specific components that may interact better via different implementations.
Here is what you can do to alleviate the tension.
1. Stick to the coding standards
Every programming language has coding conventions or quality standards. Study them in depth and make sure that you follow them closely.
Organizations may introduce their own standards as well. Make sure you’re familiar and able to follow the conventions accordingly. Read commit logs by other developers and ensure that you are aware of any particular approaches that work for your team.
2. Use static code checkers
There are static code analysis tools available as well. You may integrate them in your IDE or run them from the shell before pushing code to version control.
Some may be integrated as a pre-commit hook or ran as a part of your continuous integration server. Whatever works best, automating certain portions would give you some confidence as well.
3. Participate in peer programming sessions
If possible, participate in peer programming sessions – hackatons, working on new projects, or contributing along other experienced developers in your team.
You can even start a pet project with a friend and work remotely, sharing screen and discussing solutions and implementation live.
4. Work closely with your team
The more you work along your department, the easier would be to align with their process. That is extremely important especially for new hires who need to adjust to the workflow.
5. Regularly ask for feedback
Don’t wait for a code review to happen. Whenever you work on a larger component or you aren’t sure of the best way to implement something, ask a colleague to help and give you some tips.
This type of informal code review will make it easier when going through an official one.
6. Be brutally honest with your reviewers
Before the formal code review, discuss your concerns with your reviewer. Let them know that you’re trying hard and you want to improve. Tell them that you’re hesitant to push code and don’t want to violate any coding standards – let alone cause regressions in the product.
As long as you’re not acting cocky, reviewers may cut you some slack and show you some techniques to get better as well.
7. Suck it up
Regardless of your preparation, the first reviews would still be rough. Some remarks may show up. Code may need refactoring.
But hey, it’s for the sake of improving the entire code base. You will pay some technical debt and improve your skills as well. It’s all good at the end – just pay attention to the comments and make sure that those notices won’t occur again.