Why Developers Hate "Clean Code"? 

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.

Let's have a Retro about it Nick

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

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.

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.

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.

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.

Pleaaaase make the scrum video. It seems like I'm the only one on my team passionately hating scrum, and it drives me insane!

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.

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

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.

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

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.

we have an ol' sayin in Poland: "those who work with the scrum - they don't laugh in the circus"

The shade on poor F# 💀

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

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.

Give us an ATDD video 😎

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

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 :-)

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

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.

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.

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

"I fear no man, but that thing... (inheritance and polymorphism). It scares me"

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

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!

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.

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.

I only write instant legacy code..

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.

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.

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

Great video as usual! We need your video on scrum now!😂

Nick, what elements of functional programming do you use when coding in C#?

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?

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.

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

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.

BRB scrum meeting in 20 minutes. 😶

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?

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

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.

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.

The quiet part out-loud. Love it.

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

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.

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.

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.

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

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.

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?

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.

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

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.

With all these things having a standard or framework we all understand is important for consistency and communication, and consistency should be valued (unless valid reasons not to). A video on Scrum and Agile would be awesome. First point you can be Agile without scrum and not be agile with scrum.

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.

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.

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

You and I literally said the same exact thing, the exact same way when the *Scrum Leader* at my company scheduled a call with me -- I feel how you feel in my bones. Can't we just write good code, release on time, and just do what we CAN do to make our quality as good as possible and still maintain some velocity? Everything really is "good/fast/cheap" pick 2.

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!

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

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!

I have cases at work that my seniors did so much abstraction that sometimes when I need to do something simple I am going through base classes -> interfaces -> dependency injection -> classes that inherit the base classes with 5 constructors and reading all of those abstractions for simple things makes my head hurst. Looks like rocket science where on the end the class just connects to the sql db and pulls some data out from the table maps to an entity and that is it.

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

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.

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

You absolutely MUST make a video about scrum and agile! I would love to see it!

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.

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

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.

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.

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

As a junior developer who has only known SCRUM/AGILE, I am very curious about what alternatives you would suggest. I'd be quite interested if you made a video on the topic.

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

Scrum is the worst thing I have to deal with at work, even worse than bad code.

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.

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.

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

Focus more on the task, and less on ceremony. It will get you much further in software development.

I would really push for clean code at the last company I was at because there was A TON of copying and pasting, horrible variable names, magic numbers, etc. Being a small company, these poor practices really slowed down development especially when I was pushed to get new features out the door extremely quickly. How was I supposed to know that the same code block was copied in 30 different places with only a slight change? I had to hunt things down all the time and replace them with a method. It really slows you down when you have to ask someone what a magic number is for/how they arrived at that number in the first place when there are no comments. If I fixed a bug in one place, I would have to search around the codebase to see where the same code was implemented again due to the poor practices. We followed SCRUM where I had to talk about what I was doing everyday which was mostly a waste of time.

Imo it's a mistake to think that clean code starts and ends with Clean Code. What good clean code looks like has evolved. For instance a lot of us are finding the more functional approaches to be cleaner nowadays.

I truly relate! always reviewing clean code tdd, solid before interview. When I got the job and saw the source code it was not following this concepts.

We use scrum, actually we're getting deeper into with my teams... It's not bad, but we're a data services group (data feeds and ETL) so it makes sense being incremental to work for us. To the person who said it's great for generating tech debit, that's when you inject stories or whole projects into the backlog to eliminate tech debit. Only works if you have management who is brave(?) enough to include them in the priority along with business items. It also helps to be the director in my case.

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.

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

Please make a video on scrum ... The way you describe how companies do it in the modern day, is 100% on point

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.

I used TDD Red Green Refactor. For me clean code is most useful on the Refactor. If you just do what ever it takes to make the test pass, I discover more and faster

I've long felt that being pragmatic about writing software, not trying to follow someone else's expectations about what the software should contain is the right way to develop. I feel the most important factors are can developers be productive (can they identify areas of change quickly, not repeat themselves and not worry about gotchas while moving the code base forward) in the code base on which they work. I think that every codebase, every team, every organization brings new challenges that mean it's not always practical to apply everything to, but it doesn't mean you shouldn't try and do some things.

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

Absolutely loved your reaction to Scrum! I agree please make a video.

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.