4 ms·

I just don't think this meshes with any of my experience talking with people who work at places like Google. Your argument keeps being "but Google is bad and wh

I just don't think this meshes with any of my experience talking with people who work at places like Google. Your argument keeps being "but Google is bad and what it makes is useless, therefore the code behind it is terrible and made by people who can't think". Working at places with a lot of tech debt, or where you're creating tech debt knowingly is just the state of the industry at almost every company. I've never met a developer who doesn't see that, let alone "most technical people". This entire thread is full of current and ex-Google employees saying essentially "Yea, this is probably because of tech debt and sprawl". If you deigned to go work at Google some day, it's not as if you'd be able to just untangle all of it with a few bash scripts even if they made you King of Google. I have no love for Google's products myself, but it's mystifying to me when you let your clear distaste for some of their decisions and priority cloud your view of what they've created and maintain. When was the last time Google Search or Gmail was unreliable for more than an hour? Maybe once in the last 2 years? That doesn't even come close to any objective measurement of "quite poor ... reliability". Even if you and I seemingly don't like their services, it's just willfully blind to say that what they provide isn't useful to millions or billions of people.

trasz 4y ago
My argument keeps being “if you have an incredibly complex mechanism working at best marginally worse than an extremely simple mechanism, then something’s not right with your design”. Regarding Google employees, what I wrote is close to the exact opposite of what you claim above, so… >tech debt is everywhere The point isn’t that there’s a lot of debt there - it’s about the speed of adding new debt vs actual functionality, which in turn comes from mistaking adding complexity for improvement. >unreliable for more than hour You’re talking about availability, aka “appearing to work”. What I’m talking about is reliability, aka “does it actually work”. Not does it fail for more than hour at a time, but how often does it fail at all. You need to count the forced reloads we’ve all learned to do automatically at this point. And I’d definitely remember last time mutt(1) failed on me, and I honestly don’t; I’m guessing sometime last decade. Except intermittent IMAP connection problems… to GMail. (For which mutt already got workarounds; it’s not like anyone expects Google to fix their servers.) (And sure, my mutt was configured some eight laptops ago, but it just so happens it’s the same for my Gmail account.)

trasz 4y ago

My argument keeps being “if you have an incredibly complex mechanism working at best marginally worse than an extremely simple mechanism, then something’s not right with your design”. Regarding Google employees, what I wrote is close to the exact opposite of what you claim above, so… >tech debt is everywhere The point isn’t that there’s a lot of debt there - it’s about the speed of adding new debt vs actual functionality, which in turn comes from mistaking adding complexity for improvement. >unreliable for more than hour You’re talking about availability, aka “appearing to work”. What I’m talking about is reliability, aka “does it actually work”. Not does it fail for more than hour at a time, but how often does it fail at all. You need to count the forced reloads we’ve all learned to do automatically at this point. And I’d definitely remember last time mutt(1) failed on me, and I honestly don’t; I’m guessing sometime last decade. Except intermittent IMAP connection problems… to GMail. (For which mutt already got workarounds; it’s not like anyone expects Google to fix their servers.) (And sure, my mutt was configured some eight laptops ago, but it just so happens it’s the same for my Gmail account.)