MangoCats

Copilot sneaking in is really obnoxious, and common.

I just tried this prompt on Gemini and it worked really well:

Give me search results like a 1999 Google search on the content of the modern web for: "your search terms here"

YouTube banned me about 11 years ago. I can say: I don't miss it.

I've moderated a subreddit for about 15 years now, it's built up to ~40K members and ~100K visitors per week, ~1M views per month, and over 95-99% of that traffic is mobile (varies by the day). New Reddit (desktop) runs 0.5-3%, and old.reddit doesn't even register in the bar graphs. Still, my shortcuts all go to old.reddit.com - and not just for moderation, but it's also how I browse reddit.com.

If they cut off my old.reddit.com interface, I'll likely abandon my moderator's post - no telling what happens to that community after that happens.

cloudflare

For IR you can feasibly run IR dazzle lights all over whatever you want to mask, including your face.

So, first, it sounds like leaving that job was an upgrade...

I interviewed with a similar company, they had a 3 month average turnover in their software development department. They declined to hire me because "you're over-qualified, you'll just get a better offer and then leave us." True enough, but that might take years, is very unlikely to happen in the next 3 months and by that point I'm beating your average... I think what they were really afraid of was that I might corrupt their culture and actually teach their developers how to fix problems instead of patching them and quitting. Getting their software patched to fix problems also seemed to be perversely ingrained in their sales / support culture - I don't think sales there wanted software that "just works."

Over the years, I have done my best to avoid database and network... both seem to be an invitation into a hell of others' makings. I prefer my own hells to others'.

Whoever put code into ovens and decided we shouldn't be allowed to buy ovens without code really needs to be taken to the woodshed...

It's just like the oldest profession, you're paid to scratch an itch - make someone happy. They rarely care about exactly how or why you're doing it, just that you do it.

code was always written only once

What universe do you live in? My whole life has been modifying code. I may spend 20% of my time on "greenfield" writing of new code, but the rest is modifying other people's code, modifying my own code, explaining to people how my and other peoples' code works so they might modify it.

Writing code with LLM centric way and just focusing the high level gets hazardous pretty quickly, since somebody actually needs to understand the codebase deep down (or at least the relevant part) when something goes wrong.

In my industry we spend a significant amount of effort to ensure that "something goes wrong" before we ship, rather than after. Of course, we're only human, bugs do ship, but they're relatively rare - and field fixes get 10x the scrutiny of the already heavily scrutinized greenfield code.

For the past 6 months or so, I have come to respect LLMs' ability to find more bugs earlier in the process - doesn't matter if the code is written by people or LLMs, bugs happen. LLMs don't find them all, but people find even fewer.

The other thing LLMs are starting to excel at is verifying that the documentation says what the code does, and the code does what the documentation says. Docs out of sync with code has been the bane of my past 3 decades, and before that I just didn't write a lot of docs.

I consider myself as a seasoned programmer.

Is that hot pepper, salty, or both?

Interesting thing I see is that LLM slop generators are actually quite efficient at generating documentation, both for the end users and for developers, and like human generated slop-docs, the more cycles you put into review and refinement of them (both human guided and LLM self-review/refinement) the better quality you get out. Investing even half the person-hours in LLM generated documentation generates higher quality, more complete, better organized and more readable documentation for me than "working with a team" of writers who all have to meet and re-meet and explain and re-explain ad-nauseum until we're all sick of the process and late for delivery of the documentation products.

When this documentation investment is made in the code, some remarkable things come out like: a project co-developed with Claude in Python took 10 interactive days to make. At the end, the Python was performing fine but a little on the noticeably slow side, so the LLM was told "do it again in Go" and 3 days later with very minimal prompting, the whole thing was re-implemented in Go, running 10x faster, and flawlessly performing the same functions which were developed in Python in 10 days - I believe precisely because a significant part of the Python project was: documentation of requirements, design specifications and automated tests.

The interesting thing, to me, is how much/little architectural level design matters depending on the complexity of the system you have built, and the longevity of its maintenance in the field.

I watch things get built with bad architectural compromises for what appear to be bad reasons all the time, and they rarely "come home to roost" until years later... then the question becomes: was the implemented design a success for having gotten to market quicker and lasted so long without serious problems, or a failure for having created a mess 5 years down the road that could have been addressed with a 5 day delay of launch for a refactoring? Or, should we instead spend 5 weeks attempting to predict the optimal architecture before we even start and maybe get a good solution or maybe still end up learning things we didn't know during early development - and when we learn those things down the line from the initial architecture specification, when it it time to slaughter the sacred cow and re-arrange things?