Clean Code is SLOW But REQUIRED? | Prime Reacts

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.

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

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.

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.

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.

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.

"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."

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

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...

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

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" ;)

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

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.

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.

I believe it comes down to the priorities of the project or of the company. There are several things to consider that can have very different priorities depending on the company: 1) Performance. It might be of a very high concern if you build a game that needs that top-notch performance and wow effect (not all games are like that) or data processing that need to process terabytes of data in short time to create reports. It might be low priority if you build a JS for a web page, it is not about animations, and nanoseconds vs miliseconds doesn't matter. It might be very low priority if you write a script to process a low amount of images or data and it does not matter if it will be done in seconds or minutes. 2) Time to market. It might matter if you either build a thing and run a campaign or loose client(s) or if you either build something in time or other company will start sooner with similar service. It might be even matter of life or death for a startup in bad position. Also, a startup might be not in a good negotiating position with a big company requesting needed changes asap, or the opportunity is gone. On the other hand, if you have working reputable product and only work on enhancements, time to market won't matter. 3) Budget. You might have some budget and either you can cancel project or try to finish it without sufficient funds to do it very well. Happens pretty often in startups with investors. 4) Maintainability, quality of code, developer experience. May be a top concern for a long-run strategy. May be not if your company just tries not to drown and needs to change fast and cheap or die. 5) User experience. Usually it is very important, but might be moved to the back seat if other considerations are deemed more important. a) critical - so if that thing is even usable at all (might be not important at all for example in early PoC projects, usually top importance) b) normal - so if that thing is easy and nice to use for typical use cases I currently work in projects where it is something in this order 5a, 2, 3, 5b, 4, 1 (working startup) or 3, 2, 1, 5a (PoC projects). This means that there is a lot of rather bad code. It is not totally unmaintainable, but it is also very away from SOLID or clean code. We rarely have time to refactorize. There are also these smaller PoC subprojects that we do - there we don't take any considerations about code maintainability. We make quick scripts with code from github and GPT, stich it together and try if it works or not. If it works and project is accepted to go further, we rebuild a production version with a bit different approach (with better architecture and code), taking only some parts of PoC. I worked in projects with priorities like 5a, 5b, 4, 1, 3, 2 which were into quality. Mostly quality for enduser or client, then quality of code (but nearly on same level as usually those are corellated). This dictated totally different approach. Same person working, different projects, different decissions - both about the general architecture and code. And it is not like I evolved or rather de-evolved. I know more about how to write good quality code now than I knew back when I worked in projects which were very into the quality of code. I feel it is more like a thing dictated by the business circumstances of the projects rather than decission based on taste and knowledge. I did not work on games, but I think that in games it is most usually 5a, 1, 5b, 2, 3, 4 with 2 sometimes going up the ladder when deadline is near. They need to make game playable, make wow effects, make it to the market quick enough / on time. This dictates even different approach. Another thing is that you can overdo any of these things and make matters worse. 1) You can overdo performance and loose quality in other areas. Like your code runs fast, but results are less precise or it is too fast for the user or controlling process. 2) You can overdo time to market and add features faster than users can grasp and accomodate to the changes. It can be seen in some mobile games - they grow fast into having too many options, many with some currency/payments attached. Gets overwhelming, especially for new players. 3) Budget. Sometimes cheapest option is to take a ready code or services from the internet... and then you get locked in with it and have hard time changing things or changing provider etc. Something might be cheapest in short to middle run, but not cheap in the long run if you count cost of adaptation. 4) Maintainability. There is problem how to measure maintainability directly and we really have only some approximations like less repeating is usually more maintainable, single responsibility is usually more maintainable, more abstractions is often more maintainable. Can easly go too far with those proxy measures and get code that is actually less maintainable and harder to grasp. Also, like stated in the video, can loose on performance or user experience. 5) User experience. You can add a lot of complexity trying to have best user experience possible. You can also fall into a trap of thinking that something very usable for you will be also usable for endusers. You then can make a some custom thing instead of relying on proven typical solutions. It is hard to think like someone else or like general target group. A/B testing is here to help of course.