4 ms·

> we would have to live in a world where software engineering didn't matter. As an engineer who works very hard to do the right thing, I'm beginning to worry t

> we would have to live in a world where software engineering didn't matter. As an engineer who works very hard to do the right thing, I'm beginning to worry that software engineering doesn't matter. I write code that i think about a lot, understanding every line. It's not perfect, but I try to make sure my code is maintainable and well structured. I work much slower then my colleagues who produce unmaintainable slop at an alarming rate. In my career, no customer has ever complained about code structure or quality. It feels like I'm sinking in quicksand in an industry that's dying.

duendefm 18d ago
It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt. I can give a simple example. I have a coder here that filled the crontab of a server with periodic tasks. One of them was doing +200 failed requests per second and shutdown one of our routers. The router wrote so much logs that it changed the health of its internal disk from 15% to 85%. He doesn't even know what the crontab is. This kind of stuff is bound to happen more and more because the more you use AI to vibe, the more disconnected you get from the technology. And that's why I say, the only way that yolo vibecoding could work is if the base stuff didn't matter.
- bigfishrunning 18d ago
  > It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt. I agree with this wholeheartedly, but convincing nontechnical management of this fact has been extremely difficult. It was hard in the days of the stackoverflow copy-paste monkeys, and it's even harder in the age of LLMs.
  - juvvel 18d ago
    Some people cannot be convinced of this, but some can, as long as you don't use technical language to describe the issue. Essentially, instead of saying "we need to prevent technical debt and have a maintainable software architecture" one needs to say stuff like "software quality enables a faster time-to-market for new features and less customer churn". i.e. put it in business-y terms.
    - sanderjd 18d ago
      Yes, but then it's really important to demonstrate that this is true. If they invest in what you propose, time to market for new features needs to actually become faster, or customer churn needs to actually decrease. It's not enough to put the proposal in business-y terms, it has to actually effect the claimed improvements to the business.
  - sanderjd 18d ago
    You have to pick metrics to show management that they understand the importance of, and then be able to demonstrate degradation in those metrics when you don't do what you propose, and improvements when you do. Accomplish this and you'll build trust. Too often, what happens is that the proposed benefit is vague and not empirical, and then the benefit is not actually realized by a large investment into it, destroying trust.
juvvel 18d ago
Of course customers do not care about code quality in and of itself. Just like they don't inherently care about the type of seam used for a garment. But they do care if their clothes fall apart after two washes. People care if software is buggy or slow or becomes harder to use or more expensive over time. And the way we know how to mitigate that is by ensuring code quality (it's definitely not the only factor, but an important one).
PaulStatezny 18d ago
Agree and disagree. There have always been software companies that care about quality, and those that don't. Many who don't care about quality exist because their products are forced onto their users. (Due to footholds from enterprise relationships, regulation, etc.) I bet those are they types of companies where slop will abound, but their codebases and products were already terrible anyways. --- But research reliably shows users do care about things Just Working™ and feeling polished. With few exceptions, if software feels at all buggy or doesn't look visually amazing, you won't acquire/retain that many users. Natural selection will teach hard lessons to the industry. Customers will notice things feeling "off" on products where AI slop is allowed to abound, and they'll flee to companies with sane approaches. A sane approach: Humans actually guide the direction of the code which means they have to understand + review the code and course correct bad decisions. This doesn't mean agentic coding goes away, but it means this mad rush for insane velocity goes away. --- Compare vibe-coded apps you've interacted with against world-class polished apps like Spotify, Gmail, Slack, etc. Those apps aren't obviously showing signs of AI slop, because the organizational structure is in place in those companies to prevent engineers from just throwing slop over the fence. Those engineers are doing agentic coding but are being forced to go at a sustainable pace. The industry will eventually be forced (by the reality of business results) to recognize that this is the only approach that will lead to success.
sanderjd 18d ago
Sometimes it matters and sometimes it doesn't. The hard part is figuring out which is which. The most effective engineers are those who maximize the amount of time they spend picking the right point in the trade-off at the right times. Choosing a preferred point on the continuum and sticking to that at all times simplifies decision making (itself a useful thing!) but it's not the optimal strategy. There are a couple ways out of this conundrum. One is to try to get really good at picking the right point on the continuum as much as possible, which is essentially a forecasting problem (and thus it's really hard!). I think the somewhat easier choice is to pick roles that align well with your style. If you have a deliberate and near-perfection preference, you can seek to work on projects where there is no question of the importance of correctness. If you prefer the opposite, you can work on prototypes and zero-to-one type projects, and that will be more satisfying (and less catastrophic).

duendefm 18d ago

It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt. I can give a simple example. I have a coder here that filled the crontab of a server with periodic tasks. One of them was doing +200 failed requests per second and shutdown one of our routers. The router wrote so much logs that it changed the health of its internal disk from 15% to 85%. He doesn't even know what the crontab is. This kind of stuff is bound to happen more and more because the more you use AI to vibe, the more disconnected you get from the technology. And that's why I say, the only way that yolo vibecoding could work is if the base stuff didn't matter.

bigfishrunning 18d ago
> It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt. I agree with this wholeheartedly, but convincing nontechnical management of this fact has been extremely difficult. It was hard in the days of the stackoverflow copy-paste monkeys, and it's even harder in the age of LLMs.
- juvvel 18d ago
  Some people cannot be convinced of this, but some can, as long as you don't use technical language to describe the issue. Essentially, instead of saying "we need to prevent technical debt and have a maintainable software architecture" one needs to say stuff like "software quality enables a faster time-to-market for new features and less customer churn". i.e. put it in business-y terms.
  - sanderjd 18d ago
    Yes, but then it's really important to demonstrate that this is true. If they invest in what you propose, time to market for new features needs to actually become faster, or customer churn needs to actually decrease. It's not enough to put the proposal in business-y terms, it has to actually effect the claimed improvements to the business.
- sanderjd 18d ago
  You have to pick metrics to show management that they understand the importance of, and then be able to demonstrate degradation in those metrics when you don't do what you propose, and improvements when you do. Accomplish this and you'll build trust. Too often, what happens is that the proposed benefit is vague and not empirical, and then the benefit is not actually realized by a large investment into it, destroying trust.

juvvel 18d ago

Of course customers do not care about code quality in and of itself. Just like they don't inherently care about the type of seam used for a garment. But they do care if their clothes fall apart after two washes. People care if software is buggy or slow or becomes harder to use or more expensive over time. And the way we know how to mitigate that is by ensuring code quality (it's definitely not the only factor, but an important one).

PaulStatezny 18d ago

Agree and disagree. There have always been software companies that care about quality, and those that don't. Many who don't care about quality exist because their products are forced onto their users. (Due to footholds from enterprise relationships, regulation, etc.) I bet those are they types of companies where slop will abound, but their codebases and products were already terrible anyways. --- But research reliably shows users do care about things Just Working™ and feeling polished. With few exceptions, if software feels at all buggy or doesn't look visually amazing, you won't acquire/retain that many users. Natural selection will teach hard lessons to the industry. Customers will notice things feeling "off" on products where AI slop is allowed to abound, and they'll flee to companies with sane approaches. A sane approach: Humans actually guide the direction of the code which means they have to understand + review the code and course correct bad decisions. This doesn't mean agentic coding goes away, but it means this mad rush for insane velocity goes away. --- Compare vibe-coded apps you've interacted with against world-class polished apps like Spotify, Gmail, Slack, etc. Those apps aren't obviously showing signs of AI slop, because the organizational structure is in place in those companies to prevent engineers from just throwing slop over the fence. Those engineers are doing agentic coding but are being forced to go at a sustainable pace. The industry will eventually be forced (by the reality of business results) to recognize that this is the only approach that will lead to success.

sanderjd 18d ago

Sometimes it matters and sometimes it doesn't. The hard part is figuring out which is which. The most effective engineers are those who maximize the amount of time they spend picking the right point in the trade-off at the right times. Choosing a preferred point on the continuum and sticking to that at all times simplifies decision making (itself a useful thing!) but it's not the optimal strategy. There are a couple ways out of this conundrum. One is to try to get really good at picking the right point on the continuum as much as possible, which is essentially a forecasting problem (and thus it's really hard!). I think the somewhat easier choice is to pick roles that align well with your style. If you have a deliberate and near-perfection preference, you can seek to work on projects where there is no question of the importance of correctness. If you prefer the opposite, you can work on prototypes and zero-to-one type projects, and that will be more satisfying (and less catastrophic).