So 500 people leave for office and turn off the heating at their homes, even if there are other people (kids, elderly) or animals (cats, dogs, birds) living there?
Kids are at school during office hours, I'm not sure about pets but they I don't think they care whether the house is 23° or 16° considering most of them go outside without any issue.
I mean, I've seen enough "django specialists" to end up with queries doing a dozen of join bombs and producing 10 million rows from dataset of maybe 1000 items. So pretty safe to add "ORM" to your last statement.
It was also highlighted (recently?) iirc that it has little to do with discipline and will-power, but is surprisingly affected whether kids come from wealthy / "good" families (and thus can trust grown ups) vs kids coming from poorer / "troubled" families (and thus just leap at the opportunity and don't trust that they will actually get another marshmallow if they will wait).
Sorry to hear your situation, but that doesn't really sound like it's LLM's (a tool in the end) fault, more that poor ways of working are a norm in company you work at. Not much would change if you replace "LLM" with "Consultancy" in your post.
And it's hard to really connect the dot between "generated by llm" and "slow" -- code performance doesn't really depend on whether it's being generated or typed out.
It’s trivial to alter or remove log lines without knowing or realizing that it affects some alerting or monitoring somewhere.
That’s why there are dedicated monitoring and alerting systems to start with.
If you need an artifact from your system, it should be tested. We test our logs and many types of metrics. Too many incidents from logs or metrics changing and no longer causing alerts. Never got to build out my alert test bed that exercises all know alerts in prod, verifying they continue to work.
I worked in a company, where webapp bundle was 8 megs (so close to 2 megs compressed). Upon brief investigation turned out that it was lottie library (~2 megs) + 4 animations, all of which were shown only to first time users.
Managed to get rid of two animations, and put another two together with lottie thing istelf into lazy loading. Still, I consider that battle lost rather than won, because I couldn't really convince the designer or other developer why having 8 megs for a bundle is a bad thing.
Being on call is firemen job, and they do have shifts.
In most of the companies you have something akin to construction workers that work from 9 to 5 and then also are expected to be available to do casual firefighting from 5 to 9 because it's "easier".
At a certain scale mature software companies do in fact have dedicated incident managers, and dedicated SREs who work primarily on stability from a more systematic perspective. However they still need support from the application developers due to the nature of software.
In the old days operations tended to be very isolated in much the way you are proposing. The problem with this is that stability depends very much on the software, so over time operations folks would be extremely defensive and impose all kinds of constraints on what software could do, and the software engineers would be frustrated that they couldn't do things efficiently. Imagine how firefighters would feel if construction workers had a tendency to randomly leave explosives and gas cans hidden throughout new construction and then waltzed off to the next job while the firefighters had to deal with the consequences.
At the end of the day, devs need to have some skin in the game or it's a recipe for disaster.
The "skin in the game" argument is, IMO, not compelling. It is clearly possible to have stable software services delivered by separate Dev and Ops teams that communicate using a will defined software interface -- look at any app that uses Heroku or a similar PaaS.
But, as we know, useful software interfaces are difficult to define well and, once they exist, they tend to be the most inflexible part of a fast-changing system. It is always better (though of course more expensive) to control both sides of an interface for this reason.
The "skin in the game" argument elides this fundamental reason and substitutes one that implies all of this is the fault of lazy devs, which isn't (generally) true IME.
This argument doesn't hold water. Both Heroku and teams that run apps on Heroku have their own on-call teams. Yes, you can build stable interfaces and separation of responsibilities between infra and business services, but someone still has to be responsible for the business services stability.
Right but I meant my point to be that the people on call don't have to be literally the same people developing the application code. In fact, they never have to communicate at all, because they can coordinate at arms-length with a well-defined software interface.
Edit: I missed the part where you say the Heroku customer has their own on-call team. IME this is not true. The whole reason to use a PaaS like this is to avoid having an Ops team. Sometimes orgs outgrow their PaaS and keep using it anyway, but this isn't necessary, only a historical artifact. These orgs would likely save more money and get a better result by going with normal IaaS or racking their own servers and, in fact, are probably actively switching to that model.
The juxtaposition of "this is how it's done because otherwise those that fight fires impose restrictions that those that build don't like" and "construction workers Vs firefighters" seems to be undermining your point...
In mature industries, there absolutely are plenty of regulations in place to make sure that builders don't make responders' life harder. That doesn't mean that the responders aren't needed, but the fact that the software industry as a whole decided to go all "response is the only thing we need for most things" is evidence that it is not mature.
Because it's not a text organised into sections, paragraphs and whatnot with html, it's just a plain text file rendered into one big paragraph with whitespace set to `pre` ¯\_(ツ)_/¯.
It's arguable whether this is better or worse, because now you'll have the text wrapping where needed _but also_ again where it would have on a wider viewport, even though it already wrapped. So on mobile you'll have a full line, then half a line, then a full line, then half a line, and so on, wrapping alternatingly at the natural edge of the viewport, and again at the original line end terminated by a line break.
It probably changes from person to person, but while I find wrapping like that harder to read than seeing it all normally, for code it is still much better than scrolling back and forth for every line.
