Why Developers Hate 'Clean Code'?

Hello, everybody. I'm Nick, and in this video, I want to talk about something I keep seeing over and over again and that's the rejection of clean code by modern developers.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet

[Grumpicles]

Purely based on your reaction to reading the word "Scrum", I want to see you talk about it Nick. That reaction was "real" enough to be felt on this side of the screen.

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

[Anonymous-unnj]

Based on what I see in my project, Clean Code never existed...

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

[Jabroni]

I’m all for the Scrum rant. Give the people what they want!

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

[henningerhenningstone]

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.

[gaborpinter]

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

[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!

[ghaf]

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.

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

[krss]

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.

[Tobi-bxkt]

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

[mrBjarneLP]

I once saw a video where someone wanted to make an argument against Clean Code based solely on performance. He had a simple console application that calculated the area of geometric shapes. There was a class for each shape, function with good names and he used the formulas everyone knows from school. Someone who had no idea about the project could look at the code and know exactly what was going on.
Then he optimised for performance. He did some weird stuff with arrays and merged the different formulas for different shapes together. By the second iteration, I had already problems understanding how the code worked because it just seemed like a random array of floats. The resulting program was really fast, but unless you knew exactly how it worked, it was very hard to read.

The average desktop application does not need the last percentage of performance. But it needs to be finished, maintained, developed further, bugs need to be found and fixed. That's the main goal of Clean Code - or it should be.
Find the right mixture of performant and clean code based on what your project needs. Don't be religios about anything. Then you're good to go.

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

[SlackwareNVM]

I know this was a video about clean code (which I have yet to see applied in a company), but my god do I eye roll _hard_ when I hear scrum. Don't you just love spending half a sprint in meetings and then getting asked why the feature isn't done on time as it was estimated. Oh and estimations are such a scam. They're a thinly veiled pact you sign with blood that ensures you'll deliver your feature on time no matter what happens. And somehow we always end up having to estimate in actual days, not relative terms. Sprints exist only in some far away fantasy; in actuallity, every piece of work ends up rolling on to the next sprint because of time spent on meetings and fixing urgent issues that have come up because you don't get enough time to test and who wants to spend money on QAs. And don't get me started on the mentality of "can we put more devs to work on this feature to deliver it faster".

[mattbristo]

The bigger issue is when you have a developer that writes over 200 lines of code in the controller including SQL commands. How is it then possible to quickly understand it, let alone safely change it at a later stage? I believe aiming for good separation of concerns and clean code is the optimal solution.

[RudyGarcia]

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.

[TheoPoufinas]

My favorite project was using elements of Agile and Kanban. No Scrum in sight, we would plan each quarter at a time, set a roadmap and start working on tasks. Sometimes we would deploy to Production up to 5-10 features in a week, sometimes we would have up to 2-3 weeks of no deployments depending on feature size. And it worked, everyone was happy, everyone was super productive because we never had to deal with stupid unrealistic deadlines.

On a different project I specifically asked: what if we finish this task before the deadline, can't we just deploy it?! why wait 3 more days? Management said 'because that's scrum'...

[softwaretechnologyengineering]

Scrum is the most efficient way to introduce technical debt into a product.