Live data from Hacker News

An Amazon programmer’s perspective (2015)

pastebin.com

11–20 of 281 posts

Re: An Amazon programmer’s perspective (2015)

#12

A former colleague of mine suspects that Amazon is going to eventually run out of developers to hire because of how rapidly they burn through them. Yet to know anyone who lasted more than a year or two there. Obviously some do, but they go through an enormous number of people.

[deleted]

Re: An Amazon programmer’s perspective (2015)

#13
> I mention on-call duty because it is “peculiar” in that the only other profession requiring this kind of responsiveness is doctors, literal lifesavers. When you go on-call for the first time, it’s terrifying and tells you “holy crap, this is serious.”

A key difference is that the oncall engineer is usually able to directly influence the quality and robustness of the systems being watched. Sort of like preventative medicine, but much more direct.

Crappy teams make crappy software that pages often (or not at all if their ops fails to write any meaningful alerts)

Re: An Amazon programmer’s perspective (2015)

#14

> On-call wasn’t (and isn’t) too terrible for my team. At first we averaged 1 page every 2 weeks; now we’re up to about 1 a week. Wow, I wish I had once a week. This is way better than my previous employer/role. I was on-call for months straight, and would get paged multiple times a night, every day, even at 2am, 4am. I had to carry my laptop to dinners, date nights, game nights, etc. I got burned out and moved caree…

same. i was oncall 24x7 for about, I dunno, 8 years? I'd share it with my co-founder, so I'd get a week or two off here and there.

It was horrible and in retrospect a really bad decision with the expected outcomes, mostly broken mental health.

Re: An Amazon programmer’s perspective (2015)

#15
I appreciate this being shared, but I have some qualms.

I think talking about the Leadership Principles as a 'typical corporate motto' is unfair. Amazon lives their leadership principles far more than the other companies I've seen. They don't include things they don't actually care about, like most corporate mottos do (you'll notice the lack of 'we care about our employees' or 'do no evil' LPs).

At least in my experience, you only need to pay back Amazon proportional to (2 years minus duration employed) so it really isn't that bad (maybe that wasn't the case when this was written).

Maybe it's changed, but the signing bonuses I saw were essentially increased salary until your stock starts vesting seriously. It gets paid out and vests every paycheck so there isn't anything you need to pay back.

Re: An Amazon programmer’s perspective (2015)

#18
The on call stuff sounds outright dystopian to me, it's not even legal in my country. More places should think about adopting something akin to France's El Khomri law's (https://en.wikipedia.org/wiki/Right_to_disconnect) and ensure that every citizen has enough time to recuperate from work and isn't pestered by their employer 24/7.

Re: An Amazon programmer’s perspective (2015)

#19

> On-call wasn’t (and isn’t) too terrible for my team. At first we averaged 1 page every 2 weeks; now we’re up to about 1 a week. Wow, I wish I had once a week. This is way better than my previous employer/role. I was on-call for months straight, and would get paged multiple times a night, every day, even at 2am, 4am. I had to carry my laptop to dinners, date nights, game nights, etc. I got burned out and moved caree…

I don't know how absurd this sounds but on-call is the only reason I have stayed away from backend or frontend/web development. I had worked on both for few months and ran back to native app development. There might be a place where the company has a "follow the sun" policy for on-call but I haven't come across any.

Re: An Amazon programmer’s perspective (2015)

#20

> I mention on-call duty because it is “peculiar” in that the only other profession requiring this kind of responsiveness is doctors, literal lifesavers. When you go on-call for the first time, it’s terrifying and tells you “holy crap, this is serious.” A key difference is that the oncall engineer is usually able to directly influence the quality and robustness of the systems being watched. Sort of like preventative…

I don't trust an engineer that can't troubleshoot their own software running in production. I think the "you write it, you own it" adage is really smart and raises all tides when engineers are empowered to root cause each issue.
Post reply on HN