Still fighting with the CTO on letting people other than him do code reviews. We don't do retrospectives and code reviews also take months. I also have to fill out a change request form (CRF) that has the git hash, list of files modified, and many other useless and redundant fields that are required.
The article came off as if the company is run by designers, not engineers. While the engineers I know generally appreciate some feedback, they don't need much of it on engineering questions. UX and design, however - bring it on! So "eng crits" sound like... learning exercises for juniors? If it works for them, that's good, but I don't see myself sending my CV over, at least not based on this article.
Can't you have normal peer review with the rest of the team in lower level branches? Have everything work out as "normal" with PRs and whatnot, then when you want to merge develop into master or whatever, then do the CRF and CTO review?
It's a mix of ego and people not knowing what they are doing. I had to fight my first month just to get code into BitBucket. Before that, it was a server in rackspace you pushed to as the root user.
Because the CTO only does the code reviews, people create the PR and the CRF. Issue is because it takes so long, the CTO wants merge conflicts resolved before it's reviewed. Problem with that is, no one remembers the context a month (or longer later).
I have A LOT of spare time so I will often help out with doing reviews but because I'm not allowed to merge or deploy code, it's more of helping junior engineers write better code.
