@Anonymous-un2nj
Based on what I see in my project, Clean Code never existed...
@Jabroni24601
I’m all for the Scrum rant. Give the people what they want!
@rjanBergProfile
If we consider the broad definition of clean code as "code that is easy to read, understand, and maintain," I find it difficult to understand why some developers would "hate" it. The primary objective of clean code is to ensure that the next developer who works with your code can quickly understand it and easily extend, fix, and verify the changes. It is important to differentiate between the concept of clean code and the specific "rules" that are often associated with it. While these rules should certainly be discussed and critiqued, they should not be conflated with the overarching goal of writing clean code.
@henningerhenningstone691
I've come to a point where, when asked about CC and SOLID in an interview, my answer would be "do you want someone who's good at learning definitions by heart, or someone who writes good code? Show me some code and I'll tell you what's wrong with it". I can do the latter using common sense and a decade of experience, but have long forgotten what I had to learn by heart from books all those years ago. It's good to freshen up on concepts every now and then, but writing 10 methods with 5 lines each, which are all only called once, is anything but clean. It disrupts the flow of reading and puts correct execution order at risk, especially when all data is stored and manipulated in member variables.
@nexxxuno
Best companies I worked for used scrum effectively. When scrum doesn't work it's usually a hint about much bigger problems in the company, like not being able to commit to your short term planning (2 weeks) or not being able to plan at all.
@DanteDeRuwe
Pleaaaase make the scrum video. It seems like I'm the only one on my team passionately hating scrum, and it drives me insane!
@krss6256
Devs are sometimes such a drama queens... There is always a grain of truth in all of these principles. And as long as you are not dogmatic about them, but pragmatic they are great principles to know and use. Even scrum. Clean Code is not dead. SOLID is not dead, DRY, KISS, YAGNI are not dead. Just don't be dogmatic about them. The only thing that you should be dogmatic about is to keep to standards, conventions and concepts established by your team. And make sure you discuss with them any exceptions from the rules.
@gaborpinter4523
My experience in clean coding and agile: - There is no requirement documentation anymore, only miro boards, so basically nobody knows what are we developing - What we call MVP is a full featured application, because the customer cannot live without background color changing - We create unit tests for each and every small method, integration tests with some test data, but the first run with real data will kill the application because the one thing everybody cares about is that all the tests must be green - Devs are afraid to write code by themselves, instead they are just using libraries without deeper knowledge of the actual technology
@thebitterbeginning
A-frickin-men! Coding for over 20 years, been saying it as far as I can remember... "STOP forcing process-dogma where it doesn't belong!" Each methodology, discipline, etc has pros/cons. I've never found any of the cookie-cutter methodologies to fit unaltered to any project I've worked on. ALWAYS adapt your methodology to the needs of your project/business/etc. NEVER follow blindly.
@ghaf222
I think many developers take best practice guidelines too literally. For example on a course I went on they said a class should be no bigger than “2 screens” and methods should have no more than, I think, 7 lines of code. I get that they are trying to make you think about splitting up the code nicely etc. but some developers will split an 8 line method into two, which doesn’t necessarily always make sense.
@clixmods
In my experience working at a company that prioritizes clean code, I've found it extremely USEFUL during maintenance, bug fixing, and other tasks. Clean and well-documented code allows me to quickly find the information I need, reduces fatigue, and boosts my efficiency. However, I've also dealt with systems that weren't as clean, and on those "unclean" systems, it took significantly more time to improve, correct, and especially ANALYZE the implementation. For those who don't value clean code, please consider the next developer who will work on your project; it's crucial.
@Misteribel
So many projects have slowed down to a crawl, not being able to release new features, due to not having some semblance of clean code, a decent amount of tests, and frankly, just readable code. Being too rigid isn't good, being too loose is worse and causes spaghettification.
@Zolem-i7o
Honestly, the principles and patterns are not dead. All very important. The problem is that at any given company you have, if you are lucky, a handful of devs who know them, care, and actually use them appropriately. Everyone else tries it once and it doesn't work out because they don't know what they are doing and don't have a mentor and then call it trash. This is typical developer behavior. Most devs are in it for the money. They don't care, they just do whatever is fast and easy. They write trash code and move on to the next company because they hate the code they wrote. Product/business awards these trash developers with promotions because stuff was done fast and now you have senior devs out there who know absolutely nothing and are 100% confident in their ignorance.
@Tobi-bx8kt
Well, I suppose it depends on the product. At my last company, they developed a massive and partly unmaintainable monolith that is practically killing the business. It has become too big to rewrite and too messy to extend and maintain efficiently. Initially, shipping features quickly and cheaply was satisfying for the customers because they didn't follow any clean code principles. However, this short-term gain doesn't pay off in the long run if you plan to continue developing the product. Now, the company is basically wrecked because of this..
@softwaretechnologyengineering
Scrum is the most efficient way to introduce technical debt into a product.
@davorloncarevic5128
This is one of the best, honest, real life situation videos I have seen for a long time. You could probably make 24h video on this subject and it would not be enough, these 15 minutes are pure gold.
@HannesBiribauer
Imho and also experience from working as a developer (currently tech lead) its more important to write testable and maintainable code then strictly follow OOP, TDD or clean code guidelines. Its just a tool which helps you and gives you guidance f.e. how to structure projects, separate domain concerns from external dependencies, use IOC, ...very helpful for beginners for sure to not mess up already when starting ;) Have to say I am doing it much like Nick said at the end: Take what works well for you and your team, educate your team members to write testable code and mostly you are fine. Don't over-engineer (follow YAGNI). Also with experience you are doing a lot of useful things automatically which keeps your code maintainable. Scrum is a different topic ;) - its way better then working in a chaotic way where no-one knows what even should be developed but same as with every "tool" - it can be miss/overused.
@BillyBraga
I mostly agree with you. Some Clean Code concepts are fun to put a word on some good ways to organize code (like abstraction levels), but in general it's mostly common sense and not some kind of dogma.
@sebastianszafran5221
From my experience of being a .NET developer in Poland, it's mostly true about those crazy requirements. They will firstly ask you about each of SOLID rules or some advanced SCRUM principles just so you can land in an old legacy project with waterfall like approach...
@evanboltsis