Thank your for posting this. I disagreed with OP but couldn't _quite_ find the words to describe why. But your post covers what i was trying to say.
I was quite literally asked to implement an in-memory cache to avoid a "full table scan" caused by a join to a small DB table recently. Our architect saw "full table scans" in our database stats and assumed that must mean a performance problem. I feel like he thought he was making a data-driven profiling decision, but seemed to misunderstand that a full-table scan is faster for a small table than a lookup. That whole table is in RAM in the DB already.
So now we have a complex Redis PubSub cache invalidation strategy to save maybe a ms or two.
I would believe that we have performance problems in this chunk of code, and it's possible an in-memory cache may "fix" the issue, but if it does, then the root of the problem was more likely an N+1 query (that an in-memory cache bandaids over). But by focusing on this cache, suddenly we have a much more complex chunk of code that needs to be maintained than if we had just tracked down the N+1 query and fixed _that_
Yeah, I interpret "premature optimization" as taking a request that takes 500ms and focusing on saving a couple ms by refactoring logic to avoid a SQL JOIN or something.
Your users are not going to notice. Sure, it's faster but it's not focused on the problem.
My friend once told me an analogy about modern software engineering that went something along the lines of the following.
There are piles of money just sitting around waiting for someone to pick them up. Unfortunately it's really hard to do because the piles are scattered around and hard for any one person to pick up.
So the best way to coordinate picking up all of these piles of money is to figure out how to convince a bunch of people with autism spectrum disorder to program machines to do it for you.
In this analogy you can get rich by doing one of a few jobs:
* Finding the piles of money (sales)
* Coding robots to pick up the piles of money (engineering)
* Coordinating the above two in come capacity (management)
AI certainly makes it less lucrative to pick up some of these piles because there will be more people picking them up. But will probably also be the case that it will let us pick up piles of money we didn't even know existed before. Or ones that we knew about but were hidden deep inside of sprawling caves that were intractable to search before.
If it turns out that we don't need any coordination to pick up these piles any more, then pretty much everyone is out of a job. Not just software engineers, but pretty much every white collar job. Once that's done it'll only be a matter of time before they can automate away the blue collar jobs, too.
I guess I'm just skeptical that we'll actually automate away all of the white collar jobs.
Generally, when someone says something like "left wing groups" they mean something with a formal organization.
"Antifa" is less of an organization than even some loose collective like "anonymous"
Are there left-wing agitators? Sure, black bloc and other "direct action" protestors have been around since at least the world trade protests in the 90s.
But to the best of my knowledge there isn't really a formal "antifa" organization to dismantle or anything.
> all i know about these LLMs is that even if they understand language or can create it, they know nothing of the subjects they speak of.
As a recent example of this, I was recently curious about how the heart gets the oxygen depleted blood back to the heart. Pumping blood out made sense to me, but the return path was less obvious.
So I asked chatgpt whether the heart sucks in the blood from veins.
It told me that the heart does not suck in the blood, it creates a negative pressure zone that causes the blood to flow into it ... :facepalm:
Sure, my language was non-technical/imprecise, but I bet if I asked a cardiologist about this they would have said something like "That's not the language I would have used, but basically."
I don't know why, but lately I've been getting a lot of cases where these models contradicts themself even within the same response. I'm working out a lot (debating a triathlon) and it told me to swim and do upper body weight lifting on the same day to "avoid working out the same muscle group in the same day". Similarly it told me to run and do leg workouts on the same day.
> i do like it as a bit of a glorified google, but looking at what code it outputs my confidence it its findings lessens every prompt
I'm having the exact same reaction. I'm finding they are still more useful than google, even with an error rate close to 70%, but I am quickly learning that you can't trust anything they output and should double check everything.
I was quite literally asked to implement an in-memory cache to avoid a "full table scan" caused by a join to a small DB table recently. Our architect saw "full table scans" in our database stats and assumed that must mean a performance problem. I feel like he thought he was making a data-driven profiling decision, but seemed to misunderstand that a full-table scan is faster for a small table than a lookup. That whole table is in RAM in the DB already.
So now we have a complex Redis PubSub cache invalidation strategy to save maybe a ms or two.
I would believe that we have performance problems in this chunk of code, and it's possible an in-memory cache may "fix" the issue, but if it does, then the root of the problem was more likely an N+1 query (that an in-memory cache bandaids over). But by focusing on this cache, suddenly we have a much more complex chunk of code that needs to be maintained than if we had just tracked down the N+1 query and fixed _that_