Why engineers can't be rational about programming languages
1–10 of 206 posts
Re: Why engineers can't be rational about programming languages
#2We see the "we need to rewrite in X" conversation play out all the time here on HN. Love this take on it.
Re: Why engineers can't be rational about programming languages
#3> A programming language is the single most expensive choice a company makes, yet we treat it like a technical debate
I'd have to disagree, it really isn't, and I even think that's kind of the point the article makes.
Rewritting existing services from scratch in another language can often be a bad decision, because it assumes the choice of programming language is an important one. And any rewrite is costly, doesn't matter the reason why.
But starting a new project in a new language I don't think has much impact generally. And if it motivates the team, because they're excited about it, it can even help.
Deciding later to rewrite this once it's been built because it's not in the same language as what is common at the company, that's likely the mistake that will happen.
Re: Why engineers can't be rational about programming languages
#4I've got a different theory than this AI slop:
Engineers often aren't rational because engineers can still be stupid. Dogmatism/black-and-white thinking is often a sign of low emotional intelligence (and can also be a defense mechanism called "splitting").
The Dunning-Kruger effect also applies to "smart" people. You don't stop when you are estimating your ability correctly. As you learn more, you gain more awareness of your ignorance and continue being conservative with your self estimates.
Re: Why engineers can't be rational about programming languages
#5I don't agree with the title - I've seen many engineers be rational and pragmatic about programming languages. I'm not entirely sure why the author decided to lead with such a charged headline.
Re: Why engineers can't be rational about programming languages
#6I absolutely love this take. Then again it matches what I've been saying for decades, so I would.
Generalizing briefly, the same phenomena of identity underlies a lot of our religious wars. Be it language, braces, indentation, or a variety of other programming choices. What's fundamentally going on is that programming expertise is fragile. (I think I first saw that idea in Code Complete?) A new language / style / technology / whatever very often will leave us less competent. Ideally we would respond with, "I guess I need to get back on that learning curve." But often it is easy to instead blame the external factor. "I'm a good programmer. I tried it. The result didn't work well. It must be bad."
Among the many attempts to try to fix the problem, I can recommend https://blog.codinghorror.com/the-ten-commandments-of-egoles.... To the extent that you manage to apply its advice, you really will do better.
Of course your improvement won't directly help those around you...
Re: Why engineers can't be rational about programming languages
#7It's very rare for a rewrite to make sense unless the underlying stuff has so fundamentally changed you don't really have a choice. (For example, DOS to Windows. You have to scrap your UI completely.)
Re: Why engineers can't be rational about programming languages
#8It's very rare for a rewrite to make sense unless the underlying stuff has so fundamentally changed you don't really have a choice. (For example, DOS to Windows. You have to scrap your UI completely.)
Indeed, and the perhaps canonical article on "don't rewrite" from 2000: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Re: Why engineers can't be rational about programming languages
#9I don't agree with the title - I've seen many engineers be rational and pragmatic about programming languages. I'm not entirely sure why the author decided to lead with such a charged headline.
> I'm not entirely sure why the author decided to lead with such a charged headline.
It got people to click the link to their think piece.
Re: Why engineers can't be rational about programming languages
#10More often than not, preference should be given to the language most of the team know the best. The only exception is when everyone on the team feels a different language is a better fit for the need or there are underlying reasons for a language shift.
Personally, my bias is towards the languages I'm most comfortable with. I recognize this and will make other suggestions and if I'm not responsible for the code, I'm more than flexible.
All the fad chasing and top down declarations that we're all going to use Cucumber, GraphQL, Microservices or anything else is often a bad move.
First learn the problem you are trying to solve and empathize on behalf of the user... Then empathize on behalf of support... on behalf of the maintenance developers... on behalf of yourself in a decade. Is there a boxed solution? Buy it.. Is something custom really needed, what can you outsource as part of it? integrate it. Do the simplest, easiest thing you can to get the job done.