5 ms·

I don't see the value in posts like this. It's just a random list of things that can go wrong in software projects, with no discussion of trade-offs at all. Whe

I don't see the value in posts like this. It's just a random list of things that can go wrong in software projects, with no discussion of trade-offs at all. Where's the engineering?

MOARDONGZPLZ 1y ago
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.
- hiAndrewQuinn 1y ago
  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.
- bubblyworld 1y ago
  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).
  - brabel 1y ago
    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.
    - bubblyworld 1y ago
      Absolutely, everybody gets their say here.
  - fragmede 1y ago
    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.
    - bubblyworld 1y ago
      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.
  - computerdork 1y ago
    Hmm, was only mildly snarky in my opinion
    - bubblyworld 1y ago
      I agree, but my ego is incredibly fragile sometimes.
      - computerdork 1y ago
        good of you to notice, but yeah, in my opinion, you kind of overreacted. All good though:)
kunley 1y ago
It is not random. All the mentioned problems come from a single source.
- bubblyworld 1y ago
  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.
5350-uiop-1130 1y ago
> Where's the engineering? not every problem has a technical solution.
- bubblyworld 1y ago
  These aren't "problems" with a "solution". These are software-level decisions that have both pros and cons.
  - 5350-uiop-1130 1y ago
    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.
    - bubblyworld 1y ago
      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.
lmpdev 1y ago
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
- bubblyworld 1y ago
  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.
Towaway69 1y ago
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.

I don't see the value in posts like this. It's just a random list of things that can go wrong in software projects, with no discussion of trade-offs at all. Where's the engineering?

MOARDONGZPLZ 1y ago

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.

hiAndrewQuinn 1y ago
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.
bubblyworld 1y ago
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).
- brabel 1y ago
  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.
  - bubblyworld 1y ago
    Absolutely, everybody gets their say here.
- fragmede 1y ago
  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.
  - bubblyworld 1y ago
    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.
- computerdork 1y ago
  Hmm, was only mildly snarky in my opinion
  - bubblyworld 1y ago
    I agree, but my ego is incredibly fragile sometimes.
    - computerdork 1y ago
      good of you to notice, but yeah, in my opinion, you kind of overreacted. All good though:)

kunley 1y ago

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

bubblyworld 1y ago
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.

5350-uiop-1130 1y ago

> Where's the engineering? not every problem has a technical solution.

bubblyworld 1y ago
These aren't "problems" with a "solution". These are software-level decisions that have both pros and cons.
- 5350-uiop-1130 1y ago
  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.
  - bubblyworld 1y ago
    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.

lmpdev 1y ago

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

bubblyworld 1y ago
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.

Towaway69 1y ago

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.