I feel like Google tried to solve for this with their `withgoogle.com` domain and it just ends up being confusing or worse still, frustrating when you see something awesome and then nothing ever comes of it.
1,570 karma · joined December 2, 2020
I feel like Google tried to solve for this with their `withgoogle.com` domain and it just ends up being confusing or worse still, frustrating when you see something awesome and then nothing ever comes of it.
> is probably because
I don't mean to be contrary, but these statements stand in opposition, so I'm not sure why you are so confidently weighing in on this.
Also, while I'm sure you've "been in senior engineering management", it doesn't seem like you've been in an organization that doesn't do engineering as it's product offering. I think this article is addressing the 99% of companies that have some amount of engineers, but does not do engineering. That is to say: "My company does shoes. My senior leadership knows how to do shoes. I don't care about my engineering prowess, we do shoes. If someone says I can spend less on the thing that isn't my business (engineering) then yes, I want to do that."
Which was literally the shopping experience before Selfridges "revolutionized" the department store experience by letting customers have direct access to goods for sale.[0]
Before that everything was behind a counter and you have to be served and monitored. Even the grocery store was a similar experience, whereby you would give the clerk your list and they would select everything for you.
Everything that is old is new again.
0. https://en.wikipedia.org/wiki/Department_store#Innovations_1...
0.https://web.archive.org/web/20250310045704/https://www.nytim...
You can't be serious. On every job application I've ever filled out the last question is always a variation of: "Do you now or will you in the future require employer sponsorship to work in this country?"
0. https://www.timesofisrael.com/haredi-mens-employment-growth-...
I work in this space for a retailer almost the same size as Tesco and when factoring in all the attendant organizations, businesses, and functions it requires, 40k servers does not surprise me at all.
Outside of just the brick-and-mortar stores you have Marketing, Retail, eComm, Merchandising, Strategic Sourcing, FP&A, Finance & Accounting, Asset Protection, Corporate Real Estate, Retail Real Estate, Internal Audit, Supply Chain, Transportation, Business Services, Data Science, etc etc. and IT at every level of those. Each one of these components is large enough to be a medium-to-large sized company in its own right.
The value prop of these "Low-Code No-Code" platforms has absolutely 0 to do with the actual "user/developer" experience being better/easier/more powerful and everything to do with the orchestration, inheritability, visibility, management, and security capabilities that these platforms provide. If I have 5 artisanal, bespoke Excel workbooks that my "developer" accountant runs locally to complete a part of a critical business process (and they invariably do) then I have 5 ways my business can come to a grinding halt when any number of things happens to that accountant or their computer. I would take 50 less powerful, rickety RPA workflows that I can at least see in a control room over those 5 Excel workbooks any day of the week.
Also the 'if' doesn't negate anything as they say "I still", meaning the behavior is actively happening or ongoing; they don't use a hypothetical or conditional after "still", as in "I still would".
GMail doesn't care about dots, so you could say your email address is f.i.r.s.t.l.a.s.t@gmail.com for all the good it does. Using the dot probably does more harm, as it makes people think it's a legit differentiator.
If, as it seems in the article, they are using COCO to establish ground truth, i.e. what COCO says is correct, then whatever COCO comes up with is, by definition "correct". It is, in effect, the answer, the measuring stick, the scoring card. Now what you're hinting at is that, in this instance, that's a really bad way to establish ground truth. I agree. But that doesn't change what is and how we use ground truth.
Think of it another way:
- Your job is to pass a test.
- To pass a test you must answer a question correctly.
- The answer to that question has already been written down somewhere.
To pass the test does your answer need to be true, or does it need to match what is already written down?
When we do model evaluation the answer needs to match what is already written down.
Our ground truth should reflect the "correct" output expected of the model in regards to it's training. So while in many cases "truth" and "correct" should algin, there are many many cases where "truth" is subjective, and so we must settle for "correct".
Case in point: we've trained a model to parse out addresses from a wide-array of forms. Here is an example address as it would appear on the form.
Address: J Smith 123 Example St
City: LA State: CA Zip: 85001
Our ground truth says it should be rendered as such:
Address Line 1: J Smith
Address Line 2: 123 Example St
City: LA
State: CA
ZipCode: 85001
However our model outputs it thusly:
Address Line 1: J Smith 123 Example St
Address Line 2:
City: LA
State: CA
ZipCode: 85001
That may be true, as there is only 1 address line and we have a field for "Address Line 1", but it is not correct. Sure, there may be a problem with our taxonomy, training data, or any other number of other things, but as far as ground truth goes it is not correct.