ilitirit

Too little, too late. In fact, in this post they seem to be committing to keeping it as bad (or even making it even worse) for my use case.

I've used Windows since 3.1. Win 11 was the straw that broke the camel's back. I moved to CachyOS a few months ago and I honestly can't find a reason to switch back.

Can someone explain why LLM's write like this when most humans don't?

> Was he entirely wrong?

Yes. I mean... of course he was?. Firstly, I had already gone through this process with multiple LLMs, from various perspectives, including using Deep Research models to find out if any other businesses faced similar issues, and/or if products existed that could help with this. That lead me down a rabbit hole of data science products related to regulatory reporting of a completely different nature which was effectively useless. tl;dr: Virtually all LLMs - after understanding the context - recommended us doing thing we had already been urging the business to do - hire a Technical BA with experience in this field. And yes, that's what we ended up doing.

Now, give you some ideas about why his idea was obviously absurd:

- He had never seen the SP

- He didn't understand anything about regulatory reporting

- He didn't understand anything about financial derivatives

- He didn't understand the difference between Transact SQL and ANSI SQL

- No consideration given to IP

- etc etc

Those are the basics. Let's jump a little bit into the detail. Here's a rough snippet of what the SP looks like:

   SELECT
    CASE
    WHEN t.FLD4_TXT IN ('CCS', 'CAC', 'DEBT', ..... 'ZBBR') THEN '37772BCA2221'
    WHEN t.FLD4_TXT IN ('STCB') AND ISNULL(s.FLD5_TXT, s.FLD1_TXT) = 'X' THEN 'EUMKRT090011'
    END as [Id When CounterParty Has No Valid LEI in Region]
   -- remember, this is around 5000 lines long ....

Yes, that's a typical column name that has rotted over time, so noone even knows if it's still correct. Yes, those are typical CASE statements (170+ of them at last count, and no, they are not all equal or symmetric).

So... you're not just dealing with incredibly unwieldy and non-standard SQL (omitted), noone really understands the business rules either.

So again... yes he was entirely wrong. There is nothing "trivial" about refactoring things that noone understands.

I'm roughly the same (started at 9, currently 48), but programming hasn't really changed for me. What's changed is me having to have pointless arguments with people who obviously have no clue what they're talking about but feel qualified either because:

a) They asked an LLM

b) "This is what all our competitors are doing"

c) They saw a video on Youtube by some big influencer

d) [...insert any other absurd reason...]

True story:

In one of our recent Enterprise Architecture meetings, I was lamenting the lack of a plan to deal with our massive tech debt, and used an example of a 5000 line regulatory reporting stored procedure written 10 years ago that noone understood. I was told my complaint was irrelevant because I could just dump it into ChatGPT and it would explain it to me. These are words uttered by a so-called Senior Developer, in an Enterprise Architecture meeting.

I understand what this does. I don't get the hype, but there are obviously 1000s of people who do.

Who are these people? What is the analog for this corner of the market? Context: I'm a 47y/o developer who has seen and done most of the common and not-so-common things in software development.

This segment reminds me of the hoards of npm evangelists back in the day who lauded the idea that you could download packages to add two numbers, or to capitalise the letter `m` (the disdain is intentional).

Am I being too harsh though? What opportunity am I missing out on? Besides the potential for engagement farming...

EDIT: I got about a minute into Fireship's video* about this and after seeing that Whatsapp sidebar popup it struck me... this thing can be a boon for scammers. Remote control, automated responses based on sentiment, targeted and personalised messaging. Not that none of this isn't possible already, but having it packaged like this makes it even easier to customise and redistribute on various blackmarkets etc.

EDIT 2: Seems like many other use-cases are available for viewing in https://www.moltbook.com/m/introductions. Many of these are probably LARPs, but if not, I wonder how many people are comfortable with AI agents posting personal details about "their humans" on the net. This post is comedy gold though: https://www.moltbook.com/post/cbd6474f-8478-4894-95f1-7b104a...

[*] https://www.youtube.com/watch?v=ssYt09bCgUY

I had a lengthy argument about this in our architecture forum. I argued that "re-use" shouldn't be included as an Enterprise (keyword here) Architecture principle because they are clear use-cases where duplication is preferable to alternatives. e.g. deployment and testing decoupling etc etc. I had a lot of resistance, and eventually we just ended up with an EA principle with a ton of needless caveats.

It's unfortunate that so many people end up parroting fanciful ideas without fully appreciating the different contexts around software development.

> People need to stop making Meme distributions.

Heh. I've been saying that since I was on Mandrake in the early 2000s. This is just what the Linux landscape is like.

That said, I'm generally not easily impressed, especially by random *nix distro 347, but CachyOS is surprisingly good. I've finally switched full time from Windows. I don't even need VS anymore because Rider is x-platform.

After I read that emotive response I couldn't help but wondering if this wasn't part of a scheme to help someone cover up a crime. This is how I would have responded:

"Hi,

These do appear to be quite serious crimes. I've sent all the URLs, your email address, emails and responses to the relevant law agencies.

Regards, AdGuard"

These guys are quite well-known in China and have recently started uploading tto Youtube as well. Their videos are quite entertaining and have extremely high production value compared to many other creators.

https://www.youtube.com/@HTXStudio/videos

I love the one about the automated trash cans.

I'm referring specifically to the technique mentioned in that video. Yeah it's cool that it's there, but that doesn't seem intuitive at all.

I switched to iPhone from Android for a few months earlier this year. I don't think I qualify as an elderly person yet (I'm 47) but even I had trouble figuring things out. I don't think it was super-hard to use, but I often found myself asking "Why would they do it like this? Who uses a smart-phone like this?". I just found some things very unintuitive. Take for example re-arranging icons. I don't know if I would ever have figured out this technique without looking it up:

https://www.youtube.com/watch?v=pTdZLY9r4lg

I would recommend watching Curt Jaimungal's series of talks with Jacob Barandes. He gives a nice background history of various aspects of QM, including the formulation of Matrix and Wave mechanics (and loads of other ideas). Barandes is excellent at clearly articulating complex ideas in very simple, concise terms. He also has his own formulation of QM based on "Indivisible non-Markovian Stochastic Processes". Even if you disagree with his ideas, the interviews are quite fascinating.

In this interview he goes over pretty much exactly what you mentioned (and a lot more):

https://www.youtube.com/watch?v=7oWip00iXbo

I don't really have that much of an issue with vibe coding as an appropriate tool in experienced hands. I think the worst ideas in 2025 are probably related to IT execs pushing AI in the wrong ways, or people espousing vibe coding as some sort of software development panacea.

Pre-print of a paper which studied 1950 "transients" which - in tl;dr terms - might be evidence of artificial objects in orbit before the satellite era.

Recent comment from one of the main authors:

https://x.com/DrBeaVillarroel/status/1949780669141332205

Previous work: https://www.nature.com/articles/s41598-021-92162-7

> In that snippet are links to Postgres docs and two blog posts

Yes, that's what a snippet generally is. The generated document from my very basic research prompt is over 300k in length. There are also sources from the official mailing lists, graphile, and various community discussions.

I'm not going to post the entire outout because it is completely beside the point. In my original post, I expliclity asked "What is the qualitative and quantitative nature of relevant workloads?" exactly because it's not clear from the blog post. If, for example, they only started hitting these issues with 10k simultaneous reads/writes, then it's reasonable to assume that many people who don't have such high work loads won't really care.

The ChatGPT snippet was included to show that that's what ChatGPT research told me. Nothing more. I basically typed a 2-line prompt and asked it to include the original article. Anyone who thinks that what I posted is authoritative in any way shouldn't be considering doing this type of work.

What is wrong with you? Why would you even bother posting a comment like this?

Maybe you also don't know what ChatGPT Research is (the Enterprise version, if you really need to know), or what Executive Summary implies, but here's a snippet of the 28 sources used:

https://imgur.com/a/eMdkjAh

> The structured data gets written to our Postgres database by tens of thousands of simultaneous writers. Each of these writers is a “meeting bot”, which joins a video call and captures the data in real-time.

Maybe I missed it in some folded up embedded content, or some graph (or maybe I'm probably just blind...), but is it mentioned at which point they started running into issues? The quoted bit about "10s of thousands of simultaneous writers" is all I can find.

What is the qualitative and quantitative nature of relevant workloads? Depending on the answers, some people may not care.

I asked ChatGPT to research it and this is the executive summary:

  For PostgreSQL’s LISTEN/NOTIFY, a realistic safe throughput is:

  Up to ~100–500 notifications/sec: Handles well on most systems with minimal tuning. Low risk of contention.

  ~500–2,000 notifications/sec: Reasonable with good tuning (short transactions, fast listeners, few concurrent writers). May start to see lock contention.

  ~2,000–5,000 notifications/sec: Pushing the upper bounds. Requires careful batching, dedicated listeners, possibly separate Postgres instances for pub/sub.

  >5,000 notifications/sec: Not recommended for sustained load. You’ll likely hit serialization bottlenecks due to the global commit lock held during NOTIFY.

I'd like to see stats on how many people are getting arrested for petty crimes e.g. marijuana (which isn't even a crime in some contexts any more) back then vs now.

I currently have a big problem with AI-generated code and some of the junior devs on my team. Our execs keep pushing "vibe-coding" and agentic coding, but IMO these are just tools. And if you don't know how to use the tools effectively, you're still gonna generate bad code. One of the problems is that the devs don't realise why it's bad code.

As an example, I asked one of my devs to implement a batching process to reduce the number of database operations. He presented extremely robust, high-quality code and unit tests. The problem was that it was MASSIVE overkill.

AI generated a new service class, a background worker, several hundred lines of code in the main file. And entire unit test suites.

I rejected the PR and implemented the same functionality by adding two new methods and one extra field.

Now I often hear comments about AI can generate exactly what I want if I just use the correct prompts. OK, how do I explain that to a junior dev? How do they distinguish between "good" simple, and "bad" simple (or complex)? Furthermore, in my own experience, LLMs tend to pick up to pick up on key phrases or technologies, then builds it's own context about what it thinks you need (e.g. "Batching", "Kafka", "event-driven" etc). By the time you've refined your questions to the point where the LLM generate something that resembles what you've want, you realise that you've basically pseudo-coded the solution in your prompt - if you're lucky. More often than not the LLM responses just start degrading massively to the point where they become useless and you need to start over. This is also something that junior devs don't seem to understand.

I'm still bullish on AI-assisted coding (and AI in general), but I'm not a fan at all of the vibe/agentic coding push by IT execs.

100%. YouTube is a chapter in a textbook about how to destroy UX.

I actually cancelled my YT Premium sub after this latest change with the thumbnails. I realised it doesn't really offer me that much value, and often using the platform just annoys me.

Here's some of what I think is my personal best advice:

Learn to live in the gray areas. Don't be dogmatic. The world isn't black and white. Take some parts of the black and white. And, don't be afraid to change your mind about some things.

This may sound obvious to some of you, and sure, in theory this is simple. But in practice? Definitely not, at least in my experience. It requires a change in mindset and worldview, which generally becomes harder as you age ("because your want to conserve the way of life you enjoy").

It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel.

Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin?

And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture.

It's super-frustrating when I'm dealing with people in a professional setting and they're quick to point out something they read in a book, or even worse - a blog - with very little else to add.

This was especially bad during the NoSQL and Microservice hype. Still somewhat feeling it with PAAS/SAAS and containerization. We have so many really really basic things running as Function Apps or lambdas, or simple transformations running in ADF or Talend that add zero value and only add to the support and maintenance overhead.

Always keep in mind that sometimes the only difference between yourself and the person writing the book/blog/article is that they actually wrote it. And that their opinions were written down don't make them fact. Apply your own mind and experience.

> I think what we're attempting to define is something closer to seasoned developer.

I'm fully aware of that, which is why "Senior" is in double-quotes, but experienced (aka "seasoned") is not. My point is that you can be seasoned at delivering bad products. The point about seniority just speaks to tenure at a company. Sure, you can join a company as a "Senior dev", but that's not quite what I'm referring to here. One would think that they would be exposed during the interview process, but alas, we all know that's often not the case.

Hard to disagree. I can usually tell what type of type of experience devs have by the snarky, dismissive responses I've gotten on various internet forums over the last two decades. e.g. "Oh but you would never have this problem if you performed proper code review" - Random_Rockstar_Dev_254

However not all legacy projects are bad to work on. If they're decently developed, then often you'll find that most of the pain is in setting up your local codebase. e.g. sorting out make files, or header file clashes etc. And if you're lucky, some poor bastard has already done the hard work for you.

As an aside, I know tons of experienced "Senior" developers who just suck at their jobs. The problem is they have tons of experience in delivering terrible products based on terrible code and architectural decisions. They just never had anyone to show them any better. And now that they're "Senior", noone can tell them anything. Many devs who work in corporates understand this pain. Shoutouts to my peers who have to "fix" 3000 line stored procs with a 100 line "change control comment saying stuff like "2009-04-03 JS Added TAX_REF_ID". I live your pain.

EDIT: Also, if you happen to work at company that thrives on terrible legacy products, try to drill it into their heads that BAU Support is not part of the solution. Every time I've raised the issue of the mounting tech debt I've gotten the response "Business does not have the apetite to solve these issues. And why would they? That's why we have support teams".

I have used a myriad of programming languages in production in my nearly 25 years of professional programming. There are things I love (almost never "hate") about most languages.

But the reason C# is one of my favourite languages to code in professionally is simply because of how easy it is to setup the environment and just get to work. Admittedly on Windows, but I've learned over the last 5 years it's a pretty simliar experience on Linux too. No messing with environment variables or paths; no header file wrangling; no macro shenanigans; no messing with virtual memory settings etc etc etc.

Yeah, I get it. Choice is nice. But when it comes to my job what's most important is that I can just get to work.

> give feedback to such a person will get you this response: "you need to earn trust and learn to disagree and commit"

Sure, but you won't get fired, right?

Even so, this is just about dealing in general with people who have ego (for the sake of brevity) issues. I don't understand why this should be advice for dealing with senior leadership in general.

This title of my article doesn't make much sense to me. Why would you get fired for giving feedback? Is this just a US thing? I give feedback to my superiors all the time, and expect my subordinates to do the same. In fact, as far as my team goes, you're more likely to get into trouble (not fired) if you rarely give feedback.

I'm dealing with related issues at work right. Leadership is beating us over the head with the "innovation" hammer, without any consideration why and where they want to innovate. This mandate is a recipe for disaster in the hands of inexperienced tech-leads.

For example, there was an initiative to move from Talend to Azure Data Factory. Devs had to upskill, and it took them several months to deliver something that fails intermittently (with a huge cost behind it), and noone knows how to fix it.

I rewrote the pipeline in 2 hours (as simple Windows Service that parses a file and writes data to a DB), and polished it in around a day or so. Added some informative and error notifications, and we immediately saw benefits.

Innovation is fun, but some things just don't really need much of it. We've known how to do stuff like ETL for decades. We really don't need cloud-hosted solutions behind client secrets and gated services to load data into a DB.

Ironically, my boring solution seemed more "innovative" because users can now get customised notifications in different Teams Channels.

"Boring"/"exciting" tech isn't stifling or improving anything. These are orthoganal issues. Innovation can emerge from boring tech.

I bet he could care less.

I've always thought that people misunderstood nonplussed because they interpret it as "not fussed".