Hey, someone's gotta paint the roses red.
817 karma · joined July 2, 2009
Every Uber/ex-Uber engineer is nervously chuckling at this comment right now
> Doubt anyone releasing big changes Monday morning.
This is definitely an engineering best practice, and by best practice, I mean something that Uber's, I mean Slack's SRE team strongly pushed for, and got politely overruled on. After a code freeze is lifted, it's quite common for lots of promotion-eager engineers to release big changes.
- high risk changes that weren't released pre-holidays get released. Depending on the company, this could mean a 1-week to 1-month delay between implementation and release. The greater that interval, the higher the divergence world of production and the world of the new feature
- lots of new hires (new year = new hiring budget). New hires are missing some tribal knowledge about the system and make a production-breaking release.
I tried to think of other reasons, but these two overwhelmingly stand out as the two biggest reasons. Would love to hear from others.
My bet is that this incident is caused by a big release after a post-holiday "code freeze".
Plenty of reasons why people would convince themselves to buy them:
- I can easily return it if I don't like it (most never do)
- the OS X/iOS integration will be way better than my current headphones (my poison)
- I love Apple
- 2020 sucked, if I can't even go to Thailand this year, I'll at least treat myself to these. I deserve it.
1). While Uber has been very Bay Area-heavy, it has had a distributed engineering team for many of its core operations for a very long time. For example, many of its core infrastructure was built in Europe. Cross-timezone collaboration hasn't been the smoothest, but of all the large "FANGish" tech companies, Uber actually has the most experience with non-HQ teams building business-critical systems. Even companies seen as very progressive in terms of eng culture, like Stripe, seem to keep the core business close to HQ (this is my subjective observation, and I'd love to proven wrong here, because I think Stripe, as a whole, is awesome).
2). India is a country with many people and many engineers. If there's one strong believe I can state in this post, it's that there are many incredibly talented engineers who are living in India and are choosing to stay there. Uber has experience in building engineering teams outside of HQ. It's not a sure thing, but I think they can do it.
Happy to answer any other questions or comments.
(I guess as a disclaimer, I have zero financial stake in Uber, but I have some friends who still work at Uber, so that may or may not influence my opinion)
No one who is working on this cares about real-time by the second data - the daily cost is enough.
> Again, this is a strawman. This isn’t a response to anything I said.
OK, what are you trying to say? If my response above did not answer the question, can you give me a one sentence summary of the point?
Since they don't, if you are literally so concerned with your current costs for this month, you can set a budget and alerts for whatever you want, so that you don't exceed some cost. Also, they show you your current cost for this month, up until the moment, as well as a daily breakdown of your costs.
Maybe a good analogy is to think of AWS as C. It's flexible and powerful, but it's easy to shoot yourself in the foot. That would explain why a lot of these "> magical-tool deploy" services have emerged, promising to abstract away AWS.
Did you actually look at the billing page? Here's a screenshot of my billing page:
It meticulously breaks out per-service costs across whatever dimension you want. "EC2-Other" is rolled up in the chart, but it's broken out by each individual item further down in the list.
EDIT: sorry, I forgot to include the screenshot link - https://imgur.com/a/tVFoocr
My father (and many others like him) has been programming in C at a prominent SV company for the past 15 years (OK, it's based in the South Bay). I know many people in SF doing similar jobs, just coding away in Java or C++. Those people come to work, do their work, then go home. They don't tweet, or write Medium posts, or have dark green GitHub activity profiles. They don't work with you, so they don't talk to you. You aren't aware they exist. However, these people build many of the systems that make our day-to-day lives possible.
> I'm not denying either of these facts but it doesn't stop the small town engineers from existing.
I'm not saying they don't exist, I'm just saying that there just aren't that many of them.
> It's quite a tour de force how Amazon have taken "separation of concerns", applied it to web services and used it to create complex and difficult to understand or predict pricing to print money.
Is applying separation of concerns to web services really that bad? Look, if you're a small company with a simple product, you can just put your stuff on a few EC2 boxes and pay the monthly bill for that. At that size, your infra costs are going to be dwarfed by your other costs of doing business anyway. If you're a big business, you can literally pay people to keep track of this stuff. You've got the extra money, because now you don't employ data center architects, server engineers, etc. AWS is able to "print money" because it brings a lot of value to many businesses.
No, it does not.
> You would be surprised at how many people value their hometown or where they have settled.
I would love to see actual data about this rather than articles from hometown newspapers and posts by hometown residents, enthusiastically praising their way of life. It's easy to argue the counterpoint as well, right?
1). There are many jobs that have to be done in person 2). Many people prefer to live in large cities and accept the downsides in order to get the benefits
So, next time you want to make a claim like this, can you share anything objective about this? Thanks.
Sentry lets you send exceptions to Datadog though?