Thought it was about electric fence the malloc debug library, and was surprised to see so many comments. Turns out it is not mentioned at all in the comments, so correcting that :)
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.
> And even if you write inefficient code, CPUs are so fast that you won't notice it.
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.
> ... malloc() returns a pointer to sequentially-addressable bytes ...
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.
> It's also hard to know anything other than C++, because of how taxing the language is; there's little energy left in you to learn something else.
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.
I spent time typing in a setup with very dim ambient light (think of a photo room with dim red light). I still cannot touch-type, but after some time I discovered I can type in QWERTY on any keyboard layout.
> Changing return type from "void" into some "result" is a mechanical change.
.. 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.)
> 10. has anyone yet found a legitimate use for throwing an `int`?
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.
"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."
Somehow I doubt this wide-sweeping affirmation, are you sure? Atom is really big family by now, starting from Silvermont it vent full out of order with all bells and whistles, I find it hard to believe OO backend is anywhere near the size of x86 insn decoder.
> Mixing unsigned and signed is seriously broken in C, and hence better to stick with signed.
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.
You are of course entitled to your personal opinion, and sharing it is OK, but this:
> ... 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?
> After years of optimization, I have a better quality of life than our CEO. I'd be insane to give it up.
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...
-Werror might help with that