Laying myself off from Amazon • Hacker News Board

Re: Laying myself off from Amazon

#161

Post by gruffle » Thu, Nov 17, 2022, 1:10 AM UTC

amzn-throw wrote: post #133

marcinzm wrote: post #43

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.

Maybe so, but don't you think I talk to new employees? It's half of my job to support my whole team and deliver through others. I battled those tools when I started. I watched them get better. I've seen what new hires struggled with 5 years ago and what they struggle with 1 year ago. Night and day. The tools have gotten a lot better. Here's the other ugly truth: That "40% of struggling with internal tools" may be sav…

> Maybe so, but don't you think I talk to new employees?

Everyone below a certain level talks to new employees. Do I believe you take their concerns seriously and actively try to help? Based on my own experience with PEs as well as your comment history I think you absolutely do not.

In general my experience with PEs at Amazon led me to conclude that the vast majority of them are:

- entitled

- lazy

- egotistical

- less technically useful than the average l5 engineer

Re: Laying myself off from Amazon

#162

Post by dimmke » Thu, Nov 17, 2022, 1:13 AM UTC

matai_kolila wrote: post #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…

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 vague 2 sentence requirement from their spreadsheet that I have to turn in reality doesn't require any creativity to implement.

But what about the edge case they missed? How should I design the control flow of this? How should it handle errors? In a lot of cases, how should it look, because I only received a wireframe? Should I write this as a class or a function? Can I write this code in a way this is easy to read and performant? What if it's a really specific piece of business logic, that doesn't make sense unless you know the reasoning for it?

Good software is art the way a well designed car or watch is art. They exist to accomplish a function, but the path to get there often requires quite a bit of creativity and expression. Your assertion that art requires no function doesn't make sense.

Is a dish or menu designed by a chef not art? Is a house designed by an architect not art? I feel sorry for people who can't see the art in those things. And especially sorry for people who can't see the art in writing code.

Re: Laying myself off from Amazon

#163

Post by Zvez » Thu, Nov 17, 2022, 1:16 AM UTC

anyfoo wrote: post #135

I did not feel super sympathetic when reading the breakdown of percentages (with only 10% "actually writing code"). Yeah, those specific percentages were a bit egregious, but working on a big project it's not uncommon at all to spend more time thinking and talking things through than to actually write code. There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually eng…

>There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually engineering

In my experience there is almost no correlation between complexity of the project and time needed to do 'non-technical' work. Quite contrary, the most complex things I did as a dev required me to do a lot of coding - to prototype, to experiment, to load testing and so on.

And at the same time the easiest project in the larger corporations required me to write down design docs for trivial stuff and spent months in meetings to 'align' with people, who don't have time to even read your design doc, but want you to have bi-weekly meeting about it.

So no, I don't buy this excuse anymore. Unless you are building space ship or do very unique work, there shouldn't be any need to spend 80% of your time in non-strictly-technical work.

Re: Laying myself off from Amazon

#164

Post by anyfoo » Thu, Nov 17, 2022, 1:22 AM UTC

Zvez wrote: post #163

anyfoo wrote: post #135

I did not feel super sympathetic when reading the breakdown of percentages (with only 10% "actually writing code"). Yeah, those specific percentages were a bit egregious, but working on a big project it's not uncommon at all to spend more time thinking and talking things through than to actually write code. There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually eng…

>There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually engineering In my experience there is almost no correlation between complexity of the project and time needed to do 'non-technical' work. Quite contrary, the most complex things I did as a dev required me to do a lot of coding - to prototype, to experiment, to load testing and so on. And at the same time the e…

I fundamentally disagree with the notion that design and discussion, of often very detailed technical aspects, is "non-technical work" of any kind, or that sitting down and writing code is the only "technical work".

Re: Laying myself off from Amazon

#165

Post by Zvez » Thu, Nov 17, 2022, 1:25 AM UTC

matai_kolila wrote: post #132

at_compile_time wrote: post #117

Earlier quoted context omitted.

Code may not be art, but there is beauty in design.

Beauty doesn't put food on the table, is my point, and I'm beyond sick of working with people who put "code beauty" before "code usefulness". Ugly code that works pays bills. Beautiful code that doesn't work is, in a very literal sense, worthless. I'm not against writing clean code (there's utility in that), but I feel like some folks lose the plot and quit their jobs when they can't make "beautiful" things anymore,…

>Ugly code that works pays bills. Beautiful code that doesn't work is, in a very literal sense, worthless

what about good code that work? All places where I see your argument prevail, ended up to be not just 'ugly code', but unmaintainable code. And systems that cannot evolve at all.

Personally I don't call coding an art, but I've seen countless times how people people choose bad solution even though better one costs exactly the same, and in a long run - actually cheaper. And they _always_ use this argument - 'code is just a tool, if it solves the problem, it is good'. And then they either leave or have to spend weekends to write even more dirty code just to solve problem they wouldn't have in the first place if they spent a little bit more time thinking about the code.

Re: Laying myself off from Amazon

#166

Post by Spivak » Thu, Nov 17, 2022, 1:31 AM UTC

closeparen wrote: post #155

epolanski wrote: post #124

Earlier quoted context omitted.

I hate this whole idea that coding is a creative (in the artistic sense) activity. There's a limited number of solutions to a programming task, it's about finding the one that meets most constraints, it's about cost, effort, trade offs analysis and finally implementation.

Getting code to do the right thing is an engineering activity. Getting code to make sense, to communicate an accurate and useful sense of the problem and solution space to yourself and others across time and change, is a humanities activity.

Thank you! Writing code is a creative exercise not because there are infinite solutions to a given problem but because your solution must be one that clearly communicates it’s own intent both to the machine and to the next humans who read it and give certainty to those humans that they can make changes without tripping over load bearing coconuts.

Re: Laying myself off from Amazon

#167

Post by dimmke » Thu, Nov 17, 2022, 1:38 AM UTC

latchkey wrote: post #100

yazaddaruvala wrote: post #93

Earlier quoted context omitted.

When I was at Amazon, the general consensus was 90-95% but not higher. We also excluded all of our Java Spring/Guice configs.

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.

Re: Laying myself off from Amazon

#168

Post by wmichelin » Thu, Nov 17, 2022, 1:42 AM UTC

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.

Re: Laying myself off from Amazon

#169

Post by nicksf » Thu, Nov 17, 2022, 1:50 AM UTC

wmichelin wrote: post #168

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.

Easier said than done. Amazon is a top-down org, where each pod's (aka pizza team) work is planned 12-18 months in advance through their OLR process.

Re: Laying myself off from Amazon

#170

Post by OnceUponADevops » Thu, Nov 17, 2022, 1:55 AM UTC

bb88 wrote: post #78

goostavos wrote: post #56

Earlier quoted context omitted.

I've been on 4 different teams at Amazon (now migrating to a 5th). It depends entirely on the team and as well as your current level. Some do loops just like with external candidates. Others barely require more than a conversation with someone on the team -- though this one is a huge red flag. Teams looking for warm bodies are seldom good teams. Most of the time its somewhere in between. You'll speak with the manager…

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.