| An alternative perspective (not a solution!) from my experience: I currently work at a place in the valley as a senior lead and it is _impossible_ for me to submit a PR without comments/nitpicks requiring fixes. My colleagues seem to always want to change something for some reason, whether or not it is a necessary change. The feedback comes in from all skill levels. Honestly most of the time these changes can be (and should be, IMHO) ignored because of YAGNI and Not Invented Here. I can't count the number of times I have re-designed and implemented something to be more generic/abstract only to have that abstraction whither for _years_ without being used. Oh - and implementing our own wrappers for third party libraries? We do it all the time. The challenge that I face is every time I get frustrated enough to push back and escalate, ultimately when discussing code reviews and velocity with managers, my colleagues drop the "Q" word and it's an argument-ending trump card: quality. If anyone can argue that any trivial change increases the quality of the code base, or can argue that my PR lowers the repository code quality, the argument is over. Regardless of whether or not it's objectively true, if it's subjectively true the argument is over and ultimately any feedback has to be implemented. Management doesn't budge on quality. Ultimately though, end users and customers don't care about code quality (but the do care about product quality, there is a difference). I have worked at this company for 6+ years. The product is uninteresting to me, but the people are actually a really good fit for me. We otherwise work really well together when doing actual problem solving, requirements gathering, manager managing, customer support, etc. It's frustrating to not be able to write code in one pass, but I've learned to 'accept' it - it's the nature of the beast. It's definitely not like this everywhere; I've worked at places that were much better about code reviews and merging code. Code that takes a day to design and get requirements for and a day to code and test will usually take a full week to get merged (not uncommon for it to stretch to two weeks). If management is fine with our velocity, then I guess I ultimately don't care. Anyway, I recounted all of this for you to give you another data point and perspective. Some places thrive on this sort of torturous review process. I've learned to live with it. It's entirely possible that there is no way for you to 'improve' your way out of review hell. Instead of focusing on reading books and improving your design skills (which you should do anyway!) you might need to learn how to navigate the code review landscape at this new place, either by accepting it or playing the game. I don't know how to tell you to play the game except get more involved in the review process as early as possible. Figure out what is important to people. I've gotten into the habit of "pre-screening" my reviews with one or two of the most problematic reviewers. I've gotten to the point where I will commit a pass of pseudo-code and have them give me feedback. It makes them feel better and wastes less of my time when it comes time for actual review. |