Live data from Hacker News

An Amazon programmer’s perspective (2015)

pastebin.com

231–240 of 281 posts

Re: An Amazon programmer’s perspective (2015)

#231
post #191

Earlier quoted context omitted.

I'm sorry, but I can't track the point you are trying to make. I'll reiterate my point that shipping is a cost that has to be paid, but who bears that cost is not necessarily the customer. If it was the case that the customer was the one bearing that cost, there would be a difference in the price you pay for goods at a physical store vs. goods shipped to your home, implicitly or explicitly. There is generally no diff…

I think you're confusing who writes the check vs who bears the cost. The person writing the check isn't always the one bearing the cost.

It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. --Henry Ford

Re: An Amazon programmer’s perspective (2015)

#232

Earlier quoted context omitted.

I do believe there are people out there for whom "living their best life" truly does entail spending almost all their time in front of a computer. Nobody shamed Chopin for spending his life in front of the piano. Some people choose to dedicate their lives to one single thing, and often those are the people who end up contributing the most.

Maybe Chopin took long walks in the garden every once in an while. And maybe, just maybe, universally acclaimed musical geniuses are not a good point of comparison for common folk.

Hell, he ran off to Mallorca with George Sand. My impression is that composers work intensely, but manage to find time to do other things.

Re: An Amazon programmer’s perspective (2015)

#233

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

Crappy managers stress delivery over quality, and then engineers pay for it when they're oncall. The manager doesn't care how much their team gets paged because they'll be sound asleep while their engineer bangs their head against the wall at 2am, and the manager gets their pat on the head for delivering more projects.

Re: An Amazon programmer’s perspective (2015)

#234
post #214

Earlier quoted context omitted.

i don’t count it as in: i worked more than 3 weekends, but not because i had a choice )

I'm trying to interpret your words as something other than "well, yeah, my weekends were interrupted, but it wasn't my choice so it's not worth mentioning." I can't come up with another way to read it, though. So, don't you think that, in the context of having to give up nights and weekends, you should mention on-call? Your choice or not, the weekends and nights are affected, in fact isn't it kind of worse when it's…

i agree with you that the oncall is not ideal. it is also widespread in the industry. so what’s the point to complain about something that is an essential part of the job? (advertised or not, if you don’t want to do it you will have to look for another job)

i also think there is a huge difference between being oncall and having to respond in case something breaks vs mandatory death marches all day, every day.

Re: An Amazon programmer’s perspective (2015)

#235

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.

There is an endless supply of wide eyed new grads looking to prove themselves at a big 5

Re: An Amazon programmer’s perspective (2015)

#236
post #228

Earlier quoted context omitted.

The rate of budget increase increased dramatically without an increase in revenue.

They increased about .5% inflation adjust per year from 2010-2020. That again does not mean that spending is out of control especially when you consider that 2010 was still in the depths of the great recession.

Thats a good point thanks

Re: An Amazon programmer’s perspective (2015)

#237

Earlier quoted context omitted.

yeah no. as someone who has worked at Amazon for 7 years I can tell you that it’s not true across the board and there are good “pockets” where there is respect for people’s boundaries. To add to this, in my time there I worked during the weekend 3 times (i don’t count oncall here). My work day included 8 hours at most. I would get in at around 8AM and leave at 4PM. (optimizing the commute) I started as an SDE 2 by th…

I am sure it is not all of Amazon, but that is where the horror stories are coming from. So Amazon as a whole may not have this culture, but the teams with this culture seem to disproportionately be at Amazon.

law of numbers; Amazon Seattle headcount alone is 50K+ people. also, amazon has a service-oriented management model to match the general SoA architecture, where small teams are given massive leeway as to how exactly they run their services. managers and your leadership are thus very make or break.

Re: An Amazon programmer’s perspective (2015)

#238
post #214

Earlier quoted context omitted.

I'm trying to interpret your words as something other than "well, yeah, my weekends were interrupted, but it wasn't my choice so it's not worth mentioning." I can't come up with another way to read it, though. So, don't you think that, in the context of having to give up nights and weekends, you should mention on-call? Your choice or not, the weekends and nights are affected, in fact isn't it kind of worse when it's…

i agree with you that the oncall is not ideal. it is also widespread in the industry. so what’s the point to complain about something that is an essential part of the job? (advertised or not, if you don’t want to do it you will have to look for another job) i also think there is a huge difference between being oncall and having to respond in case something breaks vs mandatory death marches all day, every day.

I guess it depends on your definition of widespread. It is relatively common, but it's also far from universal, and there are companies that use on call which have a vastly different experience that what many people at Amazon report. In fact it seems like even different teams inside of Amazon have drastically different experience of on call. Treating it like a fact of life, like the weather, leaves you in a frame of mind that makes it impossible to advocate for change. Your own phrasing "be the change you want to see in the world" could as easily apply to on call as much as it does anything else -- but you won't take that stance if you think it's inescapable.

Re: An Amazon programmer’s perspective (2015)

#239
Burn out at work? Amazon? Oh c'mon.

The original OP's write-up misses the main questions and helpful perspective. Doctors (we have several in the extended family), lawyers (worked with some), entrepreneurs (have been one) all put in very long hours. So do grad students, and undergrad's working on tough assignments.

It's not work per se; the issues are larger, and different:

- do you enjoy what you do? If you're new, out of school you may not know this without experience. This guy got experience. We are aware that plenty of people make career changes inside and outside their industry right? Because of they realized the enjoyment and fulfillment wasn't there, right?

- do you have friends, hobbies, a social life, a wife (husband) and family? Do you do anything with them? If not, why not? Why does one work all the time?

- do you have self awareness of your red lines? If no, why not? If yes, why were they repeatedly crossed? Individuals have choice, agency if they are relatively self-aware.

- Why would a team put up with so many bugs, and so many late calls? There are a zillion developer teams ... we all have support issues/challenges, and part of the job is reducing outages which feeds into software engineering, quality, management, cross functional management with business people providing requirements, corporate culture, and many other facets.

I didn't find this article helpful. I do not cherish or dismiss the trauma reported herein, but something bad X happened at company Y is neither new, insightful, or explanative in any ultimate way that counts.

Re: An Amazon programmer’s perspective (2015)

#240

Earlier quoted context omitted.

> They were proud that they owned the product all the way from the code on the back to the customer at the front. So if you didn't want to be responsible for some level of ops, you knew that going in. There's a huge difference between being responsible for (some level of) ops and literally climbing out of bed when the pager rings. At work, I'm responsible for the operations of the services I develop, which means that…

I've always wondered how these sort of pager-duty notifications worked for heavy sleepers.

I worked for a company where developers could opt in to on-call cover. Doing so meant you got some extra cash, and if you were called then you got so much for the first hour, then a different amount for each hour after that. Not being coy, I can’t remember the details.

I'm a pretty heavy sleeper, and would go to bed with my phone on silent, set to ring a long time before going to answerphone, and with my Apple Watch on my wrist. If my phone rang then my watch would buzz me awake, eventually. The only snag was if, in my sleep, I knocked the watch out of contact enough that it locked and wouldn’t buzz on calls, but in practice I was lucky enough that I never got a call when that happened.

Not that I was called often. The company had developers around the world so it was only if they needed some specific knowledge or skills. That meant that being on-call was mostly a fee to compensate for being available at short notice and not drinking, etc.

Ultimately they decided they weren’t getting enough calls to justify the cost of paying the on-call fees and scrapped the system, just relying upon whichever developers around the world were working.

Post reply on HN