[ebzlo]

I agree with this response. Specifically highlighting the problem being a matter of practicality vs idealism. One of the things you learn as a young programmer is that bad code is inevitable when your resources are limited.

A practical generic solution, for example, that takes an extra 10 days to do, sounds fantastic from an engineering perspective-- we're trained to think this way. But on the business side of things, you may have a timeline for a feature to nab a client, or not enough budget for those extra 10 days, etc.

My opinion on these matters now generally falls into the it depends camp. Take his mentorship, because it sounds like he understands that every engineering solution is accompanied by a business solution and they must be agreeable for both parties (that said, he does seem a little jaded, so you don't have to take absolutely everything he says to heart-- there are companies who will give less weight to the business side of things, but the reality is that the consideration will always exist).

[pandler]

> every engineering solution is accompanied by a business solution

This cannot be stressed enough. Replace "business" with X. Engineering is rarely isolated. More often than not, constraints on time, budget, usability, customer relations, etc... are just as important as the down-and-dirty engineering constraints themselves.

This applies to all engineering. It is much more obvious, in some fields than others, though. E.g. material costs are easy to perform a cost/benefit analysis on, whereas software is generally more abstract.