MangoCats

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?

Code is the God in the machine.

Then God has no soul.

Yes, code defines what happens, how it happens. But what defines what the code is intended to do? Where is the intelligent design? You can wire up a bunch of relays with intelligent design, simple electrical work, define gates, build the gates into memory registers and arithmetic processing stages, make a CPU - but… are you any closer to achieving the goal for having done all that work?

Are you better off for having a hands-on deep understanding of the machine from electrical first principles, or does the warehouse full of circuits and wires and the power it consumes outweigh that benefit?

If you use a modern processor do you need to have hands-on the assembly code? Do you need to deconstruct and understand every stage of the compilers and linkers and optimizers? In the 1990s I did, because those stages weren’t reliable enough, yet.

There’s nothing different about “deterministic code” built on layers and layers of tools today than there was about assembly code built on the processors before than there was about assemblies of modular circuits that form processors and memories and peripherals… it’s all parts of the system. And for critics of the “unpredictability” of LLM code generation, you might want to look into the mysteries of “garbage collected” languages.

If I eventually stop writing C or Rust or Go or Python or Javascript or any of the other hundreds of common choices of languages out there and instead learn to feed a LLM with instructions that generates the Rust that generates the Assembly that drives the CPU that manipulates the electron flows - that doesn’t change the intelligent design of: making a thing do what it is intended to do.

I think it was when we started organizing into walled cities surrounded by agricultural lands… that was really conditioning to a miserable way of life (for most, benefitting only a few) that carries through all the way to today.

In the early 1900s the Collier family made themselves a big pile of money and bought what later became Collier County, Florida. Pretty much all of it was privately owned by them, along with a collection of every type of Porsche ever made and a bunch of other “gee, what can I do with ALL this money” activities… Property taxes encouraged them to sell the land off and now what once was a private family “farm” about 100 years ago is now home to over 400,000 people.

At least we’re not burning dead dinosaurs (and plankton) to deliver dead trees.

Are you sure? Co-dependent symbiotic relationships evolve in nature all the time - starting at the macro scale with plants and animals.

I think the bot traffic is the open mesh.

Free versions already do this. If you pay for enough tokens they can also do the real work and generate summaries better than your average human docu-drone.

Well, the old “web of links” still works, if people valued that enough to put the effort into it it could continue to thrive and grow…

Your DNS style distributed reputation system needs one fundamental foundational element to have a chance at providing any kind of value: reliable/secure author identity. PGP and signed documents have been available through standard formats for 30+ years, but almost nobody has adopted that kind of identity for mainstream publication and consumption. Until they do, reputation is going to be chaoticly fluid, unreliable and trivial to hijack/poison.

A big place with very varying “special needs” ranging from none all the way through fully supported living.

There’s no “LLM native language” to convert to for efficiency.

Yet. With 1000x as much bot-content being generated on the web as human generated content, the “bot spoken” training set will grow rather quickly, and I see no reason for it not to evolve in a similar way to how human spoken languages evolve.

Example of something I had to lookup to understand: (/hj)

Back when I was in school, Autism was a 1/10,000 Dx. 20 years ago it was crashing down from 1/100 to 1/50, checking now… 1/31 today. They’ve lumped so much into the Autism diagnosis that it’s meaningless anymore; it covers so many varied conditions and severities, and the stereotypes don’t fit most recipients of the Dx anymore.

I used to pay $10 per month for my “minimal hosting” - that inflated to nearly $15 across the decades. Then I switched to a modern host provider, now my bills are $0.02 per month for the exact same functionality that used to cost a minimum of $10.

http/https works as well as it ever did, it’s just that the overwhelming quantity of new sites have gummed it up for their own purposes.