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.

  • 5
    Do code reviews. Invite people to review your code.
    – Oded
    Commented Oct 31, 2012 at 15:15
  • 4
    Code Review Stack Exchange. Please read the site's FAQ thoroughly before you post your questions.
    – yannis
    Commented Oct 31, 2012 at 15:16
  • 2
    If nothing else works, read the code you wrote a while ago _ your old code will look as if someone else has written it, which will make you objective.
    – superM
    Commented Oct 31, 2012 at 15:18
  • 1
    Do you mean positive or constructive?
    – Blrfl
    Commented Oct 31, 2012 at 15:51

4 Answers 4


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.

  • I probably have to start out small like you said because many key co-workers that i look up to are too busy with deadlines/production issues. Your last alternative solution of sitting by myself and explaining how my own code seems like the very minimal thing i can do next. It's a good idea and I remember reading about it once as the Rubber Duck Debugging. en.wikipedia.org/wiki/Rubber_duck_debugging
    – burnt1ce
    Commented Oct 31, 2012 at 21:40

No fancy tools, in my opinion, could replace sitting with a senior developer or architect and walk through the code (or their code, and see what they did first hand). That said, I've found that unit testing code forces you to think in a reusable way, it also forces you to incorporate patterns that could make your code more readable (with the added benefit of better tested code).

  • 1
    IMHO unit testing forces you to think in a unit-testable way, nothing more, nothing less. People often state that this will make the code more reusable, but in my opionion thats some kind of urban legend.
    – Doc Brown
    Commented Oct 31, 2012 at 21:10
  • Here's my two cents, and my reasoning behind the reusability aspect: most of the unit testing I've done dealt at some point or another with mock objects. This forces you to think on how to test your software later, but it also helps you think about the interfaces between your objects. These interfaces in turn, what a mock object would fake, IMHO could lead you to the path of more reusable code (this is kind of an art however). If you can clearly design lean interfaces, you could easily mock, and in turn get better code out of it.
    – abellina
    Commented Nov 1, 2012 at 2:41

Do you have good tools for code reviews? We had a similar problem in my group. I took some time to install a Reviewboard server, and participation in code reviews jumped. I have found that people like to comment on code when it is made easy.


You should really consider taking time to do code reviews, because in my experience it is worth the effort regarding the quality of your code. If code review is no option at your team and you want to understand how people think, maybe pair programming is an option for you. You get immediate feedback on what you're typing - something like an instant review.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.