Yeah and they’re typically fired for incompetence, or their startup fails, or their product flounders but that’s okay because the company doesn’t need the product to actually be successful.
Meanwhile, the people who work on actual products that matter have a valid criticism that can’t be dismissed with “some humans don’t even manage to do that.”
Yes, including myself in the past. I’m grateful to be out of that situation.
Probably a vast majority of software written never actually gets interacted with by a user. A vast majority of VC-funded software probably never gets interacted with by a user.
Feels pretty great to work on a product that actually has a user, and that user isn’t actually the product (and that user isn’t being manipulated or exploited). Tiny, tiny minority of the software industry I work in.
That does not sound right, I would guess the most code is in enterprise and business applications and people have to use it no matter how bad it is. I would guess only a tiny fraction of code - besides hobby projects - ends up in the trash without ever having users.
I’m coming from the angle that the majority of software written is internal or B2B rather than B2C, and that most critical B2B software features are hammered out in the first couple of years of development while the remaining development cycles are for niche requests to maintain specific clients who don’t actually know what they want and then don’t end up resubscribing / even using the feature.
If you don’t think about it as a per-software criteria, but per-feature criteria, the vast majority of software features developed are probably completely ignored or even untouched compared to the “critical few”.
Very, very long tail distribution. The most executed 100 lines of code (maybe some Java class init snippet, or some Linux kernel snippet) is probably executed more per day than the per-day bottom 80% of all code combined. Maybe the bottom 99.9% of all code combined.
But that is generally true, most things in the real world have a few common cases and a lot of rare exceptions, so every software dealing with the thing will have a hot path and many additional paths that are rarely or maybe never executed. Or look at large applications like Excel, Photoshop or Blender, they have a million features but most user will probably never use even a single percent of them.
If you would fire all incompetent [1] software developers, there would be almost nobody left.
[1] There is probably a more fitting word, I am just reusing incompetence here, but that is not a really fitting description, I think. I would maybe say carelessness or something like that, but a single word is not going to capture the issue accurately.
Same with pretty much any other profession. Hunting for reliable and reasonably-priced HVAC, plumbing, handymen, etc. is a part-time job.
But the point OP was trying to make is that because LLM harnesses output code that is at least better than the worst, say, 20% of developers then we should be fine with it. Meanwhile, I’ve worked in shops where you have to be way above the worst 20% in order to keep your job or even be hired in the first place. And it isn’t some crazy lose-sleep-over-it, stressful requirement. It’s just that literally if you’re not good enough your work will be identified as a liability and you’ll be let go. It’s only happened to 3 people fwiw.
I think crappy code that looks like crap, is better than good looking code that is actually crap if someone cares to look..at least it can be fixed early.
LLMs commit crap, and read the "pattern" back, and consider it as gospel and repeat it all across the code base...
