The last 10% was simply a theory issue. The reviewer wanted things his way, which would have taken an inordinate amount of time for the feature. I told him that it was unnecessary, and would increase dev time. I was thinking about the entire product process, while he was focusing on how the code should look -- which was purely arbitrary.
He wouldn't waver, and delayed my PR. It eventually was escalated to the head of engineering, who sided with me. It was a trivial feature, and my code was tested and worked -- it just wasn't the reviewer's way of doing things.
Anyway, it got merged as is. But, I can only wonder about how a junior dev may have handled it. Wasting hours of time to conform to a particular senior engineer's arbitrary "way" of doing things -- correctness be damned. As for my own code reviews, I follow a simple process: 1. Can I parse it in 10 seconds? 2. Does it fit the specs? 3. Is it tested? 4. Is it extensible?
What are the useful techniques to deal with such people? Many times, it is just easier to comply to their vague requirements rather than engage in prolonged discussions, as they usually don't have the ability or will to look at things from the other side. I consider escalation to a higher management the last resort.
Does anyone produced some successful strategies to deal with that?
It's just a quirk of his without malice I think, but it does get to me depending on who its in front of. I think he just wanted to be seen as the teacher.
Fairly often, you gotta show confidence and show boundaries.