Solving Code Reviews

At Large Online Retailer, me and code reviews have a bit of a history.  They are kind of a pain in the ass, mostly because every time you make a change you basically have to drop what you are doing while you wait for someone else to look at it.  No one really wants to read your code, though, so it will be a while unless you personally pester people.

I tried to experiment with developing methods where we streamlined the reviewing process and decoupled checkins from the reviewing.  That is when I found out that code reviews have religious status in the minds of...pretty much everyone at Large Online Retailer.

So that's fine.  Add it to the list:  death, taxes, and code reviews.  Attempt to escape any of them at your own risk.

What about dealing with them then?  Sure, the advice from senior devs that I respect has always been helpful, and taught me a lot, but what about retarded advice from stupid devs who are pushing their lame style religions (tabs vs spaces) or just asking you to move stuff around for no functional reason?

Fighting them over stupid things is actually not an option either.  I tried to keep my code nice, and to fight people so that the final check in was still something I would be proud of (or at least not ashamed to have my name on it), but then I got a shit ton of comments in my performance review about me being "defensive" or argumentative or some bullshit.

In order to remedy that, and since I hate my job and am planning to leave anyway, and since the senior devs with good advice are all gone, I started to simply acquiesce to all of the dumb reviews requests.

This did not work either.  I just watched a code change, which my manager was riding me for, get delayed for days because even though I made every little renaming and shuffling change, the person doing the code review kept finding more things we wanted renamed, or shuffled.  By the time we were done stirring everything around my exasperation was becoming visible.

Therefore, the best solution I can think of, which I will implement after switching companies, is to start keeping secret notes on everyone I might need a code review from.  The notes would include what stupid stylistic things they will have a fit over (when to break a line, what order to compare things in, etc), and it would also note how often they make ridiculous requests (like splitting a small function into two smaller functions for no reason) that I cannot anticipate ahead of time.

Using this information, I would hopefully be better armed to navigate the political landscape of code reviews.  For example, if one code reviewer insists on fucking up my code, the next time I make a change, if I know I'm going to have a different review with different flavors of style angst, I could use that as an opportunity to fix the code.

This might not actually be a real problem though.  I suspect that if I were to make it to a team with great developers, they would probably also be great, helpful, insightful code reviewers.  So maybe I can leave the politics here with the rotting code.