[taeric]

To be fair, you'd also be shocked to learn how many top developers will rarely need any of those tricks. Even more shocking, to learn that FAANG developers are just as guilty of many of these "sins."

Take the uploading to s3 point. If you are saturating your network... going multithreaded will do nothing. If you are not, find out why.

The other examples are also lacking a lot of details. 30 seconds of latency can be bad, of course. But so can adding concurrency to a team that doesn't understand it well. (Really, this one sounds like it just needs more context. I'd normally push to remove extra calls moreso than jumping to concurrency. But, each has its place.)

Edit: And the logs... this is just a result of not putting cost as a tracked item for teams. Too many folks fall afoul of a hoarder mentality when it comes to logs.

[staticassertion]

FAANGs are full of terrible programmers. It's obvious. What they do have though is a higher number of good programmers, and they try to leverage them as best they can to make use of the bad ones.

[taeric]

I hesitate to call them terrible. Developing is a hilariously multi paradigmed skill that is tough to train. Such that a good programmer may make a terrible developer, without the appropriate supporting team.

Similarly, an otherwise great developer can be horrible in a team that doesn't know how to use them.

[carlmr]

>The other examples are also lacking a lot of details. 30 seconds of latency can be bad, of course. But so can adding concurrency to a team that doesn't understand it well.

It might also be that it's not worth spending effort on speeding up some script like this. How often does it run?

Do these 30 seconds matter? Maybe they do now but they didn't in the beginning, but then that's ok, too, and you refactor.