zlacker

>>jinhku+(OP)
First you must accept that engineering elegance != market value. Only certain applications and business models need the crème de le crème of engineers.

LLM has been hollowing out the mid and lower end of engineering. But has not eroded highest end. Otherwise all the LLM companies wouldn’t pay for talent, they’d just use their own LLM.

>>monero+M9
I keep hearing this but I don’t understand. If inelegant code means more bugs that are harder to fix later, that translates into negative business value. You won’t see it right away which is probably where this sentiment is coming from, but it will absolutely catch up to you.

Elegant code isn’t just for looks. It’s code that can still adapt weeks, months, years after it has shipped and created “business value”.

>>WD-42+7f
> I keep hearing this but I don’t understand. If inelegant code means more bugs that are harder to fix later, that translates into negative business value.

That's a rather short-sighted opinion. Ask yourself how "inelegant code" find it's way into a codebase, even with working code review processes.

The answer more often than not is what's typically referred to as tech debt driven development. Meaning, sometimes a hacky solution with glaring failure modes left unaddressed is all it takes to deliver a major feature in a short development cycle. Once the feature is out, it becomes less pressing to pay off that tech debt because the risk was already assumed and the business value was already created.

Later you stumble upon a weird bug in your hacky solution. Is that bug negative business value?

>>lockni+Ph
Of course a bug is negative business value. Perhaps the benefit of shipping faster was worth the cost of introducing bugs, but that doesn't make it not a cost.

>>lmm+6j
If a bug is present but there is no one who encounters it, is it negative business value?

>>anonzz+6l
That’s not how this goes.

Because the entire codebase is crap, each user encounters a different bug. So now all your customers are mad, but they’re all mad for different reasons, and support is powerless to do anything about it. The problems pile up but they’re can’t be solved without a competent rewrite. This is a bad place to be.

And at some level of sloppiness you can get load bearing bugs, where there’s an unknown amount of behavior that’s dependent on core logic being dead wrong. Yes, I’ve encountered that one…

>>coffee+Qn
> That’s not how this goes.

Once you gain some professional experience working with software development, you'll understand that that's exactly how it goes.

I think you are failing to understand the "soft" in "software". Changing software is trivial. All software has bugs, but the only ones being worked on are those which are a) deemed worthy of being worked on, b) have customer impact.

> So now all your customers are mad, but they’re all mad for different reasons, and support is powerless to do anything about it.

That's not how it works. You are somehow assuming software isn't maintained. What do you think software developers do for a living?

>>lockni+YI
Nothing I just described was hypothetical. I’ve been the developer on the rewrite crew, the EM determining if there’s anything to salvage, and the client with a list of critical bugs that aren’t getting fixed and ultimately killed the contract.

If you haven’t seen anything reach that level of tech debt with active clients, well, lucky you.