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.
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.
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.
>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.
I’ve worked in demanding startups where I question my own competence and lethargic enterprises where I’ve never felt more under challenged. It’s hard to find a good job that strikes a nice balance.
Fraud is a complete overreaction. A fraud might be someone posing as a doctor with no doctoral degree, or an electrician with no such training. Software is so broad and has no real, agreed upon training that it simply a gap between what an employer thinks someone can do and what they can actually do.
Fraud is a bit strong, but there are many people that have mastered the art of beating that particular system. I've met engineers that have become exceptionally good at pattern matching to the FAANG hazing ritual but which otherwise have unremarkable engineering skill.
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.