Title: I work on a small software team that develops code for scientific instruments. Our team runs very efficiently, and the focus on code quality is a big part of our culture.<p>However, lately, I have noticed that I&#x27;m unhappy with the intense code review cycles. The features work, have test coverage, and good git history, but we end up with a lot of back and forth until everything is precisely how our architect wants it to be. My perception is that I reached a point where I spend 50% of the time developing a solution (since I have enough architectural and domain knowledge) and the other 50% figuring out what will fly on review and merging back.<p>I do have some conflicting points in mind:
- My skills have evolved a lot in this process, and I take pride in delivering good-quality code. But now that the learning curve is flattening, I feel the weight of not having enough creative freedom to write something up quickly or try different designs.
- I see a lot of value in the shared ownership from the lengthy reviews, and we usually end up with better code&#x2F;design as the suggestions are technically sound.
- I&#x27;m starting to feel like code is implementation detail since our high code standard does not necessarily add more value to users.
- The focus of reviews is not on correctness but stuff like naming, docstrings, and design. Whenever a colleague makes a suggestion that helps the code improve, I&#x27;m happy to oblige. But lately, I wish I could slip a docstring that explains what is done instead of the why.
- In essence, we follow open-source library development standards while making a closed source application.
- The nature of our projects requires big additions to the software, so it is very common to have chained PRs.<p>Have you ever found yourself in such a position? What do you think about code review? Can too much of it be wrong?
Upvote: