Live data from Hacker News

Laying myself off from Amazon

daniel.do

271–280 of 374 posts

Re: Laying myself off from Amazon

#271

My experience has been similar at other large companies (MSFT, Google). My advice is to look for founder-led teams (not companies). If there are plenty of founders still on the team, they will likely care a lot about the product and code and hold everyone to high standards which make the work easier in the long run. On the other hand when I've been on teams where all the original founders left, it's been a constant s…

> My experience has been similar at other large companies (MSFT, Google). I would expect Google to have better engineering discipline than Amazon or Meta.

I can't comment on Amazon, but I find the engineering culture very similar at Meta and Google, having worked at both.

olladecarne's story lines up very well with my own experience working on a post-startup-acquisition org at Google.

Re: Laying myself off from Amazon

#272
I spent just over a year up here at the Seattle mothership back in the mid-20-teens. I met a few really smart / kind people that I'm still friends with (I even liked my boss, who I'm going to have coffee with after the holiday craziness.) I last a year. Most everyone I know there I know left.

My experience was similar. On the first day of orientation we were trying to build an environment to run some tests in. But some aspect of it was borked. I got to file a Sev 2 ticket my first day of work. The component that completed the dependency closure was borked (what was that, brazil? can't remember the name.) But the whole company spent two hours not building software.

I love that all teams advertise their capabilities through online services, but man.. it would have been cool if maybe they tested that update to the build system since we were all forced to use it.

The other big hilarious problem was when we ran out of IP addresses for new sites. Long story short someone made a mistake three or four teams up the chain and it only became obvious when we tried to allocate a new routable (public) IP address. The problem was in the DNS team, but we didn't use their service interface directly, so we had to wait while the team upstream of us responded. And then they had to file a ticket with the team upstream of them. And so on.

It always seemed to me that while they were trying to prevent their interfaces from being brittle, they missed out on some opportunities to understand what was going on by looking at data flowing from one team to another. I hope there's SOMEONE in the company doing that, but we never met them.

Not all my work relationships were toxic, but I saw quite a bit of toxicity while there.

I quit the day after my then new boss wore a MAGA hat to work and made comments about killing trans-folk (I'm f2m.) Our HR rep was out on vacation and the main office indicated they weren't interested in doing anything about it. I probably should have sued, but it wasn't clear I had a strong case (he said/xe said). At the very least I could have forced everyone to take another sensitivity training class.

Which is to say... There are some amazing people there. Also some complete shits. If you have a high tolerance for death threats, you'll probably do fine there. Some of the technology is amazing. Some of it is completely bonkers. When things are good, they're amazing and very good. When they're bad, they're hellish.

Re: Laying myself off from Amazon

#273
post #262

Earlier quoted context omitted.

I've made a great career of being a code janitor and doing what others don't want, while having a good attitude. In the last few years, I just rewrite everything I possibly can in Rust and I've yet to regret it.

> I just rewrite everything I possibly can in Rust and I've yet to regret it. And hopefully no one else regrets it...

By then you're onto the next thing and it's their problem, right?

Thus is the circle of (engineering) life.

Just kidding. Please write maintainable code.

Re: Laying myself off from Amazon

#274
post #240

Earlier quoted context omitted.

I cannot code in prod anymore and have definitely been looking to develop a habit like this. Any tips from you and others on: a) How to make it stick b) How to maximize its efficacy/efficiency Would be awesome.

There are no tricks, that's just a distraction. Just sit down and do it. Ass in chair gets you there.

Thanks for this. This is the right answer to 95% of "how do I" questions.

Re: Laying myself off from Amazon

#275

Earlier quoted context omitted.

Everytime I bypass some stupid process or break glass, I now just put 'bias for action' as the reason. Ahahaha I don't give a shit anymore.

That one is my favorite. At Amazon, "bias for action" is a knee-jerk managerial phrase that typically means, "I'm going to spew ambiguous/ignorant bullshit into the room and you do something meaningful with it."

“Disagree and commit” aka “bend over and take it” is my personal fave

Re: Laying myself off from Amazon

#276
post #69

Earlier quoted context omitted.

This is the general feeling of what I see from AWS support as well as a consumer of the platform. I'm battling something for weeks now which is a completely broken ass piece of shit inside AWS. I spent the first 3 weeks trying to get attention for this via support tickets and someone to take it seriously, resulting in escalating to account management. I've been on calls with the programme managers, been apologised to…

I know the types of companies that are Microsoft shops come with their own problems, but my quality of life via tooling at two Microsoft shops has been great.

Do you mean Azure? I don't quite follow your comment.

Re: Laying myself off from Amazon

#277
post #162

Earlier quoted context omitted.

A few years ago I visited New York City and went to the MoMA. At the time, they had an entire floor dedicated to mid century design. I was always particularly taken with the Kennedy Armchair and the Eames lounge chair. Those pieces to me are undoubtedly art. But they also serve a function. They're chairs. A business analyst once told me - "you programmers have it so easy. It either works or it doesn't!" as if the vag…

So you've listed houses, cars, watches, food. All these things indeed serve a purpose as well as allow for creativity and expression. But the difference is, all those things have sale values that DIFFER based on that creativity and beauty. Code does not. My customer does not care if my backend code is beautiful, and neither does my CEO because it won't make more money. > Is a dish or menu designed by a chef not art?…

[deleted]

Re: Laying myself off from Amazon

#278
post #224

Earlier quoted context omitted.

You can do PRs from branches in the same repo on GitHub just fine if you want to. Having them in a separate repo makes more sense because 1) it doesn't require the dev submitting a PR to have anything above and beyond simple read access to the target repo, and 2) there's no concern that someone might depend on WIP branches created in those private forks, so they can be deleted or rebased at will. The reason why it's…

> You can do PRs from branches in the same repo on GitHub just fine if you want to. Having them in a separate repo makes more sense because 1) it doesn't require the dev submitting a PR to have anything above and beyond simple read access to the target repo Right, that's my point, though - why is there no distinction between "ability to create a real, actual, complete branch on a repo" and "ability to create a 'fake'…

I see your point. FWIW I personally like it because it lets me move between my desktop and my laptop almost seamlessly - just push any changes on one end, and pull them on the other. It also means that, if any (or even all) devices suddenly die on me, whatever I was working on is still safely in my private repo.

But, yes, this does mean pushing things routinely a lot, not just when it's time to make a PR.

Re: Laying myself off from Amazon

#279

Earlier quoted context omitted.

Hiring managers have a lot of latitude at Amazon, so there isn't a consistent standard. I don't want to share too much PII but I was in a similar situation. I was able to transfer teams after an informal chat with a few engineers on the team (discussing past projects, the new team's product vision, etc.). There was no whiteboarding involved.

So the internal hiring managers are there for no reason at all?

The hiring managers are themselves managers of the team e.g. for a team of devs, a software development manager. In parent comment's case, the manager likely asked for opinions from the team after the chats before giving the final approval.

Re: Laying myself off from Amazon

#280

Worked for AWS for just under a year and a half; this mirrors my experience exactly. Poorly designed, failure-prone, brittle internal tooling was a time and energy sink to the point where even the most trivial deployment change was a nail-biter. Automated tooling and tests that were ostensibly created to make life easier were the number one pain point and constantly failed in obscure ways that required cutting ticket…

> Poorly designed, failure-prone, brittle internal tooling was a time and energy sink to the point where even the most trivial deployment change was a nail-biter. Considering rather good quality APIs they expose to the external world, this is shocking to read.

Good is a big word, but they exist and have docs. A lot of the time the docs are even correct, if you can find them.
Post reply on HN