Does anyone know what role or title the the author might have had there? They mentioned DevOps but then also in another paragraph they mentioned front-end development.
Laying myself off from Amazon
31–40 of 374 posts
Re: Laying myself off from Amazon
#32How does this compare to your experience at CDC?
Re: Laying myself off from Amazon
#33Earlier 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.
No post body was provided.
Re: Laying myself off from Amazon
#34> 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… This gives the lie to Jeff Bezos' whole "Day 1" philosophy. If you're at a Day 1 company you don't spend 40% of your time fighting with the crappy internal tools.
I think what "Day 1" means at Amazon is that you're always still finding your footing, until you quit.
Re: Laying myself off from Amazon
#35Amazon's internal tooling really is the ninth circle of hell. It seems unsalvageable too; ostensibly the teams are supposed to be customer obsessed and the developers are the customer, but there's no accountability for anything to work well at all.
Well what are they (the developer-customers) going to do, buy from another vendor?
Re: Laying myself off from Amazon
#36My experience has been similar at other large companies (MSFT, Google). My advice is to look for founder-led teams (not companies). If there are plenty of founders still on the team, they will likely care a lot about the product and code and hold everyone to high standards which make the work easier in the long run. On the other hand when I've been on teams where all the original founders left, it's been a constant struggle to make anyone care about anything. At that point there is no ownership and most people are there for a paycheck. Lots of sloppy code gets shipped, everyone approves anything that looks like code, and eventually adding a single line anywhere feels like playing Russian roulette. Extreme short term thinking takes hold and no one cares that in 2-3 years the code will be unmaintainable because they don't plan to be on the team by then.
Re: Laying myself off from Amazon
#37I completely understand where the author is coming from. I did literally the same thing. I am fortunate to be in a similar circumstance where I have the savings to weather the storm. The only difference is I was working for a highly dysfunctional manager and team. Towards the last days before I resigned, I was nearly on the brink of panic attacks from every meeting I had with my manager. I could see that my skills as a developer in doing actual, meaningful work had severely atrophied in a short period of time. To anyone that had to make difficult decisions like this, do what is best for you and your loved ones because a job shouldn't define you.
Re: Laying myself off from Amazon
#38Worked 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.
How easy is it to transfer between teams? Some companies make this easy, others make it almost harder to apply internally then externally.
Re: Laying myself off from Amazon
#39No voluntary layoff plan you could take advantage of to get some severance pay? Might have been worth holding off a week to see if they rolled one of those out. Water under the bridge now, though.
Literally today -- about three hours ago, Amazon extended voluntary buyout offers to some employees.
Re: Laying myself off from Amazon
#40Earlier 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…
I've seen people complain about it who were wrong, but I've also seen people fail to complain about it when they really should have been. I just worked at a fang company, and here's an example - to search CI logs to see if a certain log happened frequently you would : WRITE A SCRIPT to download 100MB CI logs and search them for you.
Your example does not sound as outrageous as you seem to think - I can imagine a number of scenarios where this would be totally acceptable solution assuming we’re talking about software engineers here. Consider the fact that most startups don’t even have dedicated teams running CI unlike at fangs and it’s up to devs to set everything up. Yet I don’t really hear about folks complaining about internal tooling at early startups