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 ;)
At an even more fundamental I tend to think about software as managing _risk_, where complexity is just one component. A large portion of my career has been about making difficult decisions around accepting particular sorts of software risk to reduce other types of risk, like my coworkers continuing to receive paychecks, for example.
Put even simpler: code is a liability, and understanding is an asset.
It's easy to add more code, but it also increases the risk, especially if you are the only one who understands how it works. As more people on the team understand it, the risk decreases. It becomes less likely that the code interacts in an unexpected way with other parts of the system, and it also becomes more likely that the existence of the code is justified because noone felt the need to replace it.
If you fire the team and replace it with another, you now have a lot of code and zero understanding. That understanding first has to be mined before you can close the asset/liability gap.
In the age of LLMs, it becomes easy to produce 10x as much code as before, but I don't think you can put the same multiplier on how fast you can increase the understanding. It may even be <1 if you are not being mindful about your LLM use.
I think a lot of people will tell you that now it's much easier because they can just ask their LLM how it works, but in practice I don't think people are able to absorb enough from these purely need-based interactions to arrive at understanding that translates into sustained long-term increases in productivity for large projects.
The thing I keep seeing is greenfield AI projects built by ill-conceived, self-styled software factories. They grow incredibly quickly, and then reality sets in and the pace slows. Demonstrating this is difficult. There are real productivity increases to be had here no doubt, but the long tail is still expensive.
Exactly. And LLMs will only accelerate your rate of understanding so far by helping you find and organize information, at the end of the day you are still limited by your own mental bandwidth.
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 ;)
devin · · focus · HN ↗
ulrikrasmussen · · focus · HN ↗
It's easy to add more code, but it also increases the risk, especially if you are the only one who understands how it works. As more people on the team understand it, the risk decreases. It becomes less likely that the code interacts in an unexpected way with other parts of the system, and it also becomes more likely that the existence of the code is justified because noone felt the need to replace it.
If you fire the team and replace it with another, you now have a lot of code and zero understanding. That understanding first has to be mined before you can close the asset/liability gap.
In the age of LLMs, it becomes easy to produce 10x as much code as before, but I don't think you can put the same multiplier on how fast you can increase the understanding. It may even be <1 if you are not being mindful about your LLM use.
devin · · focus · HN ↗
The thing I keep seeing is greenfield AI projects built by ill-conceived, self-styled software factories. They grow incredibly quickly, and then reality sets in and the pace slows. Demonstrating this is difficult. There are real productivity increases to be had here no doubt, but the long tail is still expensive.
ulrikrasmussen · · focus · HN ↗