If you’re sitting under a tree in the rain and it gets soaked through and you start getting wet, finding another tree won’t help you.
The whole industry is adjusting to the reality that the expected output of an engineer is much higher than it used to be. It’s not local to one company. You may find a better environment for the time being, but this is the direction everything is headed.
I don’t disagree that the expectations are higher, but token output hardly correlates to code output worthy of merging.
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.
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.
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.
Code quality directly correlates to everything you describe.
Yea, but I’m not sure customers or mgmt get that
As code quality goes down, so does productivity, as it becomes more difficult to add new features and there are more bugs introduced.
Nobody cares until the code gets so twisted in knots that bugs and security issues predominate.
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.
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
I think some tests should be considered to be part of the specification rather than the product.
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.
They don't care about quality as long as it works enough. It's a clown show all the way through.
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.
*the whole industry in countries without strong worker rights
American software engineers are paid commensurately more than equivalent roles in countries with strong worker rights. There is no free lunch.
Besides, it's probably counterproductive in the long run to think of strong worker rights as being opposed to the employer wanting higher productivity out of the worker.
Well, if we are talking the worldwide software development industry, FAANG-like salaries are a tiny exception. There are so many places without strong worker rights and without a high premium for workers.
The expectation of higher productivity measured by completely useless means, letting a highly qualified employee jump through hoops for the amusement and misconceptions of the C-level.
It’s too bad that, yet again, instead of the productivity gains leading to shorter work weeks, the benefits accrue to the companies. Just once I’d like to see productivity gains lead to more leisure time, not higher expectation.
Be careful what you are wishing for. All the leisure time you would want while having no job or money could be the future we are heading for.
Fair point. Though I don’t think time without money is really leisure time :)