Live data from Hacker News

Laying myself off from Amazon

daniel.do

321–330 of 374 posts

Re: Laying myself off from Amazon

#321
I want to offer a different perspective. I work on EC2 and my experience is completely different.

Lots of good internal tooling. When something critical to us breaks, we usually cut high severity ticket to get other team's attention.

We rarely have actual customer affecting issues in production, there's no PIP threat, promotions feel achievable within a couple years if you really want them and the extra responsibility, automation is very helpful and we're constantly looking for ways to reduce our operational load.

Yes, testing could be better. Yes, we could have more engineers. Yes, oncall could be less stressful. Yes, I spend 10+ hours on meetings every week. Yes, I write a lot of documents and do a lot if ops to debug issues. I have probably merged just 10-20 lines if code in the last couple months.

But EC2 dataplane is very complicated. Every small change needs to be given a lot of thought. Success and scale bring responsibility. Plus, I've learned so much here. I'm never bored.

And my work life balance is good overall. Slightly less than 40 serious pomodoro hours a week except when oncall.

Ec2 is a very stable system and we keep making it more stable for our customers. Do use it. It's not brittle at all. Expect occasional instance failures and design around that with cross-AZ redundancy and you should be golden.

Re: Laying myself off from Amazon

#322
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'…

FWIW a personal “fork” is being made for you, the tooling just makes it invisible.

Re: Laying myself off from Amazon

#323
Daniel.

I can only wish you the best. 6 months ago, I was in your shoes. Today, I have my own startup building applications I am passionate about. I have never been happier. I’m grateful for everything that I’ve learned and endured so far.

I just wanted to tell you that I hope you stay positive even during the dark days and that you maintain your integrity. Truly, I wish you the very best.

Regards, Daniel :)

Re: Laying myself off from Amazon

#324

Earlier quoted context omitted.

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.

Yup, that's exactly what happened.

IME, the best managers are the ones who trust and enable their teams to make the right decisions. It would be a red flag if the manager was just giving out offers without allowing the team to provide their input.

Re: Laying myself off from Amazon

#325
post #241
post #42

Earlier quoted context omitted.

Poorly designed, failure-prone, brittle internal tooling was a time and energy sink Sometimes I get frustrated at my own job for some reason or another, but I appreciate learning that the grass isn't really greener anywhere else & even places where tech is the core business are having a lot of the same problems.

Well, it's definitely not greener at Amazon

It's green from all the cash lying around, but it is a blasted hellscape

Re: Laying myself off from Amazon

#326
post #273
post #262

Earlier quoted context omitted.

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

He's using RUST. Haven't you seen all the blogicles that explain how it's impossible to write bad code in rust??

Re: Laying myself off from Amazon

#327
post #78

Earlier quoted context omitted.

I've seen a lot of red flags in my career where managers put people on PIPs -- when in reality it's not a PIP but a personality conflict. And from what I understand at Amazon, it's kind of the same thing, but PIPs have been aggressively weaponized.

Christ, I wish PIPs were that easy where I work. Some days it feels like the public sector trying to get rid of employees that coast for months at a time before we can work our way through the process to can them.

Pips take months too, they're really not ideal

Re: Laying myself off from Amazon

#328

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…

I worked a contract there and the team barely understood how some of those configuration panes functioned. It was always a case of staring at someone else's config and then at yours until you found enlightenment. And the target kept changing, so there was a very bad week where my computer worked for 80 minutes total. I coded like hell during that time, pair programmed with the other contractors or did math on a white…

Man, that's crazy. You can go to big boy jail for that, haha.

When I quit Amazon, they ran to my desk and unplugged my dev machine, since they thought I was going to leave a software "time bomb". I thought that was the stupidest concern in the world, but maybe it does actually happen.

Re: Laying myself off from Amazon

#329
post #211

Earlier quoted context omitted.

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

>all those things have sale values that DIFFER based on that creativity and beauty. Code does not. I wouldn't be so sure about that. I certainly prefer to use software that has a nice interface, is fast and responsive and has thoughtful features. I remember the first time my iPhone opened a pop up at just the right time asking if I wanted to share a wifi password with my Mac. Wow! Delightful. And I am willing to pay…

I’m sorry but this is complete nonsense; there is no pleasure derived from viewing “beautiful” code from the perspective of the consumer such as in your other examples.

A program is not like a car, a chair, or a house, and if any of this were brought up in a design meeting for code, you’d rightfully be laughed out of the meeting.

But it’s fine to disagree about these things up to the moment where you attempt to slow progress towards delivery for these values. At that point, the point at which functionality is hindered in any way by your artistry, are you now a problem on a development team.

There are plenty of productive ways to deal with problems, but make no mistake, on any competent software team you will be disabused of this “art” notion, not the other way around.

Re: Laying myself off from Amazon

#330

Earlier quoted context omitted.

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

Those principles are so obnoxious. You can use them to justify or excoriate literally any action at any time.
Post reply on HN