7 ms·

That intuitive feel of "what's faster" has been lost ever since computing power exploded. Back when the resources were at a premium, we were just better enginee

That intuitive feel of "what's faster" has been lost ever since computing power exploded. Back when the resources were at a premium, we were just better engineers. Not all of us had the command of Leetcode algorithm problems, but we rarely missed a database index and knew to stay close to the metal as much as possible, avoiding network trips, avoiding database trips. It still holds true today, and software has become bloated and slower because these simple rules are being ignored. It's all in the cloud, it's all distributed, it's all "free". As for Rails - it's the same problem but it's different. If you stay too high up in the abstraction orbit, it's hard to think of the nitty gritty of performance. What is the cloud doing? What is the ORM doing? Once it's all "magic", you just keep piling on non-performant crap until it becomes an emergency. Then you just add more cache :)

SketchySeaBeast 3y ago
I don't think it's necessarily abstraction, it's just complexity. We've been given a thousand footguns and we're expected to know how to use each one. You didn't consider microservices and lambda twenty years ago because they didn't exist. But you also didn't have to build an app that worked everywhere and looked good on every screen.
- deleted 3y ago
  [deleted]
- stabamole 3y ago
  There’s also the fact that we shouldn’t be thinking about problems the way they used to be solved - not that we shouldn’t be considering database calls and network, but because compute/memory/storage are cheaper than they used to be, we’re able to make more tradeoffs to save developer time or to improve experience. Back when the option was to further optimize how many registers your assembly is using or to leave an application in a virtually unusable state, you didn’t really have a choice. You optimized the small details
  - renegade-otter 3y ago
    Oh, compute and storage are cheap alright, until they are not. At many jobs I had to deal with the all-hands-on-deck, code red emergency "our AWS bill got too damn high, what can we cut" situation. I can guarantee you a ton of companies are going through this exercise right now. Some software engineers purposefully develop using fewer resources to force themselves to reason about efficiency. Abundance leads to complacency and laziness, and those resources are no longer cheap if you are abusing them.

SketchySeaBeast 3y ago

I don't think it's necessarily abstraction, it's just complexity. We've been given a thousand footguns and we're expected to know how to use each one. You didn't consider microservices and lambda twenty years ago because they didn't exist. But you also didn't have to build an app that worked everywhere and looked good on every screen.

deleted 3y ago
[deleted]
stabamole 3y ago
There’s also the fact that we shouldn’t be thinking about problems the way they used to be solved - not that we shouldn’t be considering database calls and network, but because compute/memory/storage are cheaper than they used to be, we’re able to make more tradeoffs to save developer time or to improve experience. Back when the option was to further optimize how many registers your assembly is using or to leave an application in a virtually unusable state, you didn’t really have a choice. You optimized the small details
- renegade-otter 3y ago
  Oh, compute and storage are cheap alright, until they are not. At many jobs I had to deal with the all-hands-on-deck, code red emergency "our AWS bill got too damn high, what can we cut" situation. I can guarantee you a ton of companies are going through this exercise right now. Some software engineers purposefully develop using fewer resources to force themselves to reason about efficiency. Abundance leads to complacency and laziness, and those resources are no longer cheap if you are abusing them.