Clean Code is SLOW But REQUIRED? | Prime Reacts

Over the years, people have talked about Clean Code for more hours than anyone has actually written Clean Code

First time I saw "Scrum Master" as a title I really thought it was something dirty and a 12 year old had hacked the employee directory again.

I don't see why this guy is criticizing the quake fast inverse square root. That's about as clean as it gets. It's a pure function that uses primitive data types. There's nothing to maintain there. Sure it's hard to understand, but from a maintenance PoV, it's literally one standalone function. Nothing else you change in your codebase will alter how it works.

I worked on a system at the NAIC that was written in C++ and implemented all of their polymorphism via templates rather than via inheritance. The result was wrappers inside of wrappers inside of wrappers, and the error messages were horrendous due to extensive use of nested templates. We had to pipe our gdb message through stlfilt just to figure out what types were involved whenever we had a failure. There is a happy medium between code that is inscrutable because it is monolithic spaghetti code, and code that is inscrutable because it has been atomized into a fine mist of components. Ironically the reasons why monolithic spaghetti code is hard, is actually the same reason why overly abstracted code is hard. There's too many things to keep track of in your head, the only difference being what you're tracking.

"Paying our developers less because they can do more work for the money is more important then the performance of our apps." .... And that's the reason why my multicore-n-ghz-smartphone lags the F out with displaying a 350px wide webpage, while my singlecore 900mhz Pentium in 2002 had no problem with that. I'm just happy that when I learned programming we had to learn to watch our resource-usage. Today everybody is like "ok let's import a 500kb library to concat 2 strings together. More time to *sips latte, writes blogpost about stuff.*" And then I am sitting here and people wonder how I can search fulltext through 5000 rows of data and respond in ms. Like ... that's not magic, I just don't burden myself with 300 frameworks and ALL the abstractions known to man in between just to tell SQL to do a where. And that code is still maintainable.... if something looks like magic, write a comment there on the why and what... done.

I like how Brian Will described fine-grained encapsulation, "The princess is always in another castle."

As many in the chat pointed out, the TF2 coconut JPG thing was a joke that people took seriously. TF2 YouTuber shounic has a video explaining this, but the short answer is that while there is a coconut image in TF2’s files, it’s just part of an unused “coffee bean” particle and deleting it has no effect on the game’s stability.

The fast inverse square root is self contained in its own lil function so it’s pretty clean™️ and you don’t have to worry about the details until you have to.

This article does the classic defence of Clean Code bait-and-switch where one moment they're talking about Clean Code™ and the next moment they're talking about regular run-of-the-mill clean code.

I think it's wise here to take the good aspects and discard the bad. Writing a million 3-line helpers = bad. Giving things reasonable names and understanding how and when to use an interface = good. Writing shouldQueryIfConditionIsCorrect() to write something that could be expressed as a ternary conditional -> bad. Using enums and structs liberally with descriptive names instead of a million hardcoded constants = good. It helps to work in a codebase with very experienced colleagues who all of their own individual takes, that way you avoid any cargo culting of ideas from books.

One of my favorite Bjarne tips was "just use a vector"

Abstractions should be discovered, not designed

simple and readable code is much more important to me that clean code, ive seen design patterns and uber atomized components escpecially react codebases that didnt make any sense to me and was very difficult to provide any value or build new features

People don't even understand what a Cartesian product is... So you had a product with something like 25 customizable items (color, texture, etc.) and each item had between 10 and 50 options. Some options are not compatible. For example, you cannot get the pink color with the wood texture. There was a function to select the first viable combination. Said function was stupid and would compute a large part of the Cartesian product before finishing. I estimated that it would complete after about 150 years... I extracted the responsibility of computing the Cartesian product in a separate function (and optimized it to discard non-viable combinations before computing the whole combination). In that new function, I used the lexical field of a Cartesian product, as this function sole responsibility was computing the Cartesian product... The developer that owned the module asked me to rename all variables to match the business domain, because he didn't understand what a Cartesian product was. So I cannot imagine the average developer to properly understand the abstractions from the GoF...

If the code is hard to understand and maintain, then it's not, by definition, a clean code.

Clean code was a GOAL. Clean Code (capital) is the religion. Not in any way different from the "Manifesto for Agile Software Development" goals vs Agile. It's always a process from where you take something that has good intentions and turn it into a clusterfsck of dogmas and rituals and ceremonies. Some more cynical people might say that it happens because you can't capitalize good intentions, but you sure can turn "the clusterfsck" into a set of books, courses, talks, etc... Maybe what you need is just an "utilitarian" version of it all. Pragmatic CC, Pragmatic Agile, etc... The pragmatic part being "does it make sense?", "do we need it?", "have we gone too far of the deep end?", etc... At my place we have a running joke about a certain component that we refer to as "the best hammer ever". It can hammer in any nail under any conditions. Only about 15% of it's potential has ever been needed/used. Nobody truly greps to the full extent how it works. As a testament to the skill of the creator, it's rock solid and never fails. And thank god, because everyone that ever went through it in debug had to resort to some alcohol fueled "therapy" after. We just marked it DontTouchJustWorksTM because it does, and we always "Step through" never "Step into" ;)

The bit at the end about refactoring something and arriving at the same conclusion as the original programmer is a trap I’ve fallen into several times. At this point I’ve learned that if I see some code that on its face seems just extremely WEIRD that there almost always is a reason. Sometimes I don’t always arrive at the same conclusion but I’ll understand the original reasoning more. Honestly it’s helped me get my ego in check, too.

too much padding there isn't much meat in the article.

2:50 I will never be tired of you talking about this. I was hesitant to start coding seriously for like 10 years because I thought that since I can't hold so much in my head that means I'm bad software engineer and I don't belong there.

one aspect of the constant striving for perfect, clean code that gets overlooked is the impact on developer morale. especially when you know that when you open a PR it's just going to get trashed by someone who gets a high off making others write overengineered code. I see a lot of junior engineers lose so much confidence and their performance slows to a halt because of practices like this