Live data from Hacker News

Laying myself off from Amazon

daniel.do

211–220 of 374 posts

Re: Laying myself off from Amazon

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

>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 more money for such things.

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

What is "works"? I'm not being disingenuous here. The software development process is often plagued by things like scope creep, unreasonable asks from stakeholders, cutting things for budget or time etc...

"works" is a subjective concept in your hypothetical customer's mind. Likely molded by you or your project manager setting expectations, pushing back on feature requests, etc...

My real point is, it's not just the value of the consumer or "customer". But the artist as well. It's the satisfaction you can get from designing a performant service that handles requirements and has the capacity for future expansion, etc...

Just because some people are philistines doesn't make the creation any less valuable as a piece of art.

Re: Laying myself off from Amazon

#212

Earlier quoted context omitted.

Yup. Once you're doing staff-level IC work, most of your technical work is talking.

Maybe so, so long as we disagree with the notion that that the most senior engineers, the ones who are having "discussions" and making technical decisions, should not have to be active in the code, work with the development teams, and have a deep technical understanding about it works today. They don't have to have the highest commit counts, but if they're not the ones the rest of the development team look to for hel…

I mean, of course. That's part of the job: you can't search for multiplier effects without knowing what they are.

Re: Laying myself off from Amazon

#213

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've been at AWS for almost 6 years now. It depends on what you mean by "internal tooling". But considering all the tooling I've used over the years at least 75% of the internal tooling that was in use when I joined is no longer in use as it has been replaced by newer, better versions of what came before.

Things definitely move at a slower pace than at new startups, but systems within AWS still change at a pretty fast pace for such a large organization. A fair number of employees don't stay past two years because of how compensation works, so they don't stay long enough to observe tooling changes, and are left with the assumption that tools are sacred. The reality is that it takes about two years between major rewritten versions of most tools. Then there is a leap forward, stasis for a while while feedback is gathered and the limits of the existing tooling are found, then in roughly two years there is another leap forward, etc. This churn requires work to keep up with, so some teams also fall behind if their product team prioritizes features over keeping up, so they may also be stuck on old versions of tooling for even longer.

So in summary I'd say yes in the short term some of the tools appear sacred. In the long term pretty much every internal tool or framework is discarded and replaced by newer versions on a fairly regular cadence.

Re: Laying myself off from Amazon

#214

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…

Code isn't Art, it's Craft, or, to use the current buzzword "artisinal".

Software development isn't "engineering" by a long stretch. There is still another 40-50 years of development and consolidation before it could be considered the equivalent of other engineering practice.

I've lived through numerous lifecycles of "this time for sure" regarding software as engineering, from "modular programming" to "CASE" to "iterative development" to "UML" to (god help us all) "Agile".

What a lot of practitioners think of as "engineering" is actually "project management". Engineering is about defined practise, measurable inputs and outcomes, responsibility for signoffs and approvals that ensure that the defined practise has been followed.

Re: Laying myself off from Amazon

#215
post #167

Earlier quoted context omitted.

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?

everybody on my team. Are you seriously implying I was put on some kind of special "extra testing required" probation system where the unit test coverage requirement was upped from 95% to 100%?

Are you trolling?

Re: Laying myself off from Amazon

#216

IMHO you shouldn't have worked for Amazon in the first place. Most of what they do is more negative than positive for society overall. Good that you're out of there - please consider doing something more redeeming with your skills.

I wouldn't say that AWS is negative. That is seperate to the business of Amazon, which exploits warehouse and delivery employees, but is not unusual for the US.

Re: Laying myself off from Amazon

#217
post #92

Earlier quoted context omitted.

Find out what they drink for "Team alcohol evenings." Whiskey team? Ok, probably somewhat stressful but doable. Wine team? Plush and cushy, with a line of people who want to be on that team out the door. Vodka team? Oh hell no. Etc. ... I'm kidding. Sort of. But not entirely.

RedBull & Ketamine?

You’re probably thinking of a crypto exchange as the money exits the “backdoor”.

Re: Laying myself off from Amazon

#218

If you're thinking of joining big tech, try to join a team that develops an internal tool. You have as much impact and are exposed to as much scale (maybe not in terms of TPS but in terms of data, etc.), but you usually have much lighter development processes and a much more frequent release cycle. Your ops will also be a lot lighter.

> as much scale I'm an early career software engineer and am curious - why do people say working "at scale" like it's a good thing? Why is that desirable? What are you doing differently from someone who doesn't work "at scale"?

Making software work for single use is relatively simple, making software that runs at 100% uptime, with large numbers of "users"/"tasks"/etc is an entirely different level of development and design.

The actual functionality is a very small part of software development.

Making it work within its constraints (memory/CPU/network/storage in the small scale, ability to handle peaks while maintaining uptime at a larger scale), as well as dealing with the "non-functionals" like AuthN/AuthZ, obervability, performance, etc is actually the "hard part".

Then add in business "non-functionals" like "minimize CapEx/OpEx", "meet external SLAs with measurable and reportable KPIs", "meet corporate and regulatory standards and requirements" etc.

All of that is much larger than the actual function being developed.

Re: Laying myself off from Amazon

#219
post #215

Earlier quoted context omitted.

Was this just you or everyone on your team?

everybody on my team. Are you seriously implying I was put on some kind of special "extra testing required" probation system where the unit test coverage requirement was upped from 95% to 100%? Are you trolling?

It sounds kind of absurd really. I've never once been asked to sign a contract that required me to do 100% code coverage. As others have noted in the thread, it is like some mythical number any way. It sounds to me like this wasn't going to end well since the expectations were wonky from the start.

Re: Laying myself off from Amazon

#220
post #27

> I also know that every team at Amazon is different, so please don’t take my description for what it’s like working there as a whole. No, no, this sounds pretty much like every team I was on for the nearly-decade I was there.

Why did you waste 10 years of your life there if it was that bad to you? Legit curious here. I can’t imagine spending more than a couple months in an awful situation.
Post reply on HN