Hacker News Reader

Comment by wmichelin | Hacker News Reader

This author sounds insufferable. Tooling sucks? Fix it. It's important to lead with a culture of quality and impact. Wasting 40 hours a month on something broken? It'd literally be faster to stop your feature work, fix that thing, and then go back to your feature work.

Be the change you want to see.

View on HN

I can only assume you've never worked at a company even close to the scale of Amazon. There's no such things as "fixing it" with a lot of these internal tools. They'll often have entire teams dedicated just to developing these tools. More often than not you won't even have access to the source code and even if you did it would probably be incredibly difficult to make any meaningful changes.

You say it would literally be faster to stop feature work and fix the broken thing which is a laughably naive view on how these companies operate. That's just not an option unless you do it all on your own time in which case you will still be incredibly limited on what you can change and even if you make a significant fix there will be no extra reward for doing so. The incentives are all wrong.

I'm sorry but you honestly have no idea of what you are talking about. The tooling in Amazon is developed by hundreds of engineers and it doesn't suck because of small bugs here and there but rather because of systemic issues related to how it's been architected.

It's not something that is fixable at all, let alone by a lone engineer.

That said, I also want to be more tempered than the author, I don't find the tooling to be that bad. Most teams are on full Native AWS now and the few non-native tools actually do make your life easier because of how well they're integrated in the whole Amazon ecosystem.

Some tooling does suck, but it's more like 2% of my time spent fighting bad tools, not 40%.

My team was not native AWS at all. So yeah, huge variance based on what your team uses.

Also the guy you’re replying to has no idea what he’s talking about. If I had tried to do that my manager would have said “that’s not the work we have planned for you, that’s not the work our team does at all” and if I had just done it anyways (not that I think I could have) I’d have gotten fired.

Lol. If the author had really tried to fix the internal tooling by himself in such a top-don huge corp like Amazon, he would've gotten himself laid off much quicker.

Easier said than done. Amazon is a top-down org, where each pod's (aka pizza team) work is planned 12-18 months in advance through their OLR process.

OLR is employee performance reviews.

OP1

You are grossly underestimating the effort it takes to change things at a company this size. Ignoring the scope of the technical work to be done, you cannot just send diffs to another team and expect them to just accept them.

But the problem is, fixing existing broken stuff might not be rewarded as much as working on the "new feature". This means that if I focus on just fixing the broken stuff, I'd be managed out. Even say I put in the extra effort to fix the broken stuff, and deliver my new features, other thousands of engineers won't do that same- meaning I can't make a meaningful dent.

(i dont work for amazon, but I can imagine it's similar everywhere)

Reply on news.ycombinator.com