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.
I use Neovim exclusively for the past 4 years or so. Before that I used WebStorm + sometimes Vim for another 6 years or so. To this day I'm thankful to my colleague and mentor, who introduced me to the basics of Vim (you know, how to quit it and all that) saying "it get's pretty handy when you need to edit something on the server"; that was probably around 14 years ago.
WebStorm was great, it was really magical how it just knows how this or that code relates to another piece of code, navigating around was a bliss. Where is that variable defined? Jump to definition, and you're there. You want to know what's that function does, even if it's somewhere in third-party libraries? No problem, jump to definition.
The fuzzy-finder for everything (literally. From file names to methods to editor's commands and variables) was also amazing.
At some point though I got a bit annoyed with the fact that it took 5 seconds to start it up (multiply that by amount of different projects you need to open), and it's general resource hungry-ness. So I started experimenting with Neovim 0.3 (at the time), and pretty quickly managed to get near-webstorm experience with gutentags, fzf and amazing vim-fugitive for all the git things I did in the command line.
And with resent native lsp & treesitter, it doesn't
I tried VSCode once, which was a fiasco -- for some reason it failed jumping to definition in a basic react project with typescript. Oh well.
Helix looks really cool, I'm playing around the idea of using it more, though I still will have to keep (Neo)vim around for vim-fugitive. Slightly concerned with how much muscle-memory re-training will needed though, then again it didn't took me too much to get to the same level of ease of use with Doom Emacs.
Speaking of which, it worked flawlessly (and has even better git tool), but still was terribly slow at times, so in the end got too annoying to work with.
So in the end it boils down to Neovim being fast, not getting in the way, and habit, I guess.
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).