> 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…
Laying myself off from Amazon
71–80 of 374 posts
Re: Laying myself off from Amazon
#72You should have waited few days for the package.
Re: Laying myself off from Amazon
#73[0] which I've found to be pretty-to-extremely-good compared with what I've discovered since leaving, and would actively welcome new perspectives on what flaws I'm missing.
Re: Laying myself off from Amazon
#74Earlier quoted context omitted.
Not sure what the Amzn situation is but something I've noticed at few previous gigs that there're some folks who claim they spent significant time wrestling with tooling but when you actually go in and make them formulate the issue it's either something really obvious or a 10-min google/github search like 9/10 times. These also weren't coming from people who I considered lazy or unintelligent (well, for the most part…
When it’s an internal tool you can’t google it. You search through internal wikis that haven’t been updated in years
Re: Laying myself off from Amazon
#75Writing tests is dysfunctional? Funny, I thought that was part of the job.
it is when the focus is on having 100% coverage and not on test quality. When 100% becomes the metric it tends to get gamed pretty heavily with tests that have such a huge amount of mocks as to make the tests useless, or doing something to make it hit a branch, but ignoring actually verifying it cause that branch is just a log statement.
Re: Laying myself off from Amazon
#76Amazon 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…
THANK YOU. I feel like I'm taking crazy pills whenever I see people bash Builder Tools - Pipelines in particular. Compared with what seems to be available in the Open Source world, it's fucking stupendous, and has silky-smooth integration.
Re: Laying myself off from Amazon
#77Earlier quoted context omitted.
I thought that the deployment pipelines are part of their core business considering AWS has such products that are meant to be used by customers. I assume that the internal tools are different than what AWS customers use for deployments?
A lot of internal teams don't use the AWS software for various reasons. So like, CodePipeline might be great, but there's an internal analogue (I'm not sure the detail I can go into here) that is awful that a lot of teams use. There's been an internal movement to try to get all teams onto AWS services, but it's incredibly slow moving and there's no timeline that I know of.
Re: Laying myself off from Amazon
#78Earlier quoted context omitted.
How easy is it to transfer between teams? Some companies make this easy, others make it almost harder to apply internally then externally.
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…
And from what I understand at Amazon, it's kind of the same thing, but PIPs have been aggressively weaponized.
Re: Laying myself off from Amazon
#79Worked 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…
You should have just switched teams. Amazon has amazing teams working on deep technology, they also have huge systems with technical debt and stress. People dont realize how different it can be inside the company.
Btw this happens in most companies, tons of tech debt. And those who created that st are off onto new projects recreating the exact same mess all over again.
It is a cycle that never ends.
Only chance is to join early and be in for the long run.
Re: Laying myself off from Amazon
#80I left Amazon in June of this year, in a similar-ish position to the author. I didn't have anywhere near that level of problems with the internal tooling[0], my frustrations were more related to seeing poor product prioritization decisions, neglect of tech debt, and repeated inefficiencies and mistakes in org-wide projects. Nonetheless, the feeling choosing to prioritize one's own mental health and recovery really re…