My team rarely does code review, mainly because we don't have enough time and people lack the energy and will to do so. But I would really like to know what people think about my code when they read it. This way, I have a better understanding how other people think and tailor my code accordingly so it's easier to read.
So my question is, how can I get constructive criticism for my code? My intent is to understand how people think so I can write more readable code.
Best Answer
Having worked in places with code reviews and ones without, it has become one of my make-or-break issues in looking at new employment. The time you save avoiding emergencies because the problems didn't surface until you got to prod is much higher than the time you spend in code review. And that doesn't mention how much less stressful it is to find a problem in code review.
You could start small though if the team needs convincing. Since you would like your code reviewed, start there. Ask one or more of your colleagues to meet with you for an hour or so and go over some pieces of code that you feel you would like feedback on. If the feedback is largely negative, don't get defensive. Really take notes and consider making the suggested changes. But do it on something that you haven't sent to prod yet (or frankly you won't make the changes). You can even do it informally at your desk, just call someone over and say, "hey I'm not sure if I have the best solution here, what do you think?"
Another way to gradually get people to start to see the value of code review is to have a once-a-week session where everyone has to present a piece of code for review (or you rotate through each person but only one a week depending on the complexity of the kind of code that needs review). Bring doughnuts or bagels the first time! If people feel uncomfortable with telling someone in person or if you think people will be too defensive, have them email the boss and have him consolidate the comments so that the person being reviewed doesn't know who said what about the code. Frankly, I prefer to know in person who said what because my own assessment of their own coding abilities will help me decide how seriously I should take the criticism.
If you can't find someone to code review your work, sit down with yourself and try to explain the code and why you are doing what you are doing as if someone was there. I'm amazed at how often it is the person who built the code who found the problem in the course of explaining what the code was for. It also helps to sit down with your requirements document as a sort of checklist and make sure you aren't missing something required.