Abstraction Bad? | Clean Code : Horrible Performance : (Clip) Interview 

That "future proof" thing hurts me every time... I literally train myself not to overengineer those extra things that become a dead code in reality.

The problem with these discussions is they are themselves too general and they're lacking examples to consider. As always in dev it's choosing the right tool for the job.

The thing Prime describes (at the 0:52 second mark) where you code something up that hides behind an abstraction and accounts for all these possible "future uses" is a code smell, and it has a fancy name: "Speculative Generality"

Well, that was amateur level talk about code-architecture. Math is timeless, that is how a good system can scale into the future.

1. Get it working 2. Get it working well 3. Refactor 4. Repeat

I absolutely hate abstraction for the sake of abstraction. There is no reason I should have to look at 20 different classes to understand a

because Casey turned off comments under his clip about clean code I will answer here. It is false-positive hero of performance because: Incorrectly understand definition of Single responsibility about DRY - Casey doesnt even mention it is about limiting sources of truth about virtual functions & polymorphism - it is widely known thing to not use virutal tables when you got plenty of calls per frame/cycle but it is actually a single scenario where you should care about it, also this scenario isn't something very often happening about internal deps - implementation shown in the video is in wrong direction, you could reach same performance still applying to open-close rules, where you put the behaviour as an argument to the processing algorythm while still configuring it from the top/parent also this rule says about how strong should be the border in the architecture and the deps direction, but it not says it should be always this way. If you would go so strictly with this rule you would always separate internal and external types, its interfaces, DI and mappers. What Casey is saying here to go so strict with this rule it becomes totally not worth. So you would need to revise those boundaries, as architect, to decide where it would increase costs related to lack of those against the expense of the maintenance. Some modules may require so much focus on performance you have to drop some clean code rules, however, according to SOLID and Clean Architecture even then, you could enclose this area in blackbox and so it becomes a implementation detail. So it have no system wide side effects, keeps being orthogonal, and so on. And this is just a comment to the part of the clip. Still you dont consider that in 95% of projects not the performance is something most expensive. So much of modern software is now in java, python, c#, javascript where most of these nearly alwas use virtual functions and even if you break SOLID / Clean Code / Clean Arch rules you wont benefit much from it anyways. So where Casey advices matters is just a part of the software being provided. Oh and sure, some areas could use those suggestions while other shouldnt - there where you need to maintain huge codebase with huge amount of UI functionality etc you would rather focus more on clean code, while doing some highly specialized module that strongly depends on the performance you would blackboxit as clean code advices. There is no rules that satisfies all needs or all possible usecases. Still you can use clean code like in 95% of your software because most of code is about actions that are not doing heavy calculations all the time, mostly waiting for user actions or doing some operations from time to time. But when you need to put high performance module in your app you can isolate it despite the coding patterns and rules applied inside. Huge risk I see here is Casey points out just one factor - performance of the app. How many apps on your devices are doing heavy calculations or operations? Just some. How many of them are doing it ALL the time? Nealy none. So for that `Nearly none` section you can focus on performance, while all the rest could be nice, easy to ready and maintain code, otherwise we would need like 50x more devs on the market to maintain chatoic and not expandable code. Companies cant afford that focus only on performance but easy maintainabilty is huge value for them. It is way cheaper to maintain 5% performance oriented code in your app breaking clean code rules, while maintaining easy to read and maitain 95% code in much lower costs but having good code quality

Bit confused about how this is in conflict with "Clean Code" though, I don't think clean code ever argued for future proof abstractions or anything like that. Clean Code is more make your code easy to understand and refactor because in 95% of cases it isn't you who will have to change it in the future it someone else so make it easy for them. There is a big difference between trying to future proof your code (guessing now how it will change) and making your code easy to change in the future. You don't have to know how the code will change in order to follow some pretty easy steps to make it easier for that change to happen.

Please don't hold the interview hostage.

One of the goals of "clean code" is to allow multiple people to work on the same codebase without creating too many conflicts and incoherences. It looks like Prime & Casey talk about cases where they were the only ones developing at the time, so they didn't "need" that.

I think both of you have seen a lot of bad abstractions paired with overthinking in practice. Which to be fair happens to everyone with decent skills or better from time to time. A good abstraction hides complexity from the programmer so you gain some free brain capacity for something else. (Much like VIM hides typing complexity) My favorite abstractions are hardware interface classes and message or event abstraction. If i hide the bit and byte addressing of a SPI or CAN bus in a class i can just write the flags in the network/application layer, and glue the flags to the right place in memory with implementation and declaration. Done correctly (with references) you don't waste a single instruction and seperated complexity. If you want to port this code to a cheaper microcontroller for example you only need to change the memory addressing and your done >90% of the times. One rule of thumb: a good place for an abstraction is a place where you have a lot of identical code, !! not similar, not is-a, not has-a, identical code !! Then it's worth hiding it behind a function or a higher form of abstractions. If you can't unroll your abstractions into working spaghetti code you choose the wrong type of abstraction for your problem, or your problem can't really be abstracted by it's nature. Template classes and math are a good example for this, as the STL::math uses templates a lot. If you need a dot or cross product template you are doing some multivariable calculus. Do you really wonna bother with datatype specific implementations or SIMD instructions while doing multivariable calculus? Or would you rather say hey language feature here is dot and cross product, there are only so many native datatypes, i just call it with the datatype i need and you fill in the right one for me, and compiler pls do your thing afterwards. Biggest problem why student struggle with making good plans, barely any Prof really minds the time and effort to show how you really identify identical code sections and hide them behind a layer of abstraction. They all just Allice and Bob, animal - bird - mammal - cat - dog or shopping cart you, but they never really dig into group theory and how to identify a set of something identical that can be abstracted without any "is-it-really-a" typecheck code bloat or a "you-said-it-is-but-it-is-not" bug.

A crossover I never knew I needed to see, but now I can't wait for the full version.

So the way I'm thinking is that - generally speaking abstractions are usually almost always good and generally aren't even bad for performance if its bad for performance its rarely fault of abstraction instead its fault of bad design. The bigger problem is that most things that we think are "abstractions" in fact are not instead it's just layers of code that don't really abstracts much. Good abstractions is not so much about making code future proof either - future proofing something again is a design goal and certain abstractions can either help it or worsen it. For example you could say Einstein's relativity theory is more future proof that Neuton's laws of nature - as Neuton's laws are fully captured within Relativity framework with more accurately capturing extreme cases - yet we still use Neuton's laws instead of general relativity for a lot of things because it's easier and because it gets job done. What abstractions should achieve is they should help us reason about the solution in simpler terms. In essence they should allow you to think about problem from higher point of view. It's really not easy to create a abstraction most often we just add layers of functions not abstractions. Good abstraction decoupled low level thinking and high level thinking. Writing code in "single level of abstraction" IMHO is one of greatest software design advice ever created. It can be useful to set stricter smaller limits when creating new abstraction - it's much easier to come up with a useful abstraction that is more limited in it's scope than one that is more universal - often abstractions that are more universal are also ones that are either more complicated to use or they make significant performance sacrifice.

Guys that think clean code is trash are also not doing TDD. So it ends up being.. 1) write code that 'works' 2) lazily modify what works so less trash ( while introducing subtle bugs ) 3) Say your 'done' People will hate working on code bases written by smart asses like that. This is cowboy programming and how you become a 10x engineer. Reality is for most applications performance doesn't matter and you should make your code clean and use standard patterns that make it easy to extend.

I may be wrong, but it looks like you are in different world than the guest. You're talking to a guy who (from his videos) doesn't want any abstractions with virtual function calls, because the performance is bad compared to standard C code where we would just write out the code "flat". He's looking at things with a magnifier. But you're writing code in Java and Rust! You're already several levels of abstractions above what he would find acceptable. It's also questionable to read people's comments here, sharing their bad experience with "clean code" with a python code base: dude, you writing *python* - it's literally the poster child for trading away all performance for some "readability" idealism. His position is extreme to the breaking point! We don't need to prove to him that "any of this saves time", we know this. GUI and frameworks are built with OOP concepts not because we're lazy and "just following the rules" but because it's an excellent way to structure things to be safes and sharable, and compartmentalized. It saves times, it saves bugs, it eases testing (for example by defining the "contract" each bits need to implement, and allowing to stub parts of the system and test bits individually). Incremental improvements, and refactoring - my speciality - are a lot faster when things are abstracted. Yes, some people have over-abstracted things and made us waste time and added complexity, but we don't prove the value things by their worse cases. Who hasn't had to deal with someone's very long "optimized" code where it's a lot of copy/paste or they avoid using some premade things and it's a bug fest nightmare. We all have stories, like the guys that will write complex, but clever, code to avoid a few instructions, but then end up calling allocating memory which will end up executing thousands of instructions. Because they follow other "rules". The job of a programmer sometime feels like it's just collecting horror stories. To wrap this up, I just wanted to mention that modern C++ (the target of his hate) isn't really about making abstract base classes with all member virtual, like making a "shape" and "triangle" base class in a game engine. We do use classes and virtual methods to abstract a set of problems, but we also use templates for other sets of problem. The entire c++ standard library, minus the older iostream, is not using virtual functions.

Faster typing is a great point! The main benefit of Copilot for me is ONLY the ability to type faster. I program mostly in Go and those "if err..." auto completions pushed my productivity in the stratosphere.

This is ok advice if you’re working on a feature, to “just write it” and see what happens. But for designing systems wrong design decision can cause years of developer headaches

"Clean code" is for making it easier to maintain a big project by multiple people. Keeping it clean so it's easy to get an overview and extend it. And never was for performance. Yeah clean code sometimes mean more code, with more layers and/or abstractions, so it will be slower.

Clean code principles are meant to be applied during refactoring, on code that is already working, NOT planned in advance. Haven't you read the book you're ranting so much about? 90% of what you're agreeing so vividly on has been described in almost the same words in Agile Software Development in 2002... Thank you captain obvious.

I've definitely programmed 10's of times less than either one of you, but every time I coded with a plan vs. without a plan, coding with a plan helps me way more. Usually for me even just writing all my desired steps explicitly helps me immensely to understand what the program should look like. And UML diagrams get a lot of hate, but I think when you're trying to share with someone else what your mental model looks like, they do a pretty good job. Like y'all mentioned, sequence diagrams or whatever will not get every intricacy, but if I start by seeing the diagram then the code afterwards, I can navigate it with way less friction than "where am I? why am I here anyway?"

"I just want to make it work, and make it nice" is essentially TDD in a nutshell. Just document the stuff you care about via tests and as long as those work all is good. If tomorrow comes and you need to add some other thing, then add the test, make sure everything else still works, and move on with your life.

You gotta go through doing good things badly before you get to do "bad things" well. Problem is far too many people don't even get to the stage of doing good things badly and just do bad things.. badly. I've worked on some code bases that could have used 5 seconds of thought about design/architecture or even basic logic before the code was written.

Even though I disagree with Casey's thoughts about Clean Code for the most part, this snippet here is definitely true. Make it function first, make it run as fast as it needs to second, make it maintainable (clean) third is what I do. And also kinda what Uncle Bob actually promotes in his book.

9/10 times its someone who is way to good to be working on what they are working on and they are bored. They over engineer everything and its a shit show. We just brought our app from 6k lines of code to 900 by just simplifying everything. We now also have 92% coverage compared to a 60% coverage before.

Oh man, even as a noob dev with barely any work exp, I can already feel this so much with my current project, and it's *just* the front end. Thinking of my app as several, pretty separated modules, I decided to have my React app structured into features. But then I thought, "well maybe I'll need some kind of data mapper/formatter for all the data in *each* module". So I went and made a still fairly simple mapper (maps data from raw values to labels or messages, like "available: false" to "This item is unavailable"), and a formatter (formats things like currency, dates, times). But then I thought, "oh maybe some of these mappers could be shared, like a StartDate field could use the same formatter as the EndDate" so I went and made a "display mode mapper" that **maps each field to a corresponding mapper/formatter**. And now around a month after I started with that idea, I'm now left with some 7-8 different mapping/formatting objects, functions **for each module**, and I'm too scared to even touch them anymore.

What I don’t understand is what clean code has to do with drawing diagrams up front to try and understand what you’re building. It’s not like you’re not allowed to do iterative development when you’re practicing clean code. Trying to write stuff “to learn what it will do or look like” and by doing so ONLY implementing what’s necessary is literally Kent Beck’s 4 rules of simple design.

Years ago, I learned how to program from Casey's videos. And I now work with people who try to preemptively design things all the time. They're constantly hounding me about clean code principles but I can never take their criticism seriously because everything they write runs HORRIBLY. I don't understand it. There's some kind of bizarre script running in their brains that just cannot see the nightmare they've created for themselves.

I usually like the content you make in this channel - but this one in my opinion really went wrong. The thing I absolutely disagree: if you do not follow the clean code/architecture principles, then you end up in a mess and you will be not able to progress after a while - this is what Robert C Martin emphasizes in his speeches and I absolutely agree with him. There is no contradiction between iteratively building up the code (by refactorings) and using a code structure according to the clean code: DRY, using proven design patterns. It is rather the other way: if you do not do it clean, then you will be not able to refactor, because you will have a rigid structure with tons of coupling. I have known a lots of "pragmatic" programmers during my carrier stating: "abstractions/design patterns/arhitectural patterns are crap it is only for the fools in the ivory tower" - finally it turned out that they did not like it because they did not put effort into understanding them. They whining about having a extra virtual call, but it is not a problem for them to couple totally different functionalities in the same class and having 1000 method that can do everything and the world.

Young programmers perpetually rediscovering Brooks basic concepts from Mythical Man Month. These ideas are 50+ years old.

The real question is, how to deal with your coworkers always trying to plan ahead, pushing for early abstractions that just make code harder to understand. I don’t know what to do, it’s super hard to just reject their code because they are doing “clean code” and it is also hard to push my “dumb” code because they always come to my PRs suggesting the introduction of early abstractions.

I think he misses the point of clean code. Clean code was never about performance. It's about readability / maintainability and testability. I am a big proponent of not optimising prematurely. Of course if you specifically require perfromance then it's a different story. But in most big collabarative project, performance is simply not as important. And if it is, you go back and optimize that particular bit of code. Also, where do you stop with optimizing? You could go into bit manipulation and probably improve his code by a factor 10 or 100. Just because you can do something, doesn't mean you should. That being said, I do think it is very important to always be aware of performance. Especially when working on big data sets and alhorithms.

I never understood where these people come from that wants to abstract everything. I think they read it is some book followed some classes and are convinced that this is the only way. These people somehow are convinced that all programs MUST follow the exact same design and methodology or else it is wrong. However my experience is that all projects are different, every project will have a different programming style that will follow naturally from what you need to create. And you cannot predict how that programming style will be, you only discover it after you created this program.

Maybe the start here was taken out of context, but did he really say that he does not see any benefits of clean code? That is just wrong on so many levels. Clean code does not mean you need to sacrifice performance. On the contrary, clean code will help you restructure the code in the future and then most likely to increase performance a lot. Bad spaghetti code, with huge functions and bad variable names and so on is not better in any way. It is horrible if you work in a team and need both your collegues and yourself to understand and modify the code. And ugly code is certainly not faster by some sort of default. But I cannot belive any decently experienced programmer would recommend non clean code, so I assume I misunderstood the context here. Yes, if you sacrife speed a lot in some way just to make your code clean, something is of coruse wrong. That I can agree with.

I agree to all of things thats said here. Personally I am very bad at figuring design of all the classes and inheritance and connections between objects before writing code. and I usually find myself overthinking about should I design it this way or that way, do I gotta do this or that because this wouldn't violate "best practices" etc... Then I realize I have zero lines of code written, all I have is lots of thoughts about how I could've done the thing instead of just fcking doing it. And when I actually start writing the code everything becomes more clear along the way. After you get a working code you can then refactor and make the design better, but you gotta have a working code in the first place.

Glad Casey is a bit more nuanced in this interview. Honestyl Casey's own video was just too overly generalizing and shilling for my taste.

In the clean code book itself says that you have to use these words with criteria. No wonder why most of the people believe they are going to be replaced by an IA

I think the point here is that you can't plan ahead without knowing your requirements and the consequences of each action (which you won't be able to think about while stressed, depressed, rushed, or distracted). Also knowing your execution environment would be part of the requirements.. I have found that the best early optimized code was small bits used commonly in the application being made to be flexible is better than building some large and all encompassing machine. I think once you optimize some things for flexibility it makes the code easier to write and makes the predictions easier to make.

I hardly ever comment, but lord, please, this full interview needs to be released!

I consider clean code is scalable and understandable what are these people talking what is the standard for clean code I just plan a little get things to work first get it down and revise I try not to listen to the thoughts that tell me to plan more or that tell me something won't work

Please Release Sir.

I think it's important to note that the "9 ways to hell" is a micro scale thing. You cannot plan things on a micro scale, but you should plan things on a macro scale. I think the best programs come from equal parts thinking/planning(macro) and implementing/iterating(micro).

This feels like my conversations with Product and junior devs. I was once told by a senior dev many moons ago, that if someone asks for a gold sphere, build a cardboard box first. They might never need anything more.

WE SHOULD GET MORE TALKS LIKE THIS ONE

Have to deal with "I just typed this as fast as I could" code is also annoying. Those that connect many times to the database, who dont use the same entities, so they are sometimes overwriting and invalidating records in the database, those that force you to change the code in 15 different places and you probably forgot those two that will trigger a bug. Agree on this for starting a project, giving it a kick off, but not being able to test your code is damn annoying

Clean code is not only about OOP, and even for the OOP part, probably every developer who adopts OOP understand it is never about performance, it is about how to build a complicated software system and have generations of developers maintain it for 10 years.

So the interview's locked, I didn't know you were a mutex in diguise.

Yelling does not increase ASSimilation of information. Stop doing that

Had to come here to comment on the original video as stupidly comments are off. The video was TL;DR but from the first few minutes I got the impression that presenter was mainly focused on code performance ... I did not expect to hear that in 2023 there are so many more important aspects of code than performance as long as the performance is good enough. And mostly it is if you have a clue of what you are doing. So it is not worth a second though unless it becomes an issue. One thought for performance, a cursory glance, yes, second thought no.

What an awesome conversation. I couldn't agree more. This is why it's called a programming language. The "languages" we know constitute the extent of our brain's capacity for thought (I would consider math a language as well in this context). When we use the English language to write, we are actually using it to think; putting our words in the right order and sentences in the right structure is literally our process of formulating a response to a problem (we are almost always writing about a problem). So, no writer can write a book in their heads, and software engineers can't just think up the perfect code. The act of using the programming language is the same act as solving the problem.

I see what you are talking about, but i need to slightly disagree. Sometimes you absolutely know the future, and not putting in the effort stop suport it will hurt you. At work we were adding notifications for users for different kinds of events. It's obvious that in the coming months we will have more kinds of events. We created an enum with the first kind of the event, single value for now. The guy coded this function to do the thing, cool. Next guy that was adding the event, just copy pasted 100 lines of code and replaced enum with the new value. All we needed is the first guy to start with an array of enum values so that we can control which are actually processed easily, and then next tasks would be just to append the array. But no, we discovered that there is a bug in email sending endpoint that spammed users with 6 emails at once. Now we have to fix it in three places, because in the mean time we added third kind of events.

I am confused to see clean code made equal to doing things (wrongly) future proof 🤔 For me clean code is also like making things easy to comprehend in the current code. Making API symmetrical and predictable. Not changing that one variable from outside the thingy (class/module/function) while N-1 updates to it are inside that thingy. Etc.

Why does this guy scream talk. Not prime the other guy

100% agree!! While it's fun and a nice mental challenge to abstract into the future, it's SO MUCH more satisfying, when you already built the thing and know exactly where the issues and bottlenecks are. Too often, I had to fight with things that existed ONLY because of abstractions. People have a tendency to need to show off their programming skills; but the path to true mastery, as with most things, is simplicity. Also the first time I listened to this was with audio only, but my reaction was quite similar to prime's. Came back to write this and watched the video again and laughed seeing him react similarly. :D

I like how he says it happened but can't give an example, cuz he's full of crap.

Dude never turned compiler optimization....

Realy awsome interview, can't wait for the full one. I also like that Casey and Robert C Martin did some communication - even though he totally not seem to have get that Casey's enum opcode + union method instead of virtual function polymorphism handles both when operations change fast and when new "types" are added fast... It felt like he was not reading it. It is good to see you agree with Casey this much on these things! I actually in that rare breed that thinks planning ahead can win you good things though. Many of my algorithms and data structures are on paper first and I code them later on. Last time I made a lightning fast sort algo (better than ska_sort) on paper and even the first time it started running it was beating standard sort heavily even before I started any "profiling based optimization". But mind it that on paper I already planned for cache lines, ILP and all such things - not like how algorithm design usually happens with calculating something like number of comparisons or hashings or whatever abstract thing. For me the paper-thinking works best because its much easier to throw away the idea when I thought them through: So in a way and in essence it does have this kind of fast feedback loop like coding it in does. Also I do multiple alternatives sometimes too. I guess this works for me because I spent my youth totally coding in assembly only. Literally only ASM for years and I remember writing a particle system in ASM for like 6 months in mid of high school and could literally run it like months later I started making this, because 1.) I was noobie and slolw 2.) doing that in asm was just complex 3.) I did this in spare time only (some people allegedly used this later in some game I don't know). To my amazement it actually "shown something". I did fear that I will just see a crash or black screen or something that totally not indicate where the error is, but I saw particles going on the screen but they had some bad patterns - and from the patterns it was easy to tell where my bug is! Of course current me would find ways to test and try out parts of my work much earlier, also would allocate more time for it in one seating so its not spanning months and all. Yet I think coding always in ASM had it inherently that I had to "type a lot in" and because this makes the feedback loop real long even if I would optimize it much better than my young self I think it kind of teach me to plan ahead better. Think about my dad's time when he was programming in his university time on PL/1 and literally on punch cards! He designed and wrote even the program on paper, handed over to some happy maiden that once (hopefully in good order) filled that into the big machine and he got some "you wrote a syntax error" kind of message a week later. ^^All the above being said: I like at least moderately fast typing, I highly use VIM for productivity and (at least) semi-automate a lot of things most people would dumbly write out. I don't really understand why they "claim" that it does not count. It really does! And not just it saves time "WHEN" coding, but even saves time in the paper design part where I know in advance that if some better solution needs me write more words on screen its fine and I don't fear it because half of them just gets generated by vim magic, the other half is not so slowly typed in... ^^Also doing vim means to me that I do not leave the flow when I am coding. For example Magyarsort's original version on paper took me a sleepless night to get it down - then I fell asleep and the next night it took me to "properly code all that stuff into the computer". - without any of those I think it would not be what it is today. Also please see a stark contrast between this and uml kind of bullshit design. I sometimes used very lightweight UML for documenting some complex communication protocols and its fine (sequence diagram was useful), but planning in advance with uml is really not my cup of tea. Ahead planning should be on paper pieces - sometimes not even A4 paper, but "whatever I find at the moment" and can go from verry tiny up to a full description.

Hey Prime! Your content is awesome and as someone who highly appreciate Clean Code and Clean Architecture I would say that I understand what you say. I don't think you are entirely wrong. Even Robert Martin mentions that in "most projects only need 2 layers" in his Clean Architecture book. Well, isn't that what we see in most web framework samples? A controller for web endpoints (presentation + business rules) and a data access layer? The main difference would be how to use these two layers in what the calls Clean Arch. Is it worth tightly coupling with the current framework tools? How much planning is this project worth? How much and what type of human resources do you have for the project? Well, in the end you know what kind of quality you are about to get because the founders/builders might not even be sure what they are planning to build. In that case, clean coding is a total waste of time in my opinion. If you don't know what you need to build, it is not a good idea to anticipate problems and plan abstractions. But it is not the same to say you don't plan anything. Another point I entirely agree with you is that it is not wise to plan what you don't know how a particular piece of software works in REALITY. Creating POCs with 100% tightly coupled, public getters and so on are a wonderful tool for exploration and validation!

Reminds me a bit of Ed Catmull’s Creativity Inc on Pixar processes, the take away is “All Pixar movies sucked at the beginning, you just need to trust the process” , I really liked that book.

This guy is obviously terrible at abstractions. This is such lies.

This seems like a weird strawman, trying to equate clean code principles with future-proofing or big up-front predictive design. You're just advocating for quick iteration, experimentation, small refactoring as you go, YAGNI, etc., which... is in complete alignment with clean code, agile, even TDD (*gasp*). What am I missing?

I used to be very insecure, paranoid about thinking through every possible way things can go wrong. Then I learned Python. And it has that attitude of "just do it". Just do a thing. Provide some reasonable flexibility and error handling, but you can't probably write a piece of code that will universally work for every possible case ever. I finally chilled out and I began to write a better code.

I spent a while with the big JavaScript frameworks and this perfectly sums up how I feel. How much overhead have we added in trying to make things so clean and prematurely optimized?

Best April fools ever. Super excited for this interview though.

Please release. Casey is really cool. Also, how about an interview with jblow?

YAGNI for the win!

I've been writing software for 20 years and these guys are right, at least about this particular thing.

That was nice to hear. I am already incapable of memorizing even the simplest concepts. I have to see them to work with them. Sometimes I try to plan ahead and get lost in a mental spiral trying to keep 3-5 steps in my head. But those many steps already break my brain. Knowing that I am not all stupid but that writing code and optimizing it for x y and z while coding makes the approach much esier. Go ugly and simple quick and refine to decent and more complex will be the new approach. If I see the levels of abstraction and "cleanliness" of a built in method or e.g. React components, which have become this wild gibberish, rather than just some js or ts + "html"... I'm like... Okay...? WHAT THE FUCK IS GOING ON HERE!? And then you dive and dive and dive and in the end I don't even remember what I came here for... XD

There is a huge problem with turning off the comment section on your channel. You stop valid points against your ideas being made. Not everyone is a game dev and every software needs to be performant. Also the code in his example became harder and harder to read and maintain as he stripped away elements of clean code.

If you constantly write stuff (like blogging), it’s the same concept. We need to write down first to see it, then revise. Human can’t do everything in our minds, and output a beautiful final version.

Never agreed more, every day I get hit with things like "they will ask why we didn't do it before", like we have to plan ahead for things people don't know if they'll use or not, it has to be there "just in case"... This breaks my legs every single day, coding stuff that "might be used in the future".

I feel like this paradigm is what is driving cynical people crazy over AI. They think that the alignment problem for AI has to be perfectly designed. They just can't seem to accept that the reality of design is that it doesn't work in practice.

Yeah, i like to use test when is possible because help us later when we need to change software and software always change!!!

Great, so you're convinced, if you do something wrong and superfluous, it is wrong. That's a remarkable insight? Actually AFACS clean code, done right, is nothing of what you described. So let's look at one or two ideas behind it (so far, I didn't hear about any from you, though I'm starting to feel dizzy because of the shouting): So let's check, is e.g. separation of concerns wrong? Is it really good or even superior, to mix different functionalities (behaviour A, and behaviour B) into a single implementation entity? But applying your arguments you not only claim it would be faster or easier, but you claim, because you don't know about future requirements, it's (, always) inferior to split unrelated things, which is creating one entity for behaviour A and another entity for behaviour B, plus a entity which combines A&B. Obviously, if done properly, the overhead is to have a additional entity that includes and combines entity A and entity B; that's because obviously you would have to write code that implemented the behaviours A and B anyways. But also obviously the requirement is to have something which exposes behaviours/does A and B. So what is the additional investment? Maybe code which orchestrates both behaviours? Yes, you need to write code which exposes orexecutes A and B. But you needed that code anyways, even if not implementing the two behaviour (interfaces) but only one (entity) class. Besides that entity A, B and the glue entity A&B are usually much clearer and easier understandable, then the AB, where different aspects are mixed in the same method/function. Also A and B are in separation much easier testable, because e.g. you do not need to fulfill setup and dependencies of A in order to test B and other way round. I think the problem is, you need to come up with an idea how to separate and split out the given requirements into separate functional units, which can be composed to do the right thing, without adding additional functionality. And based on my experience that's what a lot of people have problems with: Abstracting the actual literal requirements into functional Lego-like software bricks without adding additional assumptions. But if course this will become more relevant the bigger your software system is. So instead of raising some generic, broad claim which can be shortened to "it is stupid to adhere to clean code", I think it might be important to say in which specific situations it could be better.

Waiting for the full interview. So far, this clip and the original article gives me the impression that we are conflating a lot of things on clean code goals. Disregarding best practices just for the sake of speed seems like early optimization. We also need to consider readability, and maintainability. Having common patterns make easier to read and understand pieces of code without having to read everything line by line. Clean code and best practices is also not for designing for future features but for making the code easier to refactor for future features. Granted it can also be misused and we may end up with big chucks of over engineered pieces of code that are just hard to read, hard to maintain, and inefficient. But that would be because of misuse, not because clean code is just bad on all instances.

What are some specific examples of things that look like clean code but actually run poorly? I fully agree with what they're both saying, I'm just curious which things should simply be avoided, even if it doesn't seem like they should.

DDH also made some absurd claims about TDD couple of years ago and in a direction conversation with Martin Fowler and Kent Beck he was grilled then ripped apart. This guy has taken one aspect of software development which is orthogonal to the subject matter of clean code and is comparing them. What he is doing is like saying 2.0 GHZ CPU is better than 8GB of RAM. Software Engineering is the art of trade-offs. When you go with one approach to maximize something, e.g. expandability you have to see what is the trade-off. If your program is CPU intensive maybe you should consider another approach. Money is not just about CPU, CPU is cheaper than human's time and complexity added to the code and architecture. A lot of things that he says e.g. in Java are addressed by JIT. It doesn't matter whether you inline a method or not. If JIT sees the need of it, it will do that for you. Yet another person who is looking at a topic in a religious manner. DRY is in general a good practice but e.g. in Tests it actually reduces the readability, hence you better not follow it. Use your brain and make the judgment based on your environment. 99% of the services running in backend systems don't have the performance constraints or needs that he is referring to here but they do suffer from lack of abstraction or not following single responsibility pattern.

UML diagrams are great when you have couple people working on the same thing and need a handshake. Smt like internal API but more lose etc. 80% of the time it will be fine and only 10% of the time just one of you will have to re-write everything :D

It all depends on what kind of software is being developed, and what the requirements are. For example, when building general purpose libraries, for example, the complexity should be hidden for the 'end user', no matter what. When building more specific logic, simplicity is more important in my opinion.

I guess I conflate "clean code" with self-documenting code. Still haven't made it all the way through Clean Code yet, so I can't fully comment on it, but self-documenting code... (Which you can do in a lot of ways...one thing I like to do is...in any "if" statement, pretty much if it has any ||'s or &&'s, definitely two or more, is extract to helper function, so that it reads like `if(isValid(obj)) { doStuff...}` Basically the more it reads like prose the better. Write complicated functions as basically an outline, a list of the steps it does, ie `data = getData(); newData = mapData(data); sendResponse(newData)`) I can't prove with metrics how much it helps, but I do know I've spend entire days wading ugly spaghetti code that's clear as mud, just trying to figure out WTF even is this, when if it was "cleaner" (more readable, easier to understand, self-documenting, written in a way that clarifies intent) it would just be like, ok, have to change this here. Done.

I'd replace typing fast with editing fast, but otherwise agree fully. I'm not the fastest typist, but I know what insights, autocompletes, snippets, etc. my editor will provide, so when prototyping I structure things in a way to trigger those aids as often as possible

He shared exactly same performance issues with Clean Code in C++ in his youtube channel (I tried to leave my comment there but comments disabled). but Clean code is not just for C++. It's for every programming languages. Generally complier decides the performance in the typical garbage collected language like Java, C#, Python. and Javascript. I belive that coding style doesn't make major performance issues as long as code is not extremly bad like using millions of O(n^2), O(n^3), O(n^100). I think that the code quality is more important than performance itself especially in the team project. In the typical microservice architecture, network latency and database communication is way more time-consuming than the performance itself in the each server. Also, If I were a C++ compiler developer, I would try to find the way to make better performance with the clean code guided codes if it have issues with Clean code as he mentioned in the video.

I'm currently reading my way through Thinking Forth, which is less about working in the Forth language itself than it is about thinking like a Forth programmer. One of the things Forth programmers do is -- write the minimum amount of code necessary to solve only the problem in front of you. If other problems come along later, deal with them then. It helps that Forth is a language so malleable only Lisp can rival it on that dimension, so it's a relative doddle to add in some new functionality and test it immediately, even on a production system.

The Prime has spoken “learn to type fast” - I say this to so many people - it’s a game changer - especially those new to programming and trying to catch the pack - I have learnt so many concepts by literally typing them out a couple of times - and I could only do it as typing wasn’t a blocker! Also, I think I have standing in the matter as I learnt to type after learning to code. I was skeptical at first, but learning to touch type is probably the one thing that improved my coding the most in the last 24 years of pro programming 🎉🎉🎉

hmm, only if there was a principle that says don't overengineer... oh wait that's YAGNI principle Joke aside, I 100% agree with what they are saying here. No need to make complicated architecture when you don't have all of the pieces. When you do, then its time to make an abstraction and optimize.

So many assignments in college consisted of writing good code, validating, then refactoring into whatever unholy mess was required at the time. A perfectly adequate function? Sorry, needs more abstraction. Writing a neural network in raw python? Thats a letter grade docked since not every function is within a class. Seems Prime had a far better experience at Montana State than I did.

I liked this then unliked it so I could like it again. Write code for today’s problems today. Write code for tomorrow’s problems tomorrow. My tech lead/manager at a previous job didn’t seem to appreciate this. He neglected real concrete present problems in favor of working on hypothetical future problems. Drove me nuts.

once you pass computer architecture and Microprocessors courses you'll never call too many functions or use multiple useless abstractions because you now know what the actual fuck is going on under the hood.

Imagine this mentality when building actual physical things. My province built roads jist big enough for horse carriages. Now the age of cars has come and the roads are too narrow and things and its impossible to expand because it would displace so many people's houses. Terrible advice

jeez, if these smart guys have the same mindset i do, maybe I'm not the reason we are missing our deadline

I think there's a term called "Wicked Problem" which is a problem that can't be solved until you solve it. A lot software is a wicked problem.

Then do baremetal programming if you don't want extractions.. assembly is that way -->

Clean code to me is: simple enough for me to fix if I break it with a simple change. Can this be fixed by reverting to a previous git commit? Clean enough for me.

I burned myself enough times with future proofing! The future proofing I do today is to devise the simplest and most flexible system of components I need paying attention not to entangle data flows unless I need to. The looser I can have data flow the better. True future proofing is done on data, there is no way around that.

In Rust/Zig you have zero cost (almost) abstractions. I've been doing Rust for the last 4 years and i forgot what it was like to use one of those old farts like Java.

My most favorite way to get around this is in V1, throw Errors. Nobody likes errors, so it's mostly happy path designs. Once the thing is working, and depending on your colleagues: leave them in or remove them.

I kinda hate UMLs, But I like to doddle logic in simple flow diagrams when I get stuck

I use diagrams of program flow just to keep a map of what I want my program to do. I get a lot of value out of this because my working memory is impaired by adhd lol. But yeah overplanning is really bad

Don't design code structure; design data structure, queries, and algorithms. Code will follow from that.

This is like 1 or 100. It is not an argument because it is not attacking something realistic. Using design ideas is to solve things that were already coded most of the time. If a programmer is adding patterns just because they are cool, the issue is the developer not the pattern. You can't blame tools for people miss using them.

Should probably ask why Casey disables comments under his videos 😅