Was a PM on the team that looked at re-doing the early implementation of restaurant receipts - fun to see this seemingly small but important set of details gett

Was a PM on the team that looked at re-doing the early implementation of restaurant receipts - fun to see this seemingly small but important set of details getting some attention! It was a topic that was discussed in detail and likely still gets examined periodically judging by how the receipts have changed since I was there. Your comment is very accurate. Restaurant POS systems are incredibly limited - some still run on Win2k or proprietary OSes - and not in any way standardized. Field length limits exist all over the place due to seemingly arbitrary manufacturer choices, perhaps due to OS limitations or desire for backward compatibility to even earlier systems. Short fields - as short as possible - scale well. Keeping the shorter codes, which started with the Eats pilot app and largely stayed that way, played nice with POS systems. Likewise for receipt printers - space is at a premium so shorter is better. Defects data are monitored very closely and swapped orders were pretty uncommon overall. Missing item, incorrectly made item or courier not picking up food were far more important problems to solve. Hence your comment 'good enough' was accurate - the system was indeed good enough. Combined with the POS / receipt printer situation and the business case wasn't really there for changing the existing implementation. There is even more inertia to not change things when those changes would impact the kitchens of 10s of thousands of restaurants around the globe, including large ones like McDonald's. The cost of change management in this situation is very real. These restaurants have intricate, in-house produced training manuals and seemingly small changes are a very big deal to them for operational efficiency. Even if the change is better it's still a bunch of doing to execute at global scale. The topic of asks also likely factors in, but in this case probably more from regulators than restaurants. The utensils field is new to me but if I had to guess I'd say likely some regulatory thing but that's just a guess. Could also be a source of defects that has cropped up. Likewise the courier number is a regulatory / security thing - important to both big restaurants and regulators that we're doing everything we can to ensure a secure chain of custody for food even if many restaurants don't use it correctly for this purpose. Naming conventions also receive an unbelievable amount of scrutiny with regulatory considerations in mind. Uber couriers are contractors and Uber was always very careful to structure word choices and operational routines to respect this. Suspect the 'courier powered delivery' word choices are carefully chosen with this in mind and unlikely to be something that would receive the necessary buy-in to change absent a major business impact. To your last correct point - human imperfections in a busy restaurant kitchen are a huge driver of order issues. Kitchens are loud, stressful, busy and increasingly complicated with all the apps. Often the solution to the type of problems seen by the OP was restaurant notification / coaching / reporting / reviews to help tune restaurants into problems that were largely operational even if other tech solutions looked like they could solve the problem. That all being said fun to see a fresh take on what could be possible as well as the code to do it. Appreciate OP taking the time to dig deep into what is a seemingly small product / engineering decision yet quickly becomes a pretty meaty body of work.