Comment by jlamberts | Hacker News Reader

Comment by jlamberts | Hacker News Reader

Parent Full thread

Engineering is about creating something that serves a purpose, while operating within a set of constraints. Part of that is realizing that "100% correct/reliable in all circumstances" is an unrealistic goal, since implementation time and cost is one of those constraints.

A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly. For example, if you're working on safety critical or very foundational systems like OSes, medical tech, etc you should bias very heavily in favor of robustness. If you're not, this can easily be an act of overengineering. The engineer's job is to find the right spot along the cost-correctness curve for the thing they are building.

This has always been true, and LLMs just change certain parts of the equation. For example, code writing is far less of a bottleneck than before, so "we can just try with a throwaway impl and see if this works" is suddenly economically viable. It also turns out that many things, in practice, don't need to be as correct as some of us may have believed.

We can still enjoy making quality things, but doing so is often an act of artisanship rather than engineering.

> LLMs just change certain parts of the equation. For example, code writing is far less of a bottleneck than before, so "we can just try with a throwaway impl and see if this works" is suddenly economically viable.

The economic costs of LLM use have been abstracted away, but they're still very much there. The ecological cost of building and running data centres will be a pretty heavy economic cost somewhere in the future. It's not obvious, but it still exists.

(I'm not dumping on LLMs — otherwise I wouldn't even be here. I'm not a glutton for punishment. I know well that HN users excited about LLM use now vocally outweigh, and are pretty intolerant of people who are more on the cautious/negative end of the spectrum. I don't want that trouble in my life).

> Engineering is about creating something that serves a purpose, while operating within a set of constraints.

A builder fits that description. Even a cook fits that description.

Engineering is something else. It's hard to describe what it is, probably why it has its own word. Dictionaries probably offer a definition.

> A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly.

An engineer will never intentionally produce something shoddy for cost reasons. They will simply refuse to do it. What you are getting at it some tasks don't require an engineer at all. You want to build a bridge to span a kilometer of water? You need an engineer. You need to occasionally cross a ditch? Anyone could lay plank across. No engineer required. The author makes this point too, with software craftsmen.

Highly recommend this if anyone wants to think more about what engineering is: https://mitpressbookstore.mit.edu/book/9781728280455

we built cathedrals without a detailed understanding of load calculations and material properties

But when nobody will die from your decision (and to be clear I think security is extremely important, but moreso for banking/healthcare than a private wow server), then “shoddy” becomes a matter of reputation/taste vs value/marketability.

The demand curve is different because it’s low stakes, like throwing a bad party or oversalting food. And part of the problem in software to begin with is too much LARPing about scale/engineering for things that don’t need it, as well as lack of accountability or care for things that do.

You can still be an “engineer” working on a game, it’s just more about making the game fun than making it safe. Or, you create a process for making and test hundreds of experimental bridges, and refine/invest additional time in understanding and verifying the safety of the best one.

Reply on news.ycombinator.com