Live data from Hacker News

Laying myself off from Amazon

daniel.do

201–210 of 374 posts

Re: Laying myself off from Amazon

#201
post #110
post #102

Earlier quoted context omitted.

I really think this is true. Like compare the CR process to Github's PR process. To me, it's horrendous. But to others who are embedded, maybe they love it.

Yeah, comparatively, I find Github's process to be bizarre. Why do I have to fork a repo just to propose a change to it? Why does my "Pull Request" (really it's a Push Request, but it's called a Pull Request because of the 2 repo requirement) have to be associated with a remote repo in the first place? (I wouldn't say I love the CR process - making multi-package CRs is definitely flawed, and I had a Sage question ope…

You can do PRs from branches in the same repo on GitHub just fine if you want to. Having them in a separate repo makes more sense because 1) it doesn't require the dev submitting a PR to have anything above and beyond simple read access to the target repo, and 2) there's no concern that someone might depend on WIP branches created in those private forks, so they can be deleted or rebased at will.

The reason why it's called a "pull request" is because you're requesting the owner to pull your changes in; I don't see what this has to do with the number of repos in the picture.

Re: Laying myself off from Amazon

#202

Earlier quoted context omitted.

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.

I seriously doubt it is actually 100%... let's verify that number.

It's quite possible to get line coverage to 100%. It doesn't really mean anything because it might be covering those lines getting executed in one very particular order - and all bets are off if that order is different.

Re: Laying myself off from Amazon

#203

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"?

If you look at tools in general as something that's intended to help other people solve some problem - and derive some enjoyment from that aspect of your job as a tool writer - tooling that operates "at scale" usually also helps more people.

Re: Laying myself off from Amazon

#204
If it works for you fine, but most of us just find another job and then resign. Few situations are intolerable for a few more months, although Twitter seems to qualify right now. As you said, you have a simpler financial situation that enables more flexibility, good for you!

Re: Laying myself off from Amazon

#205

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…

It doesn’t sound like burnout to me. It sounds more like organizational issues that have left the author with a very limited amount of time to work on a sluggish product they can’t take pride in. The name brand and pay sometimes just don’t make up for that especially for some people.

There’s nothing wrong with wanting to take pride in your work and to have working conditions that facilitate that. Get enough people together who feel that way and can find something useful to build and you get a huge competitive advantage. Software that is useful and performant is like gold but takes a lot of extra effort and passion to keep it that way.

You’re right about the “fun” part though. Making great software (and art) is hard work! “Satisfying” is probably a better metric to shoot for.

Re: Laying myself off from Amazon

#206

Earlier quoted context omitted.

that can't be right (but i have no idea). In the new group, nobody has any desire to at least do a reference check with the previous group? That would be the first thing as a hiring manager i would try to check for, say "this person is a d-bag that the entire group hated, and we were about to pip him/her anyway"? That would be kind of an equivalent of an approval, even if there is no formal approval.

I mean, yes, having your manager say "I will destroy your career if you think about leaving" would be a kind of approval needed, but short of that level of viciousness it sounds like no? Not familiar with Amazon culture so I don't know if that'd be considered acceptable behavior. I hope not!

have you considered that the manager may rightly have bad things to say? or that is just never warranted.

Re: Laying myself off from Amazon

#207
post #164

Earlier quoted context omitted.

I fundamentally disagree with the notion that design and discussion, of often very detailed technical aspects, is "non-technical work" of any kind, or that sitting down and writing code is the only "technical work".

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 help solving critical bugs and advice about new features and designs etc., then they have no business evaluating technical concerns.

Re: Laying myself off from Amazon

#208
post #69

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…

This is the general feeling of what I see from AWS support as well as a consumer of the platform. I'm battling something for weeks now which is a completely broken ass piece of shit inside AWS. I spent the first 3 weeks trying to get attention for this via support tickets and someone to take it seriously, resulting in escalating to account management. I've been on calls with the programme managers, been apologised to…

I know the types of companies that are Microsoft shops come with their own problems, but my quality of life via tooling at two Microsoft shops has been great.

Re: Laying myself off from Amazon

#209

My 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 s…

> My experience has been similar at other large companies (MSFT, Google). I would expect Google to have better engineering discipline than Amazon or Meta.

I spent 10 years at Google (left in April) and I do think it's much better than how Amazon is described in this thread. Not perfect, but really still quite good.

Re: Laying myself off from Amazon

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

They do start to care when it stops working or it takes forever to change due to it being a mess. This is the natural state most projects end up at unless the devs are putting in a ton of extra effort to keep it clean, organized and maintained. Devs that are thinking about keeping things beautiful, succinct and performant are much more likely to do that.
Post reply on HN