I agree, this seems to be based on the feeling some of us have that code has to be "done right", forgetting that the code isn't there for its own sake (at least in a job setting). The bottom line is really what matters in the end, and your boss is closer to that than you are.
On the other hand, coding efficiently in the long term will likely sometimes be good for the bottom line, and you are closer to your code's efficiency than your boss. So one should make sure to understand why the boss wants to make a certain call.
I guess you could say: Make it good. Just don't make it _too good_.
Not all code needs to be super general, extensible, and re-usable. However, all code needs to be simple and elegantly designed, and unit tested. It needs to not smell.
Comments
I agree, this seems to be based on the feeling some of us have that code has to be "done right", forgetting that the code isn't there for its own sake (at least in a job setting). The bottom line is really what matters in the end, and your boss is closer to that than you are.
On the other hand, coding efficiently in the long term will likely sometimes be good for the bottom line, and you are closer to your code's efficiency than your boss. So one should make sure to understand why the boss wants to make a certain call.
I guess you could say: Make it good. Just don't make it _too good_.
Not all code needs to be super general, extensible, and re-usable. However, all code needs to be simple and elegantly designed, and unit tested. It needs to not smell.