Basically they’re saying implicitly to be principled about adopting frameworks and other dependencies, evaluating whether they’re needed for one’s project before adopting them. It’s a pretty thought provoking post, even if it may be too subtle for some folks.

No need for the random snark? I mean, again, we're in extremely obvious territory here. Just doesn't seem appropriate for hacker news front-page (to me).

What makes their random snark any better than your original comment though? There was no need for you to come in and say that you don't see any value here. If you don't see any value here, just move on to the next post.

I mean, I'm curious why this is such a highly upvoted article, which is why I'm engaging with this comment thread. I think criticism of the article is fine (although I acknowledge I could have been less blunt). It's the unnecessary criticism of my character that I object to.

You don’t get to decide that, the people voting on HN do, they did and they disagree with you, just accept you can’t agree with a large set of people all the time.

Absolutely, everybody gets their say here.

Hmm, was only mildly snarky in my opinion

I agree, but my ego is incredibly fragile sometimes.

good of you to notice, but yeah, in my opinion, you kind of overreacted. All good though:)

What about the trade off of being principled in the first place? I was much more principled back when I refused to use any programming language that wasn't based off of the lambda calculus, and I also got a lot less done as a result.

I see it like this: with every line of code I write, I make an assumption about the final outcome. Making that assumption means that other possible outcomes aren’t possible.

The more code, the more assumptions.

Until eventually a fixed and very fragile outcome is reached. The so-called first release. Everything is well balanced and based on assumptions I have made based on the information I have been given along the way.

Turns out though my first assumption was wrong.

Now the engineering comes in. Make it look like my first assumption wasn’t wrong, but it was falsely communicated to me. Blame others for my own failings. It called human engineering and it’s great fun.

Engineering is broader than just trade-offs

Broad heuristics can be very effective

We make decisions on many more datapoints than can be put into what sometimes amounts to a “for and against” list

Obviously engineering is broader than just trade-offs. I agree that broad heuristics can be useful but the ones proposed in this article just seem bad. Dependencies are (again, obviously?) really useful in many contexts. Same with build steps and frameworks.

> Where's the engineering?

not every problem has a technical solution.

These aren't "problems" with a "solution". These are software-level decisions that have both pros and cons.

well you've decided they're "software-level". this article title talks about "time and energy".

most of the time the real trade off is financial.

especially now with AI generated boilerplate and npm commands that shit out 10,000 lines of code at a keystroke.

I don't think the choice of metric matters to my point (I'm just calling it software-level because these are decisions you make while writing software). These decisions come with both pros and cons either way, which it sounds like you agree with.

It is not random. All the mentioned problems come from a single source.

They don't really, as far as I can tell. There are lots of independent good and bad reasons to go down each of the roads in the article. Dependencies make a lot of sense in a lot of cases (e.g. the recent article on date parsing). So do build steps (static API doc generators anyone?). I think chalking it up to one thing is a bit too reductionist.