Laying myself off from Amazon

Post by nso95 » Thu, Nov 17, 2022, 5:26 AM UTC

dfxm12 wrote: post #42

nyarlathotep_ wrote: post #3

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

Post by amzn-throw » Thu, Nov 17, 2022, 5:30 AM UTC

gruffle wrote: post #87

amzn-throw wrote: post #17

Amazon has a lot of bad internal tools, but this person's experience doesn't match mine (being here for 8 years) at all > 40% of my time trying to tame the bad internal tooling I was forced to use to submit my code, get it merged, deploy it, check logs, etc… The tools for code submission, pull requests, pipelines, metrics, and logging are fantastic. Google is better. Most companies aren't. I have never spent 40% of m…

> On my team we brutally introspect the value of every meeting, and if it looks like it's not delivering value, we find a new process Oh yeah I love the multiple hours we have spend every week 'introspecting' processes, just to throw out one of the dozen we'd already defined and add another one. And this 'introspection' typically boils down to the loudest, most ambitious mouthbreathers forcing their BS down everyones…

Post by throwawaylinux » Thu, Nov 17, 2022, 5:40 AM UTC

eropple wrote: post #212

throwawaylinux wrote: post #207

Earlier quoted context omitted.

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.

Post by gruffle » Thu, Nov 17, 2022, 5:55 AM UTC

amzn-throw wrote: post #243

gruffle wrote: post #87

Earlier quoted context omitted.

> On my team we brutally introspect the value of every meeting, and if it looks like it's not delivering value, we find a new process Oh yeah I love the multiple hours we have spend every week 'introspecting' processes, just to throw out one of the dozen we'd already defined and add another one. And this 'introspection' typically boils down to the loudest, most ambitious mouthbreathers forcing their BS down everyones…

Who hurt you? Do you even like software engineering? Quit, and go make sourdough bread, shit.

Post by gruffle » Thu, Nov 17, 2022, 6:02 AM UTC

Aeolun wrote: post #239

gruffle wrote: post #68

Earlier quoted context omitted.

Completely agree. Interesting how the internal dev satisfaction polling always shows that the vast majority of devs just absolutely love the internal tooling and processes. Might have something to do with the polls not actually being anonymous. When hr/polling teams are asked about anonymity they generally skirt or ignore the question, but I've learned that enough metadata is collected to identify any responder in pr…

Why would you respond positively even on non-anonymous polls? The goal is to determine the state of the internal tools, not to purge any dissenters…