The comment reads as ragebait or sarcasm but I actually can’t tell.
I don’t want to take away from Game developers but as a “corporate developer” I can attest that a lot of what you said about us is blatantly false.
I’ve spent a lot of time optimizing the performance of many backend services. This is a very standard practice. Having highly performant code can save companies a ton of money on compute.
In fact I’ve worked on a stateless web server who’s architecture was completely designed around a custom chunked/streaming protocol specifically to minimize latency. All changes to the service went through rigorous performance testing and wouldn’t be released if it failed certain latency and throughout thresholds.
Maybe you have optimized your stuff so far that you have to use Compiler Explorer to tell you how many cycles a change will cost you in a user transaction. I doubt you do, but maybe you do. Someone surely does this, somewhere. Maybe finance developers do this actually.
I’m sure there are enterprise devs who throw all industry “best practices” out the window, because they all seem to be designed specifically to slow your software down, but I’ve never even heard of anyone doing that.
Maybe you’re an enterprise developer who writes code in a very strongly data-oriented way, rather than strongly matching the objects in their code to the simple concepts the users think of when they’re using their software.
I honestly hope you are, because I’ve been dying to see that stuff happen ever since I became an enterprise software developer and saw how things are really written.
I have always worked with people who strongly prefer to write their things in JavaScript or Python, because anything else is “too hard.” I’m only slightly exaggerating with that. Very slightly.
In my experience in enterprise code nothing really matters except the DB. From a performance perspective. The amount of compute you can save in application code is peanuts next to a poorly written query or worse, a poorly designed data model.
I've seen code take 10 minutes (yes, really) to complete a request. Naturally that's 99.99% database time. The application code, which was C++, was nothing. If we switched to Java or even Python nobody would notice.
What made that request so bad was so simple, too. No pagination, no filtering. Instead, it was done in the application code. Yes, really, grabbing hundreds of thousands of rows and then filtering them in for loops and returning less than 100. Original code written who knows when (our source control only went back to 2011 so it's anyone's guess). Probably at some point grabbing all the rows didn't really matter. But then the table grew and grew and I'm sure it's scope grew, too, and suddenly the performance was unbelievably bad.
Anyway, if you can write half decent SQL you're already leaps and bounds ahead of most backend developers. Half of backend developers avoid SQL like the plague, and it leads to doing SQL-like things in application code, which is just asking to start a fire in the server room.
I remember a time when people in this field were in this field because they wanted to be in this field. They wanted to do a good job. They learned on their own time, and practiced on their own time. They brought those skills into their employer and used those skills to make things better.
Now we have people who view IT as a route to management, and nothing more. They do shit work. They do a lot of it. They don't care.
I long for the time I remember when people actually cared. I feel like I'm one of the remaining sane people in the world.
I don’t want to take away from Game developers but as a “corporate developer” I can attest that a lot of what you said about us is blatantly false.
I’ve spent a lot of time optimizing the performance of many backend services. This is a very standard practice. Having highly performant code can save companies a ton of money on compute.
In fact I’ve worked on a stateless web server who’s architecture was completely designed around a custom chunked/streaming protocol specifically to minimize latency. All changes to the service went through rigorous performance testing and wouldn’t be released if it failed certain latency and throughout thresholds.