First you need to understand that the intent of the query string is to set a timer. Human language is ambiguous so there can be many competing interpretations.
Then you have to take all the intentions and ask backends to fulfill them with their actual results
Then you sort the result by the correct order for the user.
Then you need to render the search page. At this points some results may not want to be present anymore because they are not the top result.
That's a 50'000 foot approximation of what happens when you query Google. The process has tons more complexity as you zoom in.
It is amazing engineering, but probably not the first way you'd go about implementing a count down timer.
I’d say using tons of “amazing engineering” to implement something that’s functionally equivalent to a trivial shell script is a rather poor engineering.
I am honestly confused how people have so little experience and empathy for engineering, even on a forum like this.
Do you actually work somewhere where you're providing one of the most-used services in the world and it's held together by "trivial shell scripts"? Do you really think people at Google are so bad at their jobs that they went "Well, this is 4 lines of Bash, but I could make this needlessly complex for no reason" It's not as if they're the height of engineering, but the arrogance to just assume that there's no reasonable factors that may have not lead them to doing something more simply is so foreign to me.
It’s not that I lack empathy - I know many of those folks, and I’d work there if I wanted to. It’s just that an empathy towards Lenin bust factory workers doesn’t make their hard work any more useful.
You’re confused, because you got it exactly backwards - most technical people who work this kind of jobs lack the big picture required to realize that the vast majority of their work is just technological debt. And some others that do get it also understand the business part - and while this overcomplication is bad technologically and user-wise, it might make sense to business.
Also, let me remind you that those “most-used services” are generally of quite poor quality, both in terms of reliability and user experience. There are services that do matter - ads and tracking - and I’m guessing those are more cared about, but I’m not talking about them.
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.
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.)
The point is that it's not really the timer that's complex. It's the path taken to determine that a timer should be displayed in response to a search query. The timer itself is presumably fairly trivial.
Then you have to take all the intentions and ask backends to fulfill them with their actual results
Then you sort the result by the correct order for the user.
Then you need to render the search page. At this points some results may not want to be present anymore because they are not the top result.
That's a 50'000 foot approximation of what happens when you query Google. The process has tons more complexity as you zoom in.
It is amazing engineering, but probably not the first way you'd go about implementing a count down timer.