> You'll never convince me that copy and paste is better then reusing existing code or that it's considered good engineering What's better engineering: not sol

> You'll never convince me that copy and paste is better then reusing existing code or that it's considered good engineering What's better engineering: not solving the problem, or solving the problem in a sub-optimal way that can be improved upon in future? I don't disagree that performance is important for memcached, but your base assumption here doesn't help you make any progress. You're basically giving up from the start. Assuming that everything you need lives in the incr/decr functionality is a reasonable assumption that lets you make progress. If you assume that performance is important and a multiplication operator may have implications, you should be able to come up with assumptions/hypotheses about why that would be and try to prove or disprove them. > Do you want to see me write code that compiles and does the bare minimum or actually talk about designing a robust feature The great thing about this question is that it forces you to be specific. It's very easy to make general statements like "we need to consider performance implications" without having anything to back that up. Why is the bare minimum insufficient here? Why do you need to deviate from the existing implementation and re-design this operation in a robust way? What makes the existing implementation unsuitable for this use case? Those are the kind of questions I would expect to be answered by someone who is concerned about the performance implications of a multiplication operator. I have found that strong engineers do not pose these vague, open-ended questions and concerns without being able to dig into the underlying details and be able to validate or invalidate their hypotheses.