You seem to be conflating code quality with product integrity.

All those problems are caused by business decisions, not the developers. You do make a good point though that AI may enable more people to build their own when they can.

▲

sarchertech 14 hours ago | parent [-]

The term code quality is overloaded and not really worth discussing without defining exactly what we mean.

But yes many of those problems were caused by business decisions. But engineers are perfectly cable of creating those problems on their own. If an engineer doesn’t realize that the function they called buffers messages in memory because someone made a wrapper function around sendAsync() and called it send(), that’s a code quality issue not a business issue (except as in the broader sense where every problem is ultimately a business issue).

Or if an engineer writes a naive implementation of some algorithm and adds a spinner so that an operation takes 5s to finish when it could be instantaneous if they’d thought about the problem more.

▲

sublinear 12 hours ago | parent [-]

I've heard this opinion a lot before, but in my experience there's a lot more dysfunction behind the scenes when stuff like that happens.

It's the same in other industries too. Someone designs and implements something properly and then it gets into the hands of product people who want to rip half of it out. The business then wants some much cheaper contractors to quickly make those changes without the original engineers involved. The result is a mess.

	▲	sarchertech 3 hours ago \| parent [-]
		I’m not going to disagree with you there. A bad engineering culture is usually ultimately caused by other factors. Many times that is just hiring bad engineers though. Such that even if business got out of the way, the engineers still wouldn’t make a quality product.