[sp4ke]

This ! It seems the coming IT generation got so much sucked into the current state of programming, few actually try to look at the big picture for some perspective on "why" are we doing things the way we are in the first place.

The way I think about it: any extra effort that has no direct impact in making my life "as a programmer" easier, is a bug that needs to be fixed. Same thing applies when designing for people (i.e non technical users)

Here's an inspiring interview from Alan Key that illustrates the issue: http://www.drdobbs.com/architecture-and-design/interview-wit...

[jlg23]

> The way I think about it: any extra effort that has no direct impact in making my life "as a programmer" easier, is a bug that needs to be fixed.

And 20 years later I am able to differentiate between "minor chores" and real "real work savers".

And downloading something is definitely a minor chore, one that can be "fixed" by a few lines of code in your build pipeline. After having read a few discussion here on HN I totally get that this is "too much" for some (just revisit the discussion about the npm left-pad disaster where the consensus on HN seems to be that it "is ok to download code for that because writing your own routine for left-padding a string might take an hour"). When I was learning, I'd spend that our in my spare time because I'd be ashamed to have somebody pay me for this. Now that I am older, I'd just fire whoever utters such crap on the spot. To be perfectly clear: "I don't have to download the libs!" is NOT a valid reasoning for a technical choice. Not at all.

In the last 20 years of professional software development I've never ever encountered a situation where the time "downloading libraries" was worth more than a rounding error in a weekly budget.

PS: man alias. trust me, just a single line of config in your shell will save you hours, well minutes, well, maybe just seconds over your lifetime. But you can spend twice as much time to make the non-problem go away - and you qualify for a free shirt "for every solution, I have the problem!".

EDIT: sp4ke, I know this sounds harsh, but it is not, in any way, meant as a personal attack. Instead, please treat it as the ramblings of an old, misanthropic programmer ;)

[mgkimsal]

so maybe everyone should just wait 20 years before they understand any differences, and then they're ready to go?

"one that can be "fixed" by a few lines of code in your build pipeline"

Why do I even need a "build pipeline" for some projects?

If you actually think much of this npm/gulp/sass/build stuff will age well, and you'll be able to go back to a "build pipeline" for a project 7 years from now.... it's very likely not going to work.

"In the last 20 years of professional software development I've never ever encountered a situation where the time "downloading libraries" was worth more than a rounding error in a weekly budget."

Hrm... just last week - "npm install" on a project took 45 minutes. Then... welp, gotta do it again on the server too. 345 meg of stuff, multiple dozens of which were complete duplicates of each other. That's 90 minutes waiting, 45 of which not even sure how much time is left (2 mins? 5 seconds? an hour?) while the machine slowed to a crawl.

"I don't have to download the source libraries, then make changes, then recompile, and build and publish and push just to get a half-decent default when I can just reference these over here from a CDN" - that certainly is a valid technical choice. You can spend hours downloading, configuring, learning something that wasn't bootstrap and delivering less than "way better than bootstrap" UI/UX... that's a bad technical choice.

You're right about aliasing commands, building stuff to save yourself time, but avoiding prebuilt stuff that is perfectly suitable for a project in pursuit of pixel-level control when it's not necessary (for most projects) is wasting time.

[jlg23]

> so maybe everyone should just wait 20 years

I'd hope that people with misguided optimization agendas that effectively cost me as an employer money will be weeded out before 20 years pass.

The QED is the rest of your post; I don't care about your problem with NPM, I neither mentioned it nor do I used it beyond amusement purposes.

[fnovd]

>I don't care about your problem with NPM, I neither mentioned it nor do I used it beyond amusement purposes.

The commenter who you said had "by far the worst line of reasoning I've ever encountered" was annoyed at having to use NPM to install a simple CSS library. Not only did you flat out insult the person, you did so without taking seriously the tech stack that caused the headache! How do you expect to contribute to a discussion of the pros and cons of new tech when you yourself aren't using it to do real work?

[blowski]

Give me Bootstrap over an in-house library any day. It makes hiring and onboarding new staff easier, speeds up prototyping, and introduces standards with minimal effort.

Of course it's not right for every project, but it's perfect for a lot of them.