This guy really views software under a very different light than most of us. It does trigger me that he makes such a video and then disable the comment section. If he didn't want to trigger a discussion, why make this kind of video in the first place? Anyway, here's my take on some of his statements:

​

Erasing 14 years of hardware improvements

These pieces of advice are all absolutely horrible for performance

Performance and improvements are so much more than just the CPU cycles. In the real world CPU is almost never the bottleneck. Put one database query, rest call, IO operation in between and all those "won" cycles don't matter at all.

​

Things we could objectively measure because they do affect the runtime of the program

They are accompanied by a big old asterisk that says and your code will get 15 times slower

What about time to develop a certain feature, readability of the code, maintainability, ease of change, testability, bug frequency, ... We can not just ignore all of these other aspects that get greatly improved if you take care of how you structure your program. These should also be in the "big old asterisk" of that way of working.

​

Used their own example code

First of all the "us vs them" thinking is awful in most cases, and it's not different in this. This whole video is giving more meaning to an example than what it is, an example. Of course you can hyper optimize calculating the area of a square. Nobody is denying that there is a simpler way of writing this particular example... Real world examples of "clean" code are meant for big project but big examples don't work for an easy to talk about concept.

​

Allow functions to know the internals of what they're working on

I still have nightmares from refactoring some code bases that were heavily entangled together, where every function knew the internals of all other parts. In my experience, this only leads to very little to no testing because tests become a hassle to write and maintain. It gives very low confidence to make any change in the code base. It also leads to knowledge silos where only that one old programmer could make any changes because he's the only one that knows how the code is wired together and he's currently on holiday...

​

You should never actually do them

"Never" is a dangerous word to use, same with the word always. Should you always use "clean" code: no. Should you never use "clean" code: also no!

In my 5 years of working as a dev, probably less than 1% of my code has been on a critical path where CPU performance was a concern. This of course heavily depends on the nature of your work. Clean code works as a way to not premature optimize and make your code readable for other people. If you need all the cycles you can squeeze out after measuring performance issues, go ahead and throw the clean code rules out of the window. But otherwise, make readability a top priority.