Clean Code Is Killing Your Projects

Everyone wishes they were able to write cleaner code, but sometimes going back and refactoring code so it is cleaner is actually a bad idea. In this video I talk about the hidden cost of refactoring and some tips on how to do it right.
🌎 Find Me Here:
My Blog: blog.webdevsimplified.com
My Courses: courses.webdevsimplified.com
Patreon: / webdevsimplified
Twitter: / devsimplified
Discord: / discord
GitHub: github.com/WebDevSimplified
CodePen: codepen.io/WebDevSimplified
⏱️ Timestamps:
00:00 - Introduction
00:47 - My Story
05:00 - Tip #1
06:31 - Tip #2
07:48 - Tip #3
#Refactoring #WDS #CleanCode

[@barrykruyssen]

Spaghetti code is the death of a project. After 40+ years as a software engineer (retired now) this has been my experience. And as Kyle found out taking over a project it is very difficult and refactoring is even more difficult. Clean code, small individual functions and remember the code should be readable by humans first. Kyle does great videos.

[@user-bs8cj1bi3x]

Agree. Always refactor on the first opportunity there is to refactor. Don't let spaghetti code pass any review and never deploy it. Performance of the developers code is rarely the bottle neck. Your "optimized" code in javascript running in the users browsers takes a fraction of the CPU cycles required for the data retrieval/parsing and the complete rendering of the page. Keep it clean. Nothing worse than looking for bugs in a 700 line function or with a cyclomatic complexity going far over 50.

[@jasonruff1270]

Y tf should I care about humans?

[@tiagodagostini]

On other hand, some of the practices of the so Called Clean code book , when followed blindly instead of seeing where they apply reasonably, result in another type of spagheti (class bloat, that is just a different type of confusion)

[@epiphaeny]

@@user-bs8cj1bi3x I am currently refactoring a 1200 lines function with a cyclomatic complexity of almost 180... this is really no fun.

[@frigzy3748]

The problem is that there is no clean code. I worked for almost every company from FAANG and clean code is not something I experienced.

[@punkypinko2965]

I promise, most devs are not spending too much time refactoring. They are writing 90% spaghetti code.

[@jepsurrr]

Yes

[@LupoTosk96]

I can't argue whether it's 90%, but most developers certainly don't go over their very first version of a function to at least clean it up.

[@mikey7673]

Facts

[@Oncopoda]

You promise? Source?

[@Casprizzle]

That spaghetti code is their refactored code.

[@scigama71]

if you put 5 developers in a room to develop an app. I bet they will all do it differently

[@Ultrajuiced]

Hopefully they use Prettier for common code formatting at least.

[@jeremy0x]

@@Ultrajuiced 🤣 it's usually weird when I see a code that's poorly formatted; especially HTML, CSS or JS with 4 spaces as indentation.

[@genechristiansomoza4931]

​@@jeremy0x4 spaces is not poor format

[@KorhalKk]

@@jeremy0x I do space as indentation but just while I'm tweaking. Having that breather can help you find the lines easier.

[@AndreasKempe]

Stupid saying that perfectly outlines the lack of planning in this society and also the perfection of constantly finding excuses for responsibilities. If you have a number of developers, the first thing to do is to design common standards and guidelines so that everyone does NOT do their own thing. Millions of projects show exactly this wrong behavior. incredibly ugly code in which everyone wanted to leave a little bit of their own "scent" because they consider themselves to be the best of all developers and in the end a project that triggers nausea and that no one can really work on properly.

[@mcmanussean]

Great advice! (20-year software engineer here). I'm surprised you didn't use the term "tech-debt", that's basically what you're describing. I think of addressing tech debt the same as addressing financial debt. You don't pay off 100% of your credit cards and then not pay your rent and buy food that month... You pay off a chunk at a time when you can afford it. If you address tech debt the same way (basically what you were describing) eventually your tech debt will be at a more reasonable level.

[@tripunify]

tech-debt is overloaded term, but it is used all the time, it almost seem tech is not moving, so you go back and pay the price, but in fact when you or your team have a chance to refactor the code, the tech you use could already be out-dated. because tech is moving fast :)

[@krzysztofs3t532]

It all depends what a "clean code" means to you :) For me clean code is just to follow the project rules, for example never put styling and logic mixed togther, DRY - move logic functions to separate files, sometimes just ask somebody else if your code is understandable. That is all you need for clean code.

[@LupoTosk96]

> ask somebody else Even further - honest reviews in pull requests. Don't accept my code just for the sake of it, if something bothers you just tell me. A lot of colleagues seem to really hate going through Pull Requests. I love them: Here I'm seeing other peoples approaches and techniques to learn from and get feedback when my own code might needs improvement. Even if a single colleague tells me they don't understand it for any ridiculous reason, that means I might be able to solve that already by an inline comment or just split a single function into two. Everyone's concerns are valid to me - even those of the dumb colleague I dislike, because starting a fight or proving them wrong doesn't let us progress as a team. :)

[@The-Great-Brindian]

If you approach me and give me a hard time about DRY / Clean Code I'll refer you to KMA methodology..

[@playmaker8894]

I was literally doing unnecessary refactoring this exact moment haha, what's so special about kyle is that he doesn't just teach you how to program, but the best, most optimal practices!

[@Homiloko2]

Clean and maintainable code always wins in the long run. You should always write well structured, understandable code. The thing you don't need is extremely optimized code for performance, that can come later when you actually reach a bottleneck and improving performance becomes a goal. Oftentimes, the time you'd spend gaining a few extra cpu cycles wouldn't even be noticed by the consumer. As for refactoring, you never have idle time to work on that. The way I do it, is I only refactor the classes and methods that I'm using directly in this new feature or patch that I'm working on. It's that idea of always leaving the place cleaner than when you entered. You do small (or large) refactorings along the way to achieve your goal, and the refactoring never becomes an activity in and of itself, and then you don't ever need to convince your managers and higher ups to alocate time for this (because they won't want to, they usually only care about the finished product).

[@ifstatementifstatement2704]

Sure. If they only care about the finished product then they shouldn’t care how it’s been programmed either. Also not creating a class for everything, not having documentation comments, not writing tests and using basic commands of the programming language rather than the latest hot shit which takes time to learn, allows you to finish the project in a quarter of the time allocated for it during scrum meetings. That does not mean the code will be disorganised. It will be logical and will function. If any extension to it is needed then the programmers should be able to work on it if they are indeed programmers.

[@Rachoszsky]

You didn't refactor the code, you did a rewrite. That's an important difference!

[@arakovskiy]

Exactly

[@adamgoldsmith310]

You nearly got me with this one haha, overall great advice, using an iterative approach means that you can do small refactorings, and target areas of the code you are going to change next, I find that writing tests to capture the behaviour of your code before starting a refactoring is pretty much essential too, if you code doesn't have tests before you do this, it will after, this is also a good way to get into TDD

[@taylorkoepp3048]

I've been a professional programmer for over 20 years and this is great advice. When I started spaghetti code was the norm, not the exception. I don't suggest that was better but it's very easy to watch a tutorial on some perfectly implemented design pattern and then think there's something inherently wrong with your less than perfect implementation that's currently in production and working adequately. I wish I'd realised this years ago!

[@planesrift]

Now I feel better with having over 1000 lines for one single React component.

[@dimitridoroshko]

That's an exception for clean code rule. 1000 lines of code for one component is way too many 😢

[@AryanGNU]

That's too bad

[@AryanGNU]

It will come biting you one day

[@turolretar]

Those are rookie numbers in this racket

[@83hjf]

I have a component with hundreds of lines in react. It's a table with 20 columnns... the columns have to be defined as children of the table itself. I could extract it to a separate file. I would get zero benefit from doing this...

[@paulthomas1052]

Hi Kyle, I've been a software engineer for longer than I'd like to admit to 🤫 and I totally agree that the refactoring effort can be a pointless and expensive portion of some projects. I worked on a large banking project for a well known UK finance house and spent (along with my team) way too long on refactoring code only to add more issues and cost. I understand the technical reasons but sometimes 'less is more' - it's a cliche I know but doing nothing sometimes beats doing lots !! - love your videos and all the best from UK !

[@MrMaramor]

All in all, good info. I typically start with, plan, get it working, then look at flow and performance improvements, set a time limit for each part. Definitely set limits and add dev notes if you have ideas for the next iteration or next developer to consider. Smaller changes are usually more focused. If you have a team, peer review can also be helpful. There is also value in putting it down for a while and coming back to it.

[@at4371]

Thank you for bringing this up! I saw a lot senior developers wasted a lot budget and the product couldn’t never get out !

[@some_guy_with_a_hat]

This is something I always have trouble balancing. We had some really bad developers in the past. I'm frequently refactoring their projects, removing 90% of unnecessary code, getting massive performance gains, and fixing a few corner case bugs. There's so much to fix though, and I need to work on other projects too.

[@SOLDAT_MENDES]

oh, balancing refactoring legacy code can be a challenge, It's great that you're making progress by removing unnecessary code and improving performance. Prioritize the most critical issues and break down the work into manageable tasks. Remember, it's a gradual process, so don't feel overwhelmed. Keep up the good work.

[@yehielamar3661]

That's the role of a software architect, planning before coding is key in my opinion

[@robertholtz]

Refactor as you go. Ideally, think about the problem you’re solving in an abstract enough way that future iterations don’t need to be refactored to be extended. If you’re about to put a band-aid over another band-aid, refactor that section.

[@JustCode39]

i'm so glad to watch this video, because this sounds super similar to something I've done in the past too. Now I'm very cautious when it comes to committing to refactoring, and very cautious about updating / upgrading anything in the stack. I think we should only update is there's a bug in an older version, or there's a new feature we need in a newer version.

[@zoonvanmichiel9045]

Fully agree. And even if you do a large-scale refactor; do it in small steps. With your anecdote: a lot less time would have been wasted if you regularly merged the code into main and got to experience the benefits with implementing the new features. It also makes sure it is more in sync, you don't want a branch of a version that is a month old. The only large-scale refactor I had to do was a case where our data model did not match the data model of the source. So when they had a new feature, we could not implement it. But that refactor had a lot of planning to break it down in small steps.

[@Remls]

^ Ok bot

[@Bgrosz1]

Refactoring iteratively is excellent advice. In your scenario, if you have new feature requests coming in and you don't know how much time you have available then you can't commit to a huge refactor. I refactored constantly, but often it was just the code file I was working in and small and easy refactors to make the code easier to read and update. I did plenty of large refactors, but I always knew I had the time available to do those before I had to add new features. Basically, if you're going to do a large refactor, then make sure the boss knows you need X weeks to just work on that. Your 80/20 advice is also excellent. If you can easily read and understand what the code is doing and it reasonably efficient, then your time is better spent elsewhere.

[@SquareTales]

my experience is that you need to find a good balance between refactor and progress. Also often times you can get better at designing new features in a clean way to begin with. Of course there will always be imperfections but just stick to the rules at least and clean up stuff when you touch the code again Another big problem I have encountered is that programmers often tend to make stuff usable for every future undefined scenario. But they actually just dont know so should just stick to what they know right now. Often times they also reuse old stuff for new requirements and start implementing different modes inside a component for instance in angular. Its no shame to do a new component and make sure it does one job but one job good

[@LanguageHelp]

In our project, we started refactoring by just hunting all if nestings and made them into if guards. It made us feel good about the code. The next time we refactor we'll focus on something small like that and change it across the code.

[@vitvitvitvitvitvitvitvit]

I am experiencing something like what you went through when you were a fullstack developer. I do all the coding at my company (frontend with React and React Native, backend, deployment, etc.). I always want to refactor all the code because the me of two months ago was dumb. The worst thing is writing refactored code, which is supposed to be better, and it's not. I hate programming alone, but I think it's good in a certain way. Thanks for the tips! :)

[@dimitridoroshko]

Write code as if it will be maintained by a maniac who knows where you live

[@joelbrighton2819]

🤣 Funny but sage advice!

[@petrtcoi9398]

What works for me is to put all the messy spaghetti code into a function, tuck it away in the 'utils' folder, and enjoy clean code in the rest of the project. It's like hiding the mess under the rug and never looking under it - very effective! 😄

[@soniablanche5672]

Unfortunately sometimes you have to add spaghetti code in multiple files. Imagine if you have a system that adds stuff to a database, render an html page, sends email, sends notification and other bunch of stuff and each have their own file and your changes would break all of them unless you spaghetti code all these files.

[@petrtcoi9398]

@@soniablanche5672 Usually, such a problem is solved by organizing the code, isolating individual functional parts from each other, thus preventing them from disrupting the operation of other parts. Here, you may have to compromise on the DRY (Don't Repeat Yourself) principles, but in my opinion, it's better than getting errors in unexpected places.

[@benbynum]

This is a great topic and it sort of comes down to idealism versus pragmatism. Engineers often look at a problem and assume that they have a better solution than the current one, and frequently they do. But it is yet not realized, it's only theoretical. As such, it's impossible to know all of the unintended issues it may create, which in some cases completely offsets any benefit gained. There are no perfect solutions.

[@KittenKatja]

I believe it's ok to refactor when you just start coding in general. I have made like 4 iterations of my user style sheet for KZbin, the first looks like a long list of single selectors with 1 or more properties, the second has grouped them together based on the visible feature, and finally uses more selectors in one given rule. The third no longer groups them per feature, and puts the feature name in a comment before the selector, the fourth is below the third, calling it "restructure", and it mostly gave up on the feature names, is now grouping them based on the property, and only one property per rule. (unless it's a special rule in misc, then it can have more properties)

[@randomguy-vq4ue]

making the code 1% more readable is already considered "refactoring". Never ever recode/refactor everything at once.

[@75yado]

well it's situational. Sometimes you have to.

[@tomraaff4576]

Additional tip to tip #2 ( There is no perfect code): Accept that some parts will be messy, but if you can: try to separate the messy/complex stuff from the other parts of the code as well as you can. This is where the single responsibility principle really shines. If you have a complex part that you simply can not simplify because it just is that complex, please make sure that the complexity doesn't leak out. Put it in it's own file(s) or module and make sure it's api is strict.

[@sire_ns]

One man's refactored code is another man's spaghetti code and vice versa.

[@Michael-sh1fb]

"Refactor small bits at a time". If you lookup what 'refactor' originally meant, it's always small, by definition. People use it as a fancy way of saying 'rewrite' but that's not what it originally meant.

[@83hjf]

also instead of refactoring, time is better spent writing tests. THEN you can think of refactoring.

[@Andrey-il8rh]

Being 1 developer on the project won't make you truly appreciate refactoring. Have you ever tried to work with a codebases supported by one hundred developers when no one refactor anything because the whole thing is already so fregile that jenga looks like a fortress next to it? I was and it's a complete nightmare. Refactoring should be embedded in the process on the most fundamental level and yes, it should be iterative, than it will work very good

[@vincentdesjardins1354]

That was very good and usefull advices. Thanks

[@LinhTran-mh9lb]

Thank for sharing. That’s what i’m doing for all my projects. Sometimes, i was busy to review member code. That’s a big mistake !!!

[@wouterzonneveld2305]

On a sidenote, I think there is a time and a place for a full refactoring. This could be when you want to eliminate a piece of the current tech stack, or when simply so much time is being eaten up by finding bugs and extra time needed to add features that the refactoring pays for itself in a relatively short amount of time.

[@tripunify]

great job man, good to see you actually made a video for this. right on point. but I assume a lot of engineers might disagree, because large tech corps always tell their employees writing clean code and add more unit tests to be "engineering excellent". One thing most engineers do not even think about is those companies can afford their employees to write clean code and unit tests and continuous refactoring, and for sure clean code makes your peers or supervisors feel good when they look at it, how many times you've heard "remove these comment, it is not clean" when doing PR code reviews ? if you leave your job, they will hire another employee to do the same thing. Writing clean code is not a bad thing per say, but it will not do anything. it is simply a bundle of files. the product needs to reiterate, it needs to serve consumers, clean code will not do that. How many engineers knew those big tech firms at the time when there were only a few employees ?

[@jsonkody]

I am working on refactoring very very much :) And it's good money spent - I first fast prototype a feature fast, discover ever usecase that we may want and every loophole, then when it works and when there is time I refactor that to nice readable and smaller code - at that process I sometimes see some ways of making it faster, or I pick some minor bugs.

[@fabienbroquard7690]

Iterative is the best refactoring indeed ;) I tend to think more of it as generalizing repetitive features... It's time to refactor only when you see more or less the that same things repeated over and over. So it's about generalizing the parts that can be generalized, as simple as first noticing a couple of 5-10 lines that look very simialr here and there, then making a generic funciton of all thoses cases, and so on. The full refactoring/generalizing pattern just emerges almost naturally with such methods, because it starts looking cleaner as things grow bigger (which is the opposite of what happens in most projects!), so the patterns become visible and observable. And then, as it's iterative, it's best to just refactor old rather stable and untouched code! So as these parts become cleaner and freeer of bugs (because of the tiny groupings of all like-lookign functions/codes), it's simple to pass the refactoring unoticed to these old stable parts (it's not a hard refactoring, it's just continual grouping of similar functions and behaviours), then the new parts can slowly be made part of the refactroed code, while also not having to refactor everything else all at once. The refactoring patterns are visible and understandable, the non-refactored parts are visible (and can be refactored when time arises, or when there is a need to work again on these parts of the code) and the new parts can follow the newer/evolving coding patterns. Refactoring everything all at once, is deemed to fail, because it's not tested as it progresses... Whereas if it's a grouping/generalizing of common behaviours and small code parts, then these small parts become better tested in all their cases as the refactoring is happening. Real refactoring is a matter of small improvements that slowly creep into the production code without anyone even noticing; while actually stabilizing the repeated and generalized behavious! This leads to a point where lots of stuff are very loosely coupled, and can be moved around while remaining very stable, because they were tested in so many use cases already. At that point only, can a strutural change happen that actually causes almost no bugs and can make everything look neater quite quickly :)

[@navidkarimi5120]

You should make a podcast with this kind of information .it will be awesome

[@JustinK0]

It seems like if you're spending that much time to refactor the code, it seems like it wasnt "clean" in the first place, Open close principle for example suggest that its open to extend but not modify.

[@ericmp1199]

A really great video. I felt identified in literally everything u said haha

[@stevesaldivar1569]

One of my ex bosses, the one that would do the tech stuff, would always shit on me because he didn’t like code that I would write. The problem was, when he writes code, lets say a web scraper, it literally took him months because he wanted it to look perfect, and I would get the same thing done in a weekend.

[@limitlesskode]

I am experiencing this right now with a new company I just joined 😂. I’m presently refactoring

[@bharatchakrabarthy7571]

I was having a dejavu, then I remembered this video was part of your course 🤣. Cheers man

[@gustavoayala7385]

I think the advice is so simple that can be oversight how good it is. I can't recommend more the book of MartinFowler 'Refactoring:...' that the current edition is based on JavaScript. The key is not to think in a big complex design or elegant architecture, clean and beautiful. The magic really arise taking small steps, but there have to be automated tests, because when refactoring, and more on spaghetti code, always something can be broken.

[@Charles-sy7ej]

I kind of looked at you like a lot of other youtubers that make courses for web development. but I have actually been doing the odin project and they link a lot of your videos. So I think after I finish TOP I think I will go check out some of your courses 😅

[@laneW612]

thank you for sharing your knowledge!

[@calcaware]

I think you just prevented me from making a huge mistake. Thank you.

[@user-xz5cm5ix1c]

I was doing the same a month ago but learned the hard way. I only refactor the component I'm working on

[@arminlinzbauer]

I've had a similar experience with an overhaul / rewrite where I planned on completely overhauling the entire app but only ever got to do the frontend because I switched teams. It sucks and the backend is to this day still a huge mess that now because of my overhaul is only usable with the new frontend through a hacky git submodules setup and lots of symlinks... On a more positive note, the ld frontend code was such an utter mess that we're still better off with the new version using workarounds to connect the backend than we ever were with the old frontend.

[@DONGNebab]

I hope that in the future, you could provide tutorials for Ruby and Ruby on Rails.

[@adamos.webdev]

Thanks for the information 👍

[@floppa9415]

It depends. I think some "clean code" best practices just aren't worth the hassle like hardcore inheritance, annotations, getter and setters when they aren't needed. But some have in my opinion have a massive impact long term. The biggest one being exact typing in typescript. For example if you have a function that takes a string but in reality only does something useful with the strings 'yes', 'no' or 'maybe' than specify this with a union type. When you look at the function a year from now you are gonna be glad you did.

[@langhamp8912]

I find the Microsoft "interfaces" (not sure if other languages have something similar) to be hugely beneficial in keeping types honest across objects.

[@SOLDAT_MENDES]

Absolutely, While some "clean code" practices may not always be worth the hassle, others, like exact typing in TypeScript, can have a significant long-term impact. Using union types to specify the valid input values for a function can improve code clarity and maintainability. It helps future developers understand the intended usage and prevents potential issues down the line. It's definitely a good practice to adopt for better code readability and maintainability.

[@sonictailsandsally]

“Refactor small bits at a time” - That’s exactly what I’ve been saying.

[@Joso997]

Add feature -> refactor, rinse and repeat. Eventually similar features are going to be easily addable, and only new features might need eventual refactoring

[@eio4528]

I understand the point but this is more of an explanation about a lack of planning and not an argument supporting spaghetti code. I've been the tech lead on a project where other developers consistently left the code they worked on far worse than before. One dev decided to do his own 'rogue' refactoring, ignored precedent, and introduced bugs that have been extremely difficult to replicate. His refactoring turned code that flowed through a pipeline into a set of actions that reach into a black box of globalized state control that is hard to trace the new bugs he introduced. This cost us 3 extra months of fixing these new bugs and we kept pushing the release date. Now, we have paused development and are a week or two into a project to refactor it back towards a 'pipeline'. He rushes through tickets because he's too focused on getting things done within the point estimation of each sprint. This is wrong. If a developer completes 20 points in a sprint, but creates 10 points in bug tickets that trickle in over time, how many points did he complete? I would argue it's NOT 10 and in many cases completed NEGATIVE points. Those 10 points in bug tickets may go to other developers who also create a small bug or can't complete the fix in one ticket, etc. This is why I cannot stand the concept of measuring developer productivity by measuring their points per sprint!

[@etinosaizekor6533]

Great perspective

[@michaelgtz4873]

How have you refactored it, if I may ask? IMO if you untangle rendering, calculations and side effects, you are half-way there. And it easily can go in pieces, solving your problem going forward

[@pxkqd]

The most important metric is how easy the code is to refactor. And doing it often.

[@Oliver-rh5bv]

We are in Project Business. So this means we have a very tough time schedule to deliver the final version of the project software. In parallel we try to standardize our project software to be reused as a product after the project has finished. Now the tricky part. Every 3 month full of new feaure development we get the chance to do some imporvements in a couple of days (at most 5). But you are only allowed to do so, when you are not too late delivering your 3-months-potion of the whole project. We are kind of screwed and are sitting in a big ball of mud at the moment. I tried to group up developers to not implement new features when improvements are stacking up endlessly.

[@januzi2]

I'm in the process of cleaning the code that's almost 20 years old. I've started when it was almost 19 years old. Fortunately, I don't have any deadlines and I'm almost done. According to the script that's checking the progress, I have around 500 elements in 77 files to go. I'm doing small changes at a time, so it won't be a full blown revolution, but rather an evolution into the right direction.

[@pqsk]

You should slowly add unit tests too as you work on new/old code. I inherited a large code base last year that was written mostly bad. I started alone, but after a few months we hired one more dev. I got a good 25% of the code refactored to clean code. We’re now at about 50%. It takes time and patience, but unit tests are a must. If you refactor and then you introduce regression, you want to catch it as soon as possible. Sometimes they slip through, but it’s worse without any tests. Documenting is also a must, so you have use case steps to follow to ensure it’s all good

[@csy897]

Agree. Unit tests will also help you structure the logic, make sure you explicitly know what context you're in and make sure the methods are not too complex because then it becomes difficult to test. Also, write better assertions as you go if using typescript. Because that will jump at you even before the unit tests.

[@majorhumbert676]

What do you do when you have existing tests that are inherently coupled to the existing implementation? Tests are not unit tests and don't test the API.

[@pqsk]

@@majorhumbert676 depends on what you’re testing. Black box testing will *always* be coupled to the implementation. White box testing shouldn’t be. Although if a function changes the post outcomes then that does require a change for white box testing.

[@eNtrozx]

Not too long ago I did a really big refactor, but I regularly merged and deployed the new code.

[@billmalcolm4291]

“T’was hubris that led me here.” I’d like to think I learned a lot by trying to refactor code bases that I had no business trying to refactor, but, yeah, all in all, they were very modest improvements

[@QuanTran-wt4yt]

thanks for ur advices! I'm waiting for ur gsap tutorial 🥰🥰🥰

[@PieterWigboldus]

Best tip me helped to write clean code was TDD. Define what it should do, code don't have to be perfect, and can be optimized, and can have bugs. But you define what it should do in the test, and everybody knows what it should do, and can make it work, or more readable. So if you don't have time to make it work, you know already what it should do, and a new developer can make it work. If you have bugs, add that scenario to the test, and then write the code. Think about data, not about code. So what should be the input and output.

[@joseavilasg]

This is exactly what is happening to me right now. I am alone working on a project for a ver small company and it's hard. I'm being perfectionist most of the time.

[@joacotossello]

I have this exact conflict every time I open my projects. I'm perfectionist (because of being gifted and ADHD) so I always forget about the K.I.S.S. I'm creating an openworld, so I wanna have cleanest code possible and modular, but every time I open that project, I change same things again and again, because always there's a 'better' way to do them. I'm trying to be more realistic with my goals, but it's quiet difficult to let things 'flow', because I think I'll need something I haven't implemented yet, when actually I don't need it or won't make a big difference, and ends up adding to much overhead just for having it too modular. Logic is not my problem, but perfectionism is.

[@Showmatic]

Jesus, I'm the same way, and definitely attribute it to my ADHD as well. It's like I know I'm doing too much, but it's a struggle to pull back.

[@phamquangvi4413]

I used to be like you, currently I read Clean Code for every language I learn, then apply them if I can, and I think it's ok when I follow these rules (of some experienced developers, like Uncle Bob => you can try to read his book,...)

[@phamquangvi4413]

The main idea is you just apply these clean code rules if you actually need them for now, not for the future

[@joacotossello]

@@phamquangvi4413 I haven't said I write dirty code. logic, patterns and modularity aren't the problem. My problem is to stop refactoring code justo because there's a "better" solution, because my adhd makes me impulsive and makes me have low executive functionality like while making decitions or knowing when is too much. Because, as perfection isn't real, that's an infinite goal.

[@phamquangvi4413]

@@joacotossello ok, I got it :D

[@DamianNAudio]

My pro tip would be to THINK BEFORE YOU WRITE. Have a vision. Plan, then code, then adjust

[@IvanToshkov]

I think this video compares apples to oranges. The first part talks about "the big refactoring", but it doesn't sound like a refactoring to me. It sounds more like rewriting at least a large chunk of the project. To quote Wikipedia: "code refactoring is the process of restructuring existing computer code-changing the factoring-without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality." The fact that you're not changing the code functionality during refactoring is quite important. It means that your unit tests should continue to work after the refactoring. Here is the process that I'm trying to follow regarding refactoring: 1. Don't start refactoring the code just for the sake of refactoring. Have a goal, like adding a new feature. 2. Identify the part that needs refactoring (if any) and what kind of refactoring does it need, to accommodate the new feature. 3. Make sure there are adequate unit tests for the relevant code. As a minimum you need tests that cover all the ways that code is currently used. 3a. If you're especially paranoid, and you should be, you can also see if the tests actually work by deliberately breaking the code to see if the tests will fail. 3b. Commit. 4. Do the refactoring. Run the tests. If they pass you can commit. 5. Implement the new feature. Write tests for it. 6. Was the refactoring actually good? Perhaps you found a better way to approach the whole thing? If so, throw away the code from point 4 onward. Go back to 3. 7. Go for code-review and merge in the main branch. Of course this doesn't always work. For example, there are features that are just too big to do in one single cycle. For these you can use the Mikado method. Google it. I think it's great. Another great use for refactoring is to help you read and understand legacy code[1]. In this case you don't even need the unit tests. You just change the code the way you think it should be and see what happens. When you're done playing, throw away all changes. You now have a better understanding of how the code works and perhaps why it's written the way it is. If you still think it should be refactored, you should go through the above procedure. -- [1] "Legacy code" is the technical term for code written by somebody else or code that you've written more than 2 weeks ago.

[@zappz8858]

There is some truth to this and has to do largely with practical necessity. Example: You need a car to get you to a job. Now you can run around the world trying to find the perfect car that meets every criteria you set in terms of mileage, price, condition, etc. But guess what? For as long as you don't find that car, you can't get to your job, so you lose money every day that happens. Spaghetti code is meant to be fixed, but often is the practical first implementation.

[@RickMurt]

Yes!!!!!!! I tell this to junior devs all the time.

[@robin14441]

A good starting point for Clean Code in your projects is to use a code linter in your IDE + a code review tool that integrates in your CI/CD pipeline, such as SonarCloud. These won't avoid refactos but they surely will prevent common mistakes or bugs.

[@HoD999x]

code review tools do not help. if you are a beginner, they will just make you rewrite your code in weird ways. if you are an expert, they hold you back.

[@nightside8709]

The Athlean-x of programming

[@alejandro.rodarte]

Using else is killing my gains man.

[@Gvue003]

Company requirements into hiring: “Write clean code”

[@THE16THPHANTOM]

i'm happy with my code when people who don't much about programing or development can read it and have an idea of what im doing or better yet have an idea of where my problem could be coming from. or know where if they had to add code where it could go. all these things happened to me and it was pretty satisfying seeing people react to my code that way. i try to avoid going full C++ snob mode where you spent to much time trying to decode my code first before you can understand what its doing.

[@sexygeek8996]

In my experience, it was usually better to forbid those people from changing critical code. Sometimes it isn't practical to make things understandable by everyone.

[@THE16THPHANTOM]

@@sexygeek8996 Fair enough, i understand where you're coming from.

[@masudscloud]

Thank you and this is why I love you.

[@ariyoujahan9662]

1:59 I exactly know what you mean. I'm working as a front-end developer in a small R&D team and all those new devices, all new protocols and devices that come along with them... Those are just driving me crazy.

[@n8style]

excellent advice

[@sandman.38]

Spaghetti Code when you’re first learning how to use the language / framework -> Spend a couple weeks learning best practices / patterns, studying production grade codebases, and learning what works and what doesn’t work -> Rework the entire spaghetti codebase using your new found knowledge. When it comes to new projects you should never resort to spaghetti code unless you’re prototyping for an MVP. Production codebases are not a sandbox for your mistakes and laziness, only development.

[@daydreameravani]

Code that looks clean is sometimes very difficult to understand, as they are usually highly abstract.

[@F3GR-cx9bh]

I think it means the code was overabstracted, which is actually worse because you don't know in advance whether or not they ever gonna get appropriate to begin with and in the latter case its much harder to refactor since the excessive abstractions have already made negative impact on maintainability and readability, you should always abstract things once they start to scale, not before (though you definitely could write up (prototype) stuff in spare time in case they might get useful).

[@turolretar]

can’t we just call it organized instead of clean, I’ve seen the word “clean” wildly misinterpreted

[@theodorealenas3171]

Keeping code clean is an art. I gave it all in and it feels like trying a high level drawing thing with low drawing skills. I like comparing everything to drawing. I kinda miss drawing.

[@Kiev-en-3-jours]

If it's overly abstract it is not clean. Clean means be very easy to understand buddy.

[@macctosh]

Clean code is a natural by-product of good design and vice-versa.

[@maximilianhans208]

Actually this story shows again that a proper architecture helps create things well from the ground up. Of course it wont protect you from messy stuff, but at least the mess is just in some places instead of all over the place

[@nikhilfadnis8009]

Been there multiple times before. My learning has been it's an effort vs reward tradeoff.

[@ionutsandu5913]

Moral of the story: write clean code from the beginning so you won't have to spend months of refactor.

[@basnal_prakash]

Thanks for sharing knowledge,Love from India 🇮🇳🇮🇳🇮🇳🇮🇳

[@turolretar]

Kyle, I’m pretty sure in the end it’s me who’s killing my projects 😂

[@mazenyasser7208]

A fellow developer taught me this concept in this word "Refactoring debt" and it instantly clicked. When you go and implement a lot of features without refactoring old code as you go, it becomes an increasing debt. If you keep this going the debt will be too heavy to pay. So its better to refactor code as you go by doing small chunks each time.

[@hardwired89]

thank you for sharing

[@davidpsbn]

Man I love your content but for the love of God… can you hang at least 1 picture on that wall? It’s time…

[@artem_zakharchuk]

you should speak about this experience with your psychologist) I was listening and feeling your pain)

[@weirdwordcombo]

The good thing is after iteratively cleaning up code, you begin to see the bigger picture of you code and even more iterative cleaning up can be done, and so on. In the end, eventually, it is essentially a rewrite, but it is a longer, more sustainable and feasible process.

[@peterm.souzajr.2112]

i worked at a company that used ruby on the backend and vue on front end too! i worked ona voluntary project to help the team, a google sheets process that displays the status of all the tests based on day/month/yearly summaries. it looked great, but i tried to refactor it, and i worked nights and weekends for a year and i did get it completely refactored, BUT i got laid off before i could integrate my code!

[@paololucchesi2827]

As a software engineer, the method I use is simple: I refactor my code immediately after writing it. I consider refactoring as a part of implementing a new feature, and if the code I'm working on is not clean, my work is not finished.

[@spalczynski]

I spent last week refactoring my side project that is not even published yet. :)

[@lucienchu9649]

My clean code is my like with proper comments, and test case as @example. Every time I came back to a file, I can always find improvement, so I won't spent huge amount of time for perfect coding.

[@Yardan_gholi]

isn't like that , that if you work at a company , they have a choosing architecture phase for the project by having a meeting and also setting the design patterns that are better to use ?

[@unteejo3678]

Haha this video came out the moment I finish my one-month refactor.

[@theta2170]

My attitude is: do your job and go home. If a requirement arises that needs code to be refactored, or stuff to be removed, then do it. Else allow it. One day you'll leave anyway and it won't be your problem. The people above you have no idea how that system works, just that it has the features they expect. This is especially true of agency work where directors just want clients to be happy. Refactoring time is something you'll maybe find more of inside a product team.

[@yourDecisi0n]

I'm a perfectionist and struggled a lot with getting even one project finished because it needed to be perfect. Then I tried the exact opposite of what I was usually doing and worked quick and dirty and woosh my first version of a project was done within 2 days and about 6 hours of coding. I don't even think my code was half as bad as I thought it would be

[@83hjf]

recently one of the architects implemented a "clean architecture", DI and CQRS for a job that only needed to read a PDF file and parse it and spit the output into a table.

[@joelbrighton2819]

@@83hjf The very definition of "over engineering"! 🙄