Thank you for your answer, but I don't think that would have been feasible - our employer called me exactly because the team was very slow, and adding so many additional steps would make me very slow too.
I'm now changing contract, hopefully with the new team it will be possible to find a better compromise. For example, I offered to walk the reviewer through my code, which I think would have helped a lot, but this was refused...
Your real choices are: "fast and buggy" vs "slow and correct".
What is your preference?
> I offered to walk the reviewer through my code
Walking reviewer through your code is a good exercise. Code review of complex change should be done in interactive session (code reviewer + coder). There is so much to learn for both sides in such session.
> Your real choices are: "fast and buggy" vs "slow and correct".
It's not a binary choice, it's a dial. And anyway, after more than 30 years of programming experience, I can tell you that I can write mostly correct code by applying diligently the pyramid of tests. In my experience, code reviews catch very few bugs that weren't revealed by testing, if any.
Much more than correctness, I find them useful to verify and improve the readability and maintainability of code - which are important goals, but as always the cost needs to be measured against time and cost constraints. Depending on the project, being twice as slow to accomodate the reviewer can or can't make sense. What I'm looking for is more of a 80/20 solution: can I be 20% slower, and still get 80% of the benefits of code reviews?
I'm now changing contract, hopefully with the new team it will be possible to find a better compromise. For example, I offered to walk the reviewer through my code, which I think would have helped a lot, but this was refused...