3 ms·

Because it works. Good engineering isn't about being obtuse and convoluted, it's about making stuff that works.

asddubs 3y ago
when the purpose is to abuse your monopoly to further your business interests in another area, being obtuse and convoluted to get plausible deniability is good engineering. This is just sloppy.
- lucideer 3y ago
  I think this is a good example of corporations being made up of people, rather than being contiguous coordinated entities as many of us sometimes think of them. An engineer doing "good engineering" on a feature typically depends not only on them being a "good engineer" but also on them having some actual interest in implementing that feature.
  - asddubs 3y ago
    I would imagine that in a well coordinated company engaging in this kind of thing, the order wouldn't be "slow down firefox", but something along the lines of "use XYZ feature that firefox doesn't support and then use this polyfill for FF, which happens to be slow". Something that doesn't look too incriminating during any potential discovery process, while still getting you what you want.
    - kristopolous 3y ago
      Nah, that's got a risk profile. They could implement whatever your strategy is in the next release. You aren't going to necessarily get the longevity of the naive approach. Plus a Firefox dev would discover that more easily as opposed to this version which they can just dismiss as some JavaScript bug on YouTube's part
      - asddubs 3y ago
        that's the beautiful thing, you make the polyfill contingent on the browser being firefox rather than probing for the feature and then you forget to remove it once they implement the feature
        kristopolous 3y ago
        But why do you have to be that clever? If you're caught the consequences are the same regardless and both implementations would exhibit equivalent behavior. The only superior approach here would be one that is consistent enough to be perceived but noisy enough to be robust to analysis. Also it should be hidden on the server side. Who knows, maybe there are a bunch of equivalent slow downs on the server side in the Google property space. Given this discovery it would probably be reasonable to do some performance testing and change the user agent header string of the request. Google docs, image search and Gmail operations would be the place to hide them.
    - lucideer 3y ago
      That's assuming a degree of engineering competency at the product decision making level that is usually absent in companies that are structured as Google is, with pretty strong demarcations of competencies across teams.
- kristopolous 3y ago
  I dunno. How long has it been there without anybody noticing? 5 years? 7? Longer? No matter how they approached it, you could demonstrate the pattern through the law of large numbers regardless. Might as well make the implementation straight forward.
legends2k 3y ago
Using an idle timer, like window: requestIdleCallback [1], is good engineering. If anything passes that's not good engineering, it's laziness. I'm not even a JS programmer but I know about timers, idle wait in UI programming is a common pattern. It's the attitude of mediocre engineers not bothering to lookup or learn new things. If every OS/browser/stock market dev did what they want "because it works" we don't have a working system. We'll have systemic lags making the system sluggish and eventually unusable as more engineers follow the same mantra. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...
- kristopolous 3y ago
  Nah, then it doesn't work. "It works" is The high engineering bar and it's the hard one to hit. Oftentimes it's replaced these days with imagined complexity, ideological conformity or some arbitrarily defined set of virtues and then you get a really complicated thing that maybe works some of the time and breaks in really hard to understand ways. Transcompiled frameworks inside of microservices talking to DBMS adapters over virtual networks to do a "select *" from a table and then pipe things in the reverse direction to talk to a variety of services and providers with their own APIs and separate dependencies sitting in different microservices as it just shepherds a JSON string through a dozen wrapper functions on 5 docker containers to just send it back to the browser is The way things are done these days. This is the crap that passes for "proper" engineering. Like the programming version of the pre-revolutionary French Court. A simple solution, fit for purpose, that works as intended, easy to understand, remove, debug and modify with a no-bus factor, that's the actual high end solution, not the spaghetti stacked as lasagna that is software haute couture these days. Sometimes, in practice, the dumb solution can also be the smart one. True mastery is in what you choose Not to do.
  - legends2k 3y ago
    I agree with the spirit of your comment; I too hate over-engineering. Choose your battles is an important step in mastery, yes, but being lazy can't be chalked up to mastery. In this particular case I disagree with using `sleep`; using the idle timer it's not as roundabout as you put it: _Transcompiled frameworks inside of microservices talking to DBMS adapters over virtual networks_. It's a straight-forward callback, some lower-level timekeeper signals you and you do your thing: it's nowhere close to the convoluted jumping through hoops you explain. Mastery comes with balance: putting in the optimal effort, not more, not less either. Of course, depends on what one's trying to master: job or programming. Former means do the minimum and get maximum benefits from your job/boss, latter means enjoy learning/programming and arrive at the most optimal solution (for no reason, just because you're passionate).

when the purpose is to abuse your monopoly to further your business interests in another area, being obtuse and convoluted to get plausible deniability is good engineering. This is just sloppy.

lucideer 3y ago
I think this is a good example of corporations being made up of people, rather than being contiguous coordinated entities as many of us sometimes think of them. An engineer doing "good engineering" on a feature typically depends not only on them being a "good engineer" but also on them having some actual interest in implementing that feature.
- asddubs 3y ago
  I would imagine that in a well coordinated company engaging in this kind of thing, the order wouldn't be "slow down firefox", but something along the lines of "use XYZ feature that firefox doesn't support and then use this polyfill for FF, which happens to be slow". Something that doesn't look too incriminating during any potential discovery process, while still getting you what you want.
  - kristopolous 3y ago
    Nah, that's got a risk profile. They could implement whatever your strategy is in the next release. You aren't going to necessarily get the longevity of the naive approach. Plus a Firefox dev would discover that more easily as opposed to this version which they can just dismiss as some JavaScript bug on YouTube's part
    - asddubs 3y ago
      that's the beautiful thing, you make the polyfill contingent on the browser being firefox rather than probing for the feature and then you forget to remove it once they implement the feature
      - kristopolous 3y ago
        But why do you have to be that clever? If you're caught the consequences are the same regardless and both implementations would exhibit equivalent behavior. The only superior approach here would be one that is consistent enough to be perceived but noisy enough to be robust to analysis. Also it should be hidden on the server side. Who knows, maybe there are a bunch of equivalent slow downs on the server side in the Google property space. Given this discovery it would probably be reasonable to do some performance testing and change the user agent header string of the request. Google docs, image search and Gmail operations would be the place to hide them.
  - lucideer 3y ago
    That's assuming a degree of engineering competency at the product decision making level that is usually absent in companies that are structured as Google is, with pretty strong demarcations of competencies across teams.
kristopolous 3y ago
I dunno. How long has it been there without anybody noticing? 5 years? 7? Longer? No matter how they approached it, you could demonstrate the pattern through the law of large numbers regardless. Might as well make the implementation straight forward.

legends2k 3y ago

Using an idle timer, like window: requestIdleCallback [1], is good engineering. If anything passes that's not good engineering, it's laziness. I'm not even a JS programmer but I know about timers, idle wait in UI programming is a common pattern. It's the attitude of mediocre engineers not bothering to lookup or learn new things. If every OS/browser/stock market dev did what they want "because it works" we don't have a working system. We'll have systemic lags making the system sluggish and eventually unusable as more engineers follow the same mantra. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...

kristopolous 3y ago
Nah, then it doesn't work. "It works" is The high engineering bar and it's the hard one to hit. Oftentimes it's replaced these days with imagined complexity, ideological conformity or some arbitrarily defined set of virtues and then you get a really complicated thing that maybe works some of the time and breaks in really hard to understand ways. Transcompiled frameworks inside of microservices talking to DBMS adapters over virtual networks to do a "select *" from a table and then pipe things in the reverse direction to talk to a variety of services and providers with their own APIs and separate dependencies sitting in different microservices as it just shepherds a JSON string through a dozen wrapper functions on 5 docker containers to just send it back to the browser is The way things are done these days. This is the crap that passes for "proper" engineering. Like the programming version of the pre-revolutionary French Court. A simple solution, fit for purpose, that works as intended, easy to understand, remove, debug and modify with a no-bus factor, that's the actual high end solution, not the spaghetti stacked as lasagna that is software haute couture these days. Sometimes, in practice, the dumb solution can also be the smart one. True mastery is in what you choose Not to do.
- legends2k 3y ago
  I agree with the spirit of your comment; I too hate over-engineering. Choose your battles is an important step in mastery, yes, but being lazy can't be chalked up to mastery. In this particular case I disagree with using `sleep`; using the idle timer it's not as roundabout as you put it: _Transcompiled frameworks inside of microservices talking to DBMS adapters over virtual networks_. It's a straight-forward callback, some lower-level timekeeper signals you and you do your thing: it's nowhere close to the convoluted jumping through hoops you explain. Mastery comes with balance: putting in the optimal effort, not more, not less either. Of course, depends on what one's trying to master: job or programming. Former means do the minimum and get maximum benefits from your job/boss, latter means enjoy learning/programming and arrive at the most optimal solution (for no reason, just because you're passionate).