Why Developers Hate "Clean Code"?
ฝัง
- เผยแพร่เมื่อ 2 มิ.ย. 2024
- Check out my courses at dometrain.com
Become a Patreon and get special perks: / nickchapsas
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.
Link to the Reddit post: / is_clean_code_dead
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
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.
Id say many dont actually implement Agile Scrum properly. Where I at we just put tasks for "do work" quite pathetic
Forced adoption of scrum by an outside scrum group within the org with little to no consideration for what makes sense to that team given the circumstances is a common mistake I see. The original intent was that the team doing the work would decide for themselves what made sense.
@@MrJSplash Completely agree. And to make things worse, these agile coaches tent to only tell people what to do but not why. The result is a company and teams that just DO agile without ever actually developing a true agile mindset or understanding agile principles and values. Instead, they keep operating with a waterfall mindset in an agile framework - a recipe for disaster and very unhappy people.
@@T___Brown the problem is when people say 'agile scrum' in succession. Agile as per the original manifesto worked. SCRUM is stupid as applied by most teams using it today. The problem is when you take a good idea and try to apply it in ways it will never work. Agile is good as a concept when you don't try to systematize it and you stay close to the principles but it will never work if you try to force everyone and everything into a prescribed process, at which point it ceases to be agile anyway.
In our team we have managed to be largely happy with picking only some aspects of scrum like sprints but I agree that at least sometimes it indeed feels like mini waterfalls. The most important aspect we changed though is that we don't see the sprints as hard deadlines but rather as a point for feedback and where we can (re)evaluate the backlog and priorize (larger chunks of) work.
Based on what I see in my project, Clean Code never existed...
You’re not alone 😂
I washed all my code yesterday! It's squeaky clean now!
@@johnnyblue4799 Unfortinatly not easily done with tight coupling, low cohesion and no documentation in million lines of code.
I agree that having it as part of development process is not good and can reduce productivity. It's just a bunch of tips to help improve readability and maintenance. I introduced code reviews in the company and part of clean code advices were helpful to make code more readable and simpler. First solve the problem and if it is an important peace of code that needs to be revisit often, than try to improve it. Most of code reviewed wasn't refactored.
@@Anonymous-un2nj It was just a joke! :)
Let's have a Retro about it Nick
I think we need to have an intervention here.
First, let's have a planning for this interview. Do I prepare the poker planning dashboard?
can I get a task for this ?
I need a spike for this sprint, what shall we remove for this 20 point item?
How about we do backlog grooming first boys? How about some refinement? A 2 hour meeting should be enough.
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.
That definition of clean code is very subjective and can't possibly serve as a guide to new developers or to a team of developers. What might seem easy to read, understand, and maintain to one person ("this is a concise 30-line method where I only have to look in one spot to see what everything is doing") might not be so good for another ("that big block of code should be broken out into 5 smaller, well-named single-purpose methods"). The whole point of the Clean Code book was to lay out a series of rules for what constitutes "clean". The developers that hate it don't hate the generic concept that you mention, they hate the specific set of rules that appear in Uncle Bob's book.
As you point out, those specific rules may not work for every team. But I think it's still important that each team really decides for themselves what constitutes "clean" and come up with a set of guidelines that the team agrees to follow, even if not everyone on the team agrees with every single one of them.
Absolutely. It was not meant to be a guide on how to achieve clean code, but to underline the importance of the goal itself. How to get there should most definitely be open to discussion, innovation, and adaptation to fit modern development practices and team needs.
@@rjanBergProfile Agreed! We should work together lol
That's because there's a difference between clean code and Clean Code (TM). One is literally just readable, maintainable, and organized code, while the other is a set of guidelines, standards, principles, rules, etc. that bloat your codebase in order to achieve the above results in a specific way.
Most poor developers hate it, just like bad plummers, mechanics etc hate having to do things properly.
I’m all for the Scrum rant. Give the people what they want!
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.
Exactly. Teams who are efficient with scrum often work pretty well also before adopting it or after they changed it to something else. Scrum may or may not suit their needs and preferences, but it's not a gamechanger
Then, there are teams, which struggle with Scrum, but usually they adopted it to fix some problems which it didn't. And those problems also don't go away just by switching from Scrum to yet another method
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.
Exactly!
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.
Agree with the firts half, disagree with the last half.
@@ThugLifeModafocah You are right, the second half is debatable. I would just prefer to keep that particular thing in a purely functionally oriented world where each of these functions takes something and produces something, without side-effects. Unfortunately I've often seen it mixed in with heavy object-orientation in huge classes, which was absolutely atrocious to read :/
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
Pleaaaase make the scrum video. It seems like I'm the only one on my team passionately hating scrum, and it drives me insane!
really? I have the feeling everybody in my team hates scrum and I'm the only one who likes it.
You both need to swap, guys 😂
Majority of seasoned developers hate scrum, but if you say you dislike scrum, you will be gone...it's a religion in most large companies.
Scrum is exactly one of those things. I got sent on a course, got a certificate, the end!
I say "meh", scrum is an excellent framework, the problems come from certification, and "you have to do this" ... the whole idea behind it is the ability to adapt and change along with business needs. Daily stand ups are about keeping everyone on the team in sync, short sprints are about enabling directional change. Scrum is essentially, choose a bunch of things to work on that you can achieve within the given time-box, do the work, review what was good and what was bad during the sprint, make adjustments to your working patterns accordingly, show the stakeholders what you achieved, to give them the opportunity to guide the direction of the next piece(s) of work. Rinse and repeat.
What could possibly be wrong with that?
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.
Yes. I have been doing it the same amount of time. My juniors get paralysed by dogmatic principles. I say to apply where it makes the most sense. Just write good code and make it testable. Write code for other developers not just the business
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.
This somes it up nicely, thanks.
They're not dead and I do apply them. Obviously you want to make changes in one place, not ten. Obvious you want functions to be descriptive and do one thing well. But they're largely just common sense transformed into obnoxious sales acronyms. 😛
Clean code isn't dead, but people shouldn't rely on it as though its the gospel. Code is constantly changing. Your clean code today is potentially rewritten tomorrow. In fast pace settings just write code that's good enough, not bad but also not perfectly "clean". Sure if you had all the time in the world and what you're working on doesn't change often then go right ahead but if you are pumping out releases every month or even in some cases I've seen bi-weekly at times, clean code is the least of your concern (depending on the work ofc). Don't forget as a software developer/engineer it isn't always about just code. You have testing, validations with users, signoffs from product owners, handling the actual release, etc to worry about too. Deliverables and deadlines are usually more critical.
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.
Exactly this! SRP should be the guide for classes, methods, and functions, certainly not line-count!
I agree with this completely, a codebase is just like an app and coding within that codebase is just like UX, I write my code in a way that I feel good/comfortable using but also that my colleagues have no issue's picking off where I left without issues. Taking guidelines/practices as golden rules to never break is the best way to force a codebase to go bad as these limitations never scale properly with the application you are building
hard-limiting to 7 lines of code would just lead to 20 LINQ chains in 1 line which is impossible to follow lol. I'd say methods should be at most 1-screen long, while classes are at most 500 lines.
@@user-cs8ii8tw4y Yep, line counting drives bad practice. Dev do stupid things, making code harder to read just to fit arbitary line counts. Crazy talk!
The shade on poor F# 💀
Somewhere is the world one F# developer cried.
I was really invested in F# and was using it for a few small things at work. Then over time I found that it was constantly lacking in feature equivalency with C# and was far too hamstrung by its own limited tooling compared to what is offered by C#. It really sucks cause I like functional programming, but the drawbacks of using F# just became too heavy, especially given how others on my team didn't want to learn the language. It's a real shame.
@@MrEnvisioner I am really invested in F#. I was not looking for feature equivalency with C# when I decided to learn F#. I wanted something different (really functional, not OO with functional features). So far I am very happy with my choice.
Whenever I can convert my C# imperative code to some succinct clean functional F# code I do it.
@@fsharplove I've been curious about using F# in my C# projects. Do you have any thoughts you'd care to share on how smooth the integration is?
I’m an F# developer, I’ve never encountered a situation where I wasn’t able to write code in C# that I wasn’t able to replicate in F#, using functional alternatives
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..
The hard part of Development Management is to know When and How recover the Technical Dept of the early stages of a product.
Give us an ATDD video 😎
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.
I personally believe that we can achieve both performant code and clean code in the same project/solution. Clean code does not mean "slow code": as you mentioned, it means code that is easy to read, understand, and extend, and it certainly does not preclude performant code.
Oh the "our benchmark is 99% method calls so method calls that are inlined are faster than virtual method calls"-tests. No shit.
My second favorite benchmark after "Language X is faster than Language Y by 10.000% and then one is a const expression while other does the calculation".
@sealsharp cope and seethe oop dork. Go write some boilerplate code
Sounds like Molly Rocket's video
@@reikooters Most likely.
OP appears to be missing the context that the video was a part of an advanced course (i.e. you need more than 4 brain cells to understand) focusing on performance. So they they thought that this was his only argument against clean code, when in reality, it is not.
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".
Not necessarily a problem of scrum itself but more of the underlying company processes.
we have an ol' sayin in Poland: "those who work with the scrum - they don't laugh in the circus"
😂
it seems to be the same in many EE countries, in Russia we say exactly the same 😄
Interesting, personally I think Scrum is in much better shape in Poland than e.g. In usa. Sure, a lot of teams don't use it, but the trend of people learning Scrum on 2 days of training and becoming SM completely ignoring half of Scrum Guide was much smaller here. So currently, if someone from Poland says they work in Scrum, they usually do it by the book and it works for them, otherwise they would have already drop it
The biggest problem with scrum in West Europe and USA are companies which have been saying they do Scrum for years, effectively doing half-scrum half-waterfall, joining the worst parts of both with no opportunity to improve because team has nothing to say about how they work (which is first proof it's not Scrum)
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.
There's a point, your "common sense" is not my "common sense." In general, it's pretty useful to have some base to know we're talking about the same thing.
Maybe we split the developer role in two. Logic writers and cleaners. :D One write the logic, the other goes and adds documentation and more abstraction. :D
"I fear no man, but that thing... (inheritance and polymorphism). It scares me"
Not a big fan of either. To me the star of the show with OOP is encapsulation. You could take the other two away and I'd get along just fine. Don't get me wrong, I use them and they're handy in the right scenarios. But oh man have I seen code that overuses inheritance. :)
Inheritance shouldn't be too deep.
@@asagiai4965I’ve seen class inheritance hierarchies that would make the Hapsburgs blush
@JollyGiant19 I think that's the point, because most people inherits so deeply, it's bad. That's why I said ...
Polymorphism in a programming language is actually really great, but just based on interfaces / traits and generics, not on inherited logic implementations. Code should stay decoupled.
And that is the move that most modern languages have made these days, not just languages like Rust and Go, but in fact also just C# and Java, where everything is done by composition strategies as well.
Speaking about composition, that's also where OOP and functional programming perfectly work together. It's all about flexibly building logic in expressive ways, by builder style patterns and injected dependencies as objects or lambda expressions, which can compose new objects on the flow (which is in fact strongly related to the monad pattern). Just think about LINQ for example. And the entire dotnet DI and extensions system.
It’s all about trade-offs. Clear concepts about SOLID principles, design patterns, OOP, programming paradigms, and TDD are necessary. However, striving for perfection in these areas can sometimes be unhealthy
A nice property of the Clean Code methodology is that it is universally understood. You can come to a large Clean Code project and pretty much start working on it immediately.
The non-clean code (dirty code?), while not necessarily wrong, has potentially high, sometimes very high, barrier of entry for new developers on the project.
yeah, in theory. in practice clean code adepts over-abstract so much that finding actual code that does something feels like an striking gold at a garbage dump site
I've never been able to immediately start on any code base that was so called "clean code".
I have to spend at least an hour hopping from abstraction to abstraction to start understanding what a simple API call does
I can’t tell if this is satire or serious because it’s basically on the line 😂
From my exprience:
"Clean code" is a mess code in a long run because no one understand what's going on in the system. You can find abstractions by default and 20 methods for a simple piece of logic. You can't understand something that you don't know how works (definition of abstraction, you dont have to understand implementation, which is nearly alwasys false if it's not a library).
Clean code is usually simple code with few startegies and factories on top to make it really modular. Methods are usually small < 70 lines of code and split when there is a real need for that, not by default.
Where is this mythical large Clean Code project? 😅
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'...
So your management had no idea about Scrum as no part of scrum guide forbids deploying before the end of sprint. Currently in my company we do Scrum and we deploy every day
I only write instant legacy code..
Java?
@@naughtiousmaximus7853 😂
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.
I agree 100% with you about scrum and agile. What a waste of time and effort.
If Scrum isn’t driven by the developers, then it will just be micromanaged waterfall. I am currently working in a team that does the latter, but years ago, I was in one that the deadlines were given and we would have a large backlog of work, then the developers would work on the plan for completion of features - you want to know what happened, we completed two epics on-time and back-to-back, which the boss was surprised by and said that he hadn’t seen any team do that before and that most would miss deadlines. It isn’t the process that caused developers to hate Scrum, it’s how it is being used.
The biggest challenge is to tell management that they are to leave the developers alone and that they can and should see how to meet deadlines. That means that the stand ups are just a way to say that you need help later or that everything is tracking as expected, this is where you can just make it a simple thumbs up and move on to the next person who may have a problem and not talk in detail about what you are doing, that is a waste of time.
Just remember, Scrum is supposed to be a tool for developers to iterate the project and features based on requirements and not a management one.
Scrum is the most efficient way to introduce technical debt into a product.
You either have culture of maintaining high quality or not. The way you manage your post-its on the board has little influence on that
BRB scrum meeting in 20 minutes. 😶
Hi Nick, what do you think about, stay connected with handson coding or leave it and get into project management and work like postman to grow in career?
As middle developer I have interest in knowing different practices but I value the best to have tech lead or similar role in my project who will actually enforce one of them or at least lead the discussions.
That's it! I'm introducing the External Developer concept. Accelerate developer productivity by measuring how long it takes for a new, external developer to finish a simple, coding work item. Just like Internal/External Auditors do
I had a colleague who was quite good at clean coding according to some principles. His code got so frustrating to follow and debug because there were so many chains of clean, single-purpose functions that you got lost in the depth of them when trying to understand what happened. The best, clean code is not only relatively "clean" but it should also be pedagogical and make sense. Sometimes it's better to not extract code to functions how contradictatory it may sound. Also, me working as a consultant in todays market where people switch jobs like underwear, it's also extremely useful to make comments in code more than maybe extracting functions to insanity because for some new, poor sob, that gets the ungrateful task of finding a bug in code he didn't build in a project where he is completely new there is no clean code that solely helps his work but making code that make sense to a human being and with some helpful comments are worth more than clean code according to all models etc.
Interesting. I see the phrase, “chains of single purpose functions.”
I agree, long chains of un-reusable code isn’t good.
In some situations, developers misapply the Clean Code Newspaper Metaphor, with very long call chains. For example, I’ve even see important business logic at the end of 6 method chain of calls-with all methods/functions not reusable. That code base was very hard to read!
What I think has gone awry when following software engineering principles, is following one or two principles to the exclusion of other software engineering principles.
All the principles must be applied together, to find a harmonious balanced fit within code. But when a developer applies a principle very narrowly, trouble lies ahead.
The challenge, of course, is developing the skills to know all the major principles, and apply them well. That takes years of experience and proactive discussion to get good at it.
@@michaelrarela5734 I appreciate your answer. Coding is, i.m.o, a form of art that is dependent very much on the experience of the developer, his/hers personalty and style, and the current environment in which the code/logic is to be applied, plus many other factors..
great video, we had a senior come in recently who got a team lead role who tried to push clean code straight from the book on everyone. He ended up leaving in January after tanknig the performance of our performance critical application lots of simulations and calculations. My main issue was that it took the science out of everything, and that he replaced certain optimizations or even whole modules with code that was essentially 2008 Java (abstractions on abstractions on abstractions), causing a sub milisecond simulation to swell to 10 ms. His thought was to scale it more on AWS (this didn't work and cost us a fortune in extra compute required for our SLAs). Also, don't get me started on the ways I've seen scrum attempted in a couple of previous companies!
Yeah, they really don't grep the cost of excessive abstraction on performance critical sections. If you're dealing with more pragmatic people, you can just say "we'll put 'here be dragons' on that section and properly document it" and done, but if you're going against a "purist", good luck with that...
you've mistook "clean" code and confused it with SOLID. That's the difference.
clean code is about effectively cleaning business layers
What developers do is JAM in their rules and code and over time it that ONE function extends and extends so you end up with 10 rules inside foreach, no clear documentation about what is going on.
What you've described is C#/SOLID/OOP which is what your hard core developers did 2000-2010 - they got wiped out in SPA applications
So to me, in your example, there's a difference :)
Having one method that extends and extends so you end up with 10 rules inside foreach, with no clear documentation about what is going on is NOT performant, not reusable, not maintanable and not professional. I'm not advocating at all for that. Reuse, testabillity and maintainabillity are extremely important, and wherever possible should be used.
The underlying issue here was that in pursuit of following exactly what the clean coder book perscribed, to the letter. For example the layers of abstractions and simplifications degraded our performance critical solution to a point where we could be exploited by the market.
@@alexthebassist23 Don't think too much about it. As we say around here, our friend needs to put a bit more tobacco in it because it's hitting too hard...
There's a difference between a poorly expressed train of thought and loosely connected ramblings. The former sounds like an awkward translation, the later sounds like ChatGPT on acid.
@@alexthebassist23 yes understood that :) I understand your frustration, it's hard to deal with these guys ego's how "smart" they are. In future, possible use of BenchmarkDotNet for "critical paths" so any rewrites, .net upgrades, libraries can be called out straight away in PR's/POC, etc if they don't deliver more performance or blow out performance!
To your point about startups not using CC - I think therein lies one big issue. When you don’t prioritize building the foundation of an app from the outset in an organized manner (whether that’s using CC/TDD or anything else), it becomes too expensive later on to refactor it. Or for example, I’ve been on teams that try bolting on CC concepts to an existing application and it just becomes a big mess of competing patterns
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.
The issue is what is the definition of clean code? If you mean the book and its set of rules, there are several articles and videos that bring some light in why some of the stuff is poorly coded in the book and why some concepts do not make that much sense anymore, since the evolution of the languages has brought new features and not functional programming is gaining traction.
if you talk about creating a code base that is easy to understand, and maintain and generates few bugs, that is what everyone is aiming for.
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.
Nick, what elements of functional programming do you use when coding in C#?
Great video as usual! We need your video on scrum now!😂
The quiet part out-loud. Love it.
In my job i was able to teach some basic concepts of clean code and the code quality improved a lot, i think basic clean code can be followed for everyone and helps a lot to improve the quality.
Fr, like if the team has no standards, creating some will definitely be an improvement!
Great article topic to review, keep these kind of videos coming! Hard to tell when you're switching between reading the article and voicing your own opinion though. Maybe, add a pause before the switch?
My first .NET interview was with a fintech company. The whole interview was about clean code and design patterns. It was 4 hours long and very boring.
Now, more than five years later, I force my team to write clean code whenever I can. I think to some degree clean code and specific patterns are important. Yes, I know it’s important to deliver a product as fast as possible, but I work in a very large company with a lot of developers, and it’s also very important to keep the code maintainable and readable because we often switch projects between teams. At least with my team, I can feel good that we deliver code everyone can maintain, and in the long run, that reduces costs by a lot because it also reduces onboarding time etc.
I don't think it is dead in the sense that the one of the responsibilities of developers is to have code that is easy to maintain by the team, not just the individual. I have also seen things extracted out to far for the applications purposes, so just like the 'Odd Couple' there is the extremes of Messy but works hard to maintain and So clean it is hard to understand but it works.
As developers we need to advocate for the code. I do believe understanding the concepts of both CC and SOLID can make you better at avoiding pitfalls. I'm a fan of TDD because so often developers start coding a solution and add extra or get distracted by "features" not yet needed or discussed. I see it as a focus tool as well as a way to define when done with this coding session.
As for Scrum and Agile my main issue is too often these are sapping time away from teams and at times the ceremonies seem more to justify a position in the company vs actually helping teams succeed. Worse is when I see a team of 10+ and they try to keep a standup to 15 minutes, that is insane and would drive anyone crazy.
Every now and then a new "big thing" comes along that people hype up as the one thing that fixes all our problems. Clean Code is one of them, also scrum/ agile and microservices. Since everything in tech is just a tradeoff of things, the obvious problems with the "new big thing" come to light and everyone hates it. It is exceptionally ironic, when the people hyping it up (neglecting all criticism) are the same who hate it after. Imho I think every "good" engineer/ craftsman knows what to keep and what to discard pretty soon. If following a recipe to the T would bring guaranteed success, none of us would have a job, because a high schooler could do it in his/her summer break.
Scrum: What went well in the last sprint? Bob really took charge and was able to do an amazing job adding the 8 point feature. Way to go Bob!
@Nick I think you are missing the point about "New developers joining..." he is talking about day one of development, not necessarily day one of joining the company. we all know that it takes roughly a week for a new (permanent) employee to be ready to start coding -contractor engagements are a different kettle of fish and usually it only takes a couple of days because, generally speaking, there is a lot less involved in the onboarding process.
I have only 2.5 years of experience. I have never dealt with scrum and I didn't use SOLID, OOP, TDD stuff either. But I know that managing a big code base requires consistency and some amount of attention in giving names to the variables you create. When you do those 2 principles, you can manage big code bases easily and you can have fun while writing code.
I want to try out scrum, I want to use SOLID, OOP and TDD principles. But those are not things that define my coding skills. They shouldn't define yours as well. Don't be obsessed with writing the best code.
Best engineers are always those who can min max in any situation as best as they can. Don't forget that.
Coding skills are defined as writing code in such a way that another dev (or future you :) ) can understand and mantain the code without too much effort. Naming is one thing, but things like SOLID and other clean code practicrs can help you to achieve that goal. It's also being nice to your co developers. In my 20 years as dev i've seen of lot of big code bases with spaghetti code which could be somewhat prevented by using clean code principles.
"it's not about you, it's about them". That's a wake-up call we should all try to remember when getting stuck into a fun and satisfying refactoring exercise!
I would love a video on the bad things about scrum and its many downsides! 🤩 Your points mentioned are some of the ones I have had myself for a long time.
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.
After company where I work adopted SAFE and Scrum I have gained understanding why people hate them and how they feel like extra obstacle instead of helping to get job done
Again, it's people being dogmatic that is the problem, it's certainly not scrum. Scrum is ... chose the work for the next sprint. Work on it. At the end of the sprint reflect upon where improvements in the process can be made, make those improvements. Rinse and repeat. Tell me, how that can be a problem?
@@user-cs8ii8tw4y In theory that is how it should work. But that is not what is seen in reality. In sprint plannings and program increment plannings situation is more often than not such that team plans time allocation for different type works, like how much support cases the most likely will be, how much time will be used for customer x and how much for customer y and how much time will be used to plan features that sales team has sold for customer z. Then team has to also allocate time for two legacy systems which needs to be supported until new system that is done team in another country is ready, but that transition is already been done for several years and there is again new delay. And end result is that nothing concrete was planned in those planning meetings, there is nothing that can be done to improve the process as that is not priority for company management as it is more important to get new sales in order to satisfy owners and whole process is just some strange pantomime where people pretend that they have things under control because there are jira ticket for time allocation for it, even though every one knows that time allocation ticket will be moved to another sprint or used to some other work.
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...
Let's breathe slowly and look at the bigger picture. Long-term development velocity is crucial _if_ (and that's a big "if") the software has a long life cycle. And Clean Code is a decent, though not perfect, way of maintaining long-term velocity. I work for a company that (among other things) still extends complex software that entered the market in the 90s. If you let a code base like that rot, it will kill you. Every "unclean" coding may improve your time to market for the first release cycle, and kill your time to market for all future features.
While it's good to question some technical details of Clean Code: If you work in a team that produces long-lived software and find it consists mostly of hacks - run!
Nailed it as usual, the amount of places I have interviewed at that ask me about SOLID, I guess its a great interview question, the same as TDD. Rarely seen these principles followed
Sound observations and advice. My only criteria these days (I do like clean code, tdd, unit testing etc) is trying to get continuous delivery going. I think this trumps all since incremental changes and feedback are the most crucial part of delivering software. So in the end you must ask yourself "what are the roadblocks stopping you from doing CI/CD". Does it mean forgoing all good principles? Of course not. As you pointed out, you find a balance and hopefully you can deliver qualify as well.
Even uncle Bob moved away from Oop and now is programming functional. The big problem is that proper OO often ruins locality of behaviour. You need to look at 20 files to understand a trivial thing.
Hey Nick... Given yoru reaction on scrum, I'm all for the rant about it. And what would be your perception on the best project management aproach to build and ship software products.
I was in a situation a couple of years ago where I was on a team of developers who were each working on their own unrelated projects. We were developing code examples for other developers using multiple languages. Most of the time my report at scrum really had nothing to do with what anyone else was doing. I dreaded daily scrum meetings because the only real use for scrum was so that the manager could keep track of what you were doing, a topic that should have been discussed at the manager one-on-one. I felt that it was the biggest waste of time on my calendar.
Scrum is the worst thing I have to deal with at work, even worse than bad code.
scrum is not the problem. Scrum is a means of time-boxing work effort, that's all. How can that be the problem? ... time to look and see what the problems actually are and adapt It could be that people are paying too much attention to "you've got to do it like this. This book says do this." That problem is not scrum, that is people.
@@user-cs8ii8tw4y Easy, when there are things which cant be time-boxed into say 1 sprint. Or say allocating the correct amount of points. Or say requirements which aren't flushed out but are required. Scrum seems like it works on paper but in practice it only works in the minds of scrum leaders/masters.
Oh lets just keep fail over these stories, making the dev look bad even though they put in all the work they can but its just not enough and we can't put anything above a 5 pointer.
@@TizzyT455 "Scrum seems like it works on paper but in practice it only works in the minds of scrum leaders/masters."
That statement is complete poppy-cock.
It sounds to me like your experience has been tainted by not sufficiently making tasks small enough, admittedly it is something that only comes with practice, but large tasks can be broken down into smaller composite parts.
If requirements are not fleshed out, then they are not sprint ready, that is the point behind backlog grooming.
Also it should be noted that Scrum is not the best approach for every project, and there are alternatives whilst still working in an agile manner: Kanban for example; but Scrum itself is not bad and MANY organisations use it effectively.
@user-cs8ii8tw4y funny as you mention kanban as that's what we were kinda doing before this crap, and it worked fine enough. Also, if my requirements aren't sprint ready, and I'm not in control of the requirements, what do I just not have work? What I tend to do I make up some crap and then change it later when I have said requirements.
Also my statement isn't "poppy cock" what ever that is when you yourself admit that it isn't always best. I believe it isn't that companies need to use it effectively, but which projects can utilize it effectively. I've had scrum in my old job and it worked okay (still not perfect) but the thing im working on now, the entire team is always struggling to create proper tickets. Oh, we require a fix version, but we don't have a release for it yet. Oh, it needs an epic, but it doesn't fit anywhere... so either scrum works on paper and where I work is fucking it up royally or it doesn't work that well and everyone is making adjustments to it so that it works well for their team/project.
@@TizzyT455 you said that scrum
Only works in the minds … which is nonsense, it also works in practice. There are literally hundreds of organisations that use it effectively.
There are challenges, the same as with any framework, but the problems are people problems not with the framework itself.
As I mentioned before, deconstructing work into meaningful timeboxable (I made that word up) work items that deliver value takes practice to get right. It’s also a team effort, including the product owner: they tell the engineers what they want and the engineers tell them what they can deliver, how they can deliver it in an iterative manner. It’s only the engineers that are able to break a feature into deliverable parts since they are the ones who know how to build what is being asked for.
And in answer to your question about not doing any work if requirements are not sufficiently prepared, I would say that the work which can be done is getting those requirements sufficiently understood and broken down into tasks. You are right, you cannot start a sprint if the requirements are not sprint ready. Product owners need to understand this and the only way to make them understand is to not start a sprint and instead continue getting requirements properly fleshed out.
I absolutely agree with you. Using all these principles as a guide line without strictly following is the most effective way of developing applications. For the entirety of my career so far (almost 20 years) one thing is constant - time is limited. It would be great to spend months refactoring, upgrading technologies and improving implementation but there's always very limited time for these things, because the customers are waiting on the newly requested features.
Hey Nick. I've love you to do a deeper dive on what aspects of OOP you avoid and how you handle them these days.
Exactly what you mention at 09:30 . Trying and learning TDD, SOLID Principles and so makes code better by default even when nocht epxlicitly applying those principles. There are so many easy ways to change coding style without effort to avoid race conditions, unnecessary states, reducing complexity and so on without heavily relying on tdd, just by slidly changing the way I write intuitivly code
Really curious to see a video with your take on scrum. Not because I necessarily think it is great, but more because what the posted described of "picking and choosing 'what works for them'" about scrum and that not being the way to do it, is very similar to how you described using TDD or CleanCode should be done ("picking principles that make sense in what I'm doing"). Did I misinterpret what you meant?
I totally agree with you Nick. 30 years of software development and all of these buzzwords and practices have only ever slowed me down... Thankfully running my own software company now, we don't use scrum. Although I will say... it does help to keep you accountable for time...
Neither Clean Code nor TDD are micro-optimizations, they're practices and you don't need to follow them by the book (literally) in order to gain value from them as long as you have a clear idea of how you want to write code and how it should look like to be maintainable while delivering value to clients/customers. With regards to TDD, I've just refactored a piece of code that didn't have any (valuable) unit tests and just by writing some important test cases before making changes to the code, I found several issues with the code and these issues would not have come to light without writing those tests, they also would never have existed had TDD been applied in the first place.
A note about scrum based on personal experience working with different teams: The Agile Manifesto declares "people over processes" (actually "Individuals and interactions over processes and tools"), but most teams or companies that do Scrum actually do this in reverse by putting "processes over people", which is where everything falls apart.
Scrum... yeah we need your rant Nick!
My take: Scrum rhymes with scum and scam.
Scrum = micromanagement = wall of green = speed delusion = dust (mountains) under the rug = reward for quick and dirty devs.
Comes deployment time and poof vaporware.
You absolutely MUST make a video about scrum and agile! I would love to see it!
the company I just started working at grew really really fast in the beggining and is still growing fast, so when they developed their system they basically just put all features in the system without following any standards and Clean Code. However, they now have so many developers that they have made a team, the one I am part of, that is only in charge of fixing the old code: refactoring, changing design and architercture, following standards, optimizing, etc. while the other developers adding new features now are following the same standards so eventually the system will be really "Clean".
So this has nothing to do with clean code itself. More of “I’ve done this once and know where it can be improved so refactoring it will make it “cleaner””. Moral of the story? Just code shit and refactor when u need to because you don’t have a magic ball telling you everything you will need.
I would love to see a video on which aspects that are good to adopt regarding these conventions that are wrapped in a acronym. Maybe a video series, I dont know :D
I always try to write the cleanest possible code with the highest meaningful code coverage (using TDD principles the way you describe it, writing code by default that IS testable) but, as we say in French, "not trying to be more catholic than the pope" and over-abusing the concept just to fit to what some guys decided was "clean" and "not clean".
About stupid questions in job interviews, when I was a junior, I've had an interview where the guy asked me "For the precompiler, what is better between a Dataset and a Datareader?" I couldn't answer (because, really, nobody cares) and his answer was "Are you sure you are a C# developer?"... I'm still a C# developer, not this guy and not because he had a promotion at his company...
About SCRUM, I must say that yes, it works, when it is implemented by the book. Often times (always?), the people making decisions just heard it talks about sprints, they think "sprint is fast, it's good, people will work faster and deliver faster". They then take some parts of the framework they accept to use but reject what would require them to change THEIR way of working (or controlling other people's work...), see after three months that developers didn't suddenly work 4X times faster and end up by saying "scrum is a joke, you're not sprinting, you're walking, it's useless, let's work like we've used to do since the 1980's"...
I've seen companies where Scrum works perfectly, people are happy to work there, they deliver features at a sustainable pace. They all have a common point : they implemented Scrum by the book, and the management agreed to let the realization teams have some kind of autonomy on their work to make it better.
What do you use instead of SCRUM?
Gang of Four > Clean Code. For testing, I’m a big fan of narrow integration tests so I can focus on what usually ends up being my database interactions and get those down pat before building out the other layers. I find it’s those integration points that make or break your performance wise. Unit test the business logic. Write a few broad integration tests to make sure all the pieces talk okay. I find I can go pretty darn fast that way.
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.
I find Nicks argument that management doesn't care about clean code because "who cares about 10% improvement on speed" really bad. Conflating clean code with optimization of execution speed is so weird, it's not the point at all. Clean code is about optimizing development speed: maintainability / keeping cost of change low. Management dóés care about how long development takes for features in the years to come. So it ís important for them and bad code is still a problem.
Weird take from Nick.
Count yourself lucky if you work in a company and have a manager that accept you saying "I need two weeks" and getting that time allotted. I have to agree with Nick that many managers and companies care about the bottom line which is money. They rather have 2 features this week than 1 "clean" one. My personal experience is, and I have been literally asked like this; can it also be done in a week if you cut some corners? We can fix it later! That hacky piece of code will the there for years and years to come. It is not that I disagree with the fact that cleaner code has benefits in the future.
Another way of looking at it is that one could buy a 4 bedroom house or a 2 bedroom house, on the same plot for the same price? Many will choose size and visual appearance (like nice faucet and outlets) over the fact that "quality" brands, 5/8 drywall instead of 1/2 and a nice solid double layer subfloor is put in and will also be delivered earlier.
Management does not understand what any of this means, and how or why it may affect the cost of change is totally esoteric to them. Management is "we need this by Wednesday." If you set yourself up so that it's painless to get it in by Wednesday, you're okay. If not, you piss them off, no matter how clean your code is. And having that kind of agility is as much about anticipating what management / clients will likely need and ask for before they know it themselves than about any methodology.
I was hardcore into "clean code" for many years, but lately I've noticed what I'm doing counts as ... "something else" ... and I think "small code" probably describes it better. And I try to invert things where it makes stuff simpler, not only inverting if statements to early returns and less nesting but also larger concepts like an ID/GUID tracking system or something: rather than trying to build a huge, super class with data collections I'll just make a more centralized and flat buffer and make entries responsible for adding/removing themselves when created or destroyed and so forth. I want the smallest and fastest code possible that's easy to read (because there's not a lot of it) and easy to edit.
I've done it both ways, and I think there's a place for both. The huge, sprawling spider class might be good for nailing some really specific activity that needs to be expandable but in a very concrete way, like say reading, writing and interpreting new json files with who knows what structures. Stuff like GUID, better to keep simple.
"I don't use things very much like inheritance"
From what I know, composition is often preferrable to inheritance ^^
I tend to like OOP with bits of functional. "Clean" OOP design makes the development easier, and tend to lower the code needed for a new feature (from my experience).
Conversely, agile is often a vast waste of time. Nobody gets the quotation in "points". The good part of it is that agile projects I've seen tended to put less pressure on developers. Not sure it is a side effect of it.
I hated Scrum from the beginning. When it was introduced in our company around 15 years ago, the productivity dropped dramatically.
When people saw the productivity loss, they always argued, that's because we're are not fully 100% doing Scrum. Or other similar excuses, no one dares to question Scrum. I got a special agreement not have to do Scrum within the company.
My main critic point is, that no one is responsible for nothing. And everybody has a little knowledge about everything, but there are no experts any more. And the overhead of forced meetings of no real sense is enormous.
I would not choose a job position, where I would force to do Scrum.
The only advantage of Scrum is, that it doubles the job opertunities for computer science positions :-)
Interesting, Scrum says literally nothing about removing responsibility. It even says that team is allowed to split responsibilities within the team as they want
Also, I've never worked in a company, where meetings would take less than 15-20% of work time, no matter if they use Scrum or not
In our case, Scrum moved the responsibility from a single person to a team foreach part. In my experience the code quality decreased dramatically, because there was no longer a code ownership.
Yes, in any case there are often to much meetings. But in Scrum there are often forced meetings, where I counted the minutes until each meeting was over. Some people really like to talk about each pixel they moved.
@@juergenzhang9133 Scrum did not do that, people did that. It sounds like nobody where you work has grasped the concept. As pointed out above, scrum says nothing about nobody taking responsibility.
We do scrum-ish now, but there is still code responsibility. Actually they won't even let you open an issue without owning it first. For that matter, most people prefer it that way... nobody wants to debug someone else's stuff. ;) We do have the absurd meetings though.
No matter how much anyone tries there is no clean code ever!
It's amusing to hear your take on Scrum. I agree that many aspects of Scrum can be unproductive and time-consuming. Retrospectives are the worst, especially when the Scrum Master insists on playing random games to make us feel excited about something that ultimately feels like a waste of time. I go to work to be productive, not to talk about my feelings disguised as a therapy session with children's games. 😂
Lucky man here: We're going from legacy projects (hackatons) to new projects (now 3y in prod): clean and mostly flat functional style code, easy to maintain, easy to add features to. No dead set on hard and fast rules, but solid is the base of our practice.
Absolutely loved your reaction to Scrum! I agree please make a video.
When I started work, and building API, I tried to do code most universal as is possible, like universal actions for removing entity, and inherit from models.
Then I started go get new requirements from clients and PMs. "Change this, add that, change the logic how this working" etc. Then universal started to be trouble, because we need some exceptions, more and more.
Finally repeated code started to be better. When I needed to change something in some module - I just did it, not thinking how it can affect to other pieces of code in another module.
Theory and scheme is one think - practical, and changing requirements other
I was obsessed with clean code and all the practices that come with it in one company where I stayed for a while. After I left I found the practice to be non-existent in other companies. I can also attest that some interviews have questions related to it, but the companies themselves don't practice it. I feel like architecture is more of a practice at businesses now. I also now feel like architecture is extremely important. As an example we are doing business with another company and they gave us are response time limit. To me that time limit it's mostly architecture that gives you those extra milliseconds or maybe even seconds. Sure the implementation is important, but as long as you don't use really crappy code then the implementation shouldn't cause a problem for any latency. And if there is then there is only a small amount of code that is responsible for the wait and see that you will have to change
Great point, seen it in many places with established products: if something requires time and resources investment, but brings little value - business won't agree to that, since it is net loss. Roughly speaking, "if it works - don't touch it"
I have some ambiguous thoughts about scrum methodology, daily calls in particular: I don't like to tell what I was working on yesterday and what I will be doing today, but I like to have a talk on a call about everything else. And like calls in general, because it's good way to practice English
Ah scrum and sprints ... always a joy on meetings twice a week where I take that time to actually do work and code, while "listening" for my name to finally be called so I can say what I'm working on in 5 seconds.
I think something that has changed is the life span of various parts of the software. I think software used to be around longer before it was deprecated or rewritten. This means that spending time on clean code has less value as you will be upgrading troubleshooting and refactoring each component for much less time and each component has less time accumulate the complexity that makes clean code more and more valuable. Nowadays it feels like software has a very short lifespan. I think part of that was the push to microservices (it's easier to rewrite a small component) even though in recent years we've moved backwards from that a bit. I think API standards have drastically improved to the point where it's easier to make another API that replicates the functionality of the original in new tech as well. Even in software that lasts longer, subcomponents change or are rewritten themselves more frequently.
I got a job offer where they ask for a extreme developer and I didn't bother to answer. They just want to put trending words on their positions just to make them look more attractive where they are recruiting
Thank you for your insight Nick!
Never heard about Scrum in such details before.
Focus more on the task, and less on ceremony. It will get you much further in software development.
TDD can be extrapolated into extremes. Some developers are fanatics about code coverage and want to cover every line in their code. Sometimes you must go for the middle ground, where your code should be testable, especially your central code. But often there is not enough money to add as much tests as you desire. Sadly, many in middle management also lack the understanding why tests are important. Tests are important, but one must be pragmatic.
Clean code should be grounded on accepted standards. You could enforce code style via .editorconfig in Visual Studio for instance. But it can be off putting to some developers with too strict a regime.
I think its important to have some ideals to aim for. Clean code, SOLID, etc., these are ideals. Many developers are not even capable of following them to the letter. I think it is important to distill the principles out and use them when they make sense, but as nick says, one has to be pragmatic. Enforced uniformity stifles creativity, however. People also have different skill levels and maturity. Some of these concepts are not obvious and need to be learned by doing and there isn't always time to do the learning in industry..
Agile is take and use what works for your team. Similarly to all these concepts, they are good to know the reasoning so you have more tools in the toolbox to use. Just don't take your only tool the hammer to caulk in the window.
I once told a new programmer on team about design patterns that 1: our customer doesn't care, 2: I can describe my code as following any design pattern, and 3: they are useful to know so that you have various tools and ways of doing and understanding things.
IMHO the problem with our craft is that it's not yet a science. It's on a level similar to Alchemy, where the Big Guru recommends something, and everyone uses it because Big Guru says so. Managers love Big Guru's teaching because it makes them think they know what they're doing and it calms down stakeholders.
Depends on the product. If it is a huge complex system, that is gonna be extended and maintained for many years. Not having clean code will probably end up costing more monney in the end, since feature/bugs fixing will take much more time.
Good coding practices are not only for how fast code execute but more how maintainable is, how easy you can scale the product and add new features. Product managers doesn't care about all these until you need to fix something or add something new, then they will complain how developers doesn't perform.
And adding to my previous comment, I feel it's crazy so many devs are against scrum, scrum PROTECTS developers by design from constantly changing priorities, this alone should be enough to love scrum. It's usually the stakeholders who hate it because it forces them to plan and to stick to the plan for at least two weeks! If you hate scrum you are either doing it wrong OR you are one of those devs who like chaos because in chaos it's easier to hide yourself 😅
Over the last decade, I have tried to delve deeper and deeper into the topic of clean code. But the more I've looked into it, the harder it is to find a reasonable definition for clean code. It somehow seems like a magical creature. Almost every developer thinks they have seen the creature from a distance. But when you get up close and try to define criteria for what exactly clean code is, it usually ends up being an exchange of opinions, having little to do with facts and more to do with personal preferences.
In the end, I avoid these discussions now. If someone makes suggestions to improve "readability" and I can't see anything obviously bad, then I accept the suggestions, even if I disagree.
In the end, I believe that my time is worth more than the potential outcome of such a discussion.