| Neither quality nor velocity can be quantified. Keep that in mind when defending your changes. As to design, it is also often very subjective. Some designs lead to less code: this at least is measurable. Others are outright clearer but this is less measurable. When discussing maintainability, stay focused on _realistic_ scenarios: what if we need to add an X, to handle Z in addition to Y. If you think a possible generalisation is not realistic, refer to your manager or with peers, head to head. More important than design, get confidence that your algorithm is correct and show it. Show that you thought of corner cases and handled some of them, traced those you do not handle. As to performance, be very clear about it: performance can only be _measured_. If you and a reviewer disagree on assumed performance, candidly ask if there is time to implement both alternatives and profile them. If you know your code will be less than efficient when some data gets too big, comment it in the code and explain why this is acceptable for now. Oh and if there are comments on style, ask the coding conventions in force. When you have them _respect_them_ and refuse further changes on things that are left unspecified. Finally, talk to people head to head (or by phone) and not only through the review system, where things escalate quickly. Sometimes you will learn new technical stuff, sometimes the reviewer will admit "maybe my proposition does not apply in your case". In any case you would have learned something and increased your understanding of the problem to solve. |