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 ;)
And building the correct structure for your problem/program is still a huge part of the job. If you completely delegate structure, you still get a clusterfuck.
I have found working with LLM's is best when I provide as much structure and constraints as possible, and reduce the degrees of freedom that the LLM can exercise, so that it is forced to fit its logic inside the structural boxes I have laid out.
If you just delegate everything to the LLM to get an absolute morass.
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 ;)
rjbwork · · focus · HN ↗
I have found working with LLM's is best when I provide as much structure and constraints as possible, and reduce the degrees of freedom that the LLM can exercise, so that it is forced to fit its logic inside the structural boxes I have laid out.
If you just delegate everything to the LLM to get an absolute morass.