Hacker News Reader

Comment by koonsolo | Hacker News Reader

I also have 20 years of experience, and was thinking the same thing about the article. Liked everything except the opinions. But for me the reason is a bit different.

Everything has benefits and drawbacks, and you always know the drawbacks of something you use better. Decisions are always about tradeoffs, never about "strong opinions". For example we recently had a discussion about git normal merge vs squash. My opinion was "I lean towards normal merge, but maybe in our context we prefer squash. Let's check with the team members...". Now if you have a strong opinion on either one, I know you are inexperienced, because you cannot just throw away the benefits and drawbacks of either one. You might fool juniors who equal strong opinion with knowledge, but not me.

And on juniors vs seniors, the biggest difference I see is that juniors can really get stuck on a problem, with nowhere else to go. A senior is always able to find a way.

View on HN

Ironically, you have a very strong opinion on people with strong opinions. Going as far as saying if you have a strong opinion on how to use git means you're a junior is a bit extreme, in my opinion.

I’m sure you could change his mind with a good reason. What reasoned argument can you give as to why it would be better to have a strong opinion about why one type of merge is always better.

To steel-man this argument for them:

Maybe you’ve seen the long term affects of squashing commits in several different contexts, and it always leads to a poor outcome eventually. Sure there might still be reasons to do it, but you’ve never seen a case where it’s worth the cost in the long term. Eventually with experience (and several different contexts), you think the costs of squashing commits is so high that no reason to do it is worth the trade-off.

Maybe this doesn’t actually apply to git merges, but I imagine that there are certain things that eventually emerge as having extraordinarily unfavorable trade-off ratios.

It’s hard for me to think of anything off the top of my head, but one example could be using global scope for all of your variables. Sure, it’s a small app now, but do you really want to rewrite everything later when it’s impossible to understand? Of course there are (tiny) benefits to building an app with all global variables, but it’s hard to imagine that is ever a worthwhile trade-off, and I think it’s fair to build a strong opinion that you should use (at least some) local scope.

> you think the costs of squashing commits is so high that no reason to do it is worth the trade-off.

I think a "measured" approach here would be to say that the evidence required to convince you that this would be a good idea raises which each new domain in which you see it fail. It's not to say that you cannot be convinced; but it's to say that the burden of proof is heavy.

I think it often is the "multiplication" of severity and frequency. Once burned badly enough gives a lot of weight to your preference, even though it is not what you typically associate with the word "measure".

Not OP, but there are places where you have to cut the knot so to speak. Reminded me of -

"When you know that my poems are not poems, Then we can speak of poetry."

seems like tolerance paradox

It seems like you do have a strong opinion on git merge vs. squash. You seem fairly convinced that one should adapt to local conditions and not doggedly stick to one of them. (You even go as far as saying that the latter is a signal of inexperience!)

For me I have found different paradigms to be useful. But sometimes just getting the team to agree on one system and one set of build tools can be an uphill battle. So sometimes you end up with 2 or 3 systems instead of one. For some things that is perfectly fine. But others it becomes a roadblock on bringing in new people. When starting a new job sometimes just where the bathroom is can be a bit of a chore much less trying to figure out what someone 3 years ago was arguing about and you just want to check some code in and get it reviewed. But when you first show up you probably at least want to get a lay of the land and figure out where the Chesterton's fences are before trying to 'fix it'. It could be they already had this discussion a few times. It could be they never considered it. But until you do it their way for a bit you will not be able to speak with any authority.

>You seem fairly convinced that one should adapt to local conditions and not doggedly stick to one of them

If there ever was an universal truth about any subject that's being dealt with by someone who knows even a little about said subject, it would be phrased approximately like that

"Don't be a zealot about $thing" shouldn't be considered a strong opinion

I remain a zealot about the harms of leaded gasoline and corruption, for example. Also the roundness of Earth, and the applicability of Newtonian physics at human scales. There are a large class of things you should be zealous about if someone offers opinion to the contrary!

Well, how much good has it done to be zealous about those things when someone offers an opinion to the contrary?

Ever managed to actually convert anyone back to sanity?

Well that's such a topic that it's not really worth to have strong opinion over yes, but there are other things that will determine the success of an application or system, like whether you use REST, GraphQL, micro-services etc, so the architecture of those things, having knowledge to form an opinion about those would seem important. These type of things can matter in the future where they could have 10x productivity difference depending on the path you choose.

Reply on news.ycombinator.com