[rayvy]

I think this write up is very fair for a solid engineering team. Is it groundbreaking and eye opening? Absolutely not, I’d say the most “hmm I didn’t know that” part of the entire thing was the part about R-Trees and S2. Is that bad? Absolutely not. These guys did the work, logged their performance and are sharing their story.

However, and I believe this is where the animosity in the comments is coming from - given the elitist (for lack of a better term) attitude of these engineering types at these orgs (think of the poster children of the Valley), this is pretty...lacking. I mean, the part about using the Read/Write lock on the second attempt and instead trying to go with an installed package just screams Node.js, and honestly made me chuckle. I guess Leetcoding and Production Engineering really are different things. I genuinely expected more.

[0xEFF]

> I guess Leetcoding and Production Engineering really are different things.

This is key point.

They delivered value to the business. That's the only thing that matters.

[privateprofile]

> They delivered value to the business. That's the only thing that matters.

Except this is an engineering blog post, so the engineering part actually matters.

And, as demonstrated in the article [1] linked around this discussion, there were better engineering approaches that would have been even "better for business", as being more efficient means lower costs per transaction and/or higher throughput.

[1] https://medium.com/@buckhx/unwinding-uber-s-most-efficient-s...

[elbear]

It matters for engineers reading the article. It doesn't matter for the business. What they delivered was good enough. Could they have delivered a better solutions? Yes.

Should they have searched for a better solution instead of implementing the one they found? They could have spent some time researching, but you can always miss something. It's better to err on the side of delivering something now with a not-so-good solution than constantly searching for a better one.

I say this as software developer who is obsessed with efficiency. I'm starting to turn around and focus more on just delivering.

[SilasX]

>It matters for engineers reading the article. It doesn't matter for the business. What they delivered was good enough. Could they have delivered a better solutions? Yes.

The entire reason they posted the article is to brag about having accomplished intelligently. It's relevant if their approach was actually not so intelligent.

"We encountered a standard problem and applied standard solutions" is like "dog bites man". It's not what they were trying to say with the blog post.

>Should they have searched for a better solution instead of implementing the one they found? They could have spent some time researching, but you can always miss something. [...] I'm starting to turn around and focus more on just delivering.

I think the critics point is that the efficient way was probably also cheaper than what they did, and would take the same time to implement, and have lower recurring costs. It would have just been a matter of using off-the-shelf tools and not reinventing the wheel because that wheel is "complicated" and "obviously our case is special". (Someone did benchmarks, and their case is not special.)

You're right, there is a danger to what-if-ing everything and being stuck in decision paralysis. But the clear subtext is that they merit some kind of admiration for how well they did. If that subtext is wrong, it is worth pointing out.

[ionforce]

> They delivered value to the business. That's the only thing that matters.

But this bit isn't true during the interview process.

[vorpalhex]

That's half of the interview process. The other half is convincing your future-peers you aren't a liability. Provide value, get along well, communicate decently.

[tomtomtom777]

> They delivered value to the business. That's the only thing that matters.

Although hardware is relatively cheap, 170 QPS on 40 servers for this type of query is astonishingly horrible even from a Business/Product Engineering standpoint.

Boasting this as "highest QPS* engineering achievement is just awkward. It may be better suited for an article on how throwing hardware at problems is cheaper than hiring engineers.

[mkolodny]

The article mentions 170k QPS, not 170.

[spookthesunset]

> They delivered value to the business.

Sure, but could there have been ways to deliver that value with lower maintenance costs and shorter lead times?

If all you care about is gross revenue and never focus on margins and cost of goods sold then you can justify any project as "adding value to the business".