3 ms·
But often times the "good reason" is that the engineer can quietly solve a problem in their cubicle without fighting an epic political battle that affects multi
by asdfman123 7y ago
But often times the "good reason" is that the engineer can quietly solve a problem in their cubicle without fighting an epic political battle that affects multiple departments. From that engineer's perspective, it's a perfectly rational choice.
And that engineer who writes code might be a brilliant engineer and competent coder, but they just haven't been on many software projects before and they don't see how damning that decision could end up being.
It works and everyone is happy, but it's a wart that people have to build around for the next 20 years.
- bdamm 7y agoAs a software guy I have to point out that often software "engineers" overbuild and abstract the wrong stuff, doing stupid things like making everything a layer. There is way more bad code written by professional software engineers than by EEs, who tend to be more results oriented.
- taneq 7y agoI partly agree, but also, have you seen EE code (from EEs who are not also software devs)? It's not terrible in a "uses php instead of lambdas", it's terrible in a "absolutely zero consistency in variable naming, indentation, or in fact anything, also any comments will consist entirely of broken code or cryptic half-words." I deal with this stuff semi-regularly in my day job and wow.
- JetSpiegel 7y agoI could live with all that crap, but what kills me is the unnecessary global state. Everywhere, particularly when it's not needed. It's a complete nightmare to integrate with the rest of the application.
- taneq 7y agoOh, yeah I forgot to mention the “global-first” memory management style. So scary.