Live data from Hacker News

Laying myself off from Amazon

daniel.do

101–110 of 374 posts

Re: Laying myself off from Amazon

#101

Why does anyone work there?

Former Amazonian here. The learning is unmatched. I've been in different FAANGs but the way that Amazon pushes one to learn and challenge the status quo is unthinkable. I never saw "no, you can't do that, that system/business/area is sacred". Everything is up for grabs all the time. While there are pathological side effects to this (AWS promotion-per-launch, constantly battle for scope), the amount of knowledge one c…

Yet the internal tooling has been cited by several here as being one of the major time wasters and reasons they don't want to work there. It seems sacred to me...

Re: Laying myself off from Amazon

#102

Amazon has a lot of bad internal tools, but this person's experience doesn't match mine (being here for 8 years) at all > 40% of my time trying to tame the bad internal tooling I was forced to use to submit my code, get it merged, deploy it, check logs, etc… The tools for code submission, pull requests, pipelines, metrics, and logging are fantastic. Google is better. Most companies aren't. I have never spent 40% of m…

>I have never spent 40% of my time battling internal tools.... In my experience, not at Amazon, long tenure employees get used to the quirky tools but the impact on new employees can be massive. Same with bad code bases, bad documentation and so on.

I really think this is true. Like compare the CR process to Github's PR process. To me, it's horrendous. But to others who are embedded, maybe they love it.

Re: Laying myself off from Amazon

#103

> 40% of my time trying to tame the bad internal tooling I was forced to use to submit my code, get it merged, deploy it, check logs, etc… This gives the lie to Jeff Bezos' whole "Day 1" philosophy. If you're at a Day 1 company you don't spend 40% of your time fighting with the crappy internal tools.

I think what "Day 1" means at Amazon is that you're always still finding your footing, until you quit.

Haha, I found this quite funny :) I'm sure there's an element of truth to it considering how complicated the code base must be for the various services

Re: Laying myself off from Amazon

#104
Sigh... another loss at the hands of, "Code is Art!"

It's not art. Art requires no function, it exists as a representation. (Professional) code, and software engineering generally, must produce valuable things, and sometimes the process of making those valuable things isn't "fun", but that's never been part of the equation. Aligning "fun" with "valuable" is nearly impossible, and when you try you're dooming yourself to almost certain failure.

This is really burnout, and the mental health effects that cause burnout. I'm sorry the author has gotten to this place, but wrapping it up in "passion" is a disguise.

Re: Laying myself off from Amazon

#105
post #16

Earlier quoted context omitted.

I've seen people complain about it who were wrong, but I've also seen people fail to complain about it when they really should have been. I just worked at a fang company, and here's an example - to search CI logs to see if a certain log happened frequently you would : WRITE A SCRIPT to download 100MB CI logs and search them for you.

Your example does not sound as outrageous as you seem to think - I can imagine a number of scenarios where this would be totally acceptable solution assuming we’re talking about software engineers here. Consider the fact that most startups don’t even have dedicated teams running CI unlike at fangs and it’s up to devs to set everything up. Yet I don’t really hear about folks complaining about internal tooling at early…

The fact that you don't think that's ridiculous is a great example of terrible tooling be accepted as "normal."

Any startup can get this by piping their jenkins (etc) logs into ELK/Splunk/Sumo. And indeed this is exactly what I built at the last startup I worked for.

But again I was talking about a FAANG company not having a way to search logs (again, each individual log file is 100mb and there are 100k of them generated a day).

If it's not clear why that's entirely unacceptable, imagine your team is running the CI for over 10,000 engineers and you're landing changes to this CI system daily. Engineers are seeing all kinds of logs and bugs daily and you need to ascertain if these errors are new, unique to some subset of jobs, lead to failed jobs, etc.

Re: Laying myself off from Amazon

#106

Earlier quoted context omitted.

Former Amazonian here. The learning is unmatched. I've been in different FAANGs but the way that Amazon pushes one to learn and challenge the status quo is unthinkable. I never saw "no, you can't do that, that system/business/area is sacred". Everything is up for grabs all the time. While there are pathological side effects to this (AWS promotion-per-launch, constantly battle for scope), the amount of knowledge one c…

Yet the internal tooling has been cited by several here as being one of the major time wasters and reasons they don't want to work there. It seems sacred to me...

I would say that 1) the experience varies by team 2) there's a lot of truth to that. But it's not a matter of being sacred, but the (sad) fact that Amazon being a ruthlessly data-driven business, investment on the tools and on reducing technical debt (real or perceived) is always prioritized down in OP1s.

Re: Laying myself off from Amazon

#108
post #80
post #73

I left Amazon in June of this year, in a similar-ish position to the author. I didn't have anywhere near that level of problems with the internal tooling[0], my frustrations were more related to seeing poor product prioritization decisions, neglect of tech debt, and repeated inefficiencies and mistakes in org-wide projects. Nonetheless, the feeling choosing to prioritize one's own mental health and recovery really re…

Curious, did you go somewhere that at least matched your salary? I know Amazon compensates very well, so much so that it's probably difficult to find something else unless it's another FAANG company. I have a friend working there who basically deals with all the not-so-good things mostly because the compensation is so good.

Haven't moved on yet (intentionally took some time off to relax and refresh), but I expect I'll have to take a bit of a pay cut.

> I know Amazon compensates very well

That's not been my understanding - I thought it was noticeably below other FAANG companies (at least until the pay hike earlier this year)? I have only just started reaching out to possible employers so I don't really have any points of comparison.

Re: Laying myself off from Amazon

#109
post #16

Earlier quoted context omitted.

I've seen people complain about it who were wrong, but I've also seen people fail to complain about it when they really should have been. I just worked at a fang company, and here's an example - to search CI logs to see if a certain log happened frequently you would : WRITE A SCRIPT to download 100MB CI logs and search them for you.

Your example does not sound as outrageous as you seem to think - I can imagine a number of scenarios where this would be totally acceptable solution assuming we’re talking about software engineers here. Consider the fact that most startups don’t even have dedicated teams running CI unlike at fangs and it’s up to devs to set everything up. Yet I don’t really hear about folks complaining about internal tooling at early…

If you're smaller you'd hopefully use something like Datadog, where you can easily ingest logs and have alert triggers from log lines. It's probably harder at bigger firms, where internal politics get in the way of having nice things.

Re: Laying myself off from Amazon

#110
post #102

Earlier quoted context omitted.

>I have never spent 40% of my time battling internal tools.... In my experience, not at Amazon, long tenure employees get used to the quirky tools but the impact on new employees can be massive. Same with bad code bases, bad documentation and so on.

I really think this is true. Like compare the CR process to Github's PR process. To me, it's horrendous. But to others who are embedded, maybe they love it.

Yeah, comparatively, I find Github's process to be bizarre. Why do I have to fork a repo just to propose a change to it? Why does my "Pull Request" (really it's a Push Request, but it's called a Pull Request because of the 2 repo requirement) have to be associated with a remote repo in the first place?

(I wouldn't say I love the CR process - making multi-package CRs is definitely flawed, and I had a Sage question open with the Builder Team for nearly a year where they admitted as much - but I certainly prefer it to Github's)

But I'm pretty new to the outside world and really keen to understand alternative perspectives. What's good about Github's process to you?

Post reply on HN