To me software engineering was often about: how do we structure the project so that the crappy code the other students/co-workers write don't break everything?
Not because everyone writes bad code. They do, at-least the do first time you read their code. You only think someones code is decent when you spent 3 hours trying to refactor their PR, and realized that the compromises they made were perhaps reasonable.
(This is an important lesson to learn)
Whether code written by others is poor or not is also besides the point.
You cannot keep everything in a large project in context (biological or not).
Software engineering (not computer science) is about: managing complexity. Structure your project in layers or abstractions or packages or silos or verticals or objects or whatever.
But break complexity into bits, so that everything isn't in mind all the time.
Nothing new about that. And poor engineering can be papered over with hard work. It's just easier to reach the point where poor engineering really bites ;)
The difference is, the total cost for a human to write/modify code files is much higher than for an LLM. A lot of time has been spent designing program languages so that human time is more optimized. LLMS dgaf if the code is structured cleanly or is a mess.
So even if you end up with a mess of a codebase, as long as you define your test cases and they all pass, what is in the middle doesn't really matter.
jopsen · · focus · HN ↗
Not because everyone writes bad code. They do, at-least the do first time you read their code. You only think someones code is decent when you spent 3 hours trying to refactor their PR, and realized that the compromises they made were perhaps reasonable. (This is an important lesson to learn)
Whether code written by others is poor or not is also besides the point. You cannot keep everything in a large project in context (biological or not).
Software engineering (not computer science) is about: managing complexity. Structure your project in layers or abstractions or packages or silos or verticals or objects or whatever.
But break complexity into bits, so that everything isn't in mind all the time.
Nothing new about that. And poor engineering can be papered over with hard work. It's just easier to reach the point where poor engineering really bites ;)
ActorNightly · · focus · HN ↗
So even if you end up with a mess of a codebase, as long as you define your test cases and they all pass, what is in the middle doesn't really matter.