[amzn-throw]

Amazon 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 my time battling internal tools....

> 20% of my time in meetings

Developers complain when they're not invited to meetings, and they complain when they're invited. On my team we brutally introspect the value of every meeting, and if it looks like it's not delivering value, we find a new process.

> 20% of my time writing unit tests to hit the 100% coverage requirement of the codebase I worked on.

This makes no sense. This isn't a company mandate, every team is free to determine what code coverage percentage makes sense for them. Give this feedback to your tech lead, nearest Sr. SDE or PE -> 100% test coverage should never be "required"

> 10% of my time tracking down bugs in other team’s codebases for either internal tools or frameworks and trying to get them to acknowledge the problem by filing tickets.

So, software engineering?

[gruffle]

> On my team we brutally introspect the value of every meeting, and if it looks like it's not delivering value, we find a new process

Oh yeah I love the multiple hours we have spend every week 'introspecting' processes, just to throw out one of the dozen we'd already defined and add another one. And this 'introspection' typically boils down to the loudest, most ambitious mouthbreathers forcing their BS down everyones throats so that they can jot down their amazing process contributions in their promo doc. Brutal is the right word.

[amzn-throw]

Who hurt you? Do you even like software engineering?

Quit, and go make sourdough bread, shit.

[marcinzm]

>I have never spent 40% of my time battling internal tools....

In my experience, not at Amazon, long tenure employees get used to the quirky tools but the impact on new employees can be massive. Same with bad code bases, bad documentation and so on.

[amzn-throw]

Maybe so, but don't you think I talk to new employees? It's half of my job to support my whole team and deliver through others.

I battled those tools when I started. I watched them get better.

I've seen what new hires struggled with 5 years ago and what they struggle with 1 year ago.

Night and day.

The tools have gotten a lot better.

Here's the other ugly truth: That "40% of struggling with internal tools" may be saving the engineer 300% of time of having to implement the same from scratch themselves. Software engineering isn't all algorithms and data structures. A lot of it is just boilerplate code hooking up A to B. And better leave that boilerplate code to the internal tool that you have to figure out how to configure than implement it yourself.

[dimmke]

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.

[zeroonetwothree]

I’ve never complained about not being invited to a meeting. I’d be happy never going to a single one.

[scubbo]

> The tools for code submission, pull requests, pipelines, metrics, and logging are fantastic.

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.

[fdgsdfogijq]

Yeah I actually think this guy was just underperforming