Live data from Hacker News

Laying myself off from Amazon

daniel.do

51–60 of 374 posts

Re: Laying myself off from Amazon

#53
post #41
post #5

Earlier quoted context omitted.

>I'd actually force myself to write even trivial code on weekends to ensure my ability to develop didn't atrophy as a result of lack of use. I did not mention this in my blog post, but I have actually done similar. That's incredible. Thanks for sharing this comment. Our tenures were almost the exact same length too.

When I worked for a BigTechCo, I was doing exercism every single morning for ~30 minutes for the same reason. It really is incredible. I know a few of my former colleagues were doing the same. Today I'm on a team with 4 other engineers, so I keep busy coding.

I cannot code in prod anymore and have definitely been looking to develop a habit like this. Any tips from you and others on:

a) How to make it stick

b) How to maximize its efficacy/efficiency

Would be awesome.

Re: Laying myself off from Amazon

#56

Earlier quoted context omitted.

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.

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, speak with the team, you each review each other's artifacts, and if everyone's happy, you swap over. The balance of power is pretty nice. I've dropped out of the process many, many times after starting talking with management. Or even just learning more about what the team itself does (I couldn't live with myself if I worked on pre-roll ads, for example. So I noped out of that one).

Re: Laying myself off from Amazon

#57

Writing tests is dysfunctional? Funny, I thought that was part of the job.

You appear to have forgotten, for example, the "40% of my time trying to tame the bad internal tooling I was forced to use…".

Did you read any of his other posts on his blog?

He's a digital nomad who took off to Mexico (and Belize) and seems a bit lost in where he is going (he says it himself). I've been there myself (except I moved to Vietnam), so I understand it.

This is a lot deeper than just writing tests or 40% internal tooling issues. I also suspect that being remote, he feels like his hands are tied in a company that isn't used to working remotely. Or at least, if I was struggling with tooling, I'd work to find a way to make it better.

I also never complain about writing tests. I can't tell you how many times tests have saved my bacon or resulted in writing cleaner code.

Re: Laying myself off from Amazon

#59
post #44

Earlier quoted context omitted.

I don't think I've ever heard a testimony of Amazon having good work life balance. The best you hear is that some people get lucky and things are "ok" on that front.

My work life balance at Amazon as an SDE is great but I don't have 24/7 oncall, make of that what you will. That being said, I agree that the internal tooling at Amazon is not that great. It's actually a place where newer employees tend to clash with older Amazonian because it compares unfavourably with GitHub actions or any modern CI/CD while being significantly better than anything that existed in the early 2010s.…

This is really baffling to me. In fact, since leaving Amazon in June, I've been really frustrated by how much extra work setting up a CI/CD pipeline is in (say) Drone and Argo/Flux than with Amazon's internal tooling. You can set up a standard Amazon pipeline with a single command and answering a few prompts about naming, whereas with the open-source systems you have to hand-craft everything yourself, hack in a way to update the infra repo every time the source repo changes (I blogged more about that here: https://blog.scubbo.org/posts/ci-cd-cd-oh-my/), and it seems like Drone literally doesn't have metrics that indicate broken builds. To say nothing of how well-integrated Pipelines is with alerting and ticketing - yet _another_ integration you would have to build for yourself in OSS-land.

Literally the only advantage I'm aware of for OSS systems is that they allow you to use whatever language, dependencies, build system, etc. that you want - which, yes, fair, if that's something that you need, then that's a deal-breaker, but for the 99.99...% of internal cases that Pipelines works for, it (seems to me to) work flawlessly and smoothly.

What are some unfavourable comparisons that I'm missing?

Re: Laying myself off from Amazon

#60

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

> This gives the lie to Jeff Bezos' whole "Day 1" philosophy.

You can also interpret it like - “always start from scratch. You don’t have anything”

Post reply on HN