3 ms·

IMO it's unfair to blame the developers. Almost every developer I know loves working on performance stories. It's one of the few times we get to use our deeper

IMO it's unfair to blame the developers. Almost every developer I know loves working on performance stories. It's one of the few times we get to use our deeper technical and algorithmic skills and get a clear metric to optimize for. However, businesses are reluctant to prioritize that work and get impatient when they don't see new "features". I worked on a project where PMs would constantly complain to me about a particular admin page being slow. I wrote a ticket for them that would implement some optimizations (simple pagination and SQL optimizations) and asked them to prioritize it. They had time to complain every chance they got, but the ticket never got prioritized. I eventually got so sick of the complaining that I just took a Saturday morning and did it.

runevault 4y ago
I dunno, I run into a lot of devs on reddit/here/etc that argue "who cares about performance just spin up more containers! I just wanna write {insert slow interpreted language here}."
- ajmurmann 4y ago
  The slowness of interpreted languages is frequently not the main culprit for slow performance though. Most load times in web apps I've worked on usually were spent doing inefficient or unnecessary DB queries or API requests.
  - runevault 4y ago
    This is the claim but it isn't necessarily true as often as it is claimed. If it was how would Stack overflow back in the .NET framework days have managed on I think 2 web servers plus a failover on the massive amount of traffic they do while also being responsive. There's 0 chance a python/ruby/etc web app could have done the same thing. And to think they could theoretically use less CPU and RAM on the same workload now running in .NET 6 which is dramatically more efficient than 4.x Framework.
  - lkbm 4y ago
    Almost every single time I've had to deal with something being slow in the Python web app I work on, it's been a bad query, or bad ORM usage spawning thousands of additional queries to pull in relations. I've seen a couple out-of-memory deaths (mostly non-paginated db queries, but compounded with the inefficiency of py2), and occasionally an accidentally quadratic loop (which would be faster in C, but usually can just be made fast in Python with more thoughtful code), but it's almost always the DB—oops, I need to add an index, oops I did a cross join, oops, I'm spawning additional 10 queries for each row returned. The time spent in Python on a slow endpoint is usually negligible.
- pixl97 4y ago
  I think you're reading that the incorrect way, though it's hard to say. This is my take on it Dev: I get paid for writing features. I can write new features faster in {insert slow interpreted language here}. Also if the company is of any size, whatever they write has to fit in the rest of their CI/CD stack and pass whatever kind of code review the company does or doesn't implement. So yea it's easy to say devs suck (and they do), but without looking at the entire process they are involved in it can be very hard to qualify why they suck and where the suckage comes from.

runevault 4y ago

I dunno, I run into a lot of devs on reddit/here/etc that argue "who cares about performance just spin up more containers! I just wanna write {insert slow interpreted language here}."

ajmurmann 4y ago
The slowness of interpreted languages is frequently not the main culprit for slow performance though. Most load times in web apps I've worked on usually were spent doing inefficient or unnecessary DB queries or API requests.
- runevault 4y ago
  This is the claim but it isn't necessarily true as often as it is claimed. If it was how would Stack overflow back in the .NET framework days have managed on I think 2 web servers plus a failover on the massive amount of traffic they do while also being responsive. There's 0 chance a python/ruby/etc web app could have done the same thing. And to think they could theoretically use less CPU and RAM on the same workload now running in .NET 6 which is dramatically more efficient than 4.x Framework.
- lkbm 4y ago
  Almost every single time I've had to deal with something being slow in the Python web app I work on, it's been a bad query, or bad ORM usage spawning thousands of additional queries to pull in relations. I've seen a couple out-of-memory deaths (mostly non-paginated db queries, but compounded with the inefficiency of py2), and occasionally an accidentally quadratic loop (which would be faster in C, but usually can just be made fast in Python with more thoughtful code), but it's almost always the DB—oops, I need to add an index, oops I did a cross join, oops, I'm spawning additional 10 queries for each row returned. The time spent in Python on a slow endpoint is usually negligible.
pixl97 4y ago
I think you're reading that the incorrect way, though it's hard to say. This is my take on it Dev: I get paid for writing features. I can write new features faster in {insert slow interpreted language here}. Also if the company is of any size, whatever they write has to fit in the rest of their CI/CD stack and pass whatever kind of code review the company does or doesn't implement. So yea it's easy to say devs suck (and they do), but without looking at the entire process they are involved in it can be very hard to qualify why they suck and where the suckage comes from.