6 ms·

These are interesting scenarios. Each of them could probably use some additional context but overall I think the problem is one of practicality vs idealism. I h

These are interesting scenarios. Each of them could probably use some additional context but overall I think the problem is one of practicality vs idealism. I have been in both parties over the years and have more often than not been in the camp of over-architecting a solution. I think that on the surface, he does sound like a very practical programmer who is cognizant of the bottom line. If you are not going to be paid extra to implement something, then sometimes it doesn't make business sense to implement it. It is sad but true and you will sometimes feel the same if freelancing. To me, I would not turn my back on this guy - it does seem like there is stuff to be learnt from him. Nobody has all the answers though, so it is good for you to question him. If it is possible, maybe open dialogue with him about these would be beneficial to you both.

ebzlo 13y ago
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 13y ago
  > 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.
bcent 13y ago
I agree completely. One of the big things that made me think about it like that was his stance on generic code. As in my experience it tends to lead to over-engineering, and less efficient code (as you need to account for more things). It's takes some experience to know when the extra effort is worth the time; and it sounds like Mr. X very well slanted towards practicality ... throwing a little idealism at him where you think it's needed... AFTER you understand his reasoning... will make both him, and you better at the end of the day.

ebzlo 13y ago

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 13y ago
> 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.

bcent 13y ago

I agree completely. One of the big things that made me think about it like that was his stance on generic code. As in my experience it tends to lead to over-engineering, and less efficient code (as you need to account for more things). It's takes some experience to know when the extra effort is worth the time; and it sounds like Mr. X very well slanted towards practicality ... throwing a little idealism at him where you think it's needed... AFTER you understand his reasoning... will make both him, and you better at the end of the day.