Live data from Hacker News

An Amazon programmer’s perspective (2015)

pastebin.com

91–100 of 281 posts

Re: An Amazon programmer’s perspective (2015)

#91

This is what I don't understand. When Tbray left, he said he was doing so in solidarity with the distribution center types, but he held to the line that AWS was great. This despite nightmare stories like this one regularly bubbling up, and I've heard similar from friends. What is it about tech culture that people within it refuse to admit the level of abuse-by-design that happens at these companies? Is it that they w…

> What is it about tech culture that people within it refuse to admit the level of abuse-by-design that happens at these companies? The Amazon example is extreme, but a lot of tech workers fit the stereotype of people who don't have a lot else to do. I spend 100+ hours at my computer a week, so if you want long hours, I can live with that. I am up at 1AM anyway, so if you need something done at that time, sure. I jus…

Maybe it's just the type of people amazon hires? I've been programming for 5+ years. Know what I'm doing today at 5 pm? Headed over to Lake Michigan with the fiance. Yesterday I went on a 4 mile run. Personally I never check things outside of 8-5 and my employer is A-OK with that.

The biggest problem is when people like this article's author get a job and the HR people never make it clear that they may need to have "pager duty" or otherwise work outside of 8-5. Those different expectations is what caused him to have a very bad experience.

Re: An Amazon programmer’s perspective (2015)

#92

> I mention on-call duty because it is “peculiar” in that the only other profession requiring this kind of responsiveness is doctors Uh, not even close. I used to get up at 4am EST to trade European markets for a hedge fund. I was on call 24/7/365. I had my laptop and Bloomberg fingerprint scanner with me on any trip I took. And this is just my experience. I have had many friends in engineering, management consulting…

In the military, we had a 2 hour recall for a large chunk of our battalion, about 200 people for a few months at a time. If you got a call, you were expected to be ready to go in less than 2 hours. Social norms meant the expectation was closer to 45 minutes than 2 hours.

I think oncall is a common requirement for anything involving large sums of money, treatment of high risk injuries, or geopolitical power struggles.

Re: An Amazon programmer’s perspective (2015)

#93
post #26

This is what I don't understand. When Tbray left, he said he was doing so in solidarity with the distribution center types, but he held to the line that AWS was great. This despite nightmare stories like this one regularly bubbling up, and I've heard similar from friends. What is it about tech culture that people within it refuse to admit the level of abuse-by-design that happens at these companies? Is it that they w…

I worked at AWS. Your experience may vary significantly depending on which team you are in, either at AWS or plain-Amazon. Some people are having the time of their lives there. Some are working horrible hours, maintaining crap old code that they hate, and struggling with performance reviews that saps their morale and prevents them from seeking a better team or leaving the company. Some people genuinely like the compe…

Yeah writing history like the egyptians did building all those pyramids. So fascinating.

Re: An Amazon programmer’s perspective (2015)

#94
post #56

Earlier quoted context omitted.

> I want it to happen. I'd like a word. You could be shown the door in no-time. Amazon has forced attrition and the manager decides who gets the cull. They may make a mountain out of a mole to further their objectives.

> Amazon has forced attrition Do you know how they implement it? Is it the old Microsoft model with obligatory bell curve distribution of performance reviews?

Every org of, say, 100 people has a quota of X poor performers that they need to produce to senior management every year.

Each manager of, say, 10 people rates their own reports.

The managers in the org compare notes, and count up how many poor performers they have between them.

If the number is below X, managers who did not downrate enough people are told to go back, and find more people to give bad ratings to.

If they can't find those people, that's fine - then those managers will get downrated.

Re: An Amazon programmer’s perspective (2015)

#95
post #89

Earlier quoted context omitted.

>How are critical systems managed otherwise without having to 3x your team (assuming you want 24hr coverage with a 8hr workday)? They typically aren't, you need to hire more people then. In anything defined as critical I would suggest that being well rested is also a requirement rather than having a team of people who are so overworked they develop mental illness.

Doesn't make sense financially. You're gonna triple the size of your team, just to make sure that this one time of the week someone will restart the DB? I would much rather bite the bullet, be on call a week a month or so and use the budget for something else.

This is a law to protect the mental and physical well being of citizens and workers, obviously not Amazon's bottom line, that's literally the point. If you treat people like disposable commodities then yes this does not make any sense.

Re: An Amazon programmer’s perspective (2015)

#96

> 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.

I think the second part is super important though, but it's often forgotten.

If you work on a buggy-enough system, and don't do the root causing, then you will have incredibly bad on-call experiences.

Re: An Amazon programmer’s perspective (2015)

#97

Ex Amazon here. > SDE II basically means a software developer with at least 2–3 years of industry experience If this is true, the hiring bar has been lowered incredibly.

Most of the campus hires that I know or have seen in the last 5 years became SDE2 is 1.5/2 years.

Re: An Amazon programmer’s perspective (2015)

#98
post #78

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.

How are you proposing to run a complex system that essentially powers a big chunk of the entire internet and can go down any second without on-call? If a big selling point of your system is the ability to be on 24/7, on-call is inevitable. But it definitely can be way less gruesome than it currently is at Amazon for a lot of teams right now. For example, my on-call schedule is extremely relaxed and low-stress, it is…

>How are you proposing to run a complex system that essentially powers a big chunk of the entire internet and can go down any second without on-call?

hire more people?

Re: An Amazon programmer’s perspective (2015)

#99
post #47

Earlier quoted context omitted.

I don't understand what's so dystopian about it. Some systems are critical and need to be kept online at all time, or at least have very minimal downtime. The description in the post is not even that bad. A page a week is nothing. And it is clearly state that your workload is reduced during your on call period.

The dystopianism comes in because the vast majority of teams are decidedly _not_ 27/4 critical. Sure, some teams really run the 1-Click Buy button or the S3 API. Most run some DB behind some API behind another 3 APIs behind 5 other teams that run a widget. In practice, your workload may not be reduced during on call because it's "expected" and you still have to meet your normal deliverables while the team isn't staff…

Your "in practice" doesn't match my on call experience over the past 15 years. During "on call" workload is reduced (the author of the post even mentions it). There are ways to implement sane on call policies that benefit everyone. A few I've seen:

- use a primary and secondary on call so that the primary can still go get groceries, or play in the yard with their kids, etc - overlap on call and work hours. I did that at a job and I was fine with working 6pm - 2am just to cover this time slot. Won't work for everyone, but may be a nice compromise for some.

Like everything else, there are ways to do it right, and way to go complete bananas with it.

Re: An Amazon programmer’s perspective (2015)

#100
When my Uncle found out how much the average entry-level Amazon software developer at Amazon makes, he was completely shocked, because it's higher than his salary as a physician in practice for many years. So all things considered, when it's mentioned how doctors are the only other profession where the employees are on-call 24/7, most FANG devs are making more than the average doctor.
Post reply on HN