Code review is part of the software development process, when all code written by one developer is checked by another, more senior developer, accepting it only after findings are corrected.

While reviews obviously increase the quality of code, somewhat not all developers really like or enjoy them very much. I will not reiterate on how this could possibly be, look here, here and even here maybe for the reasons of this question.

The problem I am trying to address is the power game problem. The reviewer has the huge power over the person whose code is being reviewed and can easily use it just to prevent that person from being successful with the project. Developer unwillingness to submit themselves for this power is also fully understandable. Also, some do write crappy code but then have arguments to reject findings as said above - also a problem.

Are there any alternative processes that could replace the code review for the goal of improving the code quality? Would it be possible to have something else instead of this process? While review may be required where software bugs kill humans, could some weaker method be sufficient where the situation is far from that critical?

This question is not about applying purely technical means like code formatters or automated testing frameworks, while these obviously reduce the number of bugs.

  • 8
    Pair programming?
    – Vality
    Commented Mar 4, 2017 at 20:40
  • 7
    What specific problem are you trying to solve? That developers take code review feedback badly? That code review takes too long? Commented Mar 4, 2017 at 20:41
  • 11
    This sounds like a much deeper team/company culture issue than just not doing code reviews can solve. Ideally the manager for the people using code reviews to play power games should have a very firm talk with them about acceptable behaviour.
    – Mel Reams
    Commented Mar 4, 2017 at 22:04
  • 3
    I agree with Mel. You are trying to solve the wrong problem. If team mates are power-gaming each other, there is something broken in your culture, not in the code reviews.
    – Erik
    Commented Mar 4, 2017 at 22:57
  • 7
    You are having an XY-problem. You are not having a code review problem. You are having a problem with improper management and planning. If clear guidelines for code review exists and the project lead ensures that reviews are constructive, then there is no problem.
    – Polygnome
    Commented Mar 5, 2017 at 0:57

4 Answers 4


IMO you have misunderstood the technical process and this is causing a business problem. I will address both, because they are interrelated.

Technical misunderstanding: A code review is not a superior checking on the work of an inferior. A code review is a second (or more) pair of eyes looking at what was done, what was not done, how it was done, and how it solves the given problem, as well as how it fits into the current code and follows current coding standards. It is an acknowledment that our brains are wired to fill in missing details (search for psycholinguists and gap-filling to find details).

Business problem: your seniors are playing power games. This is probably at least partly caused by your misuse of code reviews. By having "senior reviews code of junior", you have established that (a) junior code needs review and senior doesn't (factually incorrect), and (b) that seniors do reviews. This has tied the reviews to positions within the company. Your senior reviewers almost have to find serious problems, otherwise they are saying that the juniors are as good as they are.

Solution: you need to either stop using reviews or start using them correctly, or you are going to have further problems as your seniors drive away your juniors in self defense.

Doing proper code reviews, reviews done by colleagues not superiors, is probably going to be hard. Seniors aren't going to want to have their code reviewed by juniors, juniors will be hesitant to correct code by seniors. Having juniors review juniors and seniors review seniors, will make matters worse. The only solution I see is to double down, have all code reviewed by multiple independent reviews for a time, until you are sure that everyone is onboard with the new process.

A LGTM (looks good to me) from one should be enough to commit, unless another reviewer has a concrete example of where the code doesn't work to spec.

  • 1
    I highly agree - to expand on the technical nature of the code review, it should really be against a pre-established code guideline, which includes how to intent / use brackets, how to unit test, etc. - any bugs can be noted, but need not be fixed necessarily (their cost of fixing may be higher than what the project manager is willing to spend, or their impact may be negligible). It may even be helpful to start doing blind or double-blind code reviews to remove the power plays from the code review, as that diminishes the value of an actual code review Commented Mar 5, 2017 at 19:38
  • 1
    This correct answer to the question in the sense it clearly addresses that must be done differently (hence in the alternative way). The problematic situations I faced always included high level asymmetry of the reviewing process. I am accepting this answer as the answer I need.
    – eee
    Commented Mar 6, 2017 at 12:32

Combining code reviews and power games is a recipe for disasters.

Here's the worst case: A and B have different styles. A writes code. B reviews. B complains that things are not in B's preferred style. A changes things to B's preferred style. If B had written the code and A had reviewed, A would have complained that things are not in A's preferred style. B changes things to A's preferred style. So we waste time to turn the code into the style that the author didn't like. That's nonsense, but it happens.

Long before the code is written, there should be a short discussion about the rough strategy. As a result the review shouldn't say "this is completely wrong and should have been done in an entirely different way" - that should be sorted out long before code is written.

Code review should find bugs, objectively objectionable code, and then it can make suggestions how something could be done better, or when a different style would be preferred. These should be suggestions. Bugs and objectively bad code need to be fixed, suggestions may be followed.

There is an exception: Sometimes the author himself thinks the code quality is low because there was not enough time, but there is time pressure and taking more time is hard to justify. In that situation the reviewer can help by telling the author to make changes that the author wanted to make anyway, but couldn't justify.

  • Disagree there... your project should have a style guide. (Preferably enforced by an automated tool like lint). All code is required to meet the style guide before being checked in... This is what the most successful coding projects do. It ensures that code is consitent and easy to read regardless of who wrote it.
    – Questor
    Commented Jun 12 at 17:48

Code reviews are one way to increase quality and consistency, reduce bugs, and lower effort too. When everyone is familiar with all the code, they know what they can reuse from elsewhere, they know what will be affected by their changes, and they feel comfortable working in any part of the code. And as a second pair of eyes, they may spot errors before they cause damage. Note: in order to gain all these benefits there's no need for the review to be performed by a more senior developer.

Consistency is very hard to enforce any other way. Say the team has a style preference about the way names are constructed: is it AddItem() or NewItem() or ItemAdd(), for example. Someone who writes a lot of code which all works fine but doesn't follow that style may be told to correct it, and may feel that's a big giant waste of time. (Most tools can make these sorts of changes trivially, so the response is more generally an emotional one about liking to be corrected or not liking feeling "wrong".)

Bugspotting is rarer, but it does happen that someone will say "this doesn't look [threadsafe, scalable, exception-safe]; did you test under [typical production conditions that don't occur on a dev machine]?" and a real bug is prevented. Generally this means the person has to start over and feels really humiliated for having made a rookie mistake.

The downside to code reviews is that they can get adversarial. It's hard for a reviewer not to think "what were you even thinking? Did you read our style guide? Did you even consider what production is like compared to your laptop?" and sometimes they say those things too. Making it a review gate where a senior person can pass or fail you intensifies the emotions. Developers often try to rebut corrections, saying that it's a matter of personal preference or that the reviewer is obsessed with an edge case that won't happen, or is just making up concerns to feel important or to humiliate the developer.

Now imagine instead that peers looked over each other's stuff all the time. Not as a gate that you can't get through without a gold star, but as a natural way of working. And they pointed things out to each other early, to save work and pain, not to cause it. That would be much better, right? In the same way that continuous integration and continuous testing made developers happier and code better compared to code-for-two-years-now-the-testing-can-begin, little reviews all the time - many times a week - will make developers happier and code better than one final you-thought-you-were-done-but-The-Nitpicker-is-here code reviews.

If you want to drop them entirely, you could. Plenty of code has been written and shipped without them. But it's a risk. Tests passing doesn't mean the code is readable and consistent. Not blowing up in production the first week doesn't mean it won't when you double your user numbers, or have 5 years of stuff in the database. You would be hard put to find any substitute for looking at the code to prevent those kinds of problems.

  • There is no need to explain me how good the reviews can be if everything is tuned well but the question is about the possible alternatives. Apart from over-sensitive persons, there are also obvious power games.
    – eee
    Commented Mar 4, 2017 at 21:04
  • Yes, there are lots of ways for people to be upset. But nobody can suggest to you a substitute for code reviews without first establishing the benefits of code reviews. Thus the first three paragraphs. The 5th offers a replacement to the "gate reviews" and the last discusses what would happen if you just dropped them. Commented Mar 4, 2017 at 21:17

I don't see how it can degenerate into a political issue. I presume that there are at least three people involved; two developers and a project manager.

Developer A code reviews the work of developer B. Developer B code reviews the work of developer A. The feedback circle is complete. If developer A decides to be really picky about the work of developer B, then they'd better be ready to accept a similar level of criticism back.

If it gets to the point where no code is being accepted, the project manager needs to step in and do a little project management with the development team and sort the problem out for them.

  • 1
    I agree that the project manager needs to step in, but I think this can easily become a poltical issue on a large enough team where more senior devs review more junior devs code but not the other way around. It's ridiculous and a sign of a dysfunctional culture, but I can see it happening.
    – Mel Reams
    Commented Mar 5, 2017 at 7:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .