Who should do code reviews

There is a chance that you're being singled out as a woman, but it's also possible that you're just a junior developer and new to the job.

Error-checking and expressive messages are important. If you're going to add something to the code, make sure it's right and up to the team's standards. Similarly, if you're modifying someone else's code, try to improve it where possible -- don't go off rewriting the whole thing, but do try to leave it a little cleaner than you found it.

Is there a written version of the coding standards that your team follows? If not, it might be a good idea to write it all down. You can spearhead the effort by writing down the mistakes you make and forming them into a checklist that you can refer to before submitting your changes for review. As a side effect, you can use that written standard to appeal future rejections if they contradict it.

It sounds like there may be some lack of understanding between you and the team lead. It might be helpful for you to ask for a one-on-one meeting with him and discuss what you can do to improve. You can lead in with something like "I feel like I'm still missing a lot of nuances of what I should be doing. As a junior developer I want to grow and improve. Can you help me get there?" and see what happens.

There are a few things that code reviews can do for you, and some things they can't. The arguments in favor of code reviews:

• Collective ownership
• Find bugs (QC)
• Enforce consistent style (QA)
• Mentoring

Many agile processes tackle those in different ways:

• Collective Ownership: everyone on the team is responsible for the project, which means everyone's eyes will be on the code at any given time.
• Free to refactor: this takes code reviews to the next level, and allows anyone on the team to perform refactoring as necessary.
• Unit tests (QC): unit tests are more efficient and less prone to human error then visual inspection. In fact, I have yet to find a more efficient means.
• Pair programming (QA): takes care of mentoring and provides early refactoring advice as the code is written. This is also still a controversial topic, but I find it helps while ramping up a new developer. It's also a good time to enforce coding standards.

In essence there are other avenues of taking care of the potential gains you would normally have doing peer reviews. My personal experience with peer reviews is that they are very inefficient mechanisms and are not effective at finding bugs or larger design flaws. However, they do have their place in some teams, and on projects where agile is not feasible (for whatever reason), they are quite necessary.