-Werror might help with that

Look up the section for Anatoly Dyatlov

The author, rather unfortunately, focuses primarily on the predation from the "generalized colleague", and that wasn't welcomed by many commenters, possibly because people in big-tech tend to be young and do need help, so have to ask for it.

But the way I see it, the predation is institutionalized in big companies.

-- The Intellectual Property department blocking the entire R&D of the entire product division for the whole day, to give a presentation on how to file a patent. Knowing full well that only a dozen of these people will every do, at best.

-- IT dept locking down everything, because, you know, there are risks and we don't want to take it. Doesn't matter if it slows down everyone else everywhere.

-- "Security" disabling access to slightest technical information, because, you know, someone could steal it. Just ask and you'll have access. (How does one asks for something one doesn't know exists?)

-- Purchasing that shortlists only some contracting shops and not accepting any others. Doesn't matter if the shortlisted one don't "carry" the competence (e.g., try EMC specialists).

All these people consider that as their achievements and are not shy about it when yearly appraisal comes. We all work as one team aren't we? And then comes the day of layoffs. One reason of it being that the R&D hasn't been performant enough. Guess what, we aren't so much of one team anymore.

See also: <https://en.wikipedia.org/wiki/Paris_syndrome>

I think you are arguing for the right cause but with wrong arguments. In C language, not understanding in details what exactly the code does, can be just as disastrous as in Verilog. Internet examples abound.

Not always. Switch your example to AARCH64 and check out the BFI instruction.

malloc () doesn't return even that. It returns 'void *' which isn't of much use without a further upcast. The required upcast, and the rest that follows, is the coder's own idea of what happens.

When I think that in my industry, good mastership of C++ is, what, 30% of what it takes... Throw in real-time design principles and a few different kernels, several CPU architectures, unavoidable Linux and a one or two build systems (Yocto anyone?). And only then comes the real problem domain, communications protocol stacks or image-processing algos, or what have you.

.. but then checking the returned val for error in every call sites is very far from mechanical change. (Attribute about unused return result can help here, with obvious drawbacks.)

I use that a lot in constexpr computations -- to stop the compilation, I usually do 'throw __LINE__'.

-- Using a more complex type is not warranted -- there is no catching end in constexpr.

-- And in case the same routine ends up called non-constexpr, it will be easy to identify the place that called 'throw' -- line numbers are unique without additional effort. Just don't put two throws on the same line.

"Empirical Study of Power Consumption of x86-64 Instruction Decoder"

https://www.usenix.org/system/files/conference/cooldc16/cool...

From the conclusion:

"The result demonstrates that the decoders consume between 3% and 10% of the total processor package power in our benchmarks. The power consumed by the decoders is small compared with other components such as the L2 cache, which consumed 22% of package power in benchmark #1. We conclude that switching to a different instruction set would save only a small amount of power since the instruction decoder cannot be eliminated completely in modern processors."

Mmmm .. maybe in this specific case (didn't look). But if you meant this as general advice, then one should keep in mind that unsigned overflows are specified but signed overflow is UB (barring maybe the very latest version of C standard); because of that, unsigned division in many cases is trivially optimised to less complex ops, etc.

There are many advantages in using unsigned.

> ... the low work ethic .. (I exaggerate, slightly).

is a very wide-sweeping generalization which insults many of us.

Why is it that, every time someone complains about "low work ethics", the underlying context is always "my employees don't want to spend mad hours working on my idea for the compensation I think should be fair for them"?

Work ethics goes both ways BTW, and your "glory to firing someone with less than six months notice" doesn't sit square with me. "firing" is terminating for serious misconduct, notice is not due. I assume you meant laying off for economical reasons. So you want exemplary work ethics from the employees, and then quickly get rid of them when you think you don't need them anymore, did I get that right?

Maybe you did run in to it but haven't mentioned, or maybe 5 years is not enough to see it -- have you noticed that a big part of the "remote culture" that few know how to build, is proper recognition of remote workers in the mixed- or dominantly-office- teams?

Those CEOs are perfectly aware that your life quality is higher than theirs on a much lower income, they know full well you are not going away anytime soon...