sharpy

Or problems just persisting, because the fix is easy, but explaining it to others who do not work on the system are hard. Esp. justifying why it won't cause an issue, and being told that the fixes need to be done via scripts that will only ever be used once, but nevertheless needs to be code reviewed and tested...

I wanted to be proactive and fix things before they became an issue, but such things just drained life out of me, to the point I just left.

Those 2 services that are being marked as having problems in other regions have fairly hard dependency on us-east-1. So that would be why.

The guideline has been to deploy to it last.

If the team follows pipeline best practices, they are supposed to deploy to a single small region first, wait 24 hours, and then deploy to more, wait more, and deploy to more, until finally deploying to us-east-1.

Haha... This bring back memories. It really depends on the org.

I've had push backs on my postmortems before because of phrasing that could be constituted as laying some of the blame on some person/team when it's supposed to be blameless.

And for a long time, it was fairly blameless. You would still be punished with the extra work of writing high quality postmortems, but I have seen people accidentally bring down critical tier-1 services and not be adversely affected in terms of promotion, etc.

But somewhere along the way, it became politicized. Things like the wheel of death, public grilling of teams on why they didn't follow one of the thousands of best practices, etc, etc. Some orgs are still pretty good at keeping it blameless at the individual level, but... being a big company, your mileage may vary.

oh.. changing my elections now! thanks.

I just put the extra money into regular investment account. My investments account tend to perform better than the rather boring results that 401k accounts give me. Would be different story, if I was allowed to contribute to Roth IRA. I actually didn't know about the backdoor conversion until this year, but that loophole seems to be on its way out.

Another data point.

My salary is just above $200k. After 6% contribution to retirement (max my employer will match), and $25k a year set aside for employee stock purchase program (max I can set aside - our ESPP is really good), I get just under $10k a month in direct deposit.

My rent is $3k a month. My discretionary spending is also around $3k a month. So I save $4k a month (in cash).

I also get around $350k in stock compensation. A bunch get sold off to cover taxes, but I don't sell anymore, as I believe in the company, and it has done well in the last 2 years.

Altogether, I save above $250,000 a year - in vested stock, and cash.

Conversely, it can work out great for you.

For example, Amazon stock used to go up 30-40% a year reliably. Compensation model was "conservative" and estimated 15% a year.

So if you stayed at Amazon for a while, you could be paid very very well, thanks to stock appreciation.

For the risk adverse, a strategy is to sell the stocks as they vest, effectively treating it as cash. Companies will also issue additional RSU, if stock tanks too badly, as they'd be losing people otherwise.

Personally, I worked for Amazon and Microsoft for a number of years, and have kept all my RSU. It has worked out great for me (at least on paper).

Yes, US tech salaries are rather crazy.

But at the scale they operate at, it is also relatively easy to justify such salaries. For example, just last month, I saved the company more than a million a year of cloud costs by doing 1 week of cost optimizations for just one of our services. I will create many times that in new revenues/cost savings in the remaining 2 months of the year.

My total comp for year? Barely over half a million. So I'd say they are getting a good value.

Yep. That makes more sense. But here, they are basically looking at your ability to manage credit "responsibly" by looking at your payment history, and utilization, among other things.

So say if I spend $3000 a month, and pay it off every month in full, and my total credit limit is $10,000, they will ding me regardless of my payment history, because my utilization (30%+) is considered high. So if I want to maximize my credit score, it behooves me to get more cards (easiest way to increase total credit), and spread out the payments among them.

A lot of people chase sign up bonuses. Some credit cards have sign up bonuses equivalent to $1000+. So sign up for a year, and then cancel. Also our credit score systems consider number of open accounts, and anything less than 10 is considered as having too few accounts.

Having to write the CoE (correction of error)is punishment enough.

I've seen promos being denied, because the problem wasn't sufficiently complex enough. I'd say it was, but the design was simplified as much as possible, leading to 'wrong' impressions.

That's not necessarily a bad thing for writing web services. I used to spend a fair bit of time tuning JVM to achieve acceptable tail latencies for Java services, not to mention once in a while, they would need to be tuned again... Not so with Go.

Yep. The nature of the time series data does allow for storage optimizations like that. But there is the usage pattern aspect as well, that is more interesting in my opinion.

- Availability preferred over consistency (you want your metrics when bad things are happening, even if they may not be 100% accurate)

- Extremely write heavy, with most data never being read (they mentioned that only 2% of data is ever read. in my experience at another large company, it was way less than 2%)

- For the data that is read, most of reads are for most recent points (mostly alarms, but some dashboards as well)

- Different SLAs for queries based on usage - ie. queries for alarms must be fast. Dashboards, and trend analysis - not so much.

Billing is really hard. I've had projects that literally sat on the shelves for months while we finalized our billing model, after realizing it would significantly increase the cost for our largest customers.

A lot of them do. In fact, laptop + cloud desktop that runs Amazon Linux is the standard set up now.

Except even at those companies, the actual day to day work is pretty straight forward. What we really need are engineers who can produce well thought out designs, and write quality code that is easy to maintain. Unfortunately, the emphasis on tech interviews is on algorithmic questions, possibly due to desire to reduce candidate pool size, and the fact that design output are somewhat harder to quantify.

Engineering teams at Amazon does indeed have a lot of autonomy. I have been part of multiple teams over a fairly long periods of time (7+ years), and it's been my experience every time. There were times when it felt like each team was its own start up, at least when it came to deciding what to build / prioritize.

One system I worked on showed the date as year 3900, because the function for getting current year would return 2 digit for year < 2000, and full 4 digit for >= 2000. So the code did 1900 + GetYear(). Replaced it with just calling GetFullYear() or something like that.

And reduces chances of outages... which is good for both customers and AWS.

Lambda does re-use the JVM instances where it can to alleviate that.

Probably more to do with the runtime environment.

Yep. Software can last surprisingly long time. Personally wrote a micro service with intended life-time of 6 months. 8 years on, it is still soldering on, surviving multiple attempts to replace it, with almost zero maintenance.

Same for me. A heavy user of Uber. Lyft has always been more expensive for me in the past, but I guess they categorize me as "captive user". Lyft has been cheaper for me of late, so Uber lost me as a customer. At least for now.

The only downside would be that almost 100% of the visa allocation would go to IT then. I believe medical field also gets quite a few H1B workers.

The core language is. The libraries are another matter.

From the website:

The core of the Julia implementation is licensed under the MIT license. Various libraries used by the Julia environment include their own licenses such as the GPL, LGPL, and BSD (therefore the environment, which consists of the language, user interfaces, and libraries, is under the GPL).

I had that happen to me once. A candidate (college hire) chose to code in Haskell, which I had a passing familiarity with. We offered him the job, and he was definitely a strong hire, and we used Java mostly.

Having worked at AWS for a number of years, I had difficulty keeping track of all the new features/services when I was there. If I were still there, I would have given up :-) But I do think that overall, it's better for both the customers and the company.

As to some concerns about diluted focus, service teams operate with great deal of autonomy. From what I have seen, features are driven by teams, and often as a result of conversations with customers.

That example aside, as a native speaker, I've found the English-to-Korean translation to be rather good!