7 ms·

I don’t disagree that the expectations are higher, but token output hardly correlates to code output worthy of merging.

Insanity 4mo ago
Code quality matters to engineers. Find a senior manager who cares. Or worse, find a customer who cares. While they obviously want a high quality product, no outages, a responsive system etc, I don’t think they necessarily understand why you need to avoid creating god-objects, need to reason about abstractions, etc.
- vips7L 4mo ago
  Code quality directly correlates to everything you describe.
  - Insanity 4mo ago
    Yea, but I’m not sure customers or mgmt get that
- drob518 4mo ago
  Nobody cares until the code gets so twisted in knots that bugs and security issues predominate.
  - HeyLaughingBoy 4mo ago
    Exactly. As long as poor code quality doesn't make a difference in the actual usage of the product, no-one but the engineers will care.
- thayne 4mo ago
  As code quality goes down, so does productivity, as it becomes more difficult to add new features and there are more bugs introduced.
- HeyLaughingBoy 4mo ago
  Code quality also exists on different axes. I've seen the case where code quality was poor in some aspects, e.g., tons of technical debt, coupling making it difficult to make changes, but overall product quality was very high. It had to be: it was a medical device. Most environments only care about the output. In the case I'm thinking of, Software made it perfectly clear to Management, most of whom were former engineers, that the product desperately needed redesign in some ways. But as long as the cost of that redesign exceeded the cost to get the next version out, it could be postponed. This went on for years.
xena 4mo ago
They don't care about quality as long as it works enough. It's a clown show all the way through.
- snoman 4mo ago
  As one that does, it’s a difficult discussion to have with the executives. My peers look like their teams are producing more than my teams are and any argument along the lines of “but their code sucks” isn’t going to hold water. The executives care but until there’s actual impact or poor quality, it won’t matter, and it’s a lagging metric. Many still don’t care about technical debt and that’s been well understood in industry for a while. It’ll take production incidents, impacted customers, and brand damage to make the executives start to prioritize quality over quantity again.
joshribakoff 4mo ago
Thats why they said they optimize for effective output at the cost of higher token use. They didn’t say they are intending to have high token use, instead thet implied its a second order effect of seeking more effective output.
vips7L 4mo ago
It doesn’t necessarily mean shipping faster either. Speeding up code production doesn’t mean it speeds up qa, compliance, and the litany of other things. Everyone seems to forget Amdahl’s law.
chocrates 4mo ago
On a task by task basis the code Claude generates is pretty good these days. The biggest issue I see is that it wants to rearchitect the code constantly and I have no faith in my tests anymore because Claude will just "fix" them
- fauigerzigerk 4mo ago
  I think some tests should be considered to be part of the specification rather than the product.

Code quality matters to engineers. Find a senior manager who cares. Or worse, find a customer who cares. While they obviously want a high quality product, no outages, a responsive system etc, I don’t think they necessarily understand why you need to avoid creating god-objects, need to reason about abstractions, etc.

vips7L 4mo ago
Code quality directly correlates to everything you describe.
- Insanity 4mo ago
  Yea, but I’m not sure customers or mgmt get that
drob518 4mo ago
Nobody cares until the code gets so twisted in knots that bugs and security issues predominate.
- HeyLaughingBoy 4mo ago
  Exactly. As long as poor code quality doesn't make a difference in the actual usage of the product, no-one but the engineers will care.
thayne 4mo ago
As code quality goes down, so does productivity, as it becomes more difficult to add new features and there are more bugs introduced.
HeyLaughingBoy 4mo ago
Code quality also exists on different axes. I've seen the case where code quality was poor in some aspects, e.g., tons of technical debt, coupling making it difficult to make changes, but overall product quality was very high. It had to be: it was a medical device. Most environments only care about the output. In the case I'm thinking of, Software made it perfectly clear to Management, most of whom were former engineers, that the product desperately needed redesign in some ways. But as long as the cost of that redesign exceeded the cost to get the next version out, it could be postponed. This went on for years.

xena 4mo ago

They don't care about quality as long as it works enough. It's a clown show all the way through.

snoman 4mo ago
As one that does, it’s a difficult discussion to have with the executives. My peers look like their teams are producing more than my teams are and any argument along the lines of “but their code sucks” isn’t going to hold water. The executives care but until there’s actual impact or poor quality, it won’t matter, and it’s a lagging metric. Many still don’t care about technical debt and that’s been well understood in industry for a while. It’ll take production incidents, impacted customers, and brand damage to make the executives start to prioritize quality over quantity again.

joshribakoff 4mo ago

Thats why they said they optimize for effective output at the cost of higher token use. They didn’t say they are intending to have high token use, instead thet implied its a second order effect of seeking more effective output.

vips7L 4mo ago

It doesn’t necessarily mean shipping faster either. Speeding up code production doesn’t mean it speeds up qa, compliance, and the litany of other things. Everyone seems to forget Amdahl’s law.

chocrates 4mo ago

On a task by task basis the code Claude generates is pretty good these days. The biggest issue I see is that it wants to rearchitect the code constantly and I have no faith in my tests anymore because Claude will just "fix" them

fauigerzigerk 4mo ago
I think some tests should be considered to be part of the specification rather than the product.