Live data from Hacker News

Laying myself off from Amazon

daniel.do

181–190 of 374 posts

Re: Laying myself off from Amazon

#181

This author sounds insufferable. Tooling sucks? Fix it. It's important to lead with a culture of quality and impact. Wasting 40 hours a month on something broken? It'd literally be faster to stop your feature work, fix that thing, and then go back to your feature work. Be the change you want to see.

I can only assume you've never worked at a company even close to the scale of Amazon. There's no such things as "fixing it" with a lot of these internal tools. They'll often have entire teams dedicated just to developing these tools. More often than not you won't even have access to the source code and even if you did it would probably be incredibly difficult to make any meaningful changes.

You say it would literally be faster to stop feature work and fix the broken thing which is a laughably naive view on how these companies operate. That's just not an option unless you do it all on your own time in which case you will still be incredibly limited on what you can change and even if you make a significant fix there will be no extra reward for doing so. The incentives are all wrong.

Re: Laying myself off from Amazon

#182
post #97

Earlier quoted context omitted.

You are pretty much validating that Amazon is a 2-year company, as reflected in their vesting schedule.

So basically you get most of your comp at 2 years? So crank hard for 2 years and then bounce?

You get most of your RSU comp after two years; vesting is back-loaded. Many (most?) people wash out before they collect, which obviously works out well for Amazon.

Re: Laying myself off from Amazon

#183
post #167

Earlier quoted context omitted.

Just what I thought, thanks for the confirmation. HN loves to take a number and just run with it, without verifying anything.

No, my requirement was actually 100%. I have no reason to lie about this. It’s set at a package level.

Was this just you or everyone on your team?

Re: Laying myself off from Amazon

#184
post #162

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…

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? Is a house designed by an architect not art?

Of course I see the art in those things, and in response i'll pay a lot more for a Frank Lloyd Wright than a mcmansion. But the customer of my B2B CRUD app does not care if my code looks like a FLW or a mcmansion. They care if it works.

Re: Laying myself off from Amazon

#185

Earlier quoted context omitted.

> There's a limited number of solutions to a programming task But this is literally and technically not true.

It is once you enter the real world of: costs (e.g. has to take N people X amount of time), resources available (may run only in a specific environment), performance requirements (has to solve the problem in a certain time), tools availables (you may have to solve it using a specific set of technologies), conventions (from coding style to required coverage to documentation), security and many other less measurable co…

Tell me you don't know what knowledge it takes to compose or work on a painting without telling me. Either of those tasks that we class as art also aren't simply "staring at a wall" waiting for inspiration either.

In either case you didn't specify constraints and even with those constraints it's still technically false unless you're limiting yourself to a non-turing form of computation. I'll take all your tasks with their constraints and add no-op operations onto them to make them ugly but still functional. I'll add in all kinds of ill-thought out logic that will never be reached or is "functionally" useless.

And even an "artist" has these "real world" constraints which are "must sell before starving to death" or the work won't be "completed"

Re: Laying myself off from Amazon

#186

> This is not counting the weeks where I was “on call” and forced to drop all of this to work on a backlog of DevOps related issues. I want to say sorry at the beginning if I misread what the author (you?) intended when you wrote this. And I'm coming at this from someone who is not a developer and who, compared to the lofty Software Engineer salaries in this industry, feels underpaid and underappreciated for doing th…

If your code breaks something, you should fix that code. Who else should?

If your system/product/service is down because you have a dependency on something that broke -- well it's up to that team to fix their code.

Re: Laying myself off from Amazon

#187

This author sounds insufferable. Tooling sucks? Fix it. It's important to lead with a culture of quality and impact. Wasting 40 hours a month on something broken? It'd literally be faster to stop your feature work, fix that thing, and then go back to your feature work. Be the change you want to see.

I'm sorry but you honestly have no idea of what you are talking about. The tooling in Amazon is developed by hundreds of engineers and it doesn't suck because of small bugs here and there but rather because of systemic issues related to how it's been architected. It's not something that is fixable at all, let alone by a lone engineer. That said, I also want to be more tempered than the author, I don't find the toolin…

My team was not native AWS at all. So yeah, huge variance based on what your team uses.

Also the guy you’re replying to has no idea what he’s talking about. If I had tried to do that my manager would have said “that’s not the work we have planned for you, that’s not the work our team does at all” and if I had just done it anyways (not that I think I could have) I’d have gotten fired.

Re: Laying myself off from Amazon

#188
post #108

Earlier quoted context omitted.

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.

Amazon's compensation wasn't anything special. The first two years were awesome because I got a $100K+ sign-on bonus prorated and tacked onto my paycheck every month. Once my first two years ended, my regular salary was pretty lackluster and I was easily able to find a job making a lot more elsewhere.

It's all about the RSUs. That all kicks in after year 2. If you're a lower level maybe you don't feel it as much. But for a high performing L6+ RSUs typically are -- or at least were designed to be -- the majority of your income compared to base pay.

Re: Laying myself off from Amazon

#189
post #140

Earlier quoted context omitted.

How, pray tell, is someone utterly unfamiliar with a code base supposed to be able to deal with unforeseen issues in production for that service? (Worse, the incentives for improvements to production quality, and thus on-call quality, are utterly mis-aligned.) Ironically, I say this as someone presently on-call for a bunch of stuff for which I am utterly unfamiliar with the code base of, and have no time to become fa…

On call isn't about fixing the problem yourself, it's knowing who the right person is to contact when an issue arises.

So just page that person directly (the dev, for the purposes of this argument).

(And because I feel like this is bound to draw a strawman, steelman this: while there are definitely pages that might not get routed to BE eng in particular, assume we're routing pages to the person responsible for that system. I.e., in the face of infrastructural problems, those pages get routed to something like "infra eng", although IME there's very little that can be done with those in the middle of the night…)

Re: Laying myself off from Amazon

#190

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…

[deleted]
Post reply on HN